InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0028.txt

Text File | 1993-07-02 | 7.9 KB | 178 lines

The folks on the ietf-remmail seem quite interested in this issue, and I
gather it's on the future-wish-list for CMU & UW...

The real question is how to "synchronize" which bringing the client
state up to the server state (via expunges, flag changes, and new
messages) and sending client state to the server (flag changes and new
messages).  Here's a few ways this could be done:

* It should be doable with the current version of IMAP by fetching the
internal-date and flags for all the messages in a folder, and
comparing the server internal-dates with the client ones (at least
assuming that internal-dates are unique per-message).  This requires
no change to the server, but is a bit client/network intensive.

* adding a unique-id and last-flag-change-timestamp for each message
along with command(s) to update flags by unique-id and get the flag
changes since a given timestamp, would make things much easier but add
a bit of expense to the server and clutter to the protocol.

* adding a log of folder changes indexed by timestamp would allow a
one-command synchronize, but add quite a bit of storage and complexity
to the server.

Is any of this feasable, or should disconnected operation be left to
another protocol?

        - Chris Newman
        Computing Services, Carnegie Mellon University
From [e-mail]  Mon Oct 19 20:12:47 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA29533; Mon, 19 Oct 92 20:12:47 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA26358; Mon, 19 Oct 92 20:12:43 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from cyklop.nada.kth.se by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA26352; Mon, 19 Oct 92 20:12:40 -0700
Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0)
    id AA02940; Tue, 20 Oct 92 04:06:00 +0100
Message-Id: <[e-mail]>
To: Mark Crispin <[e-mail]>
Cc: IMAP Interest List <[e-mail]>,
        Nojima Hisao <[e-mail]>
Subject: Re: international character set support in IMAP2bis
In-Reply-To: <[e-mail]>
        from "Mark Crispin <[e-mail]> "
        "Mon, 19 Oct 1992 12:09:25 -0700 (PDT) "
Date: Tue, 20 Oct 92 04:05:58 +0100
From: Peter Svanberg <[e-mail]>

Quoting:  Mark Crispin <[e-mail]>
>
> However, I am considering one possibility to assist our foreign
> friends.  That is, to define that search strings are now in the
> proposed format used to express multinational characters in message
> headers.  I forget the exact RFC number

RFC 1342, Representation of Non-ASCII Text in Internet Message Headers

> I believe that if we define that the search strings use this format
> for specifying multinational characters, it will not introduce an
> incompatability.  The worst thing that would happen is that you
> would get a false negative when searching for texts in the message
> body if the IMAP server does not support that character set.

Will it be possible for the client to find out if a certain
character set is supported, or in any other way know when there is a
risk of false negatives?

> I would like to hear, particularly from my friends at NTT, if this
> would be helpful.  I think it is better than the current choices: no
> multinational search, or coercion the string into 7-bit ASCII and
> lots of false positives.

(I'm not from Japan, I'm from Sweden.) Yes, it would help us, if this
is what you meant:

1) The user types his search string as any other text, i.e. with
   eightbit characters.
2) The client encodes the user string into RFC1342 format and
   sends it to the server.
3) The server decodes it and compares it with (a decoded version
   of) the specified part of each letter.
---
Peter Svanberg, NADA, KTH            Email: [e-mail]
Dept of Num Analysis and Comp. Science,
Royal Institute of Technology            Phone: [phone]
S-100 44  Stockholm, SWEDEN            Fax:   [phone]
From [e-mail]  Tue Oct 20 11:38:22 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA13720; Tue, 20 Oct 92 11:38:22 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA03109; Tue, 20 Oct 92 11:38:06 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from Sun.COM by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA03103; Tue, 20 Oct 92 11:38:05 -0700
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
    id AA11485; Tue, 20 Oct 92 11:37:59 PDT
Received: from lassie.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
    id AA04210; Tue, 20 Oct 92 11:38:00 PDT
Received: from localhost by lassie.Eng.Sun.COM (4.1/SMI-4.1)
    id AA20081; Tue, 20 Oct 92 11:37:55 PDT
Message-Id: <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Disconnected Operation
In-Reply-To: Your message of "Mon, 19 Oct 92 22:11:19 EDT."
             <[e-mail]>
Date: Tue, 20 Oct 92 11:37:55 PDT
From: Don Jackson <[e-mail]>


>> The folks on the ietf-remmail seem quite interested in this issue, and I
>> gather it's on the future-wish-list for CMU & UW...

Karl Jacob and I have been thinking about disconnected operation here
at Sun also.

Our model is that some users are going to want to use a variety of
clients to read, process, and compose their email.  Users may wish to
use one client on the workstation/pc in their office at work, and
another client on their notebook/notepad/PDA portable computer.
Futhermore, there will be a variety of connection mechanisms:

    Direct LAN connection
    Dialup (PPP over V32bis)
    Two way wide area packet radio (like Mobitex and ARDIS)

and sometimes clients will be disconnected.  Disconnected clients
should be able to read messages they have previously downloaded,
delete, file, respond, and compose new messages.  Upon reconnection,
synchronization needs to happen.

For this model, there are two important new issues:

    Disconnected operation, with multiple clients a possibility.
    Very low speed/high latency connection between client and server
        (imagine 2400 baud, packets, with seconds of latency,
        with every byte you send/recieve costing you $0.0002)

>> The real question is how to "synchronize" which bringing the client
>> state up to the server state (via expunges, flag changes, and new
>> messages) and sending client state to the server (flag changes and new
>> messages).  Here's a few ways this could be done:
>>
>> * It should be doable with the current version of IMAP by fetching the
>> internal-date and flags for all the messages in a folder, and
>> comparing the server internal-dates with the client ones (at least
>> assuming that internal-dates are unique per-message).  This requires
>> no change to the server, but is a bit client/network intensive.

I'm more concerned with network traffic than client complexity.

>> * adding a unique-id and last-flag-change-timestamp for each message
>> along with command(s) to update flags by unique-id and get the flag
>> changes since a given timestamp, would make things much easier but add
>> a bit of expense to the server and clutter to the protocol.

This seems like the minimum support for disconnected operation.
If each message had a unique-id, would it still be necessary to refer
to message numbers?  I guess for compatibility you'd still want to use
message numbers....

>> * adding a log of folder changes indexed by timestamp would allow a
>> one-command synchronize, but add quite a bit of storage and complexity
>> to the server.

This is even beter.

>> Is any of this feasable, or should disconnected operation be left to
>> another protocol?

How independent of mail access is disconnected operation?  My initial
position is that I'd like to see them combined.