Subject: Re: SORT and multiple From:
From: Pete Resnick <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Date: Fri, 21 Dec 2001 10:44:26 -0600
List-Id: <ietf-imapext.imc.org>

On 12/21/01 at 3:11 PM +0100, Arnt Gulbrandsen wrote:

>AFAIK, there are so far two cases where header field order matters in the
>internet mail protocols: for "received:" and sometimes for "resent-*:".
>
>This sorting issue adds a third case. Unavoidably, as far as I can tell.
>Still, it makes me sad. Wish I could think of a way to avoid it.

It's not multiple From: header fields, it's multiple From: addresses 
in the same header field.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 21 Dec 2001 15:11:03 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Subject: Re: SORT and multiple From:
Sender: [email-masked]

AFAIK, there are so far two cases where header field order matters in the
internet mail protocols: for "received:" and sometimes for "resent-*:".

This sorting issue adds a third case. Unavoidably, as far as I can tell.
Still, it makes me sad. Wish I could think of a way to avoid it.

And a merry christmas to all of you.

--Arnt

Date: Wed, 19 Dec 2001 15:37:38 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: IMAPEXT minutes
Sender: [email-masked]

Here are the minutes I took at the IMAPEXT meeting.  If you feel I am 
missing anything or inaccurate on any point, please email me the 
corrections (feel free to CC to the list, but I need to get them in email).

If you wish to discuss any issues from the minutes, please change your 
subject line to one specific to the issue you're discussing.

		Thanks,
		- Chris

----
IMAP Extensions WG 2001-12-13 Salt Lake City IETF

9:00 - 11:30

ANNOTATE

three outstanding issues

1. Mirroring IMAP flags in annotations

If we do it we need to distinguish shared/private flags.  Some discussion 
of the issue.  If ANNOTATE gets widely deployed, the shared/private model 
is more useful.  But clients will have to implement support for old flags 
model in addition to ANNOTATE flags model.  People are willing to implement 
ANNOTATE flags and opposition is mostly in the "not worth it" camp.  Rough 
concensus based on hum at meeting to go ahead and add flags.

Shared vs. private flags.  Could advertise SHAREFLAGS and PRIVATEFLAGS, but 
is it worth it?  What happens if client stores shared deleted when server 
implements client deleted?  Needs to be documented clearly.

2. When should server issue unsolicited ANNOTATE responses?

Implicit after use of annotations, or explicit tag on SELECT/EXAMINE.

No strong feelings in either direction.  So let the author make the choice.

3. How to tie ACL rights to ANNOTATIONS?

If you have READ-ONLY access to a mailbox you can only change private 
annotations.  READ-WRITE means you can change both private and shared.

Discussion: are we requiring servers to implement both private and shared 
annotations?  Yes.

ACL: write access lets you set shared, read access lets you set private.

Also need to explicitly say that annotations must persist across sessions, 
exception for flags mapped to annotations which are listed in FLAGS but not 
in PERMANANTFLAGS.

We will do a WG last call on the next revision due Jan 15.

------
CONDITIONAL STORE

Major change: replaced MODTIME with MODSEQ.

Open Issues:
Need to synchronize with annotate document.  Do we need SORT for MODSEQ? 
People like to sort directories by date, so it would be useful.

If you do conditional store for a message set it's currently atomic, all 
stores succeed or fail.  No rough consensus either way for conditional 
store on message set.  Weak consensus to leave it atomic and get 
implementation experience.

Randy has volunteered to help with language in the draft.  We will do a WG 
last call on the next revision due Jan 15.
-----
ACLs

Proposal: "d" is a macro for two new rights: one for set deleted flag, one 
for delete folder.

Proposal: "anyone" and "$" prefix are non-users.  "-" is negative rights. 
All other identifiers are presumed to be users.  Could use "$$" prefix for 
user name
beginning "$".

We must have a new capability.  It is desirable for the new ACL to have a 
superset of the syntax of the old ACL. This way server implemented to new 
ACL should work with both old and new ACL clients.  Rough consensus.

Proposal: An additional capability to advertise semantics of ACLs if 
different from the union model.  Need to take this to the list.

We will solicit input on proposal.  Target is Feb 1st for ACL extension 
draft.
-----
LISTEXT

Issues with LISTEXT: doesn't do enough.

Needs more discussion on the list.

There is a proposal to add attribute-value pairs.
-----
Pete Action item: ask Mark to add i18n to SORT/THREAD

SORT on arbitrary headers is desirable.  Cyrus will post to list to add 
arbitrary headers.
-----
Pete Action item: ask Mark to last call the imapv draft.
-----
SNAP

Request to get review of SNAP (notifications) draft by IMAP community.

Date: Mon, 17 Dec 2001 17:26:34 -0800 (PST)
From: [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging
To: Pete Maclean <[email-masked]>
Cc: Larry Osterman <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > Um...  No, this NOT IMAP poking it's nose where it doesn't belong.  It's
> > a critical part of the design of the offline mode of IMAP.

> > IMAP clients depend on the fact that UIDs are assigned to messages that
> > are constant and are strictly increasing (note: NOT monotonically).  If
> > this constraint is violated, then a client does not have the ability to
> > resynchronize with the server.

And this condition may be satisfied by assigning UIDs to messages when
the IMAP server first encounters them. It may be impractical to assign them
at the time the messages are added to a given folder.

> We may be talking at cross purposes.  I believe I understand the role of
> UIDs perfectly and appreciate their enormous value in the overall IMAP
> design.  I was taking issue only with the question of exactly when they
> must be assigned.  I cannot see that it matters if a message is not
> assigned an IMAP UID if IMAP never sees that message.

Quite right.

> On the other hand, there are so many ways to interpret things that this may
> all be moot.  My IMAP server assigns UIDs to messages that don't have them
> when it opens a folder.  I tend to think of a message being added to a
> folder when a transport provider or client puts it there.  But we could say
> that a "MAPI folder" virtually becomes an "IMAP folder" when and only when
> the server opens it and, in that virtual sense, new messages are added and
> assigned UIDs only at that point.  In which case I am following this part
> of the spec to the letter.

Well, the messages really are there with no UIDs assigned, so I prefer
to think of it as assignment when the folder is first opened by IMAP.

				Ned

content-class: urn:content-classes:message
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Mon, 17 Dec 2001 17:23:45 -0800
From: "Larry Osterman" <[email-masked]>
To: "Pete Maclean" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Then you're right - we're talking at cross purposes - the "message is
assigned..." stuff I wrote was particular to the Exchange implementation
of IMAP.  The spec's comments are totally correct however from a
conceptual standpoint - and the wording is critical - there are many
ways a message can be added to a mailbox, and all of them assign new
UIDs.   

-----Original Message-----
From: Pete Maclean [mailto:[email-masked]] 
Sent: Monday, December 17, 2001 4:36 PM
To: Larry Osterman; Cyrus Daboo
Cc: [email-masked]; [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging

>Um...  No, this NOT IMAP poking it's nose where it doesn't belong.
It's
>a critical part of the design of the offline mode of IMAP.
>
>IMAP clients depend on the fact that UIDs are assigned to messages that
>are constant and are strictly increasing (note: NOT monotonically).  If
>this constraint is violated, then a client does not have the ability to
>resynchronize with the server.

We may be talking at cross purposes.  I believe I understand the role of

UIDs perfectly and appreciate their enormous value in the overall IMAP 
design.  I was taking issue only with the question of exactly when they 
must be assigned.  I cannot see that it matters if a message is not 
assigned an IMAP UID if IMAP never sees that message.

On the other hand, there are so many ways to interpret things that this
may 
all be moot.  My IMAP server assigns UIDs to messages that don't have
them 
when it opens a folder.  I tend to think of a message being added to a 
folder when a transport provider or client puts it there.  But we could
say 
that a "MAPI folder" virtually becomes an "IMAP folder" when and only
when 
the server opens it and, in that virtual sense, new messages are added
and 
assigned UIDs only at that point.  In which case I am following this
part 
of the spec to the letter.

Pete

Date: Mon, 17 Dec 2001 19:36:00 -0500
To: "Larry Osterman" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: RE: Some thoughts about IMAP and Unified Messaging
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

>Um...  No, this NOT IMAP poking it's nose where it doesn't belong.  It's
>a critical part of the design of the offline mode of IMAP.
>
>IMAP clients depend on the fact that UIDs are assigned to messages that
>are constant and are strictly increasing (note: NOT monotonically).  If
>this constraint is violated, then a client does not have the ability to
>resynchronize with the server.

We may be talking at cross purposes.  I believe I understand the role of 
UIDs perfectly and appreciate their enormous value in the overall IMAP 
design.  I was taking issue only with the question of exactly when they 
must be assigned.  I cannot see that it matters if a message is not 
assigned an IMAP UID if IMAP never sees that message.

On the other hand, there are so many ways to interpret things that this may 
all be moot.  My IMAP server assigns UIDs to messages that don't have them 
when it opens a folder.  I tend to think of a message being added to a 
folder when a transport provider or client puts it there.  But we could say 
that a "MAPI folder" virtually becomes an "IMAP folder" when and only when 
the server opens it and, in that virtual sense, new messages are added and 
assigned UIDs only at that point.  In which case I am following this part 
of the spec to the letter.

Pete

content-class: urn:content-classes:message
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Mon, 17 Dec 2001 16:18:16 -0800
From: "Larry Osterman" <[email-masked]>
To: "Pete Maclean" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Um...  No, this NOT IMAP poking it's nose where it doesn't belong.  It's
a critical part of the design of the offline mode of IMAP.

IMAP clients depend on the fact that UIDs are assigned to messages that
are constant and are strictly increasing (note: NOT monotonically).  If
this constraint is violated, then a client does not have the ability to
resynchronize with the server.  

Cyrus is right: It is an implementation detail of the Exchange server
that all messages in the folder must have a UID, in Exchange we have the
luxury of having code that runs when messages are delivered to users AND
when they are retrieved by IMAP, in a server that does not have that
luxury, they must assign UIDs at SELECT time, and must (as he said)
assign them to messages that have not yet had a UID assigned.  My smiley
was intended as a "Oh, right - I forgot to mention this really critical
detail" - sort of an "oops" similey :)

-----Original Message-----
From: Pete Maclean [mailto:[email-masked]] 
Sent: Monday, December 17, 2001 3:47 PM
To: Larry Osterman; Cyrus Daboo
Cc: [email-masked]; [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging

>Ah - you didn't catch one internal detail (and it's an important one
>:)):
>
>         If a message exists in a folder, it MUST have a UID.

Do you say this based on IMAP's assertion that "as each message is added
to 
the mailbox it is assigned a higher UID..."?  In my view, this is IMAP 
poking its nose in where it has no business being.  I hope I am not
missing 
anything, but I cannot see that it makes any difference if UIDs are 
assigned only when the IMAP server opens a folder. But you say this
detail 
is important, Larry, and I wonder why...or should I read your smiley as 
belying that?

>Any alternative imposes a significant penalty during the SELECT phase
of
>the mailbox.  In the current implementation for Exchange, select needs
>to modify one column in one row in the database (it needs to update the
>last selected UID property in the folder).  Since the UID's are
assigned
>when the messages are added to the folder, the SELECT command doesn't
>have to write to the messages table (ok, to be exact, the
message-folder
>table, but...).  If we were to to assign UIDs on select, every the row
>in the message-folder table for each new message would need to be
>rewritten - which could conceivably be several hundred database writes
>(if there are enough messages in the folder).  It's far better to take
a
>very small hit when adding messages (when you're already writing the
>message-folder table to add the message) then it is to modify the table
>after the message has been created.

No question but my method is far from ideal in terms of performance.
Maybe 
I could set a hook and issue UIDs as messages are added to folders --
and 
maybe I will at some future point -- but for now I am satisfied with
what I 
have.  Performance is less of an issue for me than for you.  You're
dealing 
with a heavy-duty server environment where there can be a large number
of 
simultaneous users.  My market is more shared and remote access to
Outlook 
often in the absence of Exchange.

Pete

Date: Mon, 17 Dec 2001 18:47:13 -0500
To: "Larry Osterman" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: RE: Some thoughts about IMAP and Unified Messaging
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

>Ah - you didn't catch one internal detail (and it's an important one
>:)):
>
>         If a message exists in a folder, it MUST have a UID.

Do you say this based on IMAP's assertion that "as each message is added to 
the mailbox it is assigned a higher UID..."?  In my view, this is IMAP 
poking its nose in where it has no business being.  I hope I am not missing 
anything, but I cannot see that it makes any difference if UIDs are 
assigned only when the IMAP server opens a folder. But you say this detail 
is important, Larry, and I wonder why...or should I read your smiley as 
belying that?

>Any alternative imposes a significant penalty during the SELECT phase of
>the mailbox.  In the current implementation for Exchange, select needs
>to modify one column in one row in the database (it needs to update the
>last selected UID property in the folder).  Since the UID's are assigned
>when the messages are added to the folder, the SELECT command doesn't
>have to write to the messages table (ok, to be exact, the message-folder
>table, but...).  If we were to to assign UIDs on select, every the row
>in the message-folder table for each new message would need to be
>rewritten - which could conceivably be several hundred database writes
>(if there are enough messages in the folder).  It's far better to take a
>very small hit when adding messages (when you're already writing the
>message-folder table to add the message) then it is to modify the table
>after the message has been created.

No question but my method is far from ideal in terms of performance.  Maybe 
I could set a hook and issue UIDs as messages are added to folders -- and 
maybe I will at some future point -- but for now I am satisfied with what I 
have.  Performance is less of an issue for me than for you.  You're dealing 
with a heavy-duty server environment where there can be a large number of 
simultaneous users.  My market is more shared and remote access to Outlook 
often in the absence of Exchange.

Pete

Date: Mon, 17 Dec 2001 17:47:17 -0500
From: Cyrus Daboo <[email-masked]>
To: Larry Osterman <[email-masked]>, Pete Maclean <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

--On Monday, December 17, 2001 2:37 PM -0800 Larry Osterman 
<[email-masked]> wrote:

> Ah - you didn't catch one internal detail (and it's an important one
> :)):
>
> 	If a message exists in a folder, it MUST have a UID.

But Pete said he manufactured his own UID for his IMAP server, so 
presumably his UID property on the message is not set until his server 
first 'sees' the message. At least that's what I thought he was doing.

-- 
Cyrus Daboo

content-class: urn:content-classes:message
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Mon, 17 Dec 2001 14:37:16 -0800
From: "Larry Osterman" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Pete Maclean" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Ah - you didn't catch one internal detail (and it's an important one
:)):

	If a message exists in a folder, it MUST have a UID.

Any alternative imposes a significant penalty during the SELECT phase of
the mailbox.  In the current implementation for Exchange, select needs
to modify one column in one row in the database (it needs to update the
last selected UID property in the folder).  Since the UID's are assigned
when the messages are added to the folder, the SELECT command doesn't
have to write to the messages table (ok, to be exact, the message-folder
table, but...).  If we were to to assign UIDs on select, every the row
in the message-folder table for each new message would need to be
rewritten - which could conceivably be several hundred database writes
(if there are enough messages in the folder).  It's far better to take a
very small hit when adding messages (when you're already writing the
message-folder table to add the message) then it is to modify the table
after the message has been created.

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]] 
Sent: Monday, December 17, 2001 2:16 PM
To: Pete Maclean; Larry Osterman
Cc: [email-masked]; [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging

--On Monday, December 17, 2001 4:57 PM -0500 Pete Maclean 
<[email-masked]> wrote:

>>   The \Recent flag should be manufactured on a MAPI server.   You
need
>> to remember the UID of the folder on the select verb, and check the
UID
>> of the message against the UID saved in the folder, if it's greater,
the
>> message is recent.  The nature of the \Recent flag is that it can
never
>> be preserved on the message (not if you want to get the correct
>> semantics in a multi-accessed mailbox situation).
>
> I do manufacture it but a little differently from the way you suggest.
> Since I also manufacture my own UIDs, I give a message a \Recent flag
if,
> when I find it, it is marked unread and has no UID assigned.

But that won't work for a copy or append of a seen message, right? 
Technically the \Recent flag should be set on those as well. I would
think 
that 'has no UID assigned' ought to be the only test you need to set 
\Recent.

-- 
Cyrus Daboo

Date: Mon, 17 Dec 2001 17:15:38 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Maclean <[email-masked]>, Larry Osterman <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

--On Monday, December 17, 2001 4:57 PM -0500 Pete Maclean 
<[email-masked]> wrote:

>>   The \Recent flag should be manufactured on a MAPI server.   You need
>> to remember the UID of the folder on the select verb, and check the UID
>> of the message against the UID saved in the folder, if it's greater, the
>> message is recent.  The nature of the \Recent flag is that it can never
>> be preserved on the message (not if you want to get the correct
>> semantics in a multi-accessed mailbox situation).
>
> I do manufacture it but a little differently from the way you suggest.
> Since I also manufacture my own UIDs, I give a message a \Recent flag if,
> when I find it, it is marked unread and has no UID assigned.

But that won't work for a copy or append of a seen message, right? 
Technically the \Recent flag should be set on those as well. I would think 
that 'has no UID assigned' ought to be the only test you need to set 
\Recent.

-- 
Cyrus Daboo

Date: Mon, 17 Dec 2001 16:57:27 -0500
To: "Larry Osterman" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: RE: Some thoughts about IMAP and Unified Messaging
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Larry,

Thank you so much for your message.

>   The \Recent flag should be manufactured on a MAPI server.   You need
>to remember the UID of the folder on the select verb, and check the UID
>of the message against the UID saved in the folder, if it's greater, the
>message is recent.  The nature of the \Recent flag is that it can never
>be preserved on the message (not if you want to get the correct
>semantics in a multi-accessed mailbox situation).

I do manufacture it but a little differently from the way you 
suggest.  Since I also manufacture my own UIDs, I give a message a \Recent 
flag if, when I find it, it is marked unread and has no UID assigned.

>And MAPI does demand that a folder have a display name, the CreateFolder
>method on the IMapiFolder object takes an LPTSTR lpszFolderName
>parameter.

Ah, good point.  This tempted me to go and delete the PR_DISPLAY_NAME for a 
folder to see what would happen...but at the last minute I chickened out.  :-)

>When you are generating the LIST response, you need to check if the
>entryid of the folder you're enumerating is the GetReceiveFolder's name,
>and return "INBOX" for the name of that folder (and not the value of
>PR_DISPLAY_NAME).  This is what the exchange server does internally, and
>it's what you should do too :)

Aha!  That's magnificent intelligence, thank you.  I had not been doing it 
this way because I had implemented a filter for this at a high level where 
nothing MAPIish is known.  But it will be fine to add the code that you 
suggest in addition.  Thank you, thank you.

Pete

Date: Mon, 17 Dec 2001 15:07:49 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Sender: [email-masked]

--On Monday, December 17, 2001 2:41 PM -0500 Pete Maclean 
<[email-masked]> wrote:

> Thanks for your comment.  I chose to deal with this issue by not listing
> the true name of the Inbox in such a case.  But you made me realize
> (thanks again!) that I have a bug.  I took care of CREATE okay but not
> RENAME.  If a user tried to rename a folder to the true name of his
> Inbox, the operation would fail all right but the reason given (that the
> folder already exists) could be misleading.

OK. I guess you also need to trap SELECT, DELETE, SUBSCRIBE and UNSUBSCRIBE 
attempts on that mailbox name too - in fact any command that takes a 
mailbox name as a parameter - there are some extensions that do that.

-- 
Cyrus Daboo

Date: Mon, 17 Dec 2001 14:48:09 -0500
To: Lyndon Nerenberg <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Lyndon,

Once again I am much obliged to you.  Many thanks for your gracious 
response.  And I apologize for assuming too much (or too little depending 
on how you look at it).

Pete

At 12:18 PM 12/17/2001 -0700, Lyndon Nerenberg wrote:
> > If my grasp of ACAP is correct (and please tell me if it is not) then the
> > answer is no.
>
>It's not ;-)
>
> > Not that the problem could not be solved with ACAP -- it
> > seems to me that it could -- but it does not seem an appropriate use of 
> the
> > service.  Would you expect an MUA to use ACAP to obtain a list of a user's
> > mail folders?  I don't think so.  And if that's not appropriate then, it
> > seems to me, that it does not fit the issue in question either.
>
>You don't store the list of mail folders in ACAP. Instead, you define
>an ACAP profile that you use to map from logical folder names (outbox,
>sent mail) to specific folders on specific servers. The profile would
>also contain a mapping from the logical folder name to a locale-specific
>presentation string for use by the MUA. In this way you have completely
>abstracted the logical folders from the implementation space. By using
>ACAP inheritance you can set a default logical folder namespace, and
>then override it on a per-server, per-clienthost, per-mua-type, and
>per-language basis (or via combinations of these).
>
>
>--lyndon
>
>Never hit a man with glasses.  Hit him with a baseball bat.

Date: Mon, 17 Dec 2001 14:41:22 -0500
To: Cyrus Daboo <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Hi Cyrus,

Thanks for your comment.  I chose to deal with this issue by not listing 
the true name of the Inbox in such a case.  But you made me realize (thanks 
again!) that I have a bug.  I took care of CREATE okay but not RENAME.  If 
a user tried to rename a folder to the true name of his Inbox, the 
operation would fail all right but the reason given (that the folder 
already exists) could be misleading.

Pete

At 01:29 PM 12/17/2001 -0500, Cyrus Daboo wrote:
>--On Monday, December 17, 2001 10:02 AM -0800 Mark Crispin 
><[email-masked]> wrote:
>
>>You seem to be distracted by the notion that the INBOX is sometimes
>>reachable by some other string on some systems.  That is a detail that is
>>of no importance whatsoever, thanks to the foresight of IMAP's design.
>
>Actually I have come acrosss cases where users are confused by having a 
>second mailbox in thier hierarchy which appears to be a duplicate of 
>INBOX. They usually don't appreciate that this is the INBOX but with a 
>different name. I don't know this actually happened, but one can conceive 
>of a situation where a confused user will delete and expunge all message 
>in the 'duplicate' mailbox because they believe they are duplicates and 
>not originals.
>
>IMHO The best solution in this case is to have the server not return the 
>duplicate name when asked to LIST of LSUB it. The server then has to 
>reject CREATE or RENAME's that try to use the duplicate name.
>
>--
>Cyrus Daboo

content-class: urn:content-classes:message
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Mon, 17 Dec 2001 11:36:39 -0800
From: "Larry Osterman" <[email-masked]>
To: "Pete Maclean" <[email-masked]>, "Tony Hansen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Pete,

  The \Recent flag should be manufactured on a MAPI server.   You need
to remember the UID of the folder on the select verb, and check the UID
of the message against the UID saved in the folder, if it's greater, the
message is recent.  The nature of the \Recent flag is that it can never
be preserved on the message (not if you want to get the correct
semantics in a multi-accessed mailbox situation).

And MAPI does demand that a folder have a display name, the CreateFolder
method on the IMapiFolder object takes an LPTSTR lpszFolderName
parameter.

When you are generating the LIST response, you need to check if the
entryid of the folder you're enumerating is the GetReceiveFolder's name,
and return "INBOX" for the name of that folder (and not the value of
PR_DISPLAY_NAME).  This is what the exchange server does internally, and
it's what you should do too :)

Larry Osterman 

-----Original Message-----
From: Pete Maclean [mailto:[email-masked]] 
Sent: Monday, December 17, 2001 9:44 AM
To: Tony Hansen
Cc: [email-masked]; [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging

>What's a "true name"? Consider that an IMAP inbox is a name for what is

>sometimes a virtual entity that doesn't have one single location on the

>server. So I find it difficult to expect this.

I don't have much experience with such situations but I certainly do 
appreciate that an inbox may not have a name in the sense I am talking 
about and that it could indeed be a totally virtual entity.  But what I 
mean by "true name" is, to put it very precisely, the name of the
message 
container that the IMAP server refers to as "INBOX" as it is known
within 
the domain of the mailstore that it is part of -- if there is in fact
such 
a container and if it actually has a name by which it is identified
within 
its mailstore.

Let me give a concrete example.  My IMAP server has a MAPI interface
among 
others.  (MAPI is Microsoft's Messaging API.)  This means that it can
serve 
up messages from any mailstore that implements a MAPI Store-Provider 
interface.  Everything in IMAP maps neatly into MAPI except that MAPI
has 
nothing equivalent to IMAP's \Recent flag (which does not matter).  I am

not certain off-hand if MAPI demands that all folders have names, but in

all cases I have seen they certainly do.  Now MAPI includes a method
called 
GetReceiveFolder that identifies the "default receive folder for the 
message store".  This does not exactly match IMAP's definition for inbox

but it's close enough that I have always assumed they should be
considered 
equivalent.  GetReceiveFolder returns an internal id from which one can 
then derive the folder's name.  I would like to be able to feed that
name 
back to the client.  Of course, as Lyndon pointed out so well, it should
be 
up to the client and/or the user to choose whether that name should 
actually be used in the client context, but it seems desirable that this

should at least be possible.

To concretize this issue a little more, with the English-language 
installation of Microsoft's Personal Folders, the folder identified by 
GetReceiveFolder is always "Inbox" -- so it happens to be no big 
deal.  With the German-language installation however the folder is named

"Posteingang".

Pete

Organization: ACI Worldwide - Advanced Technology Group
To: Pete Maclean <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Date: Mon, 17 Dec 2001 12:18:00 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> If my grasp of ACAP is correct (and please tell me if it is not) then the 
> answer is no.  

It's not ;-)

> Not that the problem could not be solved with ACAP -- it 
> seems to me that it could -- but it does not seem an appropriate use of the 
> service.  Would you expect an MUA to use ACAP to obtain a list of a user's 
> mail folders?  I don't think so.  And if that's not appropriate then, it 
> seems to me, that it does not fit the issue in question either.

You don't store the list of mail folders in ACAP. Instead, you define
an ACAP profile that you use to map from logical folder names (outbox,
sent mail) to specific folders on specific servers. The profile would
also contain a mapping from the logical folder name to a locale-specific
presentation string for use by the MUA. In this way you have completely
abstracted the logical folders from the implementation space. By using
ACAP inheritance you can set a default logical folder namespace, and
then override it on a per-server, per-clienthost, per-mua-type, and
per-language basis (or via combinations of these).

--lyndon

Never hit a man with glasses.  Hit him with a baseball bat.

Date: Mon, 17 Dec 2001 13:29:04 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Pete Maclean <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Sender: [email-masked]

--On Monday, December 17, 2001 10:02 AM -0800 Mark Crispin 
<[email-masked]> wrote:

> You seem to be distracted by the notion that the INBOX is sometimes
> reachable by some other string on some systems.  That is a detail that is
> of no importance whatsoever, thanks to the foresight of IMAP's design.

Actually I have come acrosss cases where users are confused by having a 
second mailbox in thier hierarchy which appears to be a duplicate of INBOX. 
They usually don't appreciate that this is the INBOX but with a different 
name. I don't know this actually happened, but one can conceive of a 
situation where a confused user will delete and expunge all message in the 
'duplicate' mailbox because they believe they are duplicates and not 
originals.

IMHO The best solution in this case is to have the server not return the 
duplicate name when asked to LIST of LSUB it. The server then has to reject 
CREATE or RENAME's that try to use the duplicate name.

-- 
Cyrus Daboo

Date: Mon, 17 Dec 2001 10:02:03 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging 
To: Pete Maclean <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 17 Dec 2001 10:48:03 -0500, Pete Maclean wrote:
> Do you not think that it is unfortunate,
> to say the least, that IMAP will faithfully and precisely deliver to an MUA
> a list of all of a user's folders (as long as they have compatible names)
> but will not identify the true name of what we generically call the Inbox,
> the folder that is surely the most important for many users, indeed a
> folder that the IMAP spec itself defines as "the primary mailbox for this
> user on this server"?

It is highly fortunate that IMAP will will identify the true name of the
INBOX.

We even know what IMAP will say:

INBOX

So, the client doesn't even have to ask the IMAP server what the name of the
INBOX is.  It knows because it's an IMAP client.

You seem to be distracted by the notion that the INBOX is sometimes reachable
by some other string on some systems.  That is a detail that is of no
importance whatsoever, thanks to the foresight of IMAP's design.

This is a Very Good Thing.

Date: Mon, 17 Dec 2001 12:43:56 -0500
To: Tony Hansen <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>What's a "true name"? Consider that an IMAP inbox is a name for what is
>sometimes a virtual entity that doesn't have one single location on the
>server. So I find it difficult to expect this.

I don't have much experience with such situations but I certainly do 
appreciate that an inbox may not have a name in the sense I am talking 
about and that it could indeed be a totally virtual entity.  But what I 
mean by "true name" is, to put it very precisely, the name of the message 
container that the IMAP server refers to as "INBOX" as it is known within 
the domain of the mailstore that it is part of -- if there is in fact such 
a container and if it actually has a name by which it is identified within 
its mailstore.

Let me give a concrete example.  My IMAP server has a MAPI interface among 
others.  (MAPI is Microsoft's Messaging API.)  This means that it can serve 
up messages from any mailstore that implements a MAPI Store-Provider 
interface.  Everything in IMAP maps neatly into MAPI except that MAPI has 
nothing equivalent to IMAP's \Recent flag (which does not matter).  I am 
not certain off-hand if MAPI demands that all folders have names, but in 
all cases I have seen they certainly do.  Now MAPI includes a method called 
GetReceiveFolder that identifies the "default receive folder for the 
message store".  This does not exactly match IMAP's definition for inbox 
but it's close enough that I have always assumed they should be considered 
equivalent.  GetReceiveFolder returns an internal id from which one can 
then derive the folder's name.  I would like to be able to feed that name 
back to the client.  Of course, as Lyndon pointed out so well, it should be 
up to the client and/or the user to choose whether that name should 
actually be used in the client context, but it seems desirable that this 
should at least be possible.

To concretize this issue a little more, with the English-language 
installation of Microsoft's Personal Folders, the folder identified by 
GetReceiveFolder is always "Inbox" -- so it happens to be no big 
deal.  With the German-language installation however the folder is named 
"Posteingang".

Pete

Date: Mon, 17 Dec 2001 11:59:18 -0500
From: Tony Hansen <[email-masked]>
To: Pete Maclean <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

Pete Maclean wrote:
> 
> Let me put it as simply as I can:  Do you not think that it is unfortunate,
> to say the least, that IMAP will faithfully and precisely deliver to an MUA
> a list of all of a user's folders (as long as they have compatible names)
> but will not identify the true name of what we generically call the Inbox,
> the folder that is surely the most important for many users, indeed a
> folder that the IMAP spec itself defines as "the primary mailbox for this
> user on this server"?

What's a "true name"? Consider that an IMAP inbox is a name for what is
sometimes a virtual entity that doesn't have one single location on the
server. So I find it difficult to expect this.

	Tony Hansen
	[email-masked]

Date: Mon, 17 Dec 2001 10:48:03 -0500
To: Lyndon Nerenberg <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Lyndon,

> > This approach means we don't have to English-ize names and gets
> > around the problem of Outbox meaning two different things.  The server
> > would respond with either the appropriate name or an indication that there
> > is no such thing.
>
>Wouldn't these be better solved with ACAP or IMSP?

I responded to this briefly before by saying I knew too little about ACAP 
or IMSP to judge.  I have now read up on ACAP and wish to respond more fully.

If my grasp of ACAP is correct (and please tell me if it is not) then the 
answer is no.  Not that the problem could not be solved with ACAP -- it 
seems to me that it could -- but it does not seem an appropriate use of the 
service.  Would you expect an MUA to use ACAP to obtain a list of a user's 
mail folders?  I don't think so.  And if that's not appropriate then, it 
seems to me, that it does not fit the issue in question either.

I am puzzled by the responses to what I have posted.  I am unclear if most 
people agree with me, or if I have not explained my ideas well enough, or 
what.  The ACAP question suggests to me that I have not been clear 
enough.  To me it seems a glaringly obvious flaw.

Let me put it as simply as I can:  Do you not think that it is unfortunate, 
to say the least, that IMAP will faithfully and precisely deliver to an MUA 
a list of all of a user's folders (as long as they have compatible names) 
but will not identify the true name of what we generically call the Inbox, 
the folder that is surely the most important for many users, indeed a 
folder that the IMAP spec itself defines as "the primary mailbox for this 
user on this server"?

Pete

Date: Fri, 14 Dec 2001 06:42:09 -0800
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: The IMC web page
Sender: [email-masked]

Paul Hoffman has asked me to have you all look at the IMC IMAPEXT web 
page at <http://www.imc.org/ietf-imapext/index.html> and e-mail him 
(or me if you prefer) if things are outdated, incorrect, or missing. 
I've already see a few, but if you would go look for your own 
document, that would be quite helpful.

Thanks.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 14 Dec 2001 10:39:52 -0500
From: Tony Hansen <[email-masked]>
To: imapext <[email-masked]>, vpim <[email-masked]>
Subject: Re: [VPIM] re: SORT and arbitrary headers
Sender: [email-masked]

Cyrus Daboo wrote:
> --On Thursday, December 13, 2001 1:43 PM -0800 Mark Crispin
> <[email-masked]> wrote:
> 
> I would say its 50-50 use between sort and thread. I know personally there
> are mailboxes I prefer to view by thread and ones I prefer to view sorted -
> just depends on the nature of the content. 

Me too. My default on some mailboxes is thread, and others sort by date,
and others sort by sender, and others .... However, I also switch around
from one sort method to another, depending on what I'm trying to do with
the messages. Each of the sorting methods and threading has their uses
in different circumstances.

> There are also situations where
> I want to do a sort within thread.

ditto.

	Tony Hansen
	[email-masked]

P.S. I thought I was going to add lots to the debate, but it looks like
I wound up with just another "me too" message. :-)

Date: Fri, 14 Dec 2001 01:41:08 -0500
From: Tony Hansen <[email-masked]>
To: Steve Hole <[email-masked]>
CC: Pete Maclean <[email-masked]>, John Neystadt <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

Steve Hole wrote:
> 
> On Thu, 13 Dec 2001 10:32:16 -0500 Pete Maclean <[email-masked]>
> wrote:
> ...
> > For me, however, the ideal solution would be different
> > from what John proposes.  What I would like to see is a command that
> > essentially asks "what is the name of the message container that serves
> > function X" where X could express, for example, "is the default repository
> > for newly delivered messages" or "holds messages that have been
> > deleted".
> 
> There is such a mechanism -- the canonical name INBOX.   The client is
> absolutely free to map this however they choose.

Steve, Pete meant it more generically than just inbox. He also wants X
for other things such as "deleted messages" (his words above), "draft
messages", "sent messages", etc.

	Tony Hansen
	[email-masked]

Date: Thu, 13 Dec 2001 19:24:33 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: use for SORT
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

To answer why SORT is useful, given the presence of THREAD, vs. doing it on
the client.

SORT and THREAD are both useful when the client does not have knowledge of the
data needed to do the SORT.  They are big wins with online clients.  Or, put
another way, these command mark the difference between usability and
unusability of those functionalities in online clients.

Disconnected and offline clients probably have little, if any, need for SORT
or THREAD because they can do it on the client.

Organization: ACI Worldwide - Advanced Technology Group
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: SORT and arbitrary headers 
Date: Thu, 13 Dec 2001 20:02:20 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> >> Personally, I don't see much utility in SORT.
> By that same argument, you can say that there is no utility to THREAD 

I chose my words carefully ;-)  I said "not much," not "no."

> I would say its 50-50 use between sort and thread. I know personally there 
> are mailboxes I prefer to view by thread and ones I prefer to view sorted - 
> just depends on the nature of the content. There are also situations where 
> I want to do a sort within thread.

My question is whether the complexity of SORT (vs. doing it on the
client) is justified in the presence of THREAD. There is definately a
tradeoff here, and there is no clear-cut winner.  I think what I'm
looking for is a good example of where SORT+THREAD obviously wins over
THREAD plus client sort. (IOW, I just can't think of one, but I've
been dense before :-)

--lyndon

Date: Thu, 13 Dec 2001 16:30:16 -0700
From: Cyrus Daboo <[email-masked]>
To: Jutta Degener <[email-masked]>
cc: [email-masked]
Subject: Re: More SORT keys
Sender: [email-masked]

--On Thursday, December 13, 2001 3:12 PM -0800 Jutta Degener 
<[email-masked]> wrote:

> Maybe, rather than defining an specific extended feature set associated
> with a SORT2 capability, we could do something along the lines of a
> SORT=FOO,BAR,BAZ capability?
>
> Then new drafts that only define specific sorting rules can define SORT
> capabilities (e.g., "MESSAGEHINT") that a server can announce without
> requiring an update to SORT itself.
>
> Just an idea.

I think that would be a fine solution. The question is whether this group 
would want to define any of these now, or simply require the the current 
sort document to indicate that this extensibility is possible.

-- 
Cyrus Daboo

Date: Thu, 13 Dec 2001 15:12:05 -0800
From: Jutta Degener <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: More SORT keys
Sender: [email-masked]

On Thu, Dec 13, 2001 at 02:40:21PM -0700, Cyrus Daboo wrote:
> Comments?

Maybe, rather than defining an specific extended feature set associated with
a SORT2 capability, we could do something along the lines of a SORT=FOO,BAR,BAZ
capability?

Then new drafts that only define specific sorting rules can define SORT
capabilities (e.g., "MESSAGEHINT") that a server can announce without
requiring an update to SORT itself.

Just an idea.

Jutta <[email-masked]>

Date: Thu, 13 Dec 2001 14:34:56 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: More SORT keys
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

Here are the arguments for the counter-proposal (do SORT only, not SORT2):

1) General HEADER sorting does not scale, since it requires knowledge of the
   syntax of the header to do comparisons correctly.

2) Flag sorting is of questionable utility.  A single key flag sort is better
   done using SEARCH.  One in which the flag comes first can be done with two
   SORTs with only a single RTT cost; "SORT (FLAGGED SUBJECT) UTF-8 ALL" can
   be done as "SORT (SUBJECT) UTF-8 FLAGGED" followed by "SORT (SUBJECT) UTF-8
   UNFLAGGED".  One in which the flag comes last only matters when the
   previous key comparisons match as equality; judicious use of fetching
   (which has to be done anyway in painting the view) can largely eliminate
   this.  The real use for flag sorting is when sorting by multiple flags,
   e.g. SORT (FLAGGED ANSWERED).

Flag sorting certainly should be in SORT2, since it's harmless and is a (very)
minor functionality addition.  But it does not justify creating a SORT2.  For
SORT2 to happen, it needs to have a stronger basis.

I oppose any wording in the SORT document that requires the implementation of
SORT2.  If SORT2 happens, it should stand or fall on its own.

The only reason to want the SORT document to require SORT2 functionality is a
worry that nobody will implement SORT2 otherwise.  That is a legitimate
concern; but if SORT2 can't justify its existance on its own it deserves to
die.  The market can be cruel to good ideas that just aren't good enough.

The challenge for the advocates of SORT2 is to come up with a compelling
reason why SORT2 should be widely implemented, such that no implementor can
afford to ignore it.

Date: Thu, 13 Dec 2001 15:30:59 -0700
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Lyndon Nerenberg <[email-masked]>
cc: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Subject: re: SORT and arbitrary headers
Sender: [email-masked]

--On Thursday, December 13, 2001 1:43 PM -0800 Mark Crispin 
<[email-masked]> wrote:

>> Personally, I don't see much utility in SORT. I think that >99% of its
>> actual use will be as a poor substitute for what THREAD does.
>> Everything else SORT does can be done on the client side using the
>> results from FETCH ENVELOPE. (More accurately, I don't think SORT
>> can justify itself in the presence of THREAD.)

By that same argument, you can say that there is no utility to THREAD 
because threading can be done on the client too (you just need to do a 
fetch for References headers as well as envelope).

> I won't go that far; there is a limited set of circumstances in which
> SORT is useful.  Pine does put SORT to good use.  But Pine also uses
> THREAD, and it seems that more and more people are turning to threading
> rather than sorting.
>
> But I agree with the overall sentiment.  THREAD, not SORT, is the
> interesting extension.  It is incomprehensible to me why people want to
> waste incredible amounts of time on SORT extensions, VIEW, etc., which
> are all meaningless for THREAD.

I would say its 50-50 use between sort and thread. I know personally there 
are mailboxes I prefer to view by thread and ones I prefer to view sorted - 
just depends on the nature of the content. There are also situations where 
I want to do a sort within thread.

-- 
Cyrus Daboo

Date: Thu, 13 Dec 2001 14:40:21 -0700
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More SORT keys
Sender: [email-masked]

There was interest in imap-ext today in having more sort keys available in 
the sort extension. I was tasked with bringing this to the list.

Currently SORT has the following keys defined:

"ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" / "SUBJECT" / "TO"

There is interest in having a general "HEADER" key that takes the name of a 
header as an argument. I would also like to see sorting by flag/keyword - 
flag state being a 'column' that is frequently displayed by clients to 
users and something it is useful to sort by. There maybe other keys that 
people would like to see. There is a big question about how comparisons on 
arbitrary headers should be done. I think we will likely end up with a 
comparator operator to implment i18n support, and it will be possible to 
define custom comparitors for custom format header fields as required - but 
this should be a part of the i18n solution. For the time being a straight 
ascii compare as done for SUBJECT right now wuld have to be used.

Since adding new keys breaks backwards compatibility with existing deployed 
SORT clients and servers, we would have to do this via a new capability, 
say SORT2. The proposal is to add this to the current sort draft, requiring 
servers that use the new draft to advertise both SORT and SORT2 
capabilities, with an appendix explaining which keys were only defined in 
SORT.

Comments?

-- 
Cyrus Daboo

Date: Thu, 13 Dec 2001 17:04:50 -0500
To: Lyndon Nerenberg <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Cc: Steve Hole <[email-masked]>, John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 12:50 PM 12/13/2001 -0700, Lyndon Nerenberg wrote:
> > >client issue.   Localization / personalization of the INBOX is an client
> > >issue and MUST be dealt with there.
> >
> > Why must it be dealt with in the client?  Sorry, I am not trying to be
> > difficult; I really want to understand.  Sure, clients could be made
> > configurable so that a user could name his INBOX anything he chooses.  But
> > why when that could be centralized at the server?
>
>Because this presumes a one-to-one mapping between individuals
>and INBOXes. Imagine a single account shared by several hundred
>people on, say, a support desk. Because you have customers around
>the globe you have support staff fluent in several languages.
>So, of those (say) 50 languages spoken by your support staff
>sharing this INBOX, which one wins the name-INBOX-on-the-server
>contest? (Hint: I hope both you and your MUA can handle Mandarin.)

Aha!  Got it.  Thank you, thank you.

Pete

Date: Thu, 13 Dec 2001 13:43:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: SORT and arbitrary headers
To: Lyndon Nerenberg <[email-masked]>
cc: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 14:36:53 -0700, Lyndon Nerenberg wrote:
> Personally, I don't see much utility in SORT. I think that >99% of its
> actual use will be as a poor substitute for what THREAD does.
> Everything else SORT does can be done on the client side using the
> results from FETCH ENVELOPE. (More accurately, I don't think SORT
> can justify itself in the presence of THREAD.)

I won't go that far; there is a limited set of circumstances in which SORT is
useful.  Pine does put SORT to good use.  But Pine also uses THREAD, and it
seems that more and more people are turning to threading rather than sorting.

But I agree with the overall sentiment.  THREAD, not SORT, is the interesting
extension.  It is incomprehensible to me why people want to waste incredible
amounts of time on SORT extensions, VIEW, etc., which are all meaningless for
THREAD.

Organization: ACI Worldwide - Advanced Technology Group
To: "Neystadt, John" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: SORT and arbitrary headers
Date: Thu, 13 Dec 2001 14:36:53 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> C: A283 SORT (Message-Context SUBJECT) UTF-8 SINCE 1-Feb-1994
> 
> B) Since th list of well-known-header changes rapidly, specify in the RFC a
> list of headers that must be supported. 

This doesn't scale, because ...

> Of course I think that
> Message-Context should be one of them.

and the next person or RFC will want their header added. This will
require a re-specification of SORT, since existing implementations
will not interoperate with the new requests. This would result in the
SORT, SORT2, SORT3, SORT4, ..., SORTn extensions.

Clients that want to sort on arbitrary headers can already do so using
existing protocol mechanisms.  Since this is an unbounded problem,
it's also the only sane way to do it.  And for clients that implement
private header extensions, it's the only way they *can* do it.

Personally, I don't see much utility in SORT. I think that >99% of its
actual use will be as a poor substitute for what THREAD does.
Everything else SORT does can be done on the client side using the
results from FETCH ENVELOPE. (More accurately, I don't think SORT
can justify itself in the presence of THREAD.)

--lyndon

Date: Thu, 13 Dec 2001 13:18:51 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: SORT and multiple From:
To: Lyndon Nerenberg <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 14:15:17 -0700, Lyndon Nerenberg wrote:
> I notice that the -07 draft assumes there will be only one
> From address:
> while RFC2822 allows for more than one.

Wow.  So they fixed that bug in RFC 2822.  I didn't know that.  Good.

You'll notice that IMAP got it right.

> Should FROM not follow
> the behaviour of CC and TO? I.e.
>       FROM
>          RFC-822 local-part of the first "From" address.
>                                    ^^^^^

Yes, and I will fix this in -08.  Thank you!

To: [email-masked]
Subject: SORT and multiple From:
Organization: ACI Worldwide - Advanced Technology Group
Date: Thu, 13 Dec 2001 14:15:17 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

I notice that the -07 draft assumes there will be only one
>From address:

      FROM
         RFC-822 local-part of the "From" address.

while RFC2822 allows for more than one. Should FROM not follow
the behaviour of CC and TO? I.e.

      FROM
         RFC-822 local-part of the first "From" address.
                                   ^^^^^

--lyndon

Organization: ACI Worldwide - Advanced Technology Group
To: Pete Maclean <[email-masked]>
cc: Steve Hole <[email-masked]>, John Neystadt <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 12:50:48 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> >client issue.   Localization / personalization of the INBOX is an client
> >issue and MUST be dealt with there.
> 
> Why must it be dealt with in the client?  Sorry, I am not trying to be 
> difficult; I really want to understand.  Sure, clients could be made 
> configurable so that a user could name his INBOX anything he chooses.  But 
> why when that could be centralized at the server?

Because this presumes a one-to-one mapping between individuals
and INBOXes. Imagine a single account shared by several hundred
people on, say, a support desk. Because you have customers around
the globe you have support staff fluent in several languages.
So, of those (say) 50 languages spoken by your support staff
sharing this INBOX, which one wins the name-INBOX-on-the-server
contest? (Hint: I hope both you and your MUA can handle Mandarin.)

INBOX represents a specific entity on the IMAP server: the canonical
location where you can expect newly arrived mail to show up. The
label is arbitrary. We could have named it as an ASN-encoded OID
for that matter. Either way, how that *entity* is displayed to the
user is up to the MUA. The only purpose for giving it a (any) label
at all on the server is to allow it to be uniquely addressed.

--lyndon

Date: Thu, 13 Dec 2001 11:33:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
To: Steve Hole <[email-masked]>
cc: "Rubinstein, Dmitry" <[email-masked]>, "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 12:11:17 -0700, Steve Hole wrote:
> In short, having done it, the argument that it is too difficult to manage
> sequence numbers and UID's is simply ludicrous.

Unfortunately, too many people follow the logical trail of
   "it's difficult for me to figure it out"
-> "it's too difficult for anybody to figure it out"
-> "servers can do all this other stuff that IMAP requires, so there's no such
    thing as something that is difficult for a server"
-> "we should add a new protocol feature so the server does it and I don't
    have to figure it out"

From: Steve Hole <[email-masked]>
Date: Thu, 13 Dec 2001 12:11:17 -0700
To: "Rubinstein, Dmitry" <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Cc: "'Mark Crispin'" <[email-masked]>, "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 20:15:29 +0200 "Rubinstein, Dmitry" 
<[email-masked]> wrote:

> In fact, support for unsolicited events (especially EXPUNGE) is, from my
> expirience, the most non-trivial part of implementing an IMAP software.
> So if anything would make the implementation of IMAP available to the 
> mortals is this extension. Now that I think about it, the fact that this
> feature is not present in IMAP from the beginning looks
> like an overlook more than anything else.

Oh my!

The code to do exactly this is freely available in the uwash c-client.   
It is not exactly the way that we did it, but it certainly gives you the 
idea.   And, no disrespect intended, it isn't that hard.   It's an array.
You know how big to make the array.   You can certainly put a little 
structure into it.   You might have to worry about how big the array gets 
in a segmented memory architecture.   You might have to build a list of 
them.   The code to manage this in the c-client is about 500 lines soaking
wet.   Ours is about double that, but that is because cache management is 
bound with our asynchrous event notification and io completion 
notification framework.   That is a more advanced architecture that most 
GUI applications would be well served to try to use.  

Note that this stuff ran successfully in Mac v5 and Windows 3.1 on 
machines that were not too far off in terms of memory constraints and 
management from modern PDA devices.

In short, having done it, the argument that it is too difficult to manage 
sequence numbers and UID's is simply ludicrous.   There are some 
extensions that would require servers to maintain more state information 
for resynchronization purposes that would make synchronizing clients more 
bandwidth and storage efficient -- a 
"report-changes-since-last-checkpoint" type function.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 13 Dec 2001 10:51:07 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
To: Steve Hole <[email-masked]>
cc: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

I want my Saved Messages mailbox to have a Japanese language name using the
Japanese script.  I demand that every client in the world be fixed immediately
to display that name correctly.  By tommorrow.

No, I really don't.

I'm just trying to point out the flaw in the presumption that this can be
fobbed off on the server without any work on the client.  We can't assume that
all the world is Unicode and everybody has full fonts and drawing algorithms
for all the world's languages.  Not yet, anyway.

Even then, I can think of different ways that an otherwise-identical concept
mailbox is used; and how those ways impact data in incompatible ways.  Drafts
are an excellent example.

From: Steve Hole <[email-masked]>
Date: Thu, 13 Dec 2001 11:48:46 -0700
To: "Neystadt, John" <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Cc: "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 13:46:34 +0200 "Neystadt, John" <[email-masked]> 
wrote:

> > > 5. IMAP: Add support for IDLE of multiple folders
> 
> Well, you basically say - it is a client problem. Opening tens of
> connections for tens of visible mailboxes seems to me impractical and will
> severe damage server scalability. With my proposal, server can have a
> special optimized provisions (like subscribe for file system changes
> notifications) and it will be much more efficiently. 

No it won't.   If opening lots of connections impacts server scalability, 
then your server isn't very vertically scalable.   Our server routinely 
handles many 10's of thousands of connections on a single server.   You 
need to think about how you do that, but that is a lot easier engineering 
than thinking about how to reorganize the protocol semantics to support 
multiple mailbox selected state semantics.

Frankly, if you don't think about how to properly handle large numbers of 
TCP connections on NT servers, you have a serious scalability problem 
anyway. Fix it in one place and you fix it in all places.

> Well, INBOX name is a part of IMAP standard. Sent Items is a paradigm used
> by all MUAs on all OSes, so ignoring it is impractical. Other folders are
> more controversial. However I think it is better to standardize
> controversial names as recommendation, since there is no harm for those MUAs
> who don't use it.

Our client has provided a means for the user to select the names of the
folders that they will use for various purposes like draft storage, sent 
items, outbox, etc. and we ship with a default configuration that will 
recommend folder names for this purpose.   If the user doesn't like our 
names, they can change them.   If the organization wants to use a 
different set of defaults, they can change them.   If the user wants to 
coordinate with the names used by some other client, then they can change 
them.   No big deal actually.   I will note that after we allowed for 
customization, we never got a single trouble report on the matter.

The problem comes when client writers try to mandate the names used for 
such purposes.   Stupid design decision I think.   We could never get our 
own customer base to agree on a set of names, much less agree with another
client vendor.   It gets about a million times worse as soon as you deploy
internationally.   Bottom line is that you can make recommendations here, 
but you really can't enforce it.   And, if you pick this as the hill to 
die on ... you will die on it.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 13 Dec 2001 13:43:34 -0500
To: Steve Hole <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging
Cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > As an IMAP server developer, the one enhancement I would most like to see
> > made to IMAP is something to address this issue.  I have to deal with 
> users
> > who have what IMAP refers to as "Inbox" actually named "In", "Incoming",
> > "Posteingang", etc.
>
>You're confused :-)

That's not unusual :-)

>This is not a server or protocol issue.   This is a
>client issue.   Localization / personalization of the INBOX is an client
>issue and MUST be dealt with there.

Why must it be dealt with in the client?  Sorry, I am not trying to be 
difficult; I really want to understand.  Sure, clients could be made 
configurable so that a user could name his INBOX anything he chooses.  But 
why when that could be centralized at the server?  This is especially 
significant for transient use of clients such as when someone pops into an 
Internet cafe they'll visit only once in their lives to check their mail.

What if a user regularly uses several different clients that use different 
names for we are referring to as INBOX?  Why should he have to deal with 
"Incoming" here, "In" there, and "Inbox" somewhere else?

Please understand that I am not making a fuss about this because I think 
it's a big deal -- I don't think it's a big deal at all.  It's just that I 
think that if any changes are made to IMAP related to folder naming then I 
think it would be terrible to miss the opportunity to improve this situation.

>There is such a mechanism -- the canonical name INBOX.   The client is
>absolutely free to map this however they choose.

Exactly my point.  I want the *user* to be absolutely free to map this, 
independently of any client.

Cheers,

Pete

From: Steve Hole <[email-masked]>
Date: Thu, 13 Dec 2001 11:33:43 -0700
To: John Neystadt <[email-masked]>
Subject: Re: [VPIM] Some thoughts about IMAP and Unified Messaging
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Wed, 12 Dec 2001 22:05:16 +0200 John Neystadt <[email-masked]> wrote:

> Hi!
> 

> 2. IMAP: Add support for UIDs in unsolicited events
> 
> Currently unsolicited events in IMAP return Sequence ids of messages. This
> requires User-Agent to query server upon receiving unsolicited event for
> whole message list if it did not yet fetched list of all messages. Supplying
> UIDs will allow server to fetch information only the message that has
> changed and reflect it in UI.

No it doesn't.   It requires that you keep a message sequence number to 
UID map in your client cache.   You may have to go and fetch information 
about the messages identified in the unsolicited response in order 
to do something useful with the notification, but you can always 
choose to ignore it as well.   

Clients SHOULD implement sequence number to UID maps anyway.  Much of the 
conversation about sort and thread would have been greatly eased if 
everyone supported use of sequence numbers in the first place.   After 
all, sorting and threading are ordering operations. 

I will say this.   The number one issue (with a bullet) for a competent 
IMAP client is thinking about cache management strategies.   If your 
caching strategy has the problem that you describe above, then you need to 
think about it more.

> 7. Add support of two new system IMAP flags - to mark messages with \Spam
> and \Adult content.
> 
> Today SMTP-MTAs often support SPAM and Adult content filtering. Not always
> it is possible to remove a message with wrong content, since sometimes a
> doubt exist regarding the correctness of the identification. By marking the
> message in doubt with system-flag, it will allow User-Agents to process such
> messages differently (i.e. color them or put in special folder).

These do not need to be system flags.   Put them in the $ namespace the 
same way as MDNSent was done.   I am, in fact, guilty of proposing the 
/Draft flag and have come to regret it.   There really is nothing 
different about user flags and system flags except that system flags are 
mandatory to implement.   Why should these be mandatory to implement.   
Write a draft defining the conventional use of these flags and call it a 
day.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 13 Dec 2001 13:26:49 -0500
To: Lyndon Nerenberg <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> >  I have to deal with users
> > who have what IMAP refers to as "Inbox" actually named "In", "Incoming",
> > "Posteingang", etc.
>
>Are you talking about the MUA localizing the folder "INBOX" to
>a local representation? If so, why would this affect the server?
>If not, maybe you could explain a bit more clearly what you mean
>here.

Sorry I was not clear.  I was referring to rather the opposite, to the 
server un-localizing, as it were, the incoming-mail folder on the server 
end.  As things stand, if this folder is not called "INBOX" in the 
mailstore then the IMAP server must map between the mailstore's name for it 
(e.g. "Posteingang") and the protocol's name for it ("Inbox").  This leads 
to the minor problem that a user who has an incoming-mail folder named 
other than "Inbox" cannot have another folder which s/he chooses to name 
"Inbox".

Let me give an example to illustrate the advantage of an MUA's being able 
to determine folder names according to function.  Suppose a German fellow 
keeps his mail on a computer in Germany and that in the mailstore concerned 
his incoming-mail folder is called "Posteingang".  Now let's suppose that 
he makes a visit to Britain and wants to read his mail using an 
English-language client because that happens to be the only convenient 
option.  If my idea were implemented in both client and server, then the 
client could give him the option of referring to his incoming-mail folder 
in the local language ("Inbox" or something similar) or using the native 
name ("Posteingang") which the client would retrieve from the server. Our 
German would see his chosen (presumably German-language) names for all his 
other folders; why should he be forced to see one particular folder named 
in English?  The other side of this illustration is that an American, say, 
on sabbatical in Germany could get an email account on the same server and, 
using his customary English-language client, see his incoming-mail folder 
named as he expects it.  He would never need to know that it was actually 
known as "Posteingang" on the server's side.

> > For me, however, the ideal solution would be different
> > from what John proposes.  What I would like to see is a command that
> > essentially asks "what is the name of the message container that serves
> > function X" where X could express, for example, "is the default repository
> > for newly delivered messages"
>
>By definition: INBOX.

Ah, yes, but that's by definition of the protocol.  And that's not bad; but 
it is limiting.  And, for the reasons laid out above, I would like to get 
away from it.  My point is that, if we want to distinguish folders other 
than Inbox, then I wish we could do so by function rather than by name 
because that offers a lot more flexibility for users.  If implemented well, 
it would also be more open-ended in that we could allow user-extensible 
functions (i.e. X-functions).

> > or "holds messages that have been
> > deleted".
>
>*Every* folder holds \Deleted messages, again by definition.

Yes, but again just by IMAP definition!  And there are many other 
definitions of deleted messages.

> > This approach means we don't have to English-ize names and gets
> > around the problem of Outbox meaning two different things.  The server
> > would respond with either the appropriate name or an indication that there
> > is no such thing.
>
>Wouldn't these be better solved with ACAP or IMSP?

I am not familiar enough with ACAP or IMSP to competently answer this.  I 
may research them so that I can get some perspective.  Thank you.

Pete

From: Steve Hole <[email-masked]>
Date: Thu, 13 Dec 2001 11:13:13 -0700
To: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging
Cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 10:32:16 -0500 Pete Maclean <[email-masked]> 
wrote:

> As an IMAP server developer, the one enhancement I would most like to see 
> made to IMAP is something to address this issue.  I have to deal with users 
> who have what IMAP refers to as "Inbox" actually named "In", "Incoming", 
> "Posteingang", etc.  

You're confused :-)   This is not a server or protocol issue.   This is a 
client issue.   Localization / personalization of the INBOX is an client 
issue and MUST be dealt with there. 

> For me, however, the ideal solution would be different 
> from what John proposes.  What I would like to see is a command that 
> essentially asks "what is the name of the message container that serves 
> function X" where X could express, for example, "is the default repository 
> for newly delivered messages" or "holds messages that have been 
> deleted".  

There is such a mechanism -- the canonical name INBOX.   The client is 
absolutely free to map this however they choose.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: "Neystadt, John" <[email-masked]>
To: "'Lyndon Nerenberg'" <[email-masked]>
Cc: "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 20:11:42 +0200
Sender: [email-masked]

> > > > SORT. Why not allow sorting by ANY header?
>  
> > I would suggest that sorting by header value has the 
> following semantics:
> > 
> > 1. Take plain header value without parameters and comments 
> (i.e. strip off
> > all '; xxx=yyy')
> 
> How can you know the syntax of comments and parameters for all
> possible headers?  X- headers have arbitrary syntax, thus you can't
> sort on X- headers since you cannot perform the decomposition.  And
> you cannot RFC2047-decode a non-X- but otherwise unknown header, since
> you don't know what elements of the header are <text>.
> 
> If you don't know the structure of the header the only thing you
> can do is collapse FWS and ASCII sort the result.

I agree that there is no way to sort by generic X- header. However since
semantics of all standard headers are defined then there is no problem to
define how to sort by every specific header.

So what I propose, is a two things:

A) Add generic keyword for header sorting, something like:

C: A282 SORT (HEADER[Message-Context] HEADER[Subject]) UTF-8 SINCE
1-Feb-1994

or the header name itself

C: A283 SORT (Message-Context SUBJECT) UTF-8 SINCE 1-Feb-1994

B) Since th list of well-known-header changes rapidly, specify in the RFC a
list of headers that must be supported. Of course I think that
Message-Context should be one of them.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

From: "Neystadt, John" <[email-masked]>
To: "'Lyndon Nerenberg'" <[email-masked]>
Cc: Pete Maclean <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 19:54:16 +0200
Sender: [email-masked]

> > This approach means we don't have to English-ize names and gets 
> > around the problem of Outbox meaning two different things.  
> The server 
> > would respond with either the appropriate name or an 
> indication that there 
> > is no such thing.
> 
> Wouldn't these be better solved with ACAP or IMSP? 

Pete's approach can be implemented through ACAP, however, it seems to me
that "Sent Items" and other 'standard' folders ae wide-spread enough to
include them in the basic protocol. Especially that INBOX has created the
precendence. Then MUA can localize these names to
a local representations without asking user what is his "Sent Items" name or
quoerying ACAP, LDAP or other server that is implemented in subsciber's.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

Organization: ACI Worldwide - Advanced Technology Group
To: "Neystadt, John" <[email-masked]>
cc: "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 10:55:46 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> > > SORT. Why not allow sorting by ANY header?
 
> I would suggest that sorting by header value has the following semantics:
> 
> 1. Take plain header value without parameters and comments (i.e. strip off
> all '; xxx=yyy')

How can you know the syntax of comments and parameters for all
possible headers?  X- headers have arbitrary syntax, thus you can't
sort on X- headers since you cannot perform the decomposition.  And
you cannot RFC2047-decode a non-X- but otherwise unknown header, since
you don't know what elements of the header are <text>.

If you don't know the structure of the header the only thing you
can do is collapse FWS and ASCII sort the result.

--lyndon

Organization: ACI Worldwide - Advanced Technology Group
To: Pete Maclean <[email-masked]>
cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 10:39:17 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>  I have to deal with users 
> who have what IMAP refers to as "Inbox" actually named "In", "Incoming", 
> "Posteingang", etc.  

Are you talking about the MUA localizing the folder "INBOX" to
a local representation? If so, why would this affect the server?
If not, maybe you could explain a bit more clearly what you mean
here.

> For me, however, the ideal solution would be different 
> from what John proposes.  What I would like to see is a command that 
> essentially asks "what is the name of the message container that serves 
> function X" where X could express, for example, "is the default repository 
> for newly delivered messages"

By definition: INBOX.

> or "holds messages that have been 
> deleted". 

*Every* folder holds \Deleted messages, again by definition.

> This approach means we don't have to English-ize names and gets 
> around the problem of Outbox meaning two different things.  The server 
> would respond with either the appropriate name or an indication that there 
> is no such thing.

Wouldn't these be better solved with ACAP or IMSP? 

--lyndon

Date: Thu, 13 Dec 2001 09:29:14 -0800 (PST)
From: [email-masked]
Subject: Re: [VPIM] re: Some thoughts about IMAP and Unified Messaging
To: Arnt Gulbrandsen <[email-masked]>
Cc: "Neystadt, John" <[email-masked]>, "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> "Neystadt, John" <[email-masked]>
> > I would suggest that sorting by header value has the following semantics:
> >
> > 1. Take plain header value without parameters and comments (i.e. strip off
> > all '; xxx=yyy')
> > 2. Determine charset from header itself (according to 2047) or us-ascii by
> > default.

> Speaking on behalf of the intolerable pedants of this world, I have to
> note that RFC 2047 contains an example where two different charsets are
> used in the same header. Indeed, it's the very first example of the RFC.

I see such examples fairly regularly in practice. I suppose this sort of thing
is inevitable when you operate in an international body like the IETF. It is
especially true given that UTF-8 is way way way down the list of the most
common charsets I see used in this (and several other) contexts.

Of course conversion to UTF-8 is one way do deal with this. But such conversion
is relatively expensive.

				Ned

Organization: ACI Worldwide - Advanced Technology Group
To: "Milt Roselinsky" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: SNAP progress and request for comment 
Date: Thu, 13 Dec 2001 10:30:24 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

[Folks, please trim down the included text in your followups.]

> In bandwidth starved environments, it would be a huge win to be able to
> provide payload in the notification.  Why not design something with network
> efficiency in mind?

Could you give an example of this "huge win?" I don't see how SNAP is
more efficient at retrieving this information than IMAP is.

--lyndon

Date: Thu, 13 Dec 2001 18:25:02 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: "Neystadt, John" <[email-masked]>
Cc: "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

"Neystadt, John" <[email-masked]>
> I would suggest that sorting by header value has the following semantics:
> 
> 1. Take plain header value without parameters and comments (i.e. strip off
> all '; xxx=yyy')
> 2. Determine charset from header itself (according to 2047) or us-ascii by
> default.

Speaking on behalf of the intolerable pedants of this world, I have to
note that RFC 2047 contains an example where two different charsets are
used in the same header. Indeed, it's the very first example of the RFC.

--Arnt

Date: Thu, 13 Dec 2001 08:52:01 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
To: "Neystadt, John" <[email-masked]>
cc: [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 13:46:34 +0200, Neystadt, John wrote:
> Marc, the SORT itself is a draft. Why do a separate effort and not include
> it straight in SORT?

That's "Mark".  With a "K".  Please.

There's the small matter of production code for the past 3 or 4 years.
Furthermore, it's a bad idea from an architecture design to put functionality
into a base protocol unless that protocol is generally useful.

> BTW: I've tried to look in archives and did not found a
> discussion of including a generic HEADER keyword discussion for SORT. Why
> not allow sorting by ANY header?

A proposed functionality has to justify its existence.  The fact that a
functionality *can* be done does not mean that it *should* be done.  Protocols
need to be implementable by mere mortals in finite time before the sun novas.

This is something that some IETFers seem to have forgotten.  IMAP is not a
small protocol, but *everything* in IMAP has a use.  There is *nothing* in
IMAP which can be "not implemented" by a server without breaking clients.

This is important.  The history of RFCs is littered with good ideas that fell
victim to the "let's add everything plus the kitchen sink."  Such protocols
invariably are overtaken by smaller, leaner protocols that do the job and are
implementable by mere mortals in real time.

Do you remember why SMTP is the Simple Mail Transport Protocol?

> Why? If we introduce a new UIDIDLE capability and syntax of
> tag UID IDLE
> with new untagged responses, like:
> S: * 44 UID EXPUNGE
> S: * 108 UID FETCH (FLAGS (\Seen))
> This will not affect existing clients.

Those responses would have to be something like
	S: * 23 EXPUNGE (UID 44)
	S: * 55 FETCH (FLAGS (SEEN) UID 108)

Nevertheless, this functionality has to justify its existence.  It duplicates
existing functionality, for no reason other than to pretend that only UIDs,
not sequence numbers, exist in IMAP.  I have seen wretched client behavior due
to that notion.  I don't think that it should be encouraged.

> I do believe that this should be done with s single command. Overloading
> server with tens of STATUSes per tens (or hundreds) mailbox-es is a bad
> bahaviour on slow links.

Indeed.  So it encourages clients not to do it, and it emphasizes that a
client that does it is a poorly-designed client.

I will vigorously oppose a functionality that gives the client the ability to
launch a denial of service attack on the server with a single command.  This
includes LIST extensions unless it is made server-optional what data can be
returned.

> Opening tens of
> connections for tens of visible mailboxes seems to me impractical and will
> severe damage server scalability.

Why is use of the existing (20+ years) multiplexing protocol less scalable
than making an IMAP server multiplex mailboxes?

> With my proposal, server can have a
> special optimized provisions (like subscribe for file system changes
> notifications) and it will be much more efficiently.

And if the back end does not provide such optimized provisions the
multiplexing substantially increases the complexity of an already quite
complex protocol.

> Well, INBOX name is a part of IMAP standard.

And is the only name that has any justification from any other e-mail
protocols.

Date: Thu, 13 Dec 2001 11:44:38 -0500
From: Lawrence Greenfield <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>, "[email-masked], John" <[email-masked]>, Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

   Date: Thu, 13 Dec 2001 08:56:47 -0700
   From: Cyrus Daboo <[email-masked]>
[...]
   That would be reasonable but how do you do the sort comparison? Some 
   headers, e.g. Priority, have a particular set of values with a clear 
   ordering that is not a simple ascii sort which is all the current SORT can 
   do. I suspect we will have to add comparators to SORT to satisfy i18n 
   issues.

Yes, this is what Mike Gahrns and I were arguing about in London.  I
think an explicit comparator for each comparison is needed for this
reason, but we hadn't reached consensus.

Larry

From: "Neystadt, John" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Date: Thu, 13 Dec 2001 18:08:41 +0200
Sender: [email-masked]

> >> This could be done by an IMAP extension for VPIM.  Since
> >> Message-Context is
> >> not a MIME base header it probably does not belong in the
> >> SORT base document.
> >
> > Marc, the SORT itself is a draft. Why do a separate effort 
> and not include
> > it straight in SORT? BTW: I've tried to look in archives and did not
> > found a discussion of including a generic HEADER keyword 
> discussion for
> > SORT. Why not allow sorting by ANY header?

I would suggest that sorting by header value has the following semantics:

1. Take plain header value without parameters and comments (i.e. strip off
all '; xxx=yyy')
2. Determine charset from header itself (according to 2047) or us-ascii by
default.
3. Use same collation mechanism as for other comparators.

> That would be reasonable but how do you do the sort comparison? Some 
> headers, e.g. Priority, have a particular set of values with a clear 
> ordering that is not a simple ascii sort which is all the 
> current SORT can 
> do. I suspect we will have to add comparators to SORT to satisfy i18n 
> issues.

I think this is simplere and better than not to support anything. In my
opinion either this or a specific comparator for Message-Context is
required.

> >> > 2. IMAP: Add support for UIDs in unsolicited events
> >>
> >> This can't be done without breaking IMAP2 compatibility.
> >> IMAP2 clients are
> >> not extinct yet.  We've learned that the hard way.
> >
> > Why? If we introduce a new UIDIDLE capability and syntax of
> >
> > tag UID IDLE
> >
> > with new untagged responses, like:
> >
> > S: * 44 UID EXPUNGE
> > S: * 108 UID FETCH (FLAGS (\Seen))
> >
> > This will not affect existing clients.
> 
> But it doesn't completely solve the problem because untagged 
> responses can 
> come back outside of IDLE and those will still only have 
> sequence number. 
> The only way to do this properly is to have a switch on the 
> SELECT command 
> to turn on this behaviour.

I think this is a good idea, and trying to take it further, we can add an
option to SELECT to block unsolicited events completely and allow them only
in IDLE (or UID IDLE) mode. Once most servers implement this a big burden
will be shifted from clients' developers.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

Date: Thu, 13 Dec 2001 08:56:47 -0700
From: Cyrus Daboo <[email-masked]>
To: "Neystadt, John" <[email-masked]>, "'Mark Crispin'" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

--On Thursday, December 13, 2001 1:46 PM +0200 "Neystadt, John" 
<[email-masked]> wrote:

>> This could be done by an IMAP extension for VPIM.  Since
>> Message-Context is
>> not a MIME base header it probably does not belong in the
>> SORT base document.
>
> Marc, the SORT itself is a draft. Why do a separate effort and not include
> it straight in SORT? BTW: I've tried to look in archives and did not
> found a discussion of including a generic HEADER keyword discussion for
> SORT. Why not allow sorting by ANY header?

That would be reasonable but how do you do the sort comparison? Some 
headers, e.g. Priority, have a particular set of values with a clear 
ordering that is not a simple ascii sort which is all the current SORT can 
do. I suspect we will have to add comparators to SORT to satisfy i18n 
issues.

>> > 2. IMAP: Add support for UIDs in unsolicited events
>>
>> This can't be done without breaking IMAP2 compatibility.
>> IMAP2 clients are
>> not extinct yet.  We've learned that the hard way.
>
> Why? If we introduce a new UIDIDLE capability and syntax of
>
> tag UID IDLE
>
> with new untagged responses, like:
>
> S: * 44 UID EXPUNGE
> S: * 108 UID FETCH (FLAGS (\Seen))
>
> This will not affect existing clients.

But it doesn't completely solve the problem because untagged responses can 
come back outside of IDLE and those will still only have sequence number. 
The only way to do this properly is to have a switch on the SELECT command 
to turn on this behaviour.

-- 
Cyrus Daboo

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Mark Crispin <[email-masked]>, John Neystadt <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Date: Thu, 13 Dec 2001 08:40:20 -0700
Sender: [email-masked]

Also:

Sort by message importance, counters by message importance is a common and
required user feature.  (Counter by union of importance and context is
desirable)

While it is not strictly a matter of IMAP, we also need message quota by
context.  It might be useful to be able to interrogate the available quota
via IMAP although I can be convinced to use some other mechanism.  Quota by
context with necessary over-rides more greatly impact SMTP-Submit. 

A more controversial matter is the storage of personal greetings.  Because
of the relatively large data size per subscriber (6+ greetings per user,
each greeting of up to 30 seconds of 4kbytes/second) these have not
historically been stored in a directory server, their most natural
architectural home.  Instead, in a widely-used and effective hack, they are
typically stored in a special folder in the subscribers mailbox.  The
mailbox being a place optimized for the storage and streaming retrieval of
large objects.  There is often a URL in the "directory" pointing to the
special message(s) in the mailbox.  This folder is granted public read
access so an agent of an unauthenticated caller (the telephone answering
application) can select the appropriate greeting and play it without knowing
the  mailbox log-in.  The subscriber can update, copy, and delete greetings
via standard authenticated IMAP mechanisms.  We can harmonize and "profile"
existing practice or invent a new one.  The IMAP approach has the current
benefit that it does not require support of yet another protocol by the
application.

The ability to gain limited access to affiliated mailboxes (in same
session?) is important.  In one application example, the sub-mailboxes of a
family, it is important to be able to report the message counts for a
mailbox that you cannot otherwise read the contents.  When you come home and
see a single blinky-light for the confederation, you pick up the phone,
press the magic button, and are auto logged-in to the "main mailbox".  At
the main mailbox, you hear a status of each of the submailboxes (in addition
to the main).  The time-pressed user may then only log-in to their
sub-mailbox if there are actually messages to review.  Other applications
examples have identical requirements.

Greg V.

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]]
Sent: Wednesday, December 12, 2001 7:06 PM
To: John Neystadt
Cc: [email-masked]; [email-masked]
Subject: [VPIM] re: Some thoughts about IMAP and Unified Messaging

On Wed, 12 Dec 2001 22:05:16 +0200, John Neystadt wrote:
> 1. IMAP: Extend SORT to support Message-Context

This could be done by an IMAP extension for VPIM.  Since Message-Context is
not a MIME base header it probably does not belong in the SORT base
document.

> 2. IMAP: Add support for UIDs in unsolicited events

This can't be done without breaking IMAP2 compatibility.  IMAP2 clients are
not extinct yet.  We've learned that the hard way.

> 3. IMAP: Add support of per Message-Context counters in STATUS command

This can also be done by an IMAP extension for VPIM.

> 4. IMAP: Add support for STATUS of multiple folders

STATUS does not accept multiple mailboxes for a reason; the metadata
obtained
by STATUS may not be available to the server except by doing an internal
SELECT.  Forcing clients to do a STATUS command per mailbox emphasizes that
this is not something that should be done on a wanton basis.

There is an effort underway to extend LIST to return additional mailbox
metadata, but only if the server chooses to offer it.

> 5. IMAP: Add support for IDLE of multiple folders

The same effect can be achieved with multiple connections, one for each
mailbox, each in an IDLE.  That way, instead of adding a multiplexing
mechanism to IMAP, it uses the wonderful multiplexing system that every
Internet system has built in for free: TCP.

> 6. IMAP: Standardize English names for standard (system) folders in
addition
> to INBOX - Sent Items, Drafts, Outbox, Deleted Items

I consider it to be a great stretch to call any of these "standardized", and
as far as "Deleted Items" goes that is nothing less than a wholesale
abandonment of IMAP.

"Outbox" has at least two incompatible roles in common use by clients.  Pick
a
definition for what "Outbox" can mean, and I can argue quite convincingly
that
you're wrong and the only correct definition is a different one.  So you
give
in and go with that definition; I'll then argue quite convincingly that the
first definition was right.

This type of MUA-dependent functionality does not belong in IMAP.

> 7. Add support of two new system IMAP flags - to mark messages with \Spam
> and \Adult content.

There is no need to do this; keywords will accomplish the same thing.  There
is even a mechanism for inter-client keywords (the "$" prefix) that are well
known (perhaps we need a formal IANA registry of these).

----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email-masked]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo

Date: Thu, 13 Dec 2001 07:23:59 -0800 (PST)
From: [email-masked]
Subject: RE: SNAP progress and request for comment
To: Randall Gellens <[email-masked]>
Cc: Milt Roselinsky <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> I second the suggestion to use BEEP instead of HTTP.

First let me repeat what I said as in my capacity as an area director at the
VPIM meeting -- we now have a document (draft-moore-using-http-01.txt) that
describes the use of HTTP in other protocols. At a minimum this needs to be
reviewed to make sure your use of HTTP is appropriate.

It is not my objective as an AD to force you to use BEEP and not HTTP in this
work, merely to point out the potential issues that arise should you choose
to use HTTP.

Second, speaking entirely as an individual member of these WGs, I concur with
both Chris and Randall -- IMO BEEP is a better choice for all the reasons Chris
gave.

> ...

> Your request types might be better as hierarchical codes, either
> textual or numeric (like Delivery Status Notifications (DSNs)).  For
> example, "Account-Locked/Login-Error-Max-Exceeded" or xxx.yyy.zzz.

I have mixed feeling about this. I guess I wouldn't mind such a structure for
numeric codes -- we have examples where this appears to have worked reasonably
well. But structured textual codes make me nervous. I'm not convinced this has
worked all that well in the case of MDNs.

> (Wow -- a normative reference to MIXER!)

Which needs to go. As pointed out at the meeting, there's equivalent VPIM
text.  Don't reference MIXER.

					Ned

Date: Thu, 13 Dec 2001 10:32:16 -0500
To: John Neystadt <[email-masked]>, [email-masked], [email-masked]
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

--=====================_182982234==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>6. IMAP: Standardize English names for standard (system) folders in 
>addition to INBOX - Sent Items, Drafts, Outbox, Deleted Items
>
>Currently localization of INBOX occurs on User-Agent side, while rest of 
>folders are create directly in local agent. This requires the user to 
>configure the names of the folders in the User-Agent. The idea is to 
>standardize English names for all standard folders and make the User-Agent 
>only to display them in local language.

As an IMAP server developer, the one enhancement I would most like to see 
made to IMAP is something to address this issue.  I have to deal with users 
who have what IMAP refers to as "Inbox" actually named "In", "Incoming", 
"Posteingang", etc.  For me, however, the ideal solution would be different 
from what John proposes.  What I would like to see is a command that 
essentially asks "what is the name of the message container that serves 
function X" where X could express, for example, "is the default repository 
for newly delivered messages" or "holds messages that have been 
deleted".  This approach means we don't have to English-ize names and gets 
around the problem of Outbox meaning two different things.  The server 
would respond with either the appropriate name or an indication that there 
is no such thing.

Pete

--=====================_182982234==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<blockquote type=cite cite><font face="arial" size=2>6. IMAP: Standardize
English names for standard (system) folders in addition to INBOX - Sent
Items, Drafts, Outbox, Deleted Items<br>
</font><br>
<font face="arial" size=2>Currently localization of INBOX occurs on
User-Agent side, while rest of folders are create directly in local
agent. This requires the user to configure the names of the folders in
the User-Agent. The idea is to standardize English names for all standard
folders and make the User-Agent only to display them in local
language.</font></blockquote><font face="arial" size=2><br>
</font><font face="arial">As an IMAP server developer, the one
enhancement I would most like to see made to IMAP is something to address
this issue.&nbsp; I have to deal with users who have what IMAP refers to
as &quot;Inbox&quot; actually named &quot;In&quot;, &quot;Incoming&quot;,
&quot;Posteingang&quot;, etc.&nbsp; For me, however, the ideal solution
would be different from what John proposes.&nbsp; What I would like to
see is a command that essentially asks &quot;what is the name of the
message container that serves function X&quot; where X could express, for
example, &quot;is the default repository for newly delivered
messages&quot; or &quot;holds messages that have been
deleted&quot;.&nbsp; This approach means we don't have to English-ize
names and gets around the problem of Outbox meaning two different
things.&nbsp; The server would respond with either the appropriate name
or an indication that there is no such thing.<br>
<br>
Pete<br>
</font></html>

--=====================_182982234==_.ALT--

From: Edward Hibbert <[email-masked]>
To: "'Shapira, Noam'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: [SNAP] draft-shapira-snap-02.txt
Date: Thu, 13 Dec 2001 14:48:31 -0000
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C183E5.3BE0EB30
Content-Type: text/plain;
	charset="windows-1255"

I have a few comments on the latest draft; see below.
 
<!--StartFragment-->2.2.1 Request Order

   The source MUST send the requests to the service in the same order
   as the events that triggered them occurred. This ensures a 
   consistent behavior. For example: if there are two notifications 
   events, one indicating the user has one new message and the second
   indicating there are two new messages, the user must receive the
   first before the second.

Our experience in this area suggests that this requirement may be very
difficult to obey in multi-machine systems involving a variety of
components.  Even if the requests are generated in the correct order, you
need to ensure they arrive at the service in the same order.  This has an
implication for how these notifications are scheduled within the source
application, and also how it uses connections to the service - probably
requests for a single user must be sent over the same persistent connection
to avoid the possibility that the service will pull them off in a different
order.
 
There are two other approaches I can think of:

*	Ensure that each request contains enough information to perform a
sensible action even if requests are received out of sequence.  This is
possible with simplistic notifications such as turning an MWI light on and
off, but it's very difficult to see that is achievable with the level of
detail in this spec.
*	Tag each request with a monotonically increasing sequence number.
That way the sequence number can be generated at the point that the mailbox
is modified, and later issues in the scheduling of requests within the
source application are reduced.  However this does put more onus on the
notification service to deal with ordering the sequences and coping with
lost requests.

If we retain this requirement (rather than use a sequence number) then I
think we need a more careful discussion of the implications for behaviour in
the source application.

What do other folk think about this?
 
<!--StartFragment-->.2.4 Retries

   Upon receiving a response from the service indicating a failure, the
   source SHOULD retry the request in case the service failure is
   recoverable (i.e. temporary).

   Presumably if the source sends a request but doesn't get a response (e.g.
the service crashes and recovers), it should also do retries?
 
<!--StartFragment-->
3.2 Request Types

   This section describes the trigger for sending each request type
   and lists the groups of attributes that SHOULD appear in the
   request.

In our notification thinking, we've decided that moving an unread message
out of the Inbox folder into another folder ought to turn off an MWI.
Should there be a separate RequestType for Move, or would we generate a
ReadMsg request?  I favour the former.
 
<!--StartFragment-->3.6 CountersGroup

   The counter group includes the count of messages in the user's
   mailbox according to categories. The categories are type (Voice,
   Fax or Email), Freshness (New or not) and Urgency (Urgent or not).

   A message is considered fresh if its unseen flag is true. It
   is considered Urgent if the MsgImportance attribute as described in
   the MessageGroup is "high". Categorization to type is a
   proprietary vendor feature. The source SHOULD categorize all
   messages as Email messages.

What should a message which contains both Voice and Fax information count
towards?
 
<!--StartFragment-->4.1.3 Redirection (3xx) Status Codes

4.1.3.1 "301 Moved Permanently"

   Upon receiving this status code, the source MUST resend the
   notification request to the new URI specified in the location
   field of the response.

   When sending other requests after receiving this response, the
   source SHOULD use the new URL that is part of the URI returned in
   the "location" field.

Presumably this redirection applies to requests for all users, not just for
the one referenced in the request?

Harking back to 2.2.1, I think we also need to consider scalability and
reliability for the service, because that may impact on the protocol.  At
present there is a single contact point for the service.  If that's a single
machine it may become overloaded, so for performance and reliability we need
to have a way of it being multiple machines.  Although that can be hidden
from the source via an IP splitter, that re-introduces the problem of
requests getting out of order because a different machine picks them up.  So
I think that multiple contact points for the service needs to be explicitly
catered for, and the implications explored.  For example it might be that
all requests for a user should be sent to the same contact point while that
contact point is up.

Regards,

Edward Hibbert 
Internet Applications Group 
Data Connection Ltd 
Tel:    +44 131 662 1212                Fax:    +44 131 662 1345 
Email:  [email-masked]   Web:    http://www.dat <http://www.dat/>
aconnection.com 

------_=_NextPart_001_01C183E5.3BE0EB30
Content-Type: text/html;
	charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">
<TITLE></TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#ff00ff face=Arial size=2>I have a few comments on the latest 
draft; see below.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&lt;!--StartFragment--&gt;2.2.1 Request 
Order<BR><BR>&nbsp;&nbsp; The source MUST send the requests to the service in 
the same order<BR>&nbsp;&nbsp; as the events that triggered them occurred. This 
ensures a <BR>&nbsp;&nbsp; consistent behavior. For example: if there are two 
notifications <BR>&nbsp;&nbsp; events, one indicating the user has one new 
message and the second<BR>&nbsp;&nbsp; indicating there are two new messages, 
the user must receive the<BR>&nbsp;&nbsp; first before the 
second.<BR></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>Our experience in this area suggests 
that this requirement may be very difficult to obey in multi-machine systems 
involving a variety of components.&nbsp; Even if the requests are generated in 
the correct order, you need to ensure they arrive at the service in the same 
order.&nbsp; This has an implication for how these notifications are scheduled 
within the source application, and also how it&nbsp;uses connections to the 
service - probably requests for a single user must be sent over the same 
persistent connection to avoid the possibility that the service will pull them 
off in a different order.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>There are two other approaches I can 
think of:</FONT></DIV>
<UL>
  <LI><FONT color=#ff00ff face=Arial size=2>Ensure that each request contains 
  enough information to perform a sensible action even if requests are received 
  out of sequence.&nbsp; This is possible with simplistic notifications such as 
  turning an MWI light on and off, but it's very difficult to see that is 
  achievable with the level of detail in this spec.</LI>
  <LI><FONT color=#ff00ff face=Arial size=2>Tag each request with a 
  monotonically increasing sequence number.&nbsp; That way the sequence number 
  can be generated at the point that the mailbox is modified, and later issues 
  in the scheduling of requests within the source application ar</FONT><FONT 
  color=#ff00ff face=Arial size=2>e reduced.&nbsp; However this does put more 
  onus on the notification service to deal with ordering the sequences and 
  coping with lost requests.</FONT></LI></FONT></UL>
<DIV><FONT color=#ff00ff face=Arial size=2>If we retain this requirement (rather 
than use a sequence number) then I think we need a more careful discussion of 
the implications for behaviour in the source application.</FONT></DIV>
<UL></UL>
<DIV><FONT color=#ff00ff face=Arial size=2>What do other folk think about 
this?</FONT></DIV>
<DIV>&nbsp;</DIV><FONT face=Arial><FONT size=2>
<DIV>&lt;!--StartFragment--&gt;.2.4 Retries<BR><BR>&nbsp;&nbsp; Upon receiving a 
response from the service indicating a failure, the<BR>&nbsp;&nbsp; source 
SHOULD retry the request in case the service failure is<BR>&nbsp;&nbsp; 
recoverable (i.e. temporary).<BR><BR><FONT color=#ff00ff>&nbsp;&nbsp; 
Presumably&nbsp;if the source sends a request but doesn't get a response (e.g. 
the service crashes and recovers), it should also do 
retries?</FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV><FONT color=#ff00ff></FONT><FONT color=#ff00ff></FONT>
<DIV><FONT face=Arial size=2>&lt;!--StartFragment--&gt;<BR>3.2 Request 
Types<BR><BR>&nbsp;&nbsp; This section describes the trigger for sending each 
request type<BR>&nbsp;&nbsp; and lists the groups of attributes that SHOULD 
appear in the<BR>&nbsp;&nbsp; request.<BR></FONT></DIV>
<DIV><FONT size=2><FONT color=#ff00ff face=Arial>In our notification thinking, 
we've decided that moving an unread message out of the Inbox folder into another 
folder ought to turn off an MWI.&nbsp; Should there be a separate RequestType 
for Move, or would we generate a ReadMsg request?&nbsp; I favour the 
former.</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&lt;!--StartFragment--&gt;3.6 
CountersGroup<BR><BR>&nbsp;&nbsp; The counter group includes the count of 
messages in the user's<BR>&nbsp;&nbsp; mailbox according to categories. The 
categories are type (Voice,<BR>&nbsp;&nbsp; Fax or Email), Freshness (New or 
not) and Urgency (Urgent or not).<BR><BR>&nbsp;&nbsp; A message is considered 
fresh if its unseen flag is true. It<BR>&nbsp;&nbsp; is considered Urgent if the 
MsgImportance attribute as described in<BR>&nbsp;&nbsp; the MessageGroup is 
"high". Categorization to type is a<BR>&nbsp;&nbsp; proprietary vendor feature. 
The source SHOULD categorize all<BR>&nbsp;&nbsp; messages as Email 
messages.<BR></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>What should&nbsp;a message which 
contains both Voice and Fax information count towards?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&lt;!--StartFragment--&gt;4.1.3 Redirection (3xx) 
Status Codes<BR><BR>4.1.3.1 "301 Moved Permanently"<BR><BR>&nbsp;&nbsp; Upon 
receiving this status code, the source MUST resend the<BR>&nbsp;&nbsp; 
notification request to the new URI specified in the location<BR>&nbsp;&nbsp; 
field of the response.<BR><BR>&nbsp;&nbsp; When sending other requests after 
receiving this response, the<BR>&nbsp;&nbsp; source SHOULD use the new URL that 
is part of the URI returned in<BR>&nbsp;&nbsp; the "location" 
field.<BR></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>Presumably this redirection applies 
to requests for all users, not just for the one referenced in the 
request?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>Harking back to 2.2.1, I think we 
also need to consider scalability and reliability for the service, because that 
may impact on the protocol.&nbsp; </FONT><FONT color=#ff00ff face=Arial 
size=2>At present there is a single contact point for the service.&nbsp; If 
that's a single machine it may become overloaded, so for performance and 
reliability we need to have a way of it being multiple machines.&nbsp; Although 
that can be hidden from the source via an IP splitter, that re-introduces the 
problem of requests getting out of order because a different machine picks them 
up.&nbsp; So I think that multiple contact points for the service needs to be 
explicitly catered for, and the implications explored.&nbsp; For example it 
might be that a</FONT><FONT color=#ff00ff face=Arial size=2>ll requests for a 
user should be sent to the same contact point while that contact point is 
up.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>Regards,</FONT></DIV>
<DIV>
<P><FONT color=#000000 face=Arial size=1>Edward Hibbert</FONT> <BR><FONT 
color=#000000 face=Arial size=1>Internet Applications</FONT> <FONT color=#000000 
face=Arial size=1>Group</FONT> <BR><U><FONT color=#000000 face=Arial size=1>Data 
Connection Ltd</FONT></U> <BR><FONT color=#000000 face=Arial 
size=1>Tel:&nbsp;&nbsp;&nbsp; +44</FONT> <FONT color=#000000 face=Arial 
size=1>131 662 1212</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#000000 face=Arial 
size=1>Fax:&nbsp;&nbsp;&nbsp; +44</FONT> <FONT color=#000000 face=Arial 
size=1>131 662 1345</FONT> <BR><FONT color=#000000 face=Arial 
size=1>Email:&nbsp;</FONT> <FONT color=#000000 face=Arial size=1>eh</FONT><FONT 
color=#000000 face=Arial size=1>@dat</FONT><FONT color=#000000 face=Arial 
size=1>aconnection.com</FONT>&nbsp;&nbsp; <FONT color=#000000 face=Arial 
size=1>Web</FONT><FONT color=#000000 face=Arial 
size=1>:</FONT>&nbsp;&nbsp;&nbsp;<U> <FONT color=#0000ff face=Arial size=1><A 
href="http://www.dat/" target=_blank>http://www.dat</A></FONT><FONT 
color=#0000ff face=Arial size=1>aconnection.com</FONT></U> 
</P></DIV></BODY></HTML>

------_=_NextPart_001_01C183E5.3BE0EB30--

From: Steve Gardell <[email-masked]>
To: "'John Neystadt'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Thu, 13 Dec 2001 09:18:37 -0500
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C183E1.0E265D00
Content-Type: text/plain;
	charset="iso-8859-1"

I would be inclined to add some sort of streaming support along the lines
of draft-nerenberg-imap-channel-02.txt to this list.         

-----Original Message-----
From: John Neystadt [mailto:[email-masked]]
Sent: Wednesday, December 12, 2001 3:05 PM
To: [email-masked]; [email-masked]
Subject: Some thoughts about IMAP and Unified Messaging

Hi!

Analyzing a set of internal IMAP uses/abuses and recent developments in VPIM
group I've came with a list of few modification that can make IMAP ore
friendly with Unified Messaging. If they make sense and represent an
interest for others, I am ready to formulate them and submit as drafts.
 
1. IMAP: Extend SORT to support Message-Context

IMAP-SORT draft supports sorting by a number of keywords (To, Date, Subject,
etc). In order to support sorting per message type it should be extended to
support either arbitrary MIME header or at least Message-Context header
(vpim-hint).

2. IMAP: Add support for UIDs in unsolicited events

Currently unsolicited events in IMAP return Sequence ids of messages. This
requires User-Agent to query server upon receiving unsolicited event for
whole message list if it did not yet fetched list of all messages. Supplying
UIDs will allow server to fetch information only the message that has
changed and reflect it in UI.

3. IMAP: Add support of per Message-Context counters in STATUS command

Currently STATUS Command includes TOTAL and UNSEEN counters. Since UM
user-Agent wants to present counters per Message-Context they should be
included.

4. IMAP: Add support for STATUS of multiple folders

Often User-Agents present a list of folders with counters of a new messages
per each of them. Today STATUS command per folder must be issued. The idea
is to extend STATUS to receive a list of folders as a parameter and produce
single response for all of them.

5. IMAP: Add support for IDLE of multiple folders

Today User-Agents display a list of folders with counters. In order to
maintain list of counters they continuously poll the server with STATUS
command. Instead IDLE with list of folders could enable it to be processed
in a push mode.

6. IMAP: Standardize English names for standard (system) folders in addition
to INBOX - Sent Items, Drafts, Outbox, Deleted Items

Currently localization of INBOX occurs on User-Agent side, while rest of
folders are create directly in local agent. This requires the user to
configure the names of the folders in the User-Agent. The idea is to
standardize English names for all standard folders and make the User-Agent
only to display them in local language.

7. Add support of two new system IMAP flags - to mark messages with \Spam
and \Adult content.

Today SMTP-MTAs often support SPAM and Adult content filtering. Not always
it is possible to remove a message with wrong content, since sometimes a
doubt exist regarding the correctness of the identification. By marking the
message in doubt with system-flag, it will allow User-Agents to process such
messages differently (i.e. color them or put in special folder).

John Neystadt
[email-masked]
http://www.neystadt.org/john/ <http://www.neystadt.org/john/> 

------_=_NextPart_001_01C183E1.0E265D00
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2919.6307" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY background="" bgColor=#ffffff dir=ltr>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=668431514-13122001>I 
would be inclined to add some sort of streaming support along the 
lines</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=668431514-13122001>of 
draft-nerenberg-imap-channel-02.txt</SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=668431514-13122001> to this 
list.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> John Neystadt 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, December 12, 2001 3:05 
  PM<BR><B>To:</B> [email-masked]; 
  [email-masked]<BR><B>Subject:</B> Some thoughts about IMAP and 
  Unified Messaging<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>Hi!<BR><BR>Analyzing a set of internal IMAP 
  uses/abuses and recent developments in VPIM group I've came with a list of few 
  modification that can make IMAP ore friendly with Unified Messaging. If they 
  make sense and represent an interest for others, I am ready to formulate them 
  and submit as drafts.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>1. IMAP: Extend SORT to support 
  Message-Context</FONT></DIV>
  <DIV>
  <P><FONT face=Arial size=2>IMAP-SORT draft supports sorting by a number of 
  keywords (To, Date, Subject, etc). In order to support sorting per message 
  type it should be extended to support either arbitrary MIME header or at least 
  Message-Context header (vpim-hint).</FONT></P>
  <P><FONT face=Arial size=2>2. IMAP: Add support for UIDs in unsolicited 
  events</FONT></P>
  <P><FONT face=Arial size=2>Currently unsolicited events in IMAP return 
  Sequence ids of messages. This requires User-Agent to query server upon 
  receiving unsolicited event for whole message list if it did not yet fetched 
  list of all messages. Supplying UIDs will allow server to fetch information 
  only the message that has changed and reflect it in UI.</FONT></P>
  <P><FONT face=Arial size=2>3. IMAP: Add support of per Message-Context 
  counters in STATUS command</FONT></P>
  <P><FONT face=Arial size=2>Currently STATUS Command includes TOTAL and UNSEEN 
  counters. Since UM user-Agent wants to present counters per Message-Context 
  they should be included.</FONT></P>
  <P><FONT face=Arial size=2>4. IMAP: Add support for STATUS of multiple 
  folders</FONT></P>
  <P><FONT face=Arial size=2>Often User-Agents present a list of folders with 
  counters of a new messages per each of them. Today STATUS command per folder 
  must be issued. The idea is to extend STATUS to receive a list of folders as a 
  parameter and produce single response for all of them.</FONT></P>
  <P><FONT face=Arial size=2>5. IMAP: Add support for IDLE of multiple 
  folders</FONT></P>
  <P><FONT face=Arial size=2>Today User-Agents display a list of folders with 
  counters. In order to maintain list of counters they continuously poll the 
  server with STATUS command. Instead IDLE with list of folders could enable it 
  to be processed in a push mode.</FONT></P>
  <P><FONT face=Arial size=2>6. IMAP: Standardize English names for standard 
  (system) folders in addition to INBOX - Sent Items, Drafts, Outbox, Deleted 
  Items</FONT></P>
  <P><FONT face=Arial size=2>Currently localization of INBOX occurs on 
  User-Agent side, while rest of folders are create directly in local agent. 
  This requires the user to configure the names of the folders in the 
  User-Agent. The idea is to standardize English names for all standard folders 
  and make the User-Agent only to display them in local language.</FONT></P>
  <P><FONT face=Arial size=2>7. Add support of two new system IMAP flags - to 
  mark messages with \Spam and \Adult content.</FONT></P>
  <P><FONT face=Arial size=2>Today SMTP-MTAs often support SPAM and Adult 
  content filtering. Not always it is possible to remove a message with wrong 
  content, since sometimes a doubt exist regarding the correctness of the 
  identification. By marking the message in doubt with system-flag, it will 
  allow User-Agents to process such messages differently (i.e. color them or put 
  in special folder).</FONT></P>
  <P><FONT face=Arial size=2>John Neystadt<BR>[email-masked]<BR><A 
  href="http://www.neystadt.org/john/">http://www.neystadt.org/john/</A></FONT></P>
  <P><FONT face=Arial size=2></FONT>&nbsp;</P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C183E1.0E265D00--

From: "Neystadt, John" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Date: Thu, 13 Dec 2001 13:46:34 +0200
Sender: [email-masked]

> On Wed, 12 Dec 2001 22:05:16 +0200, John Neystadt wrote:
> > 1. IMAP: Extend SORT to support Message-Context
> 
> This could be done by an IMAP extension for VPIM.  Since 
> Message-Context is
> not a MIME base header it probably does not belong in the 
> SORT base document.

Marc, the SORT itself is a draft. Why do a separate effort and not include
it straight in SORT? BTW: I've tried to look in archives and did not found a
discussion of including a generic HEADER keyword discussion for SORT. Why
not allow sorting by ANY header?

> > 2. IMAP: Add support for UIDs in unsolicited events
> 
> This can't be done without breaking IMAP2 compatibility.  
> IMAP2 clients are
> not extinct yet.  We've learned that the hard way.

Why? If we introduce a new UIDIDLE capability and syntax of 

tag UID IDLE

with new untagged responses, like:

S: * 44 UID EXPUNGE
S: * 108 UID FETCH (FLAGS (\Seen))

This will not affect existing clients.

> > 4. IMAP: Add support for STATUS of multiple folders
> 
> STATUS does not accept multiple mailboxes for a reason; the 
> metadata obtained
> by STATUS may not be available to the server except by doing 
> an internal
> SELECT.  Forcing clients to do a STATUS command per mailbox 
> emphasizes that
> this is not something that should be done on a wanton basis.
> 
> There is an effort underway to extend LIST to return 
> additional mailbox
> metadata, but only if the server chooses to offer it.

I do believe that this should be done with s single command. Overloading
server with tens of STATUSes per tens (or hundreds) mailbox-es is a bad
bahaviour on slow links. I do agree that this can be done with an another
extension to LIST-EXTENSIONS. However LIST response in a one-liner per
mailbox, while STATUS has a set of already defined responses. Moving this to
LIST will require duplication of responses for existing metadata (UNSEEN,
etc.).

> > 5. IMAP: Add support for IDLE of multiple folders
> 
> The same effect can be achieved with multiple connections, 
> one for each
> mailbox, each in an IDLE.  That way, instead of adding a multiplexing
> mechanism to IMAP, it uses the wonderful multiplexing system 
> that every
> Internet system has built in for free: TCP.

Well, you basically say - it is a client problem. Opening tens of
connections for tens of visible mailboxes seems to me impractical and will
severe damage server scalability. With my proposal, server can have a
special optimized provisions (like subscribe for file system changes
notifications) and it will be much more efficiently. 

> > 6. IMAP: Standardize English names for standard (system) 
> folders in addition
> > to INBOX - Sent Items, Drafts, Outbox, Deleted Items
> 
> I consider it to be a great stretch to call any of these 
> "standardized", and
> as far as "Deleted Items" goes that is nothing less than a wholesale
> abandonment of IMAP.
> 
> "Outbox" has at least two incompatible roles in common use by 
> clients.  Pick a
> definition for what "Outbox" can mean, and I can argue quite 
> convincingly that
> you're wrong and the only correct definition is a different 
> one.  So you give
> in and go with that definition; I'll then argue quite 
> convincingly that the
> first definition was right.
> 
> This type of MUA-dependent functionality does not belong in IMAP.

Well, INBOX name is a part of IMAP standard. Sent Items is a paradigm used
by all MUAs on all OSes, so ignoring it is impractical. Other folders are
more controversial. However I think it is better to standardize
controversial names as recommendation, since there is no harm for those MUAs
who don't use it.

> > 7. Add support of two new system IMAP flags - to mark 
> messages with \Spam
> > and \Adult content.
> 
> There is no need to do this; keywords will accomplish the 
> same thing.  There
> is even a mechanism for inter-client keywords (the "$" 
> prefix) that are well
> known (perhaps we need a formal IANA registry of these).

Agreed.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

Date: Wed, 12 Dec 2001 21:13:55 -0700
To: "Milt Roselinsky" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: RE: SNAP progress and request for comment
Sender: [email-masked]

Some comments:

I second the suggestion to use BEEP instead of HTTP.

Please use hyphens in your header attributes (e.g., 
"Notification-Protocol-Version").  Also, clarify is case is 
significant (I think it shouldn't be).

What is the point of ApplicationName?  Is the server going to act 
differently based on the value?

You specify that all times must be in GMT (even requiring translation 
from a 'Date:' header field).  Using local time with a time zone 
conveys more information, often useful.  For example, if the event 
occurred in the middle of the night versus the afternoon, local wall 
time.

Your request types might be better as hierarchical codes, either 
textual or numeric (like Delivery Status Notifications (DSNs)).  For 
example, "Account-Locked/Login-Error-Max-Exceeded" or xxx.yyy.zzz.

(Wow -- a normative reference to MIXER!)

I second the suggestion to send information on the MIME structure 
instead of just Content-Disposition headers.

I'm not sure I like the idea of sending the message body.  I think 
that opens a potential for a lot of problems, and turns this from a 
notification protocol into a third way to get local mail.  At any 
rate, if you are going to send the body, and you allow only part of 
it to be sent, the original size needs to be included, so it is clear.

The Reject Group seems like it should use DSN codes.

The Mailbox Full Status seems like it should have a DSN code and a 
human-readable text component.

Date: Wed, 12 Dec 2001 21:01:27 -0700
To: "Milt Roselinsky" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: RE: SNAP progress and request for comment
Sender: [email-masked]

At 4:43 PM -0800 12/12/01, Milt Roselinsky wrote:

>  In bandwidth starved environments, it would be a huge win to be able to
>  provide payload in the notification.

Maybe, maybe not.  A lot of bandwidth could be consumed with notifications.

Date: Wed, 12 Dec 2001 17:06:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Some thoughts about IMAP and Unified Messaging
To: John Neystadt <[email-masked]>
cc: [email-masked], [email-masked]
Sender: [email-masked]

On Wed, 12 Dec 2001 22:05:16 +0200, John Neystadt wrote:
> 1. IMAP: Extend SORT to support Message-Context

This could be done by an IMAP extension for VPIM.  Since Message-Context is
not a MIME base header it probably does not belong in the SORT base document.

> 2. IMAP: Add support for UIDs in unsolicited events

This can't be done without breaking IMAP2 compatibility.  IMAP2 clients are
not extinct yet.  We've learned that the hard way.

> 3. IMAP: Add support of per Message-Context counters in STATUS command

This can also be done by an IMAP extension for VPIM.

> 4. IMAP: Add support for STATUS of multiple folders

STATUS does not accept multiple mailboxes for a reason; the metadata obtained
by STATUS may not be available to the server except by doing an internal
SELECT.  Forcing clients to do a STATUS command per mailbox emphasizes that
this is not something that should be done on a wanton basis.

There is an effort underway to extend LIST to return additional mailbox
metadata, but only if the server chooses to offer it.

> 5. IMAP: Add support for IDLE of multiple folders

The same effect can be achieved with multiple connections, one for each
mailbox, each in an IDLE.  That way, instead of adding a multiplexing
mechanism to IMAP, it uses the wonderful multiplexing system that every
Internet system has built in for free: TCP.

> 6. IMAP: Standardize English names for standard (system) folders in addition
> to INBOX - Sent Items, Drafts, Outbox, Deleted Items

I consider it to be a great stretch to call any of these "standardized", and
as far as "Deleted Items" goes that is nothing less than a wholesale
abandonment of IMAP.

"Outbox" has at least two incompatible roles in common use by clients.  Pick a
definition for what "Outbox" can mean, and I can argue quite convincingly that
you're wrong and the only correct definition is a different one.  So you give
in and go with that definition; I'll then argue quite convincingly that the
first definition was right.

This type of MUA-dependent functionality does not belong in IMAP.

> 7. Add support of two new system IMAP flags - to mark messages with \Spam
> and \Adult content.

There is no need to do this; keywords will accomplish the same thing.  There
is even a mechanism for inter-client keywords (the "$" prefix) that are well
known (perhaps we need a formal IANA registry of these).

From: "Milt Roselinsky" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: SNAP progress and request for comment
Date: Wed, 12 Dec 2001 16:43:07 -0800
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 7:27 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: SNAP progress and request for comment
>
>
> Thanks for your comment
>
> See my comments in text:
>
>
> > I have a few comments about the current draft, and some larger comments
> > about the scope of the ID
> >
> > In section 3.5.11 and 3.5.12 regarding attachment names and number of
> > attachments, using Content Disposition isn't a very reliable
> way of gaining
> > this information. Perhaps an IMAP-like bodystructure that's
> annotated with
> > attachment information would be more useful.
> Basically I agree that Content Disposition isn't the best thing.
> But, your alternative will make the work very "expensive". If for
> each email entering the system we will need to do this annotation
> - it will be a killer for the SMTP process on the email server
> side. Any one - thoughts on the issue?

There are very few situations where Content Disposition is going to work.
Yet in the current SNAP ID its the basis of some important functionality.
IMO it would be better to make provision of a description of message content
optional and then describe something that works than to design something
that isn't likely to work.

>
> >
> > 3.5.14 - Body should enable sending non-text body content - the
> decision on
> > what is appropriate content is outside the scope of SNAP.
> I am not sure I agree with you. This is a notification protocol
> and not a messaging transferring  protocol. The notification
> protocol should be rich enough in order to allow the notification
> server (or the UA that the notification server usses to notify
> the user) to retrieve the new message. The fact that we added the
> text (and maybe we shouldn't have..) was because of the facts
> that some of the UA are primitive and can't retrieve the message.

In bandwidth starved environments, it would be a huge win to be able to
provide payload in the notification.  Why not design something with network
efficiency in mind?

> >
> > 3.6 - counters group - specific message type counters are very
> limiting, it
> > would be better to have an extensible mechanism.
> See my later comment on the issue

This issue is actually separate from the issue of using notification for
other applications.  The counters group would be much better served by
allowing a simple extensible list of counters.  To support fax, voice and
email as in the current ID, this could be a list
"Counters:total=X,image/tiff=Y,multipart/voice-message=Z".  If an
implementation wanted to provide the number of any other media type, they
could just add it to the list.  If the recipient of this information doesn't
care about some of the information, it can just ignore it.

> >
> > General comment:
> >
> > This protocol is very specific to notification of mailbox
> status but mailbox
> > status is just one of the many applications that use
> notification.  It seems
> > that there should be application specific payload descriptions
> in the body
> > of these messages one of them related to MWI and other mailbox related
> > information and other related to other notification events.
> The interface
> > to the notification service should handle more than mailbox events.
> >
> > I strongly encourage you to expand the capabilities of the
> notification ID
> > by generalizing payload, counters and by adding an area for application
> > specific metadata.   As application developers or future IETF
> working groups
> > adopt the notification standard, they would publish the
> definition of that
> > application specific usage.
> >
> The idea of having one notification protocol for a range of
> notification events has been talked about in the past. The
> problem with this is that trying to have a generic notification
> protocol has been tried in the past and failed. What we are
> trying to do is to attack the problem - one after the other -
> starting with the messaging arena. I understand the wish to have
> a multi-purpose protocol for notification (I share it) but it
> will be impossible to close it ever. We might need to add a
> header that will help us to extend the protocol later on. What do
> you think?

I think I'm disappointed at limiting scope so drastically.  With this
approach we're doomed to implementing the same basic functions many times.

>
> > Milt Roselinsky
> > Openwave Systems
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of Shapira, Noam
> > > Sent: Tuesday, December 04, 2001 10:39 PM
> > > To: [email-masked]
> > > Subject: SNAP progress and request for comment
> > >
> > >
> > >
> > > Hi all,
> > >
> > > As you know, a new SNAP draft has been submitted to (can be found in
> > > http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).
> > >
> > > As one can recall, the SNAP describes a notification protocol
> between a
> > > Messaging Server (e.g. Email Server) and a Notification server
> > > (as specified
> > > in the draft).
> > >
> > > I would like to share some of the changes / decisions made and ask for
> > > comment on them:
> > >
> > > 1. Bind the SNAP to HTTP. This was a very big issue that we
> closed (after
> > > putting it in the SNAP mailing list). There where 3 alternatives:
> > > 	- HTTP
> > > 	- BEEP
> > > 	- No binding (and leaving the decision to the implementers).
> > >     Comments?
> > >
> > > 2. Choose 2822 like as the format of the SNAP payload. Again,
> > > there where a
> > > few alternatives:
> > > 	- 2822 Like,
> > > 	- XML
> > > 	- In the HTTP query string (in the format of "attribute = value&)
> > >     2822 like format was chosen as it is more "friendly" to
> email servers.
> > > XML has a great deal of supporters as well so it was hard to
> > > decide. I would
> > > be happy to get comments.
> > >
> > > 3. Make sure that the SNAP is compatible with 2822.
> > >
> > > 4. Made sure that message-Context is compatible with
> > > http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt
> > >
> > > 5. Draft structural changes:
> > > 	- Added top-level requirements,
> > > 	- Partitioned the draft to 3 main part: Transport Layer, Semantics
> > > and format.
> > > 	- Better define the scope of the SNAP.
> > > 	- Added both IANA and Security considerations
> > > 	- Added extended terminology
> > >
> > >
> > > I would be happy to get comments and suggestions
> > >
> > > Thanks
> > >
> > > Noam
> > >
> > >
> > >
> >
> >
> >
>
>

From: "Shapira, Noam" <[email-masked]>
To: [email-masked]
Subject: FW: SNAP progress and request for comment
Date: Thu, 13 Dec 2001 01:35:05 +0200
Sender: [email-masked]

As I am not sure it arrived

-----Original Message-----
From: Shapira, Noam(Wakefield) 
Sent: Wednesday, December 12, 2001 5:27 PM
To: [email-masked]; Shapira, Noam; [email-masked];
[email-masked]; [email-masked]
Subject: RE: SNAP progress and request for comment

Thanks for your comment

See my comments in text:

> I have a few comments about the current draft, and some larger comments
> about the scope of the ID
> 
> In section 3.5.11 and 3.5.12 regarding attachment names and number of
> attachments, using Content Disposition isn't a very reliable way of
gaining
> this information. Perhaps an IMAP-like bodystructure that's annotated with
> attachment information would be more useful.
Basically I agree that Content Disposition isn't the best thing. But, your
alternative will make the work very "expensive". If for each email entering
the system we will need to do this annotation - it will be a killer for the
SMTP process on the email server side. Any one - thoughts on the issue?

> 
> 3.5.14 - Body should enable sending non-text body content - the decision
on
> what is appropriate content is outside the scope of SNAP.
I am not sure I agree with you. This is a notification protocol and not a
messaging transferring  protocol. The notification protocol should be rich
enough in order to allow the notification server (or the UA that the
notification server usses to notify the user) to retrieve the new message.
The fact that we added the text (and maybe we shouldn't have..) was because
of the facts that some of the UA are primitive and can't retrieve the
message.

> 
> 3.6 - counters group - specific message type counters are very limiting,
it
> would be better to have an extensible mechanism.
See my later comment on the issue
> 
> General comment:
> 
> This protocol is very specific to notification of mailbox status but
mailbox
> status is just one of the many applications that use notification.  It
seems
> that there should be application specific payload descriptions in the body
> of these messages one of them related to MWI and other mailbox related
> information and other related to other notification events.  The interface
> to the notification service should handle more than mailbox events.
> 
> I strongly encourage you to expand the capabilities of the notification ID
> by generalizing payload, counters and by adding an area for application
> specific metadata.   As application developers or future IETF working
groups
> adopt the notification standard, they would publish the definition of that
> application specific usage.
> 
The idea of having one notification protocol for a range of notification
events has been talked about in the past. The problem with this is that
trying to have a generic notification protocol has been tried in the past
and failed. What we are trying to do is to attack the problem - one after
the other - starting with the messaging arena. I understand the wish to have
a multi-purpose protocol for notification (I share it) but it will be
impossible to close it ever. We might need to add a header that will help us
to extend the protocol later on. What do you think?

> Milt Roselinsky
> Openwave Systems
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Shapira, Noam
> > Sent: Tuesday, December 04, 2001 10:39 PM
> > To: [email-masked]
> > Subject: SNAP progress and request for comment
> >
> >
> >
> > Hi all,
> >
> > As you know, a new SNAP draft has been submitted to (can be found in
> > http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).
> >
> > As one can recall, the SNAP describes a notification protocol between a
> > Messaging Server (e.g. Email Server) and a Notification server
> > (as specified
> > in the draft).
> >
> > I would like to share some of the changes / decisions made and ask for
> > comment on them:
> >
> > 1. Bind the SNAP to HTTP. This was a very big issue that we closed
(after
> > putting it in the SNAP mailing list). There where 3 alternatives:
> > 	- HTTP
> > 	- BEEP
> > 	- No binding (and leaving the decision to the implementers).
> >     Comments?
> >
> > 2. Choose 2822 like as the format of the SNAP payload. Again,
> > there where a
> > few alternatives:
> > 	- 2822 Like,
> > 	- XML
> > 	- In the HTTP query string (in the format of "attribute = value&)
> >     2822 like format was chosen as it is more "friendly" to email
servers.
> > XML has a great deal of supporters as well so it was hard to
> > decide. I would
> > be happy to get comments.
> >
> > 3. Make sure that the SNAP is compatible with 2822.
> >
> > 4. Made sure that message-Context is compatible with
> > http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt
> >
> > 5. Draft structural changes:
> > 	- Added top-level requirements,
> > 	- Partitioned the draft to 3 main part: Transport Layer, Semantics
> > and format.
> > 	- Better define the scope of the SNAP.
> > 	- Added both IANA and Security considerations
> > 	- Added extended terminology
> >
> >
> > I would be happy to get comments and suggestions
> >
> > Thanks
> >
> > Noam
> >
> >
> >
> 
> 
> 

Date: Wed, 12 Dec 2001 22:05:16 +0200
From: John Neystadt <[email-masked]>
Subject: Some thoughts about IMAP and Unified Messaging
To: [email-masked], [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_/6nOZTVEQlKXkBJUwktN3w)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi!

Analyzing a set of internal IMAP uses/abuses and recent developments in VPIM
group I've came with a list of few modification that can make IMAP ore
friendly with Unified Messaging. If they make sense and represent an
interest for others, I am ready to formulate them and submit as drafts.

1. IMAP: Extend SORT to support Message-Context
IMAP-SORT draft supports sorting by a number of keywords (To, Date, Subject,
etc). In order to support sorting per message type it should be extended to
support either arbitrary MIME header or at least Message-Context header
(vpim-hint).

2. IMAP: Add support for UIDs in unsolicited events

Currently unsolicited events in IMAP return Sequence ids of messages. This
requires User-Agent to query server upon receiving unsolicited event for
whole message list if it did not yet fetched list of all messages. Supplying
UIDs will allow server to fetch information only the message that has
changed and reflect it in UI.

3. IMAP: Add support of per Message-Context counters in STATUS command

Currently STATUS Command includes TOTAL and UNSEEN counters. Since UM
user-Agent wants to present counters per Message-Context they should be
included.

4. IMAP: Add support for STATUS of multiple folders

Often User-Agents present a list of folders with counters of a new messages
per each of them. Today STATUS command per folder must be issued. The idea
is to extend STATUS to receive a list of folders as a parameter and produce
single response for all of them.

5. IMAP: Add support for IDLE of multiple folders

Today User-Agents display a list of folders with counters. In order to
maintain list of counters they continuously poll the server with STATUS
command. Instead IDLE with list of folders could enable it to be processed
in a push mode.

6. IMAP: Standardize English names for standard (system) folders in addition
to INBOX - Sent Items, Drafts, Outbox, Deleted Items

Currently localization of INBOX occurs on User-Agent side, while rest of
folders are create directly in local agent. This requires the user to
configure the names of the folders in the User-Agent. The idea is to
standardize English names for all standard folders and make the User-Agent
only to display them in local language.

7. Add support of two new system IMAP flags - to mark messages with \Spam
and \Adult content.

Today SMTP-MTAs often support SPAM and Adult content filtering. Not always
it is possible to remove a message with wrong content, since sometimes a
doubt exist regarding the correctness of the identification. By marking the
message in doubt with system-flag, it will allow User-Agents to process such
messages differently (i.e. color them or put in special folder).

John Neystadt
[email-masked]
http://www.neystadt.org/john/

--Boundary_(ID_/6nOZTVEQlKXkBJUwktN3w)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY dir=ltr bgColor=#ffffff background="">
<DIV><FONT face=Arial size=2>Hi!<BR><BR>Analyzing a set of internal IMAP 
uses/abuses and recent developments in VPIM group I've came with a list of few 
modification that can make IMAP ore friendly with Unified Messaging. If they 
make sense and represent an interest for others, I am ready to formulate them 
and submit as drafts.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>1. IMAP: Extend SORT to support 
Message-Context</FONT></DIV>
<DIV>
<P><FONT face=Arial size=2>IMAP-SORT draft supports sorting by a number of 
keywords (To, Date, Subject, etc). In order to support sorting per message type 
it should be extended to support either arbitrary MIME header or at least 
Message-Context header (vpim-hint).</FONT></P>
<P><FONT face=Arial size=2>2. IMAP: Add support for UIDs in unsolicited 
events</FONT></P>
<P><FONT face=Arial size=2>Currently unsolicited events in IMAP return Sequence 
ids of messages. This requires User-Agent to query server upon receiving 
unsolicited event for whole message list if it did not yet fetched list of all 
messages. Supplying UIDs will allow server to fetch information only the message 
that has changed and reflect it in UI.</FONT></P>
<P><FONT face=Arial size=2>3. IMAP: Add support of per Message-Context counters 
in STATUS command</FONT></P>
<P><FONT face=Arial size=2>Currently STATUS Command includes TOTAL and UNSEEN 
counters. Since UM user-Agent wants to present counters per Message-Context they 
should be included.</FONT></P>
<P><FONT face=Arial size=2>4. IMAP: Add support for STATUS of multiple 
folders</FONT></P>
<P><FONT face=Arial size=2>Often User-Agents present a list of folders with 
counters of a new messages per each of them. Today STATUS command per folder 
must be issued. The idea is to extend STATUS to receive a list of folders as a 
parameter and produce single response for all of them.</FONT></P>
<P><FONT face=Arial size=2>5. IMAP: Add support for IDLE of multiple 
folders</FONT></P>
<P><FONT face=Arial size=2>Today User-Agents display a list of folders with 
counters. In order to maintain list of counters they continuously poll the 
server with STATUS command. Instead IDLE with list of folders could enable it to 
be processed in a push mode.</FONT></P>
<P><FONT face=Arial size=2>6. IMAP: Standardize English names for standard 
(system) folders in addition to INBOX - Sent Items, Drafts, Outbox, Deleted 
Items</FONT></P>
<P><FONT face=Arial size=2>Currently localization of INBOX occurs on User-Agent 
side, while rest of folders are create directly in local agent. This requires 
the user to configure the names of the folders in the User-Agent. The idea is to 
standardize English names for all standard folders and make the User-Agent only 
to display them in local language.</FONT></P>
<P><FONT face=Arial size=2>7. Add support of two new system IMAP flags - to mark 
messages with \Spam and \Adult content.</FONT></P>
<P><FONT face=Arial size=2>Today SMTP-MTAs often support SPAM and Adult content 
filtering. Not always it is possible to remove a message with wrong content, 
since sometimes a doubt exist regarding the correctness of the identification. 
By marking the message in doubt with system-flag, it will allow User-Agents to 
process such messages differently (i.e. color them or put in special 
folder).</FONT></P>
<P><FONT face=Arial size=2>John Neystadt<BR>[email-masked]<BR><A 
href="http://www.neystadt.org/john/">http://www.neystadt.org/john/</A></FONT></P>
<P><FONT face=Arial size=2></FONT>&nbsp;</P></DIV></BODY></HTML>

--Boundary_(ID_/6nOZTVEQlKXkBJUwktN3w)--

From: "Milt Roselinsky" <[email-masked]>
To: "Shapira, Noam" <[email-masked]>, <[email-masked]>
Subject: RE: SNAP progress and request for comment
Date: Tue, 11 Dec 2001 07:53:34 -0800
Importance: Normal
Sender: [email-masked]

I have a few comments about the current draft, and some larger comments
about the scope of the ID

In section 3.5.11 and 3.5.12 regarding attachment names and number of
attachments, using Content Disposition isn't a very reliable way of gaining
this information. Perhaps an IMAP-like bodystructure that's annotated with
attachment information would be more useful.

3.5.14 - Body should enable sending non-text body content - the decision on
what is appropriate content is outside the scope of SNAP.

3.6 - counters group - specific message type counters are very limiting, it
would be better to have an extensible mechanism.

General comment:

This protocol is very specific to notification of mailbox status but mailbox
status is just one of the many applications that use notification.  It seems
that there should be application specific payload descriptions in the body
of these messages one of them related to MWI and other mailbox related
information and other related to other notification events.  The interface
to the notification service should handle more than mailbox events.

I strongly encourage you to expand the capabilities of the notification ID
by generalizing payload, counters and by adding an area for application
specific metadata.   As application developers or future IETF working groups
adopt the notification standard, they would publish the definition of that
application specific usage.

Milt Roselinsky
Openwave Systems

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Shapira, Noam
> Sent: Tuesday, December 04, 2001 10:39 PM
> To: [email-masked]
> Subject: SNAP progress and request for comment
>
>
>
> Hi all,
>
> As you know, a new SNAP draft has been submitted to (can be found in
> http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).
>
> As one can recall, the SNAP describes a notification protocol between a
> Messaging Server (e.g. Email Server) and a Notification server
> (as specified
> in the draft).
>
> I would like to share some of the changes / decisions made and ask for
> comment on them:
>
> 1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
> putting it in the SNAP mailing list). There where 3 alternatives:
> 	- HTTP
> 	- BEEP
> 	- No binding (and leaving the decision to the implementers).
>     Comments?
>
> 2. Choose 2822 like as the format of the SNAP payload. Again,
> there where a
> few alternatives:
> 	- 2822 Like,
> 	- XML
> 	- In the HTTP query string (in the format of "attribute = value&)
>     2822 like format was chosen as it is more "friendly" to email servers.
> XML has a great deal of supporters as well so it was hard to
> decide. I would
> be happy to get comments.
>
> 3. Make sure that the SNAP is compatible with 2822.
>
> 4. Made sure that message-Context is compatible with
> http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt
>
> 5. Draft structural changes:
> 	- Added top-level requirements,
> 	- Partitioned the draft to 3 main part: Transport Layer, Semantics
> and format.
> 	- Better define the scope of the SNAP.
> 	- Added both IANA and Security considerations
> 	- Added extended terminology
>
>
> I would be happy to get comments and suggestions
>
> Thanks
>
> Noam
>
>
>

Date: Sun, 09 Dec 2001 16:16:23 -0700
From: Chris Newman <[email-masked]>
To: "Shapira, Noam" <[email-masked]>, [email-masked]
Subject: Re: SNAP progress and request for comment
Sender: [email-masked]

--On Wednesday, December 5, 2001 8:39 +0200 "Shapira, Noam" 
<[email-masked]> wrote:
> 1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
> putting it in the SNAP mailing list). There where 3 alternatives:
> 	- HTTP
> 	- BEEP
> 	- No binding (and leaving the decision to the implementers).
>     Comments?

I strongly prefer BEEP because this is the sort of thing BEEP was designed 
for.  I am strongly opposed to an HTTP-only option, because HTTP is two or 
three times the complexity of BEEP and provides less functionality when 
abused as a protocol framework.  In particular, HTTP has an inflexible 
security model, complex and spotty support for persistant connections, and 
complex proxy semantics.  You'll have to write a lot of text to justify the 
abuse of HTTP and there's a good chance the IESG will reject it, especially 
given the experience with IPP.  BEEP would be a slam-dunk.

> 2. Choose 2822 like as the format of the SNAP payload. Again, there where
> a few alternatives:
> 	- 2822 Like,
> 	- XML
> 	- In the HTTP query string (in the format of "attribute = value&)
>     2822 like format was chosen as it is more "friendly" to email servers.
> XML has a great deal of supporters as well so it was hard to decide. I
> would be happy to get comments.

I'd lean slightly towards XML, since I think all email servers will 
eventually end up with an XML parser for one reason or another, but there's 
really no reason for a notification server to have anything other than an 
XML parser.  Having written an XML and a 2822 parser, they're about the 
same complexity although XML is slightly more flexible with respect to 
structure.  Of course we're talking about one moderate-sized .c file either 
way so it just doesn't matter much in the big picture.

		- Chris

From: "Shapira, Noam" <[email-masked]>
To: [email-masked]
Subject: SNAP progress and request for comment
Date: Wed, 5 Dec 2001 08:39:21 +0200 
Sender: [email-masked]

Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.

4. Made sure that message-Context is compatible with
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt

5. Draft structural changes: 
	- Added top-level requirements, 
	- Partitioned the draft to 3 main part: Transport Layer, Semantics
and format.
	- Better define the scope of the SNAP.
	- Added both IANA and Security considerations
	- Added extended terminology		

I would be happy to get comments and suggestions

Thanks

Noam

From: "Shapira, Noam" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SNAP progress and request for comment
Date: Wed, 5 Dec 2001 08:13:24 +0200 
Sender: [email-masked]

Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.

4. Made sure that message-Context is compatible with
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt

5. Draft structural changes: 
	- Added top-level requirements, 
	- Partitioned the draft to 3 main part: Transport Layer, Semantics
and format.
	- Better define the scope of the SNAP.
	- Added both IANA and Security considerations
	- Added extended terminology		

I would be happy to get comments and suggestions

Thanks

Noam

From: "Shapira, Noam" <[email-masked]>
To: [email-masked]
Subject: SNAP progress and request for comment
Date: Tue, 4 Dec 2001 19:38:38 +0200 
Sender: [email-masked]

Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.

4. Made sure that message-Context is compatible with
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt

5. Draft structural changes: 
	- Added top-level requirements, 
	- Partitioned the draft to 3 main part: Transport Layer, Semantics
and format.
	- Better define the scope of the SNAP.
	- Added both IANA and Security considerations
	- Added extended terminology		

I would be happy to get comments and suggestions

Thanks

Noam

Date: Tue, 04 Dec 2001 00:37:10 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

> We can also discuss LISTEXT if there is enough interest (Barry, are you
> coming to Salt Lake?)

I'm not, no -- no travel money.  If you discuss it, though, send me notes
and I'll make adjustments to the draft, and we can continue discussion on
the mailing list -- 's been pretty quiet of late.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Mon, 03 Dec 2001 22:13:56 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

Cyrus Daboo wrote:

> --On Monday, December 3, 2001 12:11 PM -0600 Pete Resnick
> <[email-masked]> wrote:
>
> > What are we talking about other than ANNOTATE and ACL?
>
> Conditional store - since ANNOTATE references that. Also we should discuss
> the issue of i18n for SORT/THREAD (which was a requirement from the last
> meeting). There is an i18n for internet protocols boff earlier in the week
> which I think will be relevant to this.

I tend to agree with Cyrus.

We can also discuss LISTEXT if there is enough interest (Barry, are you coming
to Salt Lake?)

On a related note, what happend to WINDOW?

Alexey

Date: Mon, 03 Dec 2001 13:55:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

--On Monday, December 3, 2001 12:11 PM -0600 Pete Resnick 
<[email-masked]> wrote:

> What are we talking about other than ANNOTATE and ACL?

Conditional store - since ANNOTATE references that. Also we should discuss 
the issue of i18n for SORT/THREAD (which was a requirement from the last 
meeting). There is an i18n for internet protocols boff earlier in the week 
which I think will be relevant to this.

-- 
Cyrus Daboo

Date: Mon, 3 Dec 2001 12:49:47 -0600
To: "Shapira, Noam" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: Agenda
Cc: [email-masked]
Sender: [email-masked]

On 12/3/01 at 8:39 PM +0200, you wrote:

>I would be happy if I could get the opportunity to present the new version
>of SNAP (Simple Notification and Alarm Protocol) - discuss some of the
>decisions taken in the new draft (some of which where raised in this mailing
>list and in other mailing list).

There won't be presentations in the WG session. I'd be happy to give 
you time on the agenda if you write up and send out to the WG list 
(in the next day or so) the decisions taken in the new draft that you 
wish to discuss. We don't need to waste the time having you present 
this in the WG session itself. Send a message, let people comment on 
the list, and those items that don't get satisfactory review can be 
discussed at the WG meeting.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: "Shapira, Noam" <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: RE: Agenda
Date: Mon, 3 Dec 2001 20:39:46 +0200 
Sender: [email-masked]

Hi,

I would be happy if I could get the opportunity to present the new version
of SNAP (Simple Notification and Alarm Protocol) - discuss some of the
decisions taken in the new draft (some of which where raised in this mailing
list and in other mailing list).

The new draft is available in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt.

Noam

> -----Original Message-----
> From: Pete Resnick [mailto:[email-masked]]
> Sent: Monday, December 03, 2001 8:12 PM
> To: [email-masked]
> Subject: Agenda
> 
> 
> 
> What are we talking about other than ANNOTATE and ACL?
> 
> pr
> -- 
> Pete Resnick <mailto:[email-masked]>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: 
> (858)651-1102
> 

Date: Mon, 3 Dec 2001 12:11:57 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Agenda
Sender: [email-masked]

What are we talking about other than ANNOTATE and ACL?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-02.txt
Date: Mon, 03 Dec 2001 08:37:55 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-02.txt
	Pages		: 19
	Date		: 30-Nov-01
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-annotate-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-annotate-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-annotate-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 21 Dec 2001 10:44:26 -0600
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: SORT and multiple From:
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

On 12/21/01 at 3:11 PM +0100, Arnt Gulbrandsen wrote:

>AFAIK, there are so far two cases where header field order matters in the
>internet mail protocols: for "received:" and sometimes for "resent-*:".
>
>This sorting issue adds a third case. Unavoidably, as far as I can tell.
>Still, it makes me sad. Wish I could think of a way to avoid it.

It's not multiple From: header fields, it's multiple From: addresses 
in the same header field.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 21 Dec 2001 15:11:03 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Subject: Re: SORT and multiple From:
Sender: [email-masked]

AFAIK, there are so far two cases where header field order matters in the
internet mail protocols: for "received:" and sometimes for "resent-*:".

This sorting issue adds a third case. Unavoidably, as far as I can tell.
Still, it makes me sad. Wish I could think of a way to avoid it.

And a merry christmas to all of you.

--Arnt

Date: Wed, 19 Dec 2001 15:37:38 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: IMAPEXT minutes
Sender: [email-masked]

Here are the minutes I took at the IMAPEXT meeting.  If you feel I am 
missing anything or inaccurate on any point, please email me the 
corrections (feel free to CC to the list, but I need to get them in email).

If you wish to discuss any issues from the minutes, please change your 
subject line to one specific to the issue you're discussing.

		Thanks,
		- Chris

----
IMAP Extensions WG 2001-12-13 Salt Lake City IETF

9:00 - 11:30

ANNOTATE

three outstanding issues

1. Mirroring IMAP flags in annotations

If we do it we need to distinguish shared/private flags.  Some discussion 
of the issue.  If ANNOTATE gets widely deployed, the shared/private model 
is more useful.  But clients will have to implement support for old flags 
model in addition to ANNOTATE flags model.  People are willing to implement 
ANNOTATE flags and opposition is mostly in the "not worth it" camp.  Rough 
concensus based on hum at meeting to go ahead and add flags.

Shared vs. private flags.  Could advertise SHAREFLAGS and PRIVATEFLAGS, but 
is it worth it?  What happens if client stores shared deleted when server 
implements client deleted?  Needs to be documented clearly.

2. When should server issue unsolicited ANNOTATE responses?

Implicit after use of annotations, or explicit tag on SELECT/EXAMINE.

No strong feelings in either direction.  So let the author make the choice.

3. How to tie ACL rights to ANNOTATIONS?

If you have READ-ONLY access to a mailbox you can only change private 
annotations.  READ-WRITE means you can change both private and shared.

Discussion: are we requiring servers to implement both private and shared 
annotations?  Yes.

ACL: write access lets you set shared, read access lets you set private.

Also need to explicitly say that annotations must persist across sessions, 
exception for flags mapped to annotations which are listed in FLAGS but not 
in PERMANANTFLAGS.

We will do a WG last call on the next revision due Jan 15.

------
CONDITIONAL STORE

Major change: replaced MODTIME with MODSEQ.

Open Issues:
Need to synchronize with annotate document.  Do we need SORT for MODSEQ? 
People like to sort directories by date, so it would be useful.

If you do conditional store for a message set it's currently atomic, all 
stores succeed or fail.  No rough consensus either way for conditional 
store on message set.  Weak consensus to leave it atomic and get 
implementation experience.

Randy has volunteered to help with language in the draft.  We will do a WG 
last call on the next revision due Jan 15.
-----
ACLs

Proposal: "d" is a macro for two new rights: one for set deleted flag, one 
for delete folder.

Proposal: "anyone" and "$" prefix are non-users.  "-" is negative rights. 
All other identifiers are presumed to be users.  Could use "$$" prefix for 
user name
beginning "$".

We must have a new capability.  It is desirable for the new ACL to have a 
superset of the syntax of the old ACL. This way server implemented to new 
ACL should work with both old and new ACL clients.  Rough consensus.

Proposal: An additional capability to advertise semantics of ACLs if 
different from the union model.  Need to take this to the list.

We will solicit input on proposal.  Target is Feb 1st for ACL extension 
draft.
-----
LISTEXT

Issues with LISTEXT: doesn't do enough.

Needs more discussion on the list.

There is a proposal to add attribute-value pairs.
-----
Pete Action item: ask Mark to add i18n to SORT/THREAD

SORT on arbitrary headers is desirable.  Cyrus will post to list to add 
arbitrary headers.
-----
Pete Action item: ask Mark to last call the imapv draft.
-----
SNAP

Request to get review of SNAP (notifications) draft by IMAP community.

Date: Mon, 17 Dec 2001 17:26:34 -0800 (PST)
From: [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging
To: Pete Maclean <[email-masked]>
Cc: Larry Osterman <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > Um...  No, this NOT IMAP poking it's nose where it doesn't belong.  It's
> > a critical part of the design of the offline mode of IMAP.

> > IMAP clients depend on the fact that UIDs are assigned to messages that
> > are constant and are strictly increasing (note: NOT monotonically).  If
> > this constraint is violated, then a client does not have the ability to
> > resynchronize with the server.

And this condition may be satisfied by assigning UIDs to messages when
the IMAP server first encounters them. It may be impractical to assign them
at the time the messages are added to a given folder.

> We may be talking at cross purposes.  I believe I understand the role of
> UIDs perfectly and appreciate their enormous value in the overall IMAP
> design.  I was taking issue only with the question of exactly when they
> must be assigned.  I cannot see that it matters if a message is not
> assigned an IMAP UID if IMAP never sees that message.

Quite right.

> On the other hand, there are so many ways to interpret things that this may
> all be moot.  My IMAP server assigns UIDs to messages that don't have them
> when it opens a folder.  I tend to think of a message being added to a
> folder when a transport provider or client puts it there.  But we could say
> that a "MAPI folder" virtually becomes an "IMAP folder" when and only when
> the server opens it and, in that virtual sense, new messages are added and
> assigned UIDs only at that point.  In which case I am following this part
> of the spec to the letter.

Well, the messages really are there with no UIDs assigned, so I prefer
to think of it as assignment when the folder is first opened by IMAP.

				Ned

content-class: urn:content-classes:message
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Mon, 17 Dec 2001 17:23:45 -0800
From: "Larry Osterman" <[email-masked]>
To: "Pete Maclean" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Then you're right - we're talking at cross purposes - the "message is
assigned..." stuff I wrote was particular to the Exchange implementation
of IMAP.  The spec's comments are totally correct however from a
conceptual standpoint - and the wording is critical - there are many
ways a message can be added to a mailbox, and all of them assign new
UIDs.   

-----Original Message-----
From: Pete Maclean [mailto:[email-masked]] 
Sent: Monday, December 17, 2001 4:36 PM
To: Larry Osterman; Cyrus Daboo
Cc: [email-masked]; [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging

>Um...  No, this NOT IMAP poking it's nose where it doesn't belong.
It's
>a critical part of the design of the offline mode of IMAP.
>
>IMAP clients depend on the fact that UIDs are assigned to messages that
>are constant and are strictly increasing (note: NOT monotonically).  If
>this constraint is violated, then a client does not have the ability to
>resynchronize with the server.

We may be talking at cross purposes.  I believe I understand the role of

UIDs perfectly and appreciate their enormous value in the overall IMAP 
design.  I was taking issue only with the question of exactly when they 
must be assigned.  I cannot see that it matters if a message is not 
assigned an IMAP UID if IMAP never sees that message.

On the other hand, there are so many ways to interpret things that this
may 
all be moot.  My IMAP server assigns UIDs to messages that don't have
them 
when it opens a folder.  I tend to think of a message being added to a 
folder when a transport provider or client puts it there.  But we could
say 
that a "MAPI folder" virtually becomes an "IMAP folder" when and only
when 
the server opens it and, in that virtual sense, new messages are added
and 
assigned UIDs only at that point.  In which case I am following this
part 
of the spec to the letter.

Pete

Date: Mon, 17 Dec 2001 19:36:00 -0500
To: "Larry Osterman" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: RE: Some thoughts about IMAP and Unified Messaging
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

>Um...  No, this NOT IMAP poking it's nose where it doesn't belong.  It's
>a critical part of the design of the offline mode of IMAP.
>
>IMAP clients depend on the fact that UIDs are assigned to messages that
>are constant and are strictly increasing (note: NOT monotonically).  If
>this constraint is violated, then a client does not have the ability to
>resynchronize with the server.

We may be talking at cross purposes.  I believe I understand the role of 
UIDs perfectly and appreciate their enormous value in the overall IMAP 
design.  I was taking issue only with the question of exactly when they 
must be assigned.  I cannot see that it matters if a message is not 
assigned an IMAP UID if IMAP never sees that message.

On the other hand, there are so many ways to interpret things that this may 
all be moot.  My IMAP server assigns UIDs to messages that don't have them 
when it opens a folder.  I tend to think of a message being added to a 
folder when a transport provider or client puts it there.  But we could say 
that a "MAPI folder" virtually becomes an "IMAP folder" when and only when 
the server opens it and, in that virtual sense, new messages are added and 
assigned UIDs only at that point.  In which case I am following this part 
of the spec to the letter.

Pete

content-class: urn:content-classes:message
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Mon, 17 Dec 2001 16:18:16 -0800
From: "Larry Osterman" <[email-masked]>
To: "Pete Maclean" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Um...  No, this NOT IMAP poking it's nose where it doesn't belong.  It's
a critical part of the design of the offline mode of IMAP.

IMAP clients depend on the fact that UIDs are assigned to messages that
are constant and are strictly increasing (note: NOT monotonically).  If
this constraint is violated, then a client does not have the ability to
resynchronize with the server.  

Cyrus is right: It is an implementation detail of the Exchange server
that all messages in the folder must have a UID, in Exchange we have the
luxury of having code that runs when messages are delivered to users AND
when they are retrieved by IMAP, in a server that does not have that
luxury, they must assign UIDs at SELECT time, and must (as he said)
assign them to messages that have not yet had a UID assigned.  My smiley
was intended as a "Oh, right - I forgot to mention this really critical
detail" - sort of an "oops" similey :)

-----Original Message-----
From: Pete Maclean [mailto:[email-masked]] 
Sent: Monday, December 17, 2001 3:47 PM
To: Larry Osterman; Cyrus Daboo
Cc: [email-masked]; [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging

>Ah - you didn't catch one internal detail (and it's an important one
>:)):
>
>         If a message exists in a folder, it MUST have a UID.

Do you say this based on IMAP's assertion that "as each message is added
to 
the mailbox it is assigned a higher UID..."?  In my view, this is IMAP 
poking its nose in where it has no business being.  I hope I am not
missing 
anything, but I cannot see that it makes any difference if UIDs are 
assigned only when the IMAP server opens a folder. But you say this
detail 
is important, Larry, and I wonder why...or should I read your smiley as 
belying that?

>Any alternative imposes a significant penalty during the SELECT phase
of
>the mailbox.  In the current implementation for Exchange, select needs
>to modify one column in one row in the database (it needs to update the
>last selected UID property in the folder).  Since the UID's are
assigned
>when the messages are added to the folder, the SELECT command doesn't
>have to write to the messages table (ok, to be exact, the
message-folder
>table, but...).  If we were to to assign UIDs on select, every the row
>in the message-folder table for each new message would need to be
>rewritten - which could conceivably be several hundred database writes
>(if there are enough messages in the folder).  It's far better to take
a
>very small hit when adding messages (when you're already writing the
>message-folder table to add the message) then it is to modify the table
>after the message has been created.

No question but my method is far from ideal in terms of performance.
Maybe 
I could set a hook and issue UIDs as messages are added to folders --
and 
maybe I will at some future point -- but for now I am satisfied with
what I 
have.  Performance is less of an issue for me than for you.  You're
dealing 
with a heavy-duty server environment where there can be a large number
of 
simultaneous users.  My market is more shared and remote access to
Outlook 
often in the absence of Exchange.

Pete

Date: Mon, 17 Dec 2001 18:47:13 -0500
To: "Larry Osterman" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: RE: Some thoughts about IMAP and Unified Messaging
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

>Ah - you didn't catch one internal detail (and it's an important one
>:)):
>
>         If a message exists in a folder, it MUST have a UID.

Do you say this based on IMAP's assertion that "as each message is added to 
the mailbox it is assigned a higher UID..."?  In my view, this is IMAP 
poking its nose in where it has no business being.  I hope I am not missing 
anything, but I cannot see that it makes any difference if UIDs are 
assigned only when the IMAP server opens a folder. But you say this detail 
is important, Larry, and I wonder why...or should I read your smiley as 
belying that?

>Any alternative imposes a significant penalty during the SELECT phase of
>the mailbox.  In the current implementation for Exchange, select needs
>to modify one column in one row in the database (it needs to update the
>last selected UID property in the folder).  Since the UID's are assigned
>when the messages are added to the folder, the SELECT command doesn't
>have to write to the messages table (ok, to be exact, the message-folder
>table, but...).  If we were to to assign UIDs on select, every the row
>in the message-folder table for each new message would need to be
>rewritten - which could conceivably be several hundred database writes
>(if there are enough messages in the folder).  It's far better to take a
>very small hit when adding messages (when you're already writing the
>message-folder table to add the message) then it is to modify the table
>after the message has been created.

No question but my method is far from ideal in terms of performance.  Maybe 
I could set a hook and issue UIDs as messages are added to folders -- and 
maybe I will at some future point -- but for now I am satisfied with what I 
have.  Performance is less of an issue for me than for you.  You're dealing 
with a heavy-duty server environment where there can be a large number of 
simultaneous users.  My market is more shared and remote access to Outlook 
often in the absence of Exchange.

Pete

Date: Mon, 17 Dec 2001 17:47:17 -0500
From: Cyrus Daboo <[email-masked]>
To: Larry Osterman <[email-masked]>, Pete Maclean <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

--On Monday, December 17, 2001 2:37 PM -0800 Larry Osterman 
<[email-masked]> wrote:

> Ah - you didn't catch one internal detail (and it's an important one
> :)):
>
> 	If a message exists in a folder, it MUST have a UID.

But Pete said he manufactured his own UID for his IMAP server, so 
presumably his UID property on the message is not set until his server 
first 'sees' the message. At least that's what I thought he was doing.

-- 
Cyrus Daboo

content-class: urn:content-classes:message
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Mon, 17 Dec 2001 14:37:16 -0800
From: "Larry Osterman" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Pete Maclean" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Ah - you didn't catch one internal detail (and it's an important one
:)):

	If a message exists in a folder, it MUST have a UID.

Any alternative imposes a significant penalty during the SELECT phase of
the mailbox.  In the current implementation for Exchange, select needs
to modify one column in one row in the database (it needs to update the
last selected UID property in the folder).  Since the UID's are assigned
when the messages are added to the folder, the SELECT command doesn't
have to write to the messages table (ok, to be exact, the message-folder
table, but...).  If we were to to assign UIDs on select, every the row
in the message-folder table for each new message would need to be
rewritten - which could conceivably be several hundred database writes
(if there are enough messages in the folder).  It's far better to take a
very small hit when adding messages (when you're already writing the
message-folder table to add the message) then it is to modify the table
after the message has been created.

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]] 
Sent: Monday, December 17, 2001 2:16 PM
To: Pete Maclean; Larry Osterman
Cc: [email-masked]; [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging

--On Monday, December 17, 2001 4:57 PM -0500 Pete Maclean 
<[email-masked]> wrote:

>>   The \Recent flag should be manufactured on a MAPI server.   You
need
>> to remember the UID of the folder on the select verb, and check the
UID
>> of the message against the UID saved in the folder, if it's greater,
the
>> message is recent.  The nature of the \Recent flag is that it can
never
>> be preserved on the message (not if you want to get the correct
>> semantics in a multi-accessed mailbox situation).
>
> I do manufacture it but a little differently from the way you suggest.
> Since I also manufacture my own UIDs, I give a message a \Recent flag
if,
> when I find it, it is marked unread and has no UID assigned.

But that won't work for a copy or append of a seen message, right? 
Technically the \Recent flag should be set on those as well. I would
think 
that 'has no UID assigned' ought to be the only test you need to set 
\Recent.

-- 
Cyrus Daboo

Date: Mon, 17 Dec 2001 17:15:38 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Maclean <[email-masked]>, Larry Osterman <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

--On Monday, December 17, 2001 4:57 PM -0500 Pete Maclean 
<[email-masked]> wrote:

>>   The \Recent flag should be manufactured on a MAPI server.   You need
>> to remember the UID of the folder on the select verb, and check the UID
>> of the message against the UID saved in the folder, if it's greater, the
>> message is recent.  The nature of the \Recent flag is that it can never
>> be preserved on the message (not if you want to get the correct
>> semantics in a multi-accessed mailbox situation).
>
> I do manufacture it but a little differently from the way you suggest.
> Since I also manufacture my own UIDs, I give a message a \Recent flag if,
> when I find it, it is marked unread and has no UID assigned.

But that won't work for a copy or append of a seen message, right? 
Technically the \Recent flag should be set on those as well. I would think 
that 'has no UID assigned' ought to be the only test you need to set 
\Recent.

-- 
Cyrus Daboo

Date: Mon, 17 Dec 2001 16:57:27 -0500
To: "Larry Osterman" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: RE: Some thoughts about IMAP and Unified Messaging
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Larry,

Thank you so much for your message.

>   The \Recent flag should be manufactured on a MAPI server.   You need
>to remember the UID of the folder on the select verb, and check the UID
>of the message against the UID saved in the folder, if it's greater, the
>message is recent.  The nature of the \Recent flag is that it can never
>be preserved on the message (not if you want to get the correct
>semantics in a multi-accessed mailbox situation).

I do manufacture it but a little differently from the way you 
suggest.  Since I also manufacture my own UIDs, I give a message a \Recent 
flag if, when I find it, it is marked unread and has no UID assigned.

>And MAPI does demand that a folder have a display name, the CreateFolder
>method on the IMapiFolder object takes an LPTSTR lpszFolderName
>parameter.

Ah, good point.  This tempted me to go and delete the PR_DISPLAY_NAME for a 
folder to see what would happen...but at the last minute I chickened out.  :-)

>When you are generating the LIST response, you need to check if the
>entryid of the folder you're enumerating is the GetReceiveFolder's name,
>and return "INBOX" for the name of that folder (and not the value of
>PR_DISPLAY_NAME).  This is what the exchange server does internally, and
>it's what you should do too :)

Aha!  That's magnificent intelligence, thank you.  I had not been doing it 
this way because I had implemented a filter for this at a high level where 
nothing MAPIish is known.  But it will be fine to add the code that you 
suggest in addition.  Thank you, thank you.

Pete

Date: Mon, 17 Dec 2001 15:07:49 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Sender: [email-masked]

--On Monday, December 17, 2001 2:41 PM -0500 Pete Maclean 
<[email-masked]> wrote:

> Thanks for your comment.  I chose to deal with this issue by not listing
> the true name of the Inbox in such a case.  But you made me realize
> (thanks again!) that I have a bug.  I took care of CREATE okay but not
> RENAME.  If a user tried to rename a folder to the true name of his
> Inbox, the operation would fail all right but the reason given (that the
> folder already exists) could be misleading.

OK. I guess you also need to trap SELECT, DELETE, SUBSCRIBE and UNSUBSCRIBE 
attempts on that mailbox name too - in fact any command that takes a 
mailbox name as a parameter - there are some extensions that do that.

-- 
Cyrus Daboo

Date: Mon, 17 Dec 2001 14:48:09 -0500
To: Lyndon Nerenberg <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Lyndon,

Once again I am much obliged to you.  Many thanks for your gracious 
response.  And I apologize for assuming too much (or too little depending 
on how you look at it).

Pete

At 12:18 PM 12/17/2001 -0700, Lyndon Nerenberg wrote:
> > If my grasp of ACAP is correct (and please tell me if it is not) then the
> > answer is no.
>
>It's not ;-)
>
> > Not that the problem could not be solved with ACAP -- it
> > seems to me that it could -- but it does not seem an appropriate use of 
> the
> > service.  Would you expect an MUA to use ACAP to obtain a list of a user's
> > mail folders?  I don't think so.  And if that's not appropriate then, it
> > seems to me, that it does not fit the issue in question either.
>
>You don't store the list of mail folders in ACAP. Instead, you define
>an ACAP profile that you use to map from logical folder names (outbox,
>sent mail) to specific folders on specific servers. The profile would
>also contain a mapping from the logical folder name to a locale-specific
>presentation string for use by the MUA. In this way you have completely
>abstracted the logical folders from the implementation space. By using
>ACAP inheritance you can set a default logical folder namespace, and
>then override it on a per-server, per-clienthost, per-mua-type, and
>per-language basis (or via combinations of these).
>
>
>--lyndon
>
>Never hit a man with glasses.  Hit him with a baseball bat.

Date: Mon, 17 Dec 2001 14:41:22 -0500
To: Cyrus Daboo <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Hi Cyrus,

Thanks for your comment.  I chose to deal with this issue by not listing 
the true name of the Inbox in such a case.  But you made me realize (thanks 
again!) that I have a bug.  I took care of CREATE okay but not RENAME.  If 
a user tried to rename a folder to the true name of his Inbox, the 
operation would fail all right but the reason given (that the folder 
already exists) could be misleading.

Pete

At 01:29 PM 12/17/2001 -0500, Cyrus Daboo wrote:
>--On Monday, December 17, 2001 10:02 AM -0800 Mark Crispin 
><[email-masked]> wrote:
>
>>You seem to be distracted by the notion that the INBOX is sometimes
>>reachable by some other string on some systems.  That is a detail that is
>>of no importance whatsoever, thanks to the foresight of IMAP's design.
>
>Actually I have come acrosss cases where users are confused by having a 
>second mailbox in thier hierarchy which appears to be a duplicate of 
>INBOX. They usually don't appreciate that this is the INBOX but with a 
>different name. I don't know this actually happened, but one can conceive 
>of a situation where a confused user will delete and expunge all message 
>in the 'duplicate' mailbox because they believe they are duplicates and 
>not originals.
>
>IMHO The best solution in this case is to have the server not return the 
>duplicate name when asked to LIST of LSUB it. The server then has to 
>reject CREATE or RENAME's that try to use the duplicate name.
>
>--
>Cyrus Daboo

content-class: urn:content-classes:message
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Mon, 17 Dec 2001 11:36:39 -0800
From: "Larry Osterman" <[email-masked]>
To: "Pete Maclean" <[email-masked]>, "Tony Hansen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Pete,

  The \Recent flag should be manufactured on a MAPI server.   You need
to remember the UID of the folder on the select verb, and check the UID
of the message against the UID saved in the folder, if it's greater, the
message is recent.  The nature of the \Recent flag is that it can never
be preserved on the message (not if you want to get the correct
semantics in a multi-accessed mailbox situation).

And MAPI does demand that a folder have a display name, the CreateFolder
method on the IMapiFolder object takes an LPTSTR lpszFolderName
parameter.

When you are generating the LIST response, you need to check if the
entryid of the folder you're enumerating is the GetReceiveFolder's name,
and return "INBOX" for the name of that folder (and not the value of
PR_DISPLAY_NAME).  This is what the exchange server does internally, and
it's what you should do too :)

Larry Osterman 

-----Original Message-----
From: Pete Maclean [mailto:[email-masked]] 
Sent: Monday, December 17, 2001 9:44 AM
To: Tony Hansen
Cc: [email-masked]; [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging

>What's a "true name"? Consider that an IMAP inbox is a name for what is

>sometimes a virtual entity that doesn't have one single location on the

>server. So I find it difficult to expect this.

I don't have much experience with such situations but I certainly do 
appreciate that an inbox may not have a name in the sense I am talking 
about and that it could indeed be a totally virtual entity.  But what I 
mean by "true name" is, to put it very precisely, the name of the
message 
container that the IMAP server refers to as "INBOX" as it is known
within 
the domain of the mailstore that it is part of -- if there is in fact
such 
a container and if it actually has a name by which it is identified
within 
its mailstore.

Let me give a concrete example.  My IMAP server has a MAPI interface
among 
others.  (MAPI is Microsoft's Messaging API.)  This means that it can
serve 
up messages from any mailstore that implements a MAPI Store-Provider 
interface.  Everything in IMAP maps neatly into MAPI except that MAPI
has 
nothing equivalent to IMAP's \Recent flag (which does not matter).  I am

not certain off-hand if MAPI demands that all folders have names, but in

all cases I have seen they certainly do.  Now MAPI includes a method
called 
GetReceiveFolder that identifies the "default receive folder for the 
message store".  This does not exactly match IMAP's definition for inbox

but it's close enough that I have always assumed they should be
considered 
equivalent.  GetReceiveFolder returns an internal id from which one can 
then derive the folder's name.  I would like to be able to feed that
name 
back to the client.  Of course, as Lyndon pointed out so well, it should
be 
up to the client and/or the user to choose whether that name should 
actually be used in the client context, but it seems desirable that this

should at least be possible.

To concretize this issue a little more, with the English-language 
installation of Microsoft's Personal Folders, the folder identified by 
GetReceiveFolder is always "Inbox" -- so it happens to be no big 
deal.  With the German-language installation however the folder is named

"Posteingang".

Pete

Organization: ACI Worldwide - Advanced Technology Group
To: Pete Maclean <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Date: Mon, 17 Dec 2001 12:18:00 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> If my grasp of ACAP is correct (and please tell me if it is not) then the 
> answer is no.  

It's not ;-)

> Not that the problem could not be solved with ACAP -- it 
> seems to me that it could -- but it does not seem an appropriate use of the 
> service.  Would you expect an MUA to use ACAP to obtain a list of a user's 
> mail folders?  I don't think so.  And if that's not appropriate then, it 
> seems to me, that it does not fit the issue in question either.

You don't store the list of mail folders in ACAP. Instead, you define
an ACAP profile that you use to map from logical folder names (outbox,
sent mail) to specific folders on specific servers. The profile would
also contain a mapping from the logical folder name to a locale-specific
presentation string for use by the MUA. In this way you have completely
abstracted the logical folders from the implementation space. By using
ACAP inheritance you can set a default logical folder namespace, and
then override it on a per-server, per-clienthost, per-mua-type, and
per-language basis (or via combinations of these).

--lyndon

Never hit a man with glasses.  Hit him with a baseball bat.

Date: Mon, 17 Dec 2001 13:29:04 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Pete Maclean <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Sender: [email-masked]

--On Monday, December 17, 2001 10:02 AM -0800 Mark Crispin 
<[email-masked]> wrote:

> You seem to be distracted by the notion that the INBOX is sometimes
> reachable by some other string on some systems.  That is a detail that is
> of no importance whatsoever, thanks to the foresight of IMAP's design.

Actually I have come acrosss cases where users are confused by having a 
second mailbox in thier hierarchy which appears to be a duplicate of INBOX. 
They usually don't appreciate that this is the INBOX but with a different 
name. I don't know this actually happened, but one can conceive of a 
situation where a confused user will delete and expunge all message in the 
'duplicate' mailbox because they believe they are duplicates and not 
originals.

IMHO The best solution in this case is to have the server not return the 
duplicate name when asked to LIST of LSUB it. The server then has to reject 
CREATE or RENAME's that try to use the duplicate name.

-- 
Cyrus Daboo

Date: Mon, 17 Dec 2001 10:02:03 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging 
To: Pete Maclean <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 17 Dec 2001 10:48:03 -0500, Pete Maclean wrote:
> Do you not think that it is unfortunate,
> to say the least, that IMAP will faithfully and precisely deliver to an MUA
> a list of all of a user's folders (as long as they have compatible names)
> but will not identify the true name of what we generically call the Inbox,
> the folder that is surely the most important for many users, indeed a
> folder that the IMAP spec itself defines as "the primary mailbox for this
> user on this server"?

It is highly fortunate that IMAP will will identify the true name of the
INBOX.

We even know what IMAP will say:

INBOX

So, the client doesn't even have to ask the IMAP server what the name of the
INBOX is.  It knows because it's an IMAP client.

You seem to be distracted by the notion that the INBOX is sometimes reachable
by some other string on some systems.  That is a detail that is of no
importance whatsoever, thanks to the foresight of IMAP's design.

This is a Very Good Thing.

Date: Mon, 17 Dec 2001 12:43:56 -0500
To: Tony Hansen <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>What's a "true name"? Consider that an IMAP inbox is a name for what is
>sometimes a virtual entity that doesn't have one single location on the
>server. So I find it difficult to expect this.

I don't have much experience with such situations but I certainly do 
appreciate that an inbox may not have a name in the sense I am talking 
about and that it could indeed be a totally virtual entity.  But what I 
mean by "true name" is, to put it very precisely, the name of the message 
container that the IMAP server refers to as "INBOX" as it is known within 
the domain of the mailstore that it is part of -- if there is in fact such 
a container and if it actually has a name by which it is identified within 
its mailstore.

Let me give a concrete example.  My IMAP server has a MAPI interface among 
others.  (MAPI is Microsoft's Messaging API.)  This means that it can serve 
up messages from any mailstore that implements a MAPI Store-Provider 
interface.  Everything in IMAP maps neatly into MAPI except that MAPI has 
nothing equivalent to IMAP's \Recent flag (which does not matter).  I am 
not certain off-hand if MAPI demands that all folders have names, but in 
all cases I have seen they certainly do.  Now MAPI includes a method called 
GetReceiveFolder that identifies the "default receive folder for the 
message store".  This does not exactly match IMAP's definition for inbox 
but it's close enough that I have always assumed they should be considered 
equivalent.  GetReceiveFolder returns an internal id from which one can 
then derive the folder's name.  I would like to be able to feed that name 
back to the client.  Of course, as Lyndon pointed out so well, it should be 
up to the client and/or the user to choose whether that name should 
actually be used in the client context, but it seems desirable that this 
should at least be possible.

To concretize this issue a little more, with the English-language 
installation of Microsoft's Personal Folders, the folder identified by 
GetReceiveFolder is always "Inbox" -- so it happens to be no big 
deal.  With the German-language installation however the folder is named 
"Posteingang".

Pete

Date: Mon, 17 Dec 2001 11:59:18 -0500
From: Tony Hansen <[email-masked]>
To: Pete Maclean <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

Pete Maclean wrote:
> 
> Let me put it as simply as I can:  Do you not think that it is unfortunate,
> to say the least, that IMAP will faithfully and precisely deliver to an MUA
> a list of all of a user's folders (as long as they have compatible names)
> but will not identify the true name of what we generically call the Inbox,
> the folder that is surely the most important for many users, indeed a
> folder that the IMAP spec itself defines as "the primary mailbox for this
> user on this server"?

What's a "true name"? Consider that an IMAP inbox is a name for what is
sometimes a virtual entity that doesn't have one single location on the
server. So I find it difficult to expect this.

	Tony Hansen
	[email-masked]

Date: Mon, 17 Dec 2001 10:48:03 -0500
To: Lyndon Nerenberg <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Lyndon,

> > This approach means we don't have to English-ize names and gets
> > around the problem of Outbox meaning two different things.  The server
> > would respond with either the appropriate name or an indication that there
> > is no such thing.
>
>Wouldn't these be better solved with ACAP or IMSP?

I responded to this briefly before by saying I knew too little about ACAP 
or IMSP to judge.  I have now read up on ACAP and wish to respond more fully.

If my grasp of ACAP is correct (and please tell me if it is not) then the 
answer is no.  Not that the problem could not be solved with ACAP -- it 
seems to me that it could -- but it does not seem an appropriate use of the 
service.  Would you expect an MUA to use ACAP to obtain a list of a user's 
mail folders?  I don't think so.  And if that's not appropriate then, it 
seems to me, that it does not fit the issue in question either.

I am puzzled by the responses to what I have posted.  I am unclear if most 
people agree with me, or if I have not explained my ideas well enough, or 
what.  The ACAP question suggests to me that I have not been clear 
enough.  To me it seems a glaringly obvious flaw.

Let me put it as simply as I can:  Do you not think that it is unfortunate, 
to say the least, that IMAP will faithfully and precisely deliver to an MUA 
a list of all of a user's folders (as long as they have compatible names) 
but will not identify the true name of what we generically call the Inbox, 
the folder that is surely the most important for many users, indeed a 
folder that the IMAP spec itself defines as "the primary mailbox for this 
user on this server"?

Pete

Date: Fri, 14 Dec 2001 06:42:09 -0800
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: The IMC web page
Sender: [email-masked]

Paul Hoffman has asked me to have you all look at the IMC IMAPEXT web 
page at <http://www.imc.org/ietf-imapext/index.html> and e-mail him 
(or me if you prefer) if things are outdated, incorrect, or missing. 
I've already see a few, but if you would go look for your own 
document, that would be quite helpful.

Thanks.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 14 Dec 2001 10:39:52 -0500
From: Tony Hansen <[email-masked]>
To: imapext <[email-masked]>, vpim <[email-masked]>
Subject: Re: [VPIM] re: SORT and arbitrary headers
Sender: [email-masked]

Cyrus Daboo wrote:
> --On Thursday, December 13, 2001 1:43 PM -0800 Mark Crispin
> <[email-masked]> wrote:
> 
> I would say its 50-50 use between sort and thread. I know personally there
> are mailboxes I prefer to view by thread and ones I prefer to view sorted -
> just depends on the nature of the content. 

Me too. My default on some mailboxes is thread, and others sort by date,
and others sort by sender, and others .... However, I also switch around
from one sort method to another, depending on what I'm trying to do with
the messages. Each of the sorting methods and threading has their uses
in different circumstances.

> There are also situations where
> I want to do a sort within thread.

ditto.

	Tony Hansen
	[email-masked]

P.S. I thought I was going to add lots to the debate, but it looks like
I wound up with just another "me too" message. :-)

Date: Fri, 14 Dec 2001 01:41:08 -0500
From: Tony Hansen <[email-masked]>
To: Steve Hole <[email-masked]>
CC: Pete Maclean <[email-masked]>, John Neystadt <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

Steve Hole wrote:
> 
> On Thu, 13 Dec 2001 10:32:16 -0500 Pete Maclean <[email-masked]>
> wrote:
> ...
> > For me, however, the ideal solution would be different
> > from what John proposes.  What I would like to see is a command that
> > essentially asks "what is the name of the message container that serves
> > function X" where X could express, for example, "is the default repository
> > for newly delivered messages" or "holds messages that have been
> > deleted".
> 
> There is such a mechanism -- the canonical name INBOX.   The client is
> absolutely free to map this however they choose.

Steve, Pete meant it more generically than just inbox. He also wants X
for other things such as "deleted messages" (his words above), "draft
messages", "sent messages", etc.

	Tony Hansen
	[email-masked]

Date: Thu, 13 Dec 2001 19:24:33 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: use for SORT
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

To answer why SORT is useful, given the presence of THREAD, vs. doing it on
the client.

SORT and THREAD are both useful when the client does not have knowledge of the
data needed to do the SORT.  They are big wins with online clients.  Or, put
another way, these command mark the difference between usability and
unusability of those functionalities in online clients.

Disconnected and offline clients probably have little, if any, need for SORT
or THREAD because they can do it on the client.

Organization: ACI Worldwide - Advanced Technology Group
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: SORT and arbitrary headers 
Date: Thu, 13 Dec 2001 20:02:20 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> >> Personally, I don't see much utility in SORT.
> By that same argument, you can say that there is no utility to THREAD 

I chose my words carefully ;-)  I said "not much," not "no."

> I would say its 50-50 use between sort and thread. I know personally there 
> are mailboxes I prefer to view by thread and ones I prefer to view sorted - 
> just depends on the nature of the content. There are also situations where 
> I want to do a sort within thread.

My question is whether the complexity of SORT (vs. doing it on the
client) is justified in the presence of THREAD. There is definately a
tradeoff here, and there is no clear-cut winner.  I think what I'm
looking for is a good example of where SORT+THREAD obviously wins over
THREAD plus client sort. (IOW, I just can't think of one, but I've
been dense before :-)

--lyndon

Date: Thu, 13 Dec 2001 16:30:16 -0700
From: Cyrus Daboo <[email-masked]>
To: Jutta Degener <[email-masked]>
cc: [email-masked]
Subject: Re: More SORT keys
Sender: [email-masked]

--On Thursday, December 13, 2001 3:12 PM -0800 Jutta Degener 
<[email-masked]> wrote:

> Maybe, rather than defining an specific extended feature set associated
> with a SORT2 capability, we could do something along the lines of a
> SORT=FOO,BAR,BAZ capability?
>
> Then new drafts that only define specific sorting rules can define SORT
> capabilities (e.g., "MESSAGEHINT") that a server can announce without
> requiring an update to SORT itself.
>
> Just an idea.

I think that would be a fine solution. The question is whether this group 
would want to define any of these now, or simply require the the current 
sort document to indicate that this extensibility is possible.

-- 
Cyrus Daboo

Date: Thu, 13 Dec 2001 15:12:05 -0800
From: Jutta Degener <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: More SORT keys
Sender: [email-masked]

On Thu, Dec 13, 2001 at 02:40:21PM -0700, Cyrus Daboo wrote:
> Comments?

Maybe, rather than defining an specific extended feature set associated with
a SORT2 capability, we could do something along the lines of a SORT=FOO,BAR,BAZ
capability?

Then new drafts that only define specific sorting rules can define SORT
capabilities (e.g., "MESSAGEHINT") that a server can announce without
requiring an update to SORT itself.

Just an idea.

Jutta <[email-masked]>

Date: Thu, 13 Dec 2001 14:34:56 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: More SORT keys
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

Here are the arguments for the counter-proposal (do SORT only, not SORT2):

1) General HEADER sorting does not scale, since it requires knowledge of the
   syntax of the header to do comparisons correctly.

2) Flag sorting is of questionable utility.  A single key flag sort is better
   done using SEARCH.  One in which the flag comes first can be done with two
   SORTs with only a single RTT cost; "SORT (FLAGGED SUBJECT) UTF-8 ALL" can
   be done as "SORT (SUBJECT) UTF-8 FLAGGED" followed by "SORT (SUBJECT) UTF-8
   UNFLAGGED".  One in which the flag comes last only matters when the
   previous key comparisons match as equality; judicious use of fetching
   (which has to be done anyway in painting the view) can largely eliminate
   this.  The real use for flag sorting is when sorting by multiple flags,
   e.g. SORT (FLAGGED ANSWERED).

Flag sorting certainly should be in SORT2, since it's harmless and is a (very)
minor functionality addition.  But it does not justify creating a SORT2.  For
SORT2 to happen, it needs to have a stronger basis.

I oppose any wording in the SORT document that requires the implementation of
SORT2.  If SORT2 happens, it should stand or fall on its own.

The only reason to want the SORT document to require SORT2 functionality is a
worry that nobody will implement SORT2 otherwise.  That is a legitimate
concern; but if SORT2 can't justify its existance on its own it deserves to
die.  The market can be cruel to good ideas that just aren't good enough.

The challenge for the advocates of SORT2 is to come up with a compelling
reason why SORT2 should be widely implemented, such that no implementor can
afford to ignore it.

Date: Thu, 13 Dec 2001 15:30:59 -0700
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Lyndon Nerenberg <[email-masked]>
cc: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Subject: re: SORT and arbitrary headers
Sender: [email-masked]

--On Thursday, December 13, 2001 1:43 PM -0800 Mark Crispin 
<[email-masked]> wrote:

>> Personally, I don't see much utility in SORT. I think that >99% of its
>> actual use will be as a poor substitute for what THREAD does.
>> Everything else SORT does can be done on the client side using the
>> results from FETCH ENVELOPE. (More accurately, I don't think SORT
>> can justify itself in the presence of THREAD.)

By that same argument, you can say that there is no utility to THREAD 
because threading can be done on the client too (you just need to do a 
fetch for References headers as well as envelope).

> I won't go that far; there is a limited set of circumstances in which
> SORT is useful.  Pine does put SORT to good use.  But Pine also uses
> THREAD, and it seems that more and more people are turning to threading
> rather than sorting.
>
> But I agree with the overall sentiment.  THREAD, not SORT, is the
> interesting extension.  It is incomprehensible to me why people want to
> waste incredible amounts of time on SORT extensions, VIEW, etc., which
> are all meaningless for THREAD.

I would say its 50-50 use between sort and thread. I know personally there 
are mailboxes I prefer to view by thread and ones I prefer to view sorted - 
just depends on the nature of the content. There are also situations where 
I want to do a sort within thread.

-- 
Cyrus Daboo

Date: Thu, 13 Dec 2001 14:40:21 -0700
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More SORT keys
Sender: [email-masked]

There was interest in imap-ext today in having more sort keys available in 
the sort extension. I was tasked with bringing this to the list.

Currently SORT has the following keys defined:

"ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" / "SUBJECT" / "TO"

There is interest in having a general "HEADER" key that takes the name of a 
header as an argument. I would also like to see sorting by flag/keyword - 
flag state being a 'column' that is frequently displayed by clients to 
users and something it is useful to sort by. There maybe other keys that 
people would like to see. There is a big question about how comparisons on 
arbitrary headers should be done. I think we will likely end up with a 
comparator operator to implment i18n support, and it will be possible to 
define custom comparitors for custom format header fields as required - but 
this should be a part of the i18n solution. For the time being a straight 
ascii compare as done for SUBJECT right now wuld have to be used.

Since adding new keys breaks backwards compatibility with existing deployed 
SORT clients and servers, we would have to do this via a new capability, 
say SORT2. The proposal is to add this to the current sort draft, requiring 
servers that use the new draft to advertise both SORT and SORT2 
capabilities, with an appendix explaining which keys were only defined in 
SORT.

Comments?

-- 
Cyrus Daboo

Date: Thu, 13 Dec 2001 17:04:50 -0500
To: Lyndon Nerenberg <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Cc: Steve Hole <[email-masked]>, John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 12:50 PM 12/13/2001 -0700, Lyndon Nerenberg wrote:
> > >client issue.   Localization / personalization of the INBOX is an client
> > >issue and MUST be dealt with there.
> >
> > Why must it be dealt with in the client?  Sorry, I am not trying to be
> > difficult; I really want to understand.  Sure, clients could be made
> > configurable so that a user could name his INBOX anything he chooses.  But
> > why when that could be centralized at the server?
>
>Because this presumes a one-to-one mapping between individuals
>and INBOXes. Imagine a single account shared by several hundred
>people on, say, a support desk. Because you have customers around
>the globe you have support staff fluent in several languages.
>So, of those (say) 50 languages spoken by your support staff
>sharing this INBOX, which one wins the name-INBOX-on-the-server
>contest? (Hint: I hope both you and your MUA can handle Mandarin.)

Aha!  Got it.  Thank you, thank you.

Pete

Date: Thu, 13 Dec 2001 13:43:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: SORT and arbitrary headers
To: Lyndon Nerenberg <[email-masked]>
cc: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 14:36:53 -0700, Lyndon Nerenberg wrote:
> Personally, I don't see much utility in SORT. I think that >99% of its
> actual use will be as a poor substitute for what THREAD does.
> Everything else SORT does can be done on the client side using the
> results from FETCH ENVELOPE. (More accurately, I don't think SORT
> can justify itself in the presence of THREAD.)

I won't go that far; there is a limited set of circumstances in which SORT is
useful.  Pine does put SORT to good use.  But Pine also uses THREAD, and it
seems that more and more people are turning to threading rather than sorting.

But I agree with the overall sentiment.  THREAD, not SORT, is the interesting
extension.  It is incomprehensible to me why people want to waste incredible
amounts of time on SORT extensions, VIEW, etc., which are all meaningless for
THREAD.

Organization: ACI Worldwide - Advanced Technology Group
To: "Neystadt, John" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: SORT and arbitrary headers
Date: Thu, 13 Dec 2001 14:36:53 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> C: A283 SORT (Message-Context SUBJECT) UTF-8 SINCE 1-Feb-1994
> 
> B) Since th list of well-known-header changes rapidly, specify in the RFC a
> list of headers that must be supported. 

This doesn't scale, because ...

> Of course I think that
> Message-Context should be one of them.

and the next person or RFC will want their header added. This will
require a re-specification of SORT, since existing implementations
will not interoperate with the new requests. This would result in the
SORT, SORT2, SORT3, SORT4, ..., SORTn extensions.

Clients that want to sort on arbitrary headers can already do so using
existing protocol mechanisms.  Since this is an unbounded problem,
it's also the only sane way to do it.  And for clients that implement
private header extensions, it's the only way they *can* do it.

Personally, I don't see much utility in SORT. I think that >99% of its
actual use will be as a poor substitute for what THREAD does.
Everything else SORT does can be done on the client side using the
results from FETCH ENVELOPE. (More accurately, I don't think SORT
can justify itself in the presence of THREAD.)

--lyndon

Date: Thu, 13 Dec 2001 13:18:51 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: SORT and multiple From:
To: Lyndon Nerenberg <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 14:15:17 -0700, Lyndon Nerenberg wrote:
> I notice that the -07 draft assumes there will be only one
> From address:
> while RFC2822 allows for more than one.

Wow.  So they fixed that bug in RFC 2822.  I didn't know that.  Good.

You'll notice that IMAP got it right.

> Should FROM not follow
> the behaviour of CC and TO? I.e.
>       FROM
>          RFC-822 local-part of the first "From" address.
>                                    ^^^^^

Yes, and I will fix this in -08.  Thank you!

To: [email-masked]
Subject: SORT and multiple From:
Organization: ACI Worldwide - Advanced Technology Group
Date: Thu, 13 Dec 2001 14:15:17 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

I notice that the -07 draft assumes there will be only one
>From address:

      FROM
         RFC-822 local-part of the "From" address.

while RFC2822 allows for more than one. Should FROM not follow
the behaviour of CC and TO? I.e.

      FROM
         RFC-822 local-part of the first "From" address.
                                   ^^^^^

--lyndon

Organization: ACI Worldwide - Advanced Technology Group
To: Pete Maclean <[email-masked]>
cc: Steve Hole <[email-masked]>, John Neystadt <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 12:50:48 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> >client issue.   Localization / personalization of the INBOX is an client
> >issue and MUST be dealt with there.
> 
> Why must it be dealt with in the client?  Sorry, I am not trying to be 
> difficult; I really want to understand.  Sure, clients could be made 
> configurable so that a user could name his INBOX anything he chooses.  But 
> why when that could be centralized at the server?

Because this presumes a one-to-one mapping between individuals
and INBOXes. Imagine a single account shared by several hundred
people on, say, a support desk. Because you have customers around
the globe you have support staff fluent in several languages.
So, of those (say) 50 languages spoken by your support staff
sharing this INBOX, which one wins the name-INBOX-on-the-server
contest? (Hint: I hope both you and your MUA can handle Mandarin.)

INBOX represents a specific entity on the IMAP server: the canonical
location where you can expect newly arrived mail to show up. The
label is arbitrary. We could have named it as an ASN-encoded OID
for that matter. Either way, how that *entity* is displayed to the
user is up to the MUA. The only purpose for giving it a (any) label
at all on the server is to allow it to be uniquely addressed.

--lyndon

Date: Thu, 13 Dec 2001 11:33:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
To: Steve Hole <[email-masked]>
cc: "Rubinstein, Dmitry" <[email-masked]>, "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 12:11:17 -0700, Steve Hole wrote:
> In short, having done it, the argument that it is too difficult to manage
> sequence numbers and UID's is simply ludicrous.

Unfortunately, too many people follow the logical trail of
   "it's difficult for me to figure it out"
-> "it's too difficult for anybody to figure it out"
-> "servers can do all this other stuff that IMAP requires, so there's no such
    thing as something that is difficult for a server"
-> "we should add a new protocol feature so the server does it and I don't
    have to figure it out"

From: Steve Hole <[email-masked]>
Date: Thu, 13 Dec 2001 12:11:17 -0700
To: "Rubinstein, Dmitry" <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Cc: "'Mark Crispin'" <[email-masked]>, "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 20:15:29 +0200 "Rubinstein, Dmitry" 
<[email-masked]> wrote:

> In fact, support for unsolicited events (especially EXPUNGE) is, from my
> expirience, the most non-trivial part of implementing an IMAP software.
> So if anything would make the implementation of IMAP available to the 
> mortals is this extension. Now that I think about it, the fact that this
> feature is not present in IMAP from the beginning looks
> like an overlook more than anything else.

Oh my!

The code to do exactly this is freely available in the uwash c-client.   
It is not exactly the way that we did it, but it certainly gives you the 
idea.   And, no disrespect intended, it isn't that hard.   It's an array.
You know how big to make the array.   You can certainly put a little 
structure into it.   You might have to worry about how big the array gets 
in a segmented memory architecture.   You might have to build a list of 
them.   The code to manage this in the c-client is about 500 lines soaking
wet.   Ours is about double that, but that is because cache management is 
bound with our asynchrous event notification and io completion 
notification framework.   That is a more advanced architecture that most 
GUI applications would be well served to try to use.  

Note that this stuff ran successfully in Mac v5 and Windows 3.1 on 
machines that were not too far off in terms of memory constraints and 
management from modern PDA devices.

In short, having done it, the argument that it is too difficult to manage 
sequence numbers and UID's is simply ludicrous.   There are some 
extensions that would require servers to maintain more state information 
for resynchronization purposes that would make synchronizing clients more 
bandwidth and storage efficient -- a 
"report-changes-since-last-checkpoint" type function.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 13 Dec 2001 10:51:07 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
To: Steve Hole <[email-masked]>
cc: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

I want my Saved Messages mailbox to have a Japanese language name using the
Japanese script.  I demand that every client in the world be fixed immediately
to display that name correctly.  By tommorrow.

No, I really don't.

I'm just trying to point out the flaw in the presumption that this can be
fobbed off on the server without any work on the client.  We can't assume that
all the world is Unicode and everybody has full fonts and drawing algorithms
for all the world's languages.  Not yet, anyway.

Even then, I can think of different ways that an otherwise-identical concept
mailbox is used; and how those ways impact data in incompatible ways.  Drafts
are an excellent example.

From: Steve Hole <[email-masked]>
Date: Thu, 13 Dec 2001 11:48:46 -0700
To: "Neystadt, John" <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Cc: "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 13:46:34 +0200 "Neystadt, John" <[email-masked]> 
wrote:

> > > 5. IMAP: Add support for IDLE of multiple folders
> 
> Well, you basically say - it is a client problem. Opening tens of
> connections for tens of visible mailboxes seems to me impractical and will
> severe damage server scalability. With my proposal, server can have a
> special optimized provisions (like subscribe for file system changes
> notifications) and it will be much more efficiently. 

No it won't.   If opening lots of connections impacts server scalability, 
then your server isn't very vertically scalable.   Our server routinely 
handles many 10's of thousands of connections on a single server.   You 
need to think about how you do that, but that is a lot easier engineering 
than thinking about how to reorganize the protocol semantics to support 
multiple mailbox selected state semantics.

Frankly, if you don't think about how to properly handle large numbers of 
TCP connections on NT servers, you have a serious scalability problem 
anyway. Fix it in one place and you fix it in all places.

> Well, INBOX name is a part of IMAP standard. Sent Items is a paradigm used
> by all MUAs on all OSes, so ignoring it is impractical. Other folders are
> more controversial. However I think it is better to standardize
> controversial names as recommendation, since there is no harm for those MUAs
> who don't use it.

Our client has provided a means for the user to select the names of the
folders that they will use for various purposes like draft storage, sent 
items, outbox, etc. and we ship with a default configuration that will 
recommend folder names for this purpose.   If the user doesn't like our 
names, they can change them.   If the organization wants to use a 
different set of defaults, they can change them.   If the user wants to 
coordinate with the names used by some other client, then they can change 
them.   No big deal actually.   I will note that after we allowed for 
customization, we never got a single trouble report on the matter.

The problem comes when client writers try to mandate the names used for 
such purposes.   Stupid design decision I think.   We could never get our 
own customer base to agree on a set of names, much less agree with another
client vendor.   It gets about a million times worse as soon as you deploy
internationally.   Bottom line is that you can make recommendations here, 
but you really can't enforce it.   And, if you pick this as the hill to 
die on ... you will die on it.

Cheers.
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 13 Dec 2001 13:43:34 -0500
To: Steve Hole <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging
Cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > As an IMAP server developer, the one enhancement I would most like to see
> > made to IMAP is something to address this issue.  I have to deal with 
> users
> > who have what IMAP refers to as "Inbox" actually named "In", "Incoming",
> > "Posteingang", etc.
>
>You're confused :-)

That's not unusual :-)

>This is not a server or protocol issue.   This is a
>client issue.   Localization / personalization of the INBOX is an client
>issue and MUST be dealt with there.

Why must it be dealt with in the client?  Sorry, I am not trying to be 
difficult; I really want to understand.  Sure, clients could be made 
configurable so that a user could name his INBOX anything he chooses.  But 
why when that could be centralized at the server?  This is especially 
significant for transient use of clients such as when someone pops into an 
Internet cafe they'll visit only once in their lives to check their mail.

What if a user regularly uses several different clients that use different 
names for we are referring to as INBOX?  Why should he have to deal with 
"Incoming" here, "In" there, and "Inbox" somewhere else?

Please understand that I am not making a fuss about this because I think 
it's a big deal -- I don't think it's a big deal at all.  It's just that I 
think that if any changes are made to IMAP related to folder naming then I 
think it would be terrible to miss the opportunity to improve this situation.

>There is such a mechanism -- the canonical name INBOX.   The client is
>absolutely free to map this however they choose.

Exactly my point.  I want the *user* to be absolutely free to map this, 
independently of any client.

Cheers,

Pete

From: Steve Hole <[email-masked]>
Date: Thu, 13 Dec 2001 11:33:43 -0700
To: John Neystadt <[email-masked]>
Subject: Re: [VPIM] Some thoughts about IMAP and Unified Messaging
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Wed, 12 Dec 2001 22:05:16 +0200 John Neystadt <[email-masked]> wrote:

> Hi!
> 

> 2. IMAP: Add support for UIDs in unsolicited events
> 
> Currently unsolicited events in IMAP return Sequence ids of messages. This
> requires User-Agent to query server upon receiving unsolicited event for
> whole message list if it did not yet fetched list of all messages. Supplying
> UIDs will allow server to fetch information only the message that has
> changed and reflect it in UI.

No it doesn't.   It requires that you keep a message sequence number to 
UID map in your client cache.   You may have to go and fetch information 
about the messages identified in the unsolicited response in order 
to do something useful with the notification, but you can always 
choose to ignore it as well.   

Clients SHOULD implement sequence number to UID maps anyway.  Much of the 
conversation about sort and thread would have been greatly eased if 
everyone supported use of sequence numbers in the first place.   After 
all, sorting and threading are ordering operations. 

I will say this.   The number one issue (with a bullet) for a competent 
IMAP client is thinking about cache management strategies.   If your 
caching strategy has the problem that you describe above, then you need to 
think about it more.

> 7. Add support of two new system IMAP flags - to mark messages with \Spam
> and \Adult content.
> 
> Today SMTP-MTAs often support SPAM and Adult content filtering. Not always
> it is possible to remove a message with wrong content, since sometimes a
> doubt exist regarding the correctness of the identification. By marking the
> message in doubt with system-flag, it will allow User-Agents to process such
> messages differently (i.e. color them or put in special folder).

These do not need to be system flags.   Put them in the $ namespace the 
same way as MDNSent was done.   I am, in fact, guilty of proposing the 
/Draft flag and have come to regret it.   There really is nothing 
different about user flags and system flags except that system flags are 
mandatory to implement.   Why should these be mandatory to implement.   
Write a draft defining the conventional use of these flags and call it a 
day.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Thu, 13 Dec 2001 13:26:49 -0500
To: Lyndon Nerenberg <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> >  I have to deal with users
> > who have what IMAP refers to as "Inbox" actually named "In", "Incoming",
> > "Posteingang", etc.
>
>Are you talking about the MUA localizing the folder "INBOX" to
>a local representation? If so, why would this affect the server?
>If not, maybe you could explain a bit more clearly what you mean
>here.

Sorry I was not clear.  I was referring to rather the opposite, to the 
server un-localizing, as it were, the incoming-mail folder on the server 
end.  As things stand, if this folder is not called "INBOX" in the 
mailstore then the IMAP server must map between the mailstore's name for it 
(e.g. "Posteingang") and the protocol's name for it ("Inbox").  This leads 
to the minor problem that a user who has an incoming-mail folder named 
other than "Inbox" cannot have another folder which s/he chooses to name 
"Inbox".

Let me give an example to illustrate the advantage of an MUA's being able 
to determine folder names according to function.  Suppose a German fellow 
keeps his mail on a computer in Germany and that in the mailstore concerned 
his incoming-mail folder is called "Posteingang".  Now let's suppose that 
he makes a visit to Britain and wants to read his mail using an 
English-language client because that happens to be the only convenient 
option.  If my idea were implemented in both client and server, then the 
client could give him the option of referring to his incoming-mail folder 
in the local language ("Inbox" or something similar) or using the native 
name ("Posteingang") which the client would retrieve from the server. Our 
German would see his chosen (presumably German-language) names for all his 
other folders; why should he be forced to see one particular folder named 
in English?  The other side of this illustration is that an American, say, 
on sabbatical in Germany could get an email account on the same server and, 
using his customary English-language client, see his incoming-mail folder 
named as he expects it.  He would never need to know that it was actually 
known as "Posteingang" on the server's side.

> > For me, however, the ideal solution would be different
> > from what John proposes.  What I would like to see is a command that
> > essentially asks "what is the name of the message container that serves
> > function X" where X could express, for example, "is the default repository
> > for newly delivered messages"
>
>By definition: INBOX.

Ah, yes, but that's by definition of the protocol.  And that's not bad; but 
it is limiting.  And, for the reasons laid out above, I would like to get 
away from it.  My point is that, if we want to distinguish folders other 
than Inbox, then I wish we could do so by function rather than by name 
because that offers a lot more flexibility for users.  If implemented well, 
it would also be more open-ended in that we could allow user-extensible 
functions (i.e. X-functions).

> > or "holds messages that have been
> > deleted".
>
>*Every* folder holds \Deleted messages, again by definition.

Yes, but again just by IMAP definition!  And there are many other 
definitions of deleted messages.

> > This approach means we don't have to English-ize names and gets
> > around the problem of Outbox meaning two different things.  The server
> > would respond with either the appropriate name or an indication that there
> > is no such thing.
>
>Wouldn't these be better solved with ACAP or IMSP?

I am not familiar enough with ACAP or IMSP to competently answer this.  I 
may research them so that I can get some perspective.  Thank you.

Pete

From: Steve Hole <[email-masked]>
Date: Thu, 13 Dec 2001 11:13:13 -0700
To: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging
Cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 10:32:16 -0500 Pete Maclean <[email-masked]> 
wrote:

> As an IMAP server developer, the one enhancement I would most like to see 
> made to IMAP is something to address this issue.  I have to deal with users 
> who have what IMAP refers to as "Inbox" actually named "In", "Incoming", 
> "Posteingang", etc.  

You're confused :-)   This is not a server or protocol issue.   This is a 
client issue.   Localization / personalization of the INBOX is an client 
issue and MUST be dealt with there. 

> For me, however, the ideal solution would be different 
> from what John proposes.  What I would like to see is a command that 
> essentially asks "what is the name of the message container that serves 
> function X" where X could express, for example, "is the default repository 
> for newly delivered messages" or "holds messages that have been 
> deleted".  

There is such a mechanism -- the canonical name INBOX.   The client is 
absolutely free to map this however they choose.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide, Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: "Neystadt, John" <[email-masked]>
To: "'Lyndon Nerenberg'" <[email-masked]>
Cc: "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 20:11:42 +0200
Sender: [email-masked]

> > > > SORT. Why not allow sorting by ANY header?
>  
> > I would suggest that sorting by header value has the 
> following semantics:
> > 
> > 1. Take plain header value without parameters and comments 
> (i.e. strip off
> > all '; xxx=yyy')
> 
> How can you know the syntax of comments and parameters for all
> possible headers?  X- headers have arbitrary syntax, thus you can't
> sort on X- headers since you cannot perform the decomposition.  And
> you cannot RFC2047-decode a non-X- but otherwise unknown header, since
> you don't know what elements of the header are <text>.
> 
> If you don't know the structure of the header the only thing you
> can do is collapse FWS and ASCII sort the result.

I agree that there is no way to sort by generic X- header. However since
semantics of all standard headers are defined then there is no problem to
define how to sort by every specific header.

So what I propose, is a two things:

A) Add generic keyword for header sorting, something like:

C: A282 SORT (HEADER[Message-Context] HEADER[Subject]) UTF-8 SINCE
1-Feb-1994

or the header name itself

C: A283 SORT (Message-Context SUBJECT) UTF-8 SINCE 1-Feb-1994

B) Since th list of well-known-header changes rapidly, specify in the RFC a
list of headers that must be supported. Of course I think that
Message-Context should be one of them.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

From: "Neystadt, John" <[email-masked]>
To: "'Lyndon Nerenberg'" <[email-masked]>
Cc: Pete Maclean <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [VPIM] Re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 19:54:16 +0200
Sender: [email-masked]

> > This approach means we don't have to English-ize names and gets 
> > around the problem of Outbox meaning two different things.  
> The server 
> > would respond with either the appropriate name or an 
> indication that there 
> > is no such thing.
> 
> Wouldn't these be better solved with ACAP or IMSP? 

Pete's approach can be implemented through ACAP, however, it seems to me
that "Sent Items" and other 'standard' folders ae wide-spread enough to
include them in the basic protocol. Especially that INBOX has created the
precendence. Then MUA can localize these names to
a local representations without asking user what is his "Sent Items" name or
quoerying ACAP, LDAP or other server that is implemented in subsciber's.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

Organization: ACI Worldwide - Advanced Technology Group
To: "Neystadt, John" <[email-masked]>
cc: "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 10:55:46 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> > > SORT. Why not allow sorting by ANY header?
 
> I would suggest that sorting by header value has the following semantics:
> 
> 1. Take plain header value without parameters and comments (i.e. strip off
> all '; xxx=yyy')

How can you know the syntax of comments and parameters for all
possible headers?  X- headers have arbitrary syntax, thus you can't
sort on X- headers since you cannot perform the decomposition.  And
you cannot RFC2047-decode a non-X- but otherwise unknown header, since
you don't know what elements of the header are <text>.

If you don't know the structure of the header the only thing you
can do is collapse FWS and ASCII sort the result.

--lyndon

Organization: ACI Worldwide - Advanced Technology Group
To: Pete Maclean <[email-masked]>
cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Some thoughts about IMAP and Unified Messaging 
Date: Thu, 13 Dec 2001 10:39:17 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>  I have to deal with users 
> who have what IMAP refers to as "Inbox" actually named "In", "Incoming", 
> "Posteingang", etc.  

Are you talking about the MUA localizing the folder "INBOX" to
a local representation? If so, why would this affect the server?
If not, maybe you could explain a bit more clearly what you mean
here.

> For me, however, the ideal solution would be different 
> from what John proposes.  What I would like to see is a command that 
> essentially asks "what is the name of the message container that serves 
> function X" where X could express, for example, "is the default repository 
> for newly delivered messages"

By definition: INBOX.

> or "holds messages that have been 
> deleted". 

*Every* folder holds \Deleted messages, again by definition.

> This approach means we don't have to English-ize names and gets 
> around the problem of Outbox meaning two different things.  The server 
> would respond with either the appropriate name or an indication that there 
> is no such thing.

Wouldn't these be better solved with ACAP or IMSP? 

--lyndon

Date: Thu, 13 Dec 2001 09:29:14 -0800 (PST)
From: [email-masked]
Subject: Re: [VPIM] re: Some thoughts about IMAP and Unified Messaging
To: Arnt Gulbrandsen <[email-masked]>
Cc: "Neystadt, John" <[email-masked]>, "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> "Neystadt, John" <[email-masked]>
> > I would suggest that sorting by header value has the following semantics:
> >
> > 1. Take plain header value without parameters and comments (i.e. strip off
> > all '; xxx=yyy')
> > 2. Determine charset from header itself (according to 2047) or us-ascii by
> > default.

> Speaking on behalf of the intolerable pedants of this world, I have to
> note that RFC 2047 contains an example where two different charsets are
> used in the same header. Indeed, it's the very first example of the RFC.

I see such examples fairly regularly in practice. I suppose this sort of thing
is inevitable when you operate in an international body like the IETF. It is
especially true given that UTF-8 is way way way down the list of the most
common charsets I see used in this (and several other) contexts.

Of course conversion to UTF-8 is one way do deal with this. But such conversion
is relatively expensive.

				Ned

Organization: ACI Worldwide - Advanced Technology Group
To: "Milt Roselinsky" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: SNAP progress and request for comment 
Date: Thu, 13 Dec 2001 10:30:24 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

[Folks, please trim down the included text in your followups.]

> In bandwidth starved environments, it would be a huge win to be able to
> provide payload in the notification.  Why not design something with network
> efficiency in mind?

Could you give an example of this "huge win?" I don't see how SNAP is
more efficient at retrieving this information than IMAP is.

--lyndon

Date: Thu, 13 Dec 2001 18:25:02 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: "Neystadt, John" <[email-masked]>
Cc: "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

"Neystadt, John" <[email-masked]>
> I would suggest that sorting by header value has the following semantics:
> 
> 1. Take plain header value without parameters and comments (i.e. strip off
> all '; xxx=yyy')
> 2. Determine charset from header itself (according to 2047) or us-ascii by
> default.

Speaking on behalf of the intolerable pedants of this world, I have to
note that RFC 2047 contains an example where two different charsets are
used in the same header. Indeed, it's the very first example of the RFC.

--Arnt

Date: Thu, 13 Dec 2001 08:52:01 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
To: "Neystadt, John" <[email-masked]>
cc: [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 13 Dec 2001 13:46:34 +0200, Neystadt, John wrote:
> Marc, the SORT itself is a draft. Why do a separate effort and not include
> it straight in SORT?

That's "Mark".  With a "K".  Please.

There's the small matter of production code for the past 3 or 4 years.
Furthermore, it's a bad idea from an architecture design to put functionality
into a base protocol unless that protocol is generally useful.

> BTW: I've tried to look in archives and did not found a
> discussion of including a generic HEADER keyword discussion for SORT. Why
> not allow sorting by ANY header?

A proposed functionality has to justify its existence.  The fact that a
functionality *can* be done does not mean that it *should* be done.  Protocols
need to be implementable by mere mortals in finite time before the sun novas.

This is something that some IETFers seem to have forgotten.  IMAP is not a
small protocol, but *everything* in IMAP has a use.  There is *nothing* in
IMAP which can be "not implemented" by a server without breaking clients.

This is important.  The history of RFCs is littered with good ideas that fell
victim to the "let's add everything plus the kitchen sink."  Such protocols
invariably are overtaken by smaller, leaner protocols that do the job and are
implementable by mere mortals in real time.

Do you remember why SMTP is the Simple Mail Transport Protocol?

> Why? If we introduce a new UIDIDLE capability and syntax of
> tag UID IDLE
> with new untagged responses, like:
> S: * 44 UID EXPUNGE
> S: * 108 UID FETCH (FLAGS (\Seen))
> This will not affect existing clients.

Those responses would have to be something like
	S: * 23 EXPUNGE (UID 44)
	S: * 55 FETCH (FLAGS (SEEN) UID 108)

Nevertheless, this functionality has to justify its existence.  It duplicates
existing functionality, for no reason other than to pretend that only UIDs,
not sequence numbers, exist in IMAP.  I have seen wretched client behavior due
to that notion.  I don't think that it should be encouraged.

> I do believe that this should be done with s single command. Overloading
> server with tens of STATUSes per tens (or hundreds) mailbox-es is a bad
> bahaviour on slow links.

Indeed.  So it encourages clients not to do it, and it emphasizes that a
client that does it is a poorly-designed client.

I will vigorously oppose a functionality that gives the client the ability to
launch a denial of service attack on the server with a single command.  This
includes LIST extensions unless it is made server-optional what data can be
returned.

> Opening tens of
> connections for tens of visible mailboxes seems to me impractical and will
> severe damage server scalability.

Why is use of the existing (20+ years) multiplexing protocol less scalable
than making an IMAP server multiplex mailboxes?

> With my proposal, server can have a
> special optimized provisions (like subscribe for file system changes
> notifications) and it will be much more efficiently.

And if the back end does not provide such optimized provisions the
multiplexing substantially increases the complexity of an already quite
complex protocol.

> Well, INBOX name is a part of IMAP standard.

And is the only name that has any justification from any other e-mail
protocols.

Date: Thu, 13 Dec 2001 11:44:38 -0500
From: Lawrence Greenfield <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>, "[email-masked], John" <[email-masked]>, Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

   Date: Thu, 13 Dec 2001 08:56:47 -0700
   From: Cyrus Daboo <[email-masked]>
[...]
   That would be reasonable but how do you do the sort comparison? Some 
   headers, e.g. Priority, have a particular set of values with a clear 
   ordering that is not a simple ascii sort which is all the current SORT can 
   do. I suspect we will have to add comparators to SORT to satisfy i18n 
   issues.

Yes, this is what Mike Gahrns and I were arguing about in London.  I
think an explicit comparator for each comparison is needed for this
reason, but we hadn't reached consensus.

Larry

From: "Neystadt, John" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Date: Thu, 13 Dec 2001 18:08:41 +0200
Sender: [email-masked]

> >> This could be done by an IMAP extension for VPIM.  Since
> >> Message-Context is
> >> not a MIME base header it probably does not belong in the
> >> SORT base document.
> >
> > Marc, the SORT itself is a draft. Why do a separate effort 
> and not include
> > it straight in SORT? BTW: I've tried to look in archives and did not
> > found a discussion of including a generic HEADER keyword 
> discussion for
> > SORT. Why not allow sorting by ANY header?

I would suggest that sorting by header value has the following semantics:

1. Take plain header value without parameters and comments (i.e. strip off
all '; xxx=yyy')
2. Determine charset from header itself (according to 2047) or us-ascii by
default.
3. Use same collation mechanism as for other comparators.

> That would be reasonable but how do you do the sort comparison? Some 
> headers, e.g. Priority, have a particular set of values with a clear 
> ordering that is not a simple ascii sort which is all the 
> current SORT can 
> do. I suspect we will have to add comparators to SORT to satisfy i18n 
> issues.

I think this is simplere and better than not to support anything. In my
opinion either this or a specific comparator for Message-Context is
required.

> >> > 2. IMAP: Add support for UIDs in unsolicited events
> >>
> >> This can't be done without breaking IMAP2 compatibility.
> >> IMAP2 clients are
> >> not extinct yet.  We've learned that the hard way.
> >
> > Why? If we introduce a new UIDIDLE capability and syntax of
> >
> > tag UID IDLE
> >
> > with new untagged responses, like:
> >
> > S: * 44 UID EXPUNGE
> > S: * 108 UID FETCH (FLAGS (\Seen))
> >
> > This will not affect existing clients.
> 
> But it doesn't completely solve the problem because untagged 
> responses can 
> come back outside of IDLE and those will still only have 
> sequence number. 
> The only way to do this properly is to have a switch on the 
> SELECT command 
> to turn on this behaviour.

I think this is a good idea, and trying to take it further, we can add an
option to SELECT to block unsolicited events completely and allow them only
in IDLE (or UID IDLE) mode. Once most servers implement this a big burden
will be shifted from clients' developers.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

Date: Thu, 13 Dec 2001 08:56:47 -0700
From: Cyrus Daboo <[email-masked]>
To: "Neystadt, John" <[email-masked]>, "'Mark Crispin'" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

--On Thursday, December 13, 2001 1:46 PM +0200 "Neystadt, John" 
<[email-masked]> wrote:

>> This could be done by an IMAP extension for VPIM.  Since
>> Message-Context is
>> not a MIME base header it probably does not belong in the
>> SORT base document.
>
> Marc, the SORT itself is a draft. Why do a separate effort and not include
> it straight in SORT? BTW: I've tried to look in archives and did not
> found a discussion of including a generic HEADER keyword discussion for
> SORT. Why not allow sorting by ANY header?

That would be reasonable but how do you do the sort comparison? Some 
headers, e.g. Priority, have a particular set of values with a clear 
ordering that is not a simple ascii sort which is all the current SORT can 
do. I suspect we will have to add comparators to SORT to satisfy i18n 
issues.

>> > 2. IMAP: Add support for UIDs in unsolicited events
>>
>> This can't be done without breaking IMAP2 compatibility.
>> IMAP2 clients are
>> not extinct yet.  We've learned that the hard way.
>
> Why? If we introduce a new UIDIDLE capability and syntax of
>
> tag UID IDLE
>
> with new untagged responses, like:
>
> S: * 44 UID EXPUNGE
> S: * 108 UID FETCH (FLAGS (\Seen))
>
> This will not affect existing clients.

But it doesn't completely solve the problem because untagged responses can 
come back outside of IDLE and those will still only have sequence number. 
The only way to do this properly is to have a switch on the SELECT command 
to turn on this behaviour.

-- 
Cyrus Daboo

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Mark Crispin <[email-masked]>, John Neystadt <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Date: Thu, 13 Dec 2001 08:40:20 -0700
Sender: [email-masked]

Also:

Sort by message importance, counters by message importance is a common and
required user feature.  (Counter by union of importance and context is
desirable)

While it is not strictly a matter of IMAP, we also need message quota by
context.  It might be useful to be able to interrogate the available quota
via IMAP although I can be convinced to use some other mechanism.  Quota by
context with necessary over-rides more greatly impact SMTP-Submit. 

A more controversial matter is the storage of personal greetings.  Because
of the relatively large data size per subscriber (6+ greetings per user,
each greeting of up to 30 seconds of 4kbytes/second) these have not
historically been stored in a directory server, their most natural
architectural home.  Instead, in a widely-used and effective hack, they are
typically stored in a special folder in the subscribers mailbox.  The
mailbox being a place optimized for the storage and streaming retrieval of
large objects.  There is often a URL in the "directory" pointing to the
special message(s) in the mailbox.  This folder is granted public read
access so an agent of an unauthenticated caller (the telephone answering
application) can select the appropriate greeting and play it without knowing
the  mailbox log-in.  The subscriber can update, copy, and delete greetings
via standard authenticated IMAP mechanisms.  We can harmonize and "profile"
existing practice or invent a new one.  The IMAP approach has the current
benefit that it does not require support of yet another protocol by the
application.

The ability to gain limited access to affiliated mailboxes (in same
session?) is important.  In one application example, the sub-mailboxes of a
family, it is important to be able to report the message counts for a
mailbox that you cannot otherwise read the contents.  When you come home and
see a single blinky-light for the confederation, you pick up the phone,
press the magic button, and are auto logged-in to the "main mailbox".  At
the main mailbox, you hear a status of each of the submailboxes (in addition
to the main).  The time-pressed user may then only log-in to their
sub-mailbox if there are actually messages to review.  Other applications
examples have identical requirements.

Greg V.

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]]
Sent: Wednesday, December 12, 2001 7:06 PM
To: John Neystadt
Cc: [email-masked]; [email-masked]
Subject: [VPIM] re: Some thoughts about IMAP and Unified Messaging

On Wed, 12 Dec 2001 22:05:16 +0200, John Neystadt wrote:
> 1. IMAP: Extend SORT to support Message-Context

This could be done by an IMAP extension for VPIM.  Since Message-Context is
not a MIME base header it probably does not belong in the SORT base
document.

> 2. IMAP: Add support for UIDs in unsolicited events

This can't be done without breaking IMAP2 compatibility.  IMAP2 clients are
not extinct yet.  We've learned that the hard way.

> 3. IMAP: Add support of per Message-Context counters in STATUS command

This can also be done by an IMAP extension for VPIM.

> 4. IMAP: Add support for STATUS of multiple folders

STATUS does not accept multiple mailboxes for a reason; the metadata
obtained
by STATUS may not be available to the server except by doing an internal
SELECT.  Forcing clients to do a STATUS command per mailbox emphasizes that
this is not something that should be done on a wanton basis.

There is an effort underway to extend LIST to return additional mailbox
metadata, but only if the server chooses to offer it.

> 5. IMAP: Add support for IDLE of multiple folders

The same effect can be achieved with multiple connections, one for each
mailbox, each in an IDLE.  That way, instead of adding a multiplexing
mechanism to IMAP, it uses the wonderful multiplexing system that every
Internet system has built in for free: TCP.

> 6. IMAP: Standardize English names for standard (system) folders in
addition
> to INBOX - Sent Items, Drafts, Outbox, Deleted Items

I consider it to be a great stretch to call any of these "standardized", and
as far as "Deleted Items" goes that is nothing less than a wholesale
abandonment of IMAP.

"Outbox" has at least two incompatible roles in common use by clients.  Pick
a
definition for what "Outbox" can mean, and I can argue quite convincingly
that
you're wrong and the only correct definition is a different one.  So you
give
in and go with that definition; I'll then argue quite convincingly that the
first definition was right.

This type of MUA-dependent functionality does not belong in IMAP.

> 7. Add support of two new system IMAP flags - to mark messages with \Spam
> and \Adult content.

There is no need to do this; keywords will accomplish the same thing.  There
is even a mechanism for inter-client keywords (the "$" prefix) that are well
known (perhaps we need a formal IANA registry of these).

----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email-masked]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo

Date: Thu, 13 Dec 2001 07:23:59 -0800 (PST)
From: [email-masked]
Subject: RE: SNAP progress and request for comment
To: Randall Gellens <[email-masked]>
Cc: Milt Roselinsky <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> I second the suggestion to use BEEP instead of HTTP.

First let me repeat what I said as in my capacity as an area director at the
VPIM meeting -- we now have a document (draft-moore-using-http-01.txt) that
describes the use of HTTP in other protocols. At a minimum this needs to be
reviewed to make sure your use of HTTP is appropriate.

It is not my objective as an AD to force you to use BEEP and not HTTP in this
work, merely to point out the potential issues that arise should you choose
to use HTTP.

Second, speaking entirely as an individual member of these WGs, I concur with
both Chris and Randall -- IMO BEEP is a better choice for all the reasons Chris
gave.

> ...

> Your request types might be better as hierarchical codes, either
> textual or numeric (like Delivery Status Notifications (DSNs)).  For
> example, "Account-Locked/Login-Error-Max-Exceeded" or xxx.yyy.zzz.

I have mixed feeling about this. I guess I wouldn't mind such a structure for
numeric codes -- we have examples where this appears to have worked reasonably
well. But structured textual codes make me nervous. I'm not convinced this has
worked all that well in the case of MDNs.

> (Wow -- a normative reference to MIXER!)

Which needs to go. As pointed out at the meeting, there's equivalent VPIM
text.  Don't reference MIXER.

					Ned

Date: Thu, 13 Dec 2001 10:32:16 -0500
To: John Neystadt <[email-masked]>, [email-masked], [email-masked]
From: Pete Maclean <[email-masked]>
Subject: Re: Some thoughts about IMAP and Unified Messaging
Sender: [email-masked]

--=====================_182982234==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>6. IMAP: Standardize English names for standard (system) folders in 
>addition to INBOX - Sent Items, Drafts, Outbox, Deleted Items
>
>Currently localization of INBOX occurs on User-Agent side, while rest of 
>folders are create directly in local agent. This requires the user to 
>configure the names of the folders in the User-Agent. The idea is to 
>standardize English names for all standard folders and make the User-Agent 
>only to display them in local language.

As an IMAP server developer, the one enhancement I would most like to see 
made to IMAP is something to address this issue.  I have to deal with users 
who have what IMAP refers to as "Inbox" actually named "In", "Incoming", 
"Posteingang", etc.  For me, however, the ideal solution would be different 
from what John proposes.  What I would like to see is a command that 
essentially asks "what is the name of the message container that serves 
function X" where X could express, for example, "is the default repository 
for newly delivered messages" or "holds messages that have been 
deleted".  This approach means we don't have to English-ize names and gets 
around the problem of Outbox meaning two different things.  The server 
would respond with either the appropriate name or an indication that there 
is no such thing.

Pete

--=====================_182982234==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<blockquote type=cite cite><font face="arial" size=2>6. IMAP: Standardize
English names for standard (system) folders in addition to INBOX - Sent
Items, Drafts, Outbox, Deleted Items<br>
</font><br>
<font face="arial" size=2>Currently localization of INBOX occurs on
User-Agent side, while rest of folders are create directly in local
agent. This requires the user to configure the names of the folders in
the User-Agent. The idea is to standardize English names for all standard
folders and make the User-Agent only to display them in local
language.</font></blockquote><font face="arial" size=2><br>
</font><font face="arial">As an IMAP server developer, the one
enhancement I would most like to see made to IMAP is something to address
this issue.&nbsp; I have to deal with users who have what IMAP refers to
as &quot;Inbox&quot; actually named &quot;In&quot;, &quot;Incoming&quot;,
&quot;Posteingang&quot;, etc.&nbsp; For me, however, the ideal solution
would be different from what John proposes.&nbsp; What I would like to
see is a command that essentially asks &quot;what is the name of the
message container that serves function X&quot; where X could express, for
example, &quot;is the default repository for newly delivered
messages&quot; or &quot;holds messages that have been
deleted&quot;.&nbsp; This approach means we don't have to English-ize
names and gets around the problem of Outbox meaning two different
things.&nbsp; The server would respond with either the appropriate name
or an indication that there is no such thing.<br>
<br>
Pete<br>
</font></html>

--=====================_182982234==_.ALT--

From: Edward Hibbert <[email-masked]>
To: "'Shapira, Noam'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: [SNAP] draft-shapira-snap-02.txt
Date: Thu, 13 Dec 2001 14:48:31 -0000
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C183E5.3BE0EB30
Content-Type: text/plain;
	charset="windows-1255"

I have a few comments on the latest draft; see below.
 
<!--StartFragment-->2.2.1 Request Order

   The source MUST send the requests to the service in the same order
   as the events that triggered them occurred. This ensures a 
   consistent behavior. For example: if there are two notifications 
   events, one indicating the user has one new message and the second
   indicating there are two new messages, the user must receive the
   first before the second.

Our experience in this area suggests that this requirement may be very
difficult to obey in multi-machine systems involving a variety of
components.  Even if the requests are generated in the correct order, you
need to ensure they arrive at the service in the same order.  This has an
implication for how these notifications are scheduled within the source
application, and also how it uses connections to the service - probably
requests for a single user must be sent over the same persistent connection
to avoid the possibility that the service will pull them off in a different
order.
 
There are two other approaches I can think of:

*	Ensure that each request contains enough information to perform a
sensible action even if requests are received out of sequence.  This is
possible with simplistic notifications such as turning an MWI light on and
off, but it's very difficult to see that is achievable with the level of
detail in this spec.
*	Tag each request with a monotonically increasing sequence number.
That way the sequence number can be generated at the point that the mailbox
is modified, and later issues in the scheduling of requests within the
source application are reduced.  However this does put more onus on the
notification service to deal with ordering the sequences and coping with
lost requests.

If we retain this requirement (rather than use a sequence number) then I
think we need a more careful discussion of the implications for behaviour in
the source application.

What do other folk think about this?
 
<!--StartFragment-->.2.4 Retries

   Upon receiving a response from the service indicating a failure, the
   source SHOULD retry the request in case the service failure is
   recoverable (i.e. temporary).

   Presumably if the source sends a request but doesn't get a response (e.g.
the service crashes and recovers), it should also do retries?
 
<!--StartFragment-->
3.2 Request Types

   This section describes the trigger for sending each request type
   and lists the groups of attributes that SHOULD appear in the
   request.

In our notification thinking, we've decided that moving an unread message
out of the Inbox folder into another folder ought to turn off an MWI.
Should there be a separate RequestType for Move, or would we generate a
ReadMsg request?  I favour the former.
 
<!--StartFragment-->3.6 CountersGroup

   The counter group includes the count of messages in the user's
   mailbox according to categories. The categories are type (Voice,
   Fax or Email), Freshness (New or not) and Urgency (Urgent or not).

   A message is considered fresh if its unseen flag is true. It
   is considered Urgent if the MsgImportance attribute as described in
   the MessageGroup is "high". Categorization to type is a
   proprietary vendor feature. The source SHOULD categorize all
   messages as Email messages.

What should a message which contains both Voice and Fax information count
towards?
 
<!--StartFragment-->4.1.3 Redirection (3xx) Status Codes

4.1.3.1 "301 Moved Permanently"

   Upon receiving this status code, the source MUST resend the
   notification request to the new URI specified in the location
   field of the response.

   When sending other requests after receiving this response, the
   source SHOULD use the new URL that is part of the URI returned in
   the "location" field.

Presumably this redirection applies to requests for all users, not just for
the one referenced in the request?

Harking back to 2.2.1, I think we also need to consider scalability and
reliability for the service, because that may impact on the protocol.  At
present there is a single contact point for the service.  If that's a single
machine it may become overloaded, so for performance and reliability we need
to have a way of it being multiple machines.  Although that can be hidden
from the source via an IP splitter, that re-introduces the problem of
requests getting out of order because a different machine picks them up.  So
I think that multiple contact points for the service needs to be explicitly
catered for, and the implications explored.  For example it might be that
all requests for a user should be sent to the same contact point while that
contact point is up.

Regards,

Edward Hibbert 
Internet Applications Group 
Data Connection Ltd 
Tel:    +44 131 662 1212                Fax:    +44 131 662 1345 
Email:  [email-masked]   Web:    http://www.dat <http://www.dat/>
aconnection.com 

------_=_NextPart_001_01C183E5.3BE0EB30
Content-Type: text/html;
	charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">
<TITLE></TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#ff00ff face=Arial size=2>I have a few comments on the latest 
draft; see below.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&lt;!--StartFragment--&gt;2.2.1 Request 
Order<BR><BR>&nbsp;&nbsp; The source MUST send the requests to the service in 
the same order<BR>&nbsp;&nbsp; as the events that triggered them occurred. This 
ensures a <BR>&nbsp;&nbsp; consistent behavior. For example: if there are two 
notifications <BR>&nbsp;&nbsp; events, one indicating the user has one new 
message and the second<BR>&nbsp;&nbsp; indicating there are two new messages, 
the user must receive the<BR>&nbsp;&nbsp; first before the 
second.<BR></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>Our experience in this area suggests 
that this requirement may be very difficult to obey in multi-machine systems 
involving a variety of components.&nbsp; Even if the requests are generated in 
the correct order, you need to ensure they arrive at the service in the same 
order.&nbsp; This has an implication for how these notifications are scheduled 
within the source application, and also how it&nbsp;uses connections to the 
service - probably requests for a single user must be sent over the same 
persistent connection to avoid the possibility that the service will pull them 
off in a different order.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>There are two other approaches I can 
think of:</FONT></DIV>
<UL>
  <LI><FONT color=#ff00ff face=Arial size=2>Ensure that each request contains 
  enough information to perform a sensible action even if requests are received 
  out of sequence.&nbsp; This is possible with simplistic notifications such as 
  turning an MWI light on and off, but it's very difficult to see that is 
  achievable with the level of detail in this spec.</LI>
  <LI><FONT color=#ff00ff face=Arial size=2>Tag each request with a 
  monotonically increasing sequence number.&nbsp; That way the sequence number 
  can be generated at the point that the mailbox is modified, and later issues 
  in the scheduling of requests within the source application ar</FONT><FONT 
  color=#ff00ff face=Arial size=2>e reduced.&nbsp; However this does put more 
  onus on the notification service to deal with ordering the sequences and 
  coping with lost requests.</FONT></LI></FONT></UL>
<DIV><FONT color=#ff00ff face=Arial size=2>If we retain this requirement (rather 
than use a sequence number) then I think we need a more careful discussion of 
the implications for behaviour in the source application.</FONT></DIV>
<UL></UL>
<DIV><FONT color=#ff00ff face=Arial size=2>What do other folk think about 
this?</FONT></DIV>
<DIV>&nbsp;</DIV><FONT face=Arial><FONT size=2>
<DIV>&lt;!--StartFragment--&gt;.2.4 Retries<BR><BR>&nbsp;&nbsp; Upon receiving a 
response from the service indicating a failure, the<BR>&nbsp;&nbsp; source 
SHOULD retry the request in case the service failure is<BR>&nbsp;&nbsp; 
recoverable (i.e. temporary).<BR><BR><FONT color=#ff00ff>&nbsp;&nbsp; 
Presumably&nbsp;if the source sends a request but doesn't get a response (e.g. 
the service crashes and recovers), it should also do 
retries?</FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV><FONT color=#ff00ff></FONT><FONT color=#ff00ff></FONT>
<DIV><FONT face=Arial size=2>&lt;!--StartFragment--&gt;<BR>3.2 Request 
Types<BR><BR>&nbsp;&nbsp; This section describes the trigger for sending each 
request type<BR>&nbsp;&nbsp; and lists the groups of attributes that SHOULD 
appear in the<BR>&nbsp;&nbsp; request.<BR></FONT></DIV>
<DIV><FONT size=2><FONT color=#ff00ff face=Arial>In our notification thinking, 
we've decided that moving an unread message out of the Inbox folder into another 
folder ought to turn off an MWI.&nbsp; Should there be a separate RequestType 
for Move, or would we generate a ReadMsg request?&nbsp; I favour the 
former.</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&lt;!--StartFragment--&gt;3.6 
CountersGroup<BR><BR>&nbsp;&nbsp; The counter group includes the count of 
messages in the user's<BR>&nbsp;&nbsp; mailbox according to categories. The 
categories are type (Voice,<BR>&nbsp;&nbsp; Fax or Email), Freshness (New or 
not) and Urgency (Urgent or not).<BR><BR>&nbsp;&nbsp; A message is considered 
fresh if its unseen flag is true. It<BR>&nbsp;&nbsp; is considered Urgent if the 
MsgImportance attribute as described in<BR>&nbsp;&nbsp; the MessageGroup is 
"high". Categorization to type is a<BR>&nbsp;&nbsp; proprietary vendor feature. 
The source SHOULD categorize all<BR>&nbsp;&nbsp; messages as Email 
messages.<BR></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>What should&nbsp;a message which 
contains both Voice and Fax information count towards?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&lt;!--StartFragment--&gt;4.1.3 Redirection (3xx) 
Status Codes<BR><BR>4.1.3.1 "301 Moved Permanently"<BR><BR>&nbsp;&nbsp; Upon 
receiving this status code, the source MUST resend the<BR>&nbsp;&nbsp; 
notification request to the new URI specified in the location<BR>&nbsp;&nbsp; 
field of the response.<BR><BR>&nbsp;&nbsp; When sending other requests after 
receiving this response, the<BR>&nbsp;&nbsp; source SHOULD use the new URL that 
is part of the URI returned in<BR>&nbsp;&nbsp; the "location" 
field.<BR></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>Presumably this redirection applies 
to requests for all users, not just for the one referenced in the 
request?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>Harking back to 2.2.1, I think we 
also need to consider scalability and reliability for the service, because that 
may impact on the protocol.&nbsp; </FONT><FONT color=#ff00ff face=Arial 
size=2>At present there is a single contact point for the service.&nbsp; If 
that's a single machine it may become overloaded, so for performance and 
reliability we need to have a way of it being multiple machines.&nbsp; Although 
that can be hidden from the source via an IP splitter, that re-introduces the 
problem of requests getting out of order because a different machine picks them 
up.&nbsp; So I think that multiple contact points for the service needs to be 
explicitly catered for, and the implications explored.&nbsp; For example it 
might be that a</FONT><FONT color=#ff00ff face=Arial size=2>ll requests for a 
user should be sent to the same contact point while that contact point is 
up.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#ff00ff face=Arial size=2>Regards,</FONT></DIV>
<DIV>
<P><FONT color=#000000 face=Arial size=1>Edward Hibbert</FONT> <BR><FONT 
color=#000000 face=Arial size=1>Internet Applications</FONT> <FONT color=#000000 
face=Arial size=1>Group</FONT> <BR><U><FONT color=#000000 face=Arial size=1>Data 
Connection Ltd</FONT></U> <BR><FONT color=#000000 face=Arial 
size=1>Tel:&nbsp;&nbsp;&nbsp; +44</FONT> <FONT color=#000000 face=Arial 
size=1>131 662 1212</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#000000 face=Arial 
size=1>Fax:&nbsp;&nbsp;&nbsp; +44</FONT> <FONT color=#000000 face=Arial 
size=1>131 662 1345</FONT> <BR><FONT color=#000000 face=Arial 
size=1>Email:&nbsp;</FONT> <FONT color=#000000 face=Arial size=1>eh</FONT><FONT 
color=#000000 face=Arial size=1>@dat</FONT><FONT color=#000000 face=Arial 
size=1>aconnection.com</FONT>&nbsp;&nbsp; <FONT color=#000000 face=Arial 
size=1>Web</FONT><FONT color=#000000 face=Arial 
size=1>:</FONT>&nbsp;&nbsp;&nbsp;<U> <FONT color=#0000ff face=Arial size=1><A 
href="http://www.dat/" target=_blank>http://www.dat</A></FONT><FONT 
color=#0000ff face=Arial size=1>aconnection.com</FONT></U> 
</P></DIV></BODY></HTML>

------_=_NextPart_001_01C183E5.3BE0EB30--

From: Steve Gardell <[email-masked]>
To: "'John Neystadt'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Some thoughts about IMAP and Unified Messaging
Date: Thu, 13 Dec 2001 09:18:37 -0500
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C183E1.0E265D00
Content-Type: text/plain;
	charset="iso-8859-1"

I would be inclined to add some sort of streaming support along the lines
of draft-nerenberg-imap-channel-02.txt to this list.         

-----Original Message-----
From: John Neystadt [mailto:[email-masked]]
Sent: Wednesday, December 12, 2001 3:05 PM
To: [email-masked]; [email-masked]
Subject: Some thoughts about IMAP and Unified Messaging

Hi!

Analyzing a set of internal IMAP uses/abuses and recent developments in VPIM
group I've came with a list of few modification that can make IMAP ore
friendly with Unified Messaging. If they make sense and represent an
interest for others, I am ready to formulate them and submit as drafts.
 
1. IMAP: Extend SORT to support Message-Context

IMAP-SORT draft supports sorting by a number of keywords (To, Date, Subject,
etc). In order to support sorting per message type it should be extended to
support either arbitrary MIME header or at least Message-Context header
(vpim-hint).

2. IMAP: Add support for UIDs in unsolicited events

Currently unsolicited events in IMAP return Sequence ids of messages. This
requires User-Agent to query server upon receiving unsolicited event for
whole message list if it did not yet fetched list of all messages. Supplying
UIDs will allow server to fetch information only the message that has
changed and reflect it in UI.

3. IMAP: Add support of per Message-Context counters in STATUS command

Currently STATUS Command includes TOTAL and UNSEEN counters. Since UM
user-Agent wants to present counters per Message-Context they should be
included.

4. IMAP: Add support for STATUS of multiple folders

Often User-Agents present a list of folders with counters of a new messages
per each of them. Today STATUS command per folder must be issued. The idea
is to extend STATUS to receive a list of folders as a parameter and produce
single response for all of them.

5. IMAP: Add support for IDLE of multiple folders

Today User-Agents display a list of folders with counters. In order to
maintain list of counters they continuously poll the server with STATUS
command. Instead IDLE with list of folders could enable it to be processed
in a push mode.

6. IMAP: Standardize English names for standard (system) folders in addition
to INBOX - Sent Items, Drafts, Outbox, Deleted Items

Currently localization of INBOX occurs on User-Agent side, while rest of
folders are create directly in local agent. This requires the user to
configure the names of the folders in the User-Agent. The idea is to
standardize English names for all standard folders and make the User-Agent
only to display them in local language.

7. Add support of two new system IMAP flags - to mark messages with \Spam
and \Adult content.

Today SMTP-MTAs often support SPAM and Adult content filtering. Not always
it is possible to remove a message with wrong content, since sometimes a
doubt exist regarding the correctness of the identification. By marking the
message in doubt with system-flag, it will allow User-Agents to process such
messages differently (i.e. color them or put in special folder).

John Neystadt
[email-masked]
http://www.neystadt.org/john/ <http://www.neystadt.org/john/> 

------_=_NextPart_001_01C183E1.0E265D00
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2919.6307" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY background="" bgColor=#ffffff dir=ltr>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=668431514-13122001>I 
would be inclined to add some sort of streaming support along the 
lines</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=668431514-13122001>of 
draft-nerenberg-imap-channel-02.txt</SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=668431514-13122001> to this 
list.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> John Neystadt 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, December 12, 2001 3:05 
  PM<BR><B>To:</B> [email-masked]; 
  [email-masked]<BR><B>Subject:</B> Some thoughts about IMAP and 
  Unified Messaging<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>Hi!<BR><BR>Analyzing a set of internal IMAP 
  uses/abuses and recent developments in VPIM group I've came with a list of few 
  modification that can make IMAP ore friendly with Unified Messaging. If they 
  make sense and represent an interest for others, I am ready to formulate them 
  and submit as drafts.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>1. IMAP: Extend SORT to support 
  Message-Context</FONT></DIV>
  <DIV>
  <P><FONT face=Arial size=2>IMAP-SORT draft supports sorting by a number of 
  keywords (To, Date, Subject, etc). In order to support sorting per message 
  type it should be extended to support either arbitrary MIME header or at least 
  Message-Context header (vpim-hint).</FONT></P>
  <P><FONT face=Arial size=2>2. IMAP: Add support for UIDs in unsolicited 
  events</FONT></P>
  <P><FONT face=Arial size=2>Currently unsolicited events in IMAP return 
  Sequence ids of messages. This requires User-Agent to query server upon 
  receiving unsolicited event for whole message list if it did not yet fetched 
  list of all messages. Supplying UIDs will allow server to fetch information 
  only the message that has changed and reflect it in UI.</FONT></P>
  <P><FONT face=Arial size=2>3. IMAP: Add support of per Message-Context 
  counters in STATUS command</FONT></P>
  <P><FONT face=Arial size=2>Currently STATUS Command includes TOTAL and UNSEEN 
  counters. Since UM user-Agent wants to present counters per Message-Context 
  they should be included.</FONT></P>
  <P><FONT face=Arial size=2>4. IMAP: Add support for STATUS of multiple 
  folders</FONT></P>
  <P><FONT face=Arial size=2>Often User-Agents present a list of folders with 
  counters of a new messages per each of them. Today STATUS command per folder 
  must be issued. The idea is to extend STATUS to receive a list of folders as a 
  parameter and produce single response for all of them.</FONT></P>
  <P><FONT face=Arial size=2>5. IMAP: Add support for IDLE of multiple 
  folders</FONT></P>
  <P><FONT face=Arial size=2>Today User-Agents display a list of folders with 
  counters. In order to maintain list of counters they continuously poll the 
  server with STATUS command. Instead IDLE with list of folders could enable it 
  to be processed in a push mode.</FONT></P>
  <P><FONT face=Arial size=2>6. IMAP: Standardize English names for standard 
  (system) folders in addition to INBOX - Sent Items, Drafts, Outbox, Deleted 
  Items</FONT></P>
  <P><FONT face=Arial size=2>Currently localization of INBOX occurs on 
  User-Agent side, while rest of folders are create directly in local agent. 
  This requires the user to configure the names of the folders in the 
  User-Agent. The idea is to standardize English names for all standard folders 
  and make the User-Agent only to display them in local language.</FONT></P>
  <P><FONT face=Arial size=2>7. Add support of two new system IMAP flags - to 
  mark messages with \Spam and \Adult content.</FONT></P>
  <P><FONT face=Arial size=2>Today SMTP-MTAs often support SPAM and Adult 
  content filtering. Not always it is possible to remove a message with wrong 
  content, since sometimes a doubt exist regarding the correctness of the 
  identification. By marking the message in doubt with system-flag, it will 
  allow User-Agents to process such messages differently (i.e. color them or put 
  in special folder).</FONT></P>
  <P><FONT face=Arial size=2>John Neystadt<BR>[email-masked]<BR><A 
  href="http://www.neystadt.org/john/">http://www.neystadt.org/john/</A></FONT></P>
  <P><FONT face=Arial size=2></FONT>&nbsp;</P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C183E1.0E265D00--

From: "Neystadt, John" <[email-masked]>
To: "'Mark Crispin'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] re: Some thoughts about IMAP and Unified Messaging
Date: Thu, 13 Dec 2001 13:46:34 +0200
Sender: [email-masked]

> On Wed, 12 Dec 2001 22:05:16 +0200, John Neystadt wrote:
> > 1. IMAP: Extend SORT to support Message-Context
> 
> This could be done by an IMAP extension for VPIM.  Since 
> Message-Context is
> not a MIME base header it probably does not belong in the 
> SORT base document.

Marc, the SORT itself is a draft. Why do a separate effort and not include
it straight in SORT? BTW: I've tried to look in archives and did not found a
discussion of including a generic HEADER keyword discussion for SORT. Why
not allow sorting by ANY header?

> > 2. IMAP: Add support for UIDs in unsolicited events
> 
> This can't be done without breaking IMAP2 compatibility.  
> IMAP2 clients are
> not extinct yet.  We've learned that the hard way.

Why? If we introduce a new UIDIDLE capability and syntax of 

tag UID IDLE

with new untagged responses, like:

S: * 44 UID EXPUNGE
S: * 108 UID FETCH (FLAGS (\Seen))

This will not affect existing clients.

> > 4. IMAP: Add support for STATUS of multiple folders
> 
> STATUS does not accept multiple mailboxes for a reason; the 
> metadata obtained
> by STATUS may not be available to the server except by doing 
> an internal
> SELECT.  Forcing clients to do a STATUS command per mailbox 
> emphasizes that
> this is not something that should be done on a wanton basis.
> 
> There is an effort underway to extend LIST to return 
> additional mailbox
> metadata, but only if the server chooses to offer it.

I do believe that this should be done with s single command. Overloading
server with tens of STATUSes per tens (or hundreds) mailbox-es is a bad
bahaviour on slow links. I do agree that this can be done with an another
extension to LIST-EXTENSIONS. However LIST response in a one-liner per
mailbox, while STATUS has a set of already defined responses. Moving this to
LIST will require duplication of responses for existing metadata (UNSEEN,
etc.).

> > 5. IMAP: Add support for IDLE of multiple folders
> 
> The same effect can be achieved with multiple connections, 
> one for each
> mailbox, each in an IDLE.  That way, instead of adding a multiplexing
> mechanism to IMAP, it uses the wonderful multiplexing system 
> that every
> Internet system has built in for free: TCP.

Well, you basically say - it is a client problem. Opening tens of
connections for tens of visible mailboxes seems to me impractical and will
severe damage server scalability. With my proposal, server can have a
special optimized provisions (like subscribe for file system changes
notifications) and it will be much more efficiently. 

> > 6. IMAP: Standardize English names for standard (system) 
> folders in addition
> > to INBOX - Sent Items, Drafts, Outbox, Deleted Items
> 
> I consider it to be a great stretch to call any of these 
> "standardized", and
> as far as "Deleted Items" goes that is nothing less than a wholesale
> abandonment of IMAP.
> 
> "Outbox" has at least two incompatible roles in common use by 
> clients.  Pick a
> definition for what "Outbox" can mean, and I can argue quite 
> convincingly that
> you're wrong and the only correct definition is a different 
> one.  So you give
> in and go with that definition; I'll then argue quite 
> convincingly that the
> first definition was right.
> 
> This type of MUA-dependent functionality does not belong in IMAP.

Well, INBOX name is a part of IMAP standard. Sent Items is a paradigm used
by all MUAs on all OSes, so ignoring it is impractical. Other folders are
more controversial. However I think it is better to standardize
controversial names as recommendation, since there is no harm for those MUAs
who don't use it.

> > 7. Add support of two new system IMAP flags - to mark 
> messages with \Spam
> > and \Adult content.
> 
> There is no need to do this; keywords will accomplish the 
> same thing.  There
> is even a mechanism for inter-client keywords (the "$" 
> prefix) that are well
> known (perhaps we need a formal IANA registry of these).

Agreed.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

Date: Wed, 12 Dec 2001 21:13:55 -0700
To: "Milt Roselinsky" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: RE: SNAP progress and request for comment
Sender: [email-masked]

Some comments:

I second the suggestion to use BEEP instead of HTTP.

Please use hyphens in your header attributes (e.g., 
"Notification-Protocol-Version").  Also, clarify is case is 
significant (I think it shouldn't be).

What is the point of ApplicationName?  Is the server going to act 
differently based on the value?

You specify that all times must be in GMT (even requiring translation 
from a 'Date:' header field).  Using local time with a time zone 
conveys more information, often useful.  For example, if the event 
occurred in the middle of the night versus the afternoon, local wall 
time.

Your request types might be better as hierarchical codes, either 
textual or numeric (like Delivery Status Notifications (DSNs)).  For 
example, "Account-Locked/Login-Error-Max-Exceeded" or xxx.yyy.zzz.

(Wow -- a normative reference to MIXER!)

I second the suggestion to send information on the MIME structure 
instead of just Content-Disposition headers.

I'm not sure I like the idea of sending the message body.  I think 
that opens a potential for a lot of problems, and turns this from a 
notification protocol into a third way to get local mail.  At any 
rate, if you are going to send the body, and you allow only part of 
it to be sent, the original size needs to be included, so it is clear.

The Reject Group seems like it should use DSN codes.

The Mailbox Full Status seems like it should have a DSN code and a 
human-readable text component.

Date: Wed, 12 Dec 2001 21:01:27 -0700
To: "Milt Roselinsky" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: RE: SNAP progress and request for comment
Sender: [email-masked]

At 4:43 PM -0800 12/12/01, Milt Roselinsky wrote:

>  In bandwidth starved environments, it would be a huge win to be able to
>  provide payload in the notification.

Maybe, maybe not.  A lot of bandwidth could be consumed with notifications.

Date: Wed, 12 Dec 2001 17:06:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Some thoughts about IMAP and Unified Messaging
To: John Neystadt <[email-masked]>
cc: [email-masked], [email-masked]
Sender: [email-masked]

On Wed, 12 Dec 2001 22:05:16 +0200, John Neystadt wrote:
> 1. IMAP: Extend SORT to support Message-Context

This could be done by an IMAP extension for VPIM.  Since Message-Context is
not a MIME base header it probably does not belong in the SORT base document.

> 2. IMAP: Add support for UIDs in unsolicited events

This can't be done without breaking IMAP2 compatibility.  IMAP2 clients are
not extinct yet.  We've learned that the hard way.

> 3. IMAP: Add support of per Message-Context counters in STATUS command

This can also be done by an IMAP extension for VPIM.

> 4. IMAP: Add support for STATUS of multiple folders

STATUS does not accept multiple mailboxes for a reason; the metadata obtained
by STATUS may not be available to the server except by doing an internal
SELECT.  Forcing clients to do a STATUS command per mailbox emphasizes that
this is not something that should be done on a wanton basis.

There is an effort underway to extend LIST to return additional mailbox
metadata, but only if the server chooses to offer it.

> 5. IMAP: Add support for IDLE of multiple folders

The same effect can be achieved with multiple connections, one for each
mailbox, each in an IDLE.  That way, instead of adding a multiplexing
mechanism to IMAP, it uses the wonderful multiplexing system that every
Internet system has built in for free: TCP.

> 6. IMAP: Standardize English names for standard (system) folders in addition
> to INBOX - Sent Items, Drafts, Outbox, Deleted Items

I consider it to be a great stretch to call any of these "standardized", and
as far as "Deleted Items" goes that is nothing less than a wholesale
abandonment of IMAP.

"Outbox" has at least two incompatible roles in common use by clients.  Pick a
definition for what "Outbox" can mean, and I can argue quite convincingly that
you're wrong and the only correct definition is a different one.  So you give
in and go with that definition; I'll then argue quite convincingly that the
first definition was right.

This type of MUA-dependent functionality does not belong in IMAP.

> 7. Add support of two new system IMAP flags - to mark messages with \Spam
> and \Adult content.

There is no need to do this; keywords will accomplish the same thing.  There
is even a mechanism for inter-client keywords (the "$" prefix) that are well
known (perhaps we need a formal IANA registry of these).

From: "Milt Roselinsky" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: SNAP progress and request for comment
Date: Wed, 12 Dec 2001 16:43:07 -0800
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 7:27 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: SNAP progress and request for comment
>
>
> Thanks for your comment
>
> See my comments in text:
>
>
> > I have a few comments about the current draft, and some larger comments
> > about the scope of the ID
> >
> > In section 3.5.11 and 3.5.12 regarding attachment names and number of
> > attachments, using Content Disposition isn't a very reliable
> way of gaining
> > this information. Perhaps an IMAP-like bodystructure that's
> annotated with
> > attachment information would be more useful.
> Basically I agree that Content Disposition isn't the best thing.
> But, your alternative will make the work very "expensive". If for
> each email entering the system we will need to do this annotation
> - it will be a killer for the SMTP process on the email server
> side. Any one - thoughts on the issue?

There are very few situations where Content Disposition is going to work.
Yet in the current SNAP ID its the basis of some important functionality.
IMO it would be better to make provision of a description of message content
optional and then describe something that works than to design something
that isn't likely to work.

>
> >
> > 3.5.14 - Body should enable sending non-text body content - the
> decision on
> > what is appropriate content is outside the scope of SNAP.
> I am not sure I agree with you. This is a notification protocol
> and not a messaging transferring  protocol. The notification
> protocol should be rich enough in order to allow the notification
> server (or the UA that the notification server usses to notify
> the user) to retrieve the new message. The fact that we added the
> text (and maybe we shouldn't have..) was because of the facts
> that some of the UA are primitive and can't retrieve the message.

In bandwidth starved environments, it would be a huge win to be able to
provide payload in the notification.  Why not design something with network
efficiency in mind?

> >
> > 3.6 - counters group - specific message type counters are very
> limiting, it
> > would be better to have an extensible mechanism.
> See my later comment on the issue

This issue is actually separate from the issue of using notification for
other applications.  The counters group would be much better served by
allowing a simple extensible list of counters.  To support fax, voice and
email as in the current ID, this could be a list
"Counters:total=X,image/tiff=Y,multipart/voice-message=Z".  If an
implementation wanted to provide the number of any other media type, they
could just add it to the list.  If the recipient of this information doesn't
care about some of the information, it can just ignore it.

> >
> > General comment:
> >
> > This protocol is very specific to notification of mailbox
> status but mailbox
> > status is just one of the many applications that use
> notification.  It seems
> > that there should be application specific payload descriptions
> in the body
> > of these messages one of them related to MWI and other mailbox related
> > information and other related to other notification events.
> The interface
> > to the notification service should handle more than mailbox events.
> >
> > I strongly encourage you to expand the capabilities of the
> notification ID
> > by generalizing payload, counters and by adding an area for application
> > specific metadata.   As application developers or future IETF
> working groups
> > adopt the notification standard, they would publish the
> definition of that
> > application specific usage.
> >
> The idea of having one notification protocol for a range of
> notification events has been talked about in the past. The
> problem with this is that trying to have a generic notification
> protocol has been tried in the past and failed. What we are
> trying to do is to attack the problem - one after the other -
> starting with the messaging arena. I understand the wish to have
> a multi-purpose protocol for notification (I share it) but it
> will be impossible to close it ever. We might need to add a
> header that will help us to extend the protocol later on. What do
> you think?

I think I'm disappointed at limiting scope so drastically.  With this
approach we're doomed to implementing the same basic functions many times.

>
> > Milt Roselinsky
> > Openwave Systems
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of Shapira, Noam
> > > Sent: Tuesday, December 04, 2001 10:39 PM
> > > To: [email-masked]
> > > Subject: SNAP progress and request for comment
> > >
> > >
> > >
> > > Hi all,
> > >
> > > As you know, a new SNAP draft has been submitted to (can be found in
> > > http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).
> > >
> > > As one can recall, the SNAP describes a notification protocol
> between a
> > > Messaging Server (e.g. Email Server) and a Notification server
> > > (as specified
> > > in the draft).
> > >
> > > I would like to share some of the changes / decisions made and ask for
> > > comment on them:
> > >
> > > 1. Bind the SNAP to HTTP. This was a very big issue that we
> closed (after
> > > putting it in the SNAP mailing list). There where 3 alternatives:
> > > 	- HTTP
> > > 	- BEEP
> > > 	- No binding (and leaving the decision to the implementers).
> > >     Comments?
> > >
> > > 2. Choose 2822 like as the format of the SNAP payload. Again,
> > > there where a
> > > few alternatives:
> > > 	- 2822 Like,
> > > 	- XML
> > > 	- In the HTTP query string (in the format of "attribute = value&)
> > >     2822 like format was chosen as it is more "friendly" to
> email servers.
> > > XML has a great deal of supporters as well so it was hard to
> > > decide. I would
> > > be happy to get comments.
> > >
> > > 3. Make sure that the SNAP is compatible with 2822.
> > >
> > > 4. Made sure that message-Context is compatible with
> > > http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt
> > >
> > > 5. Draft structural changes:
> > > 	- Added top-level requirements,
> > > 	- Partitioned the draft to 3 main part: Transport Layer, Semantics
> > > and format.
> > > 	- Better define the scope of the SNAP.
> > > 	- Added both IANA and Security considerations
> > > 	- Added extended terminology
> > >
> > >
> > > I would be happy to get comments and suggestions
> > >
> > > Thanks
> > >
> > > Noam
> > >
> > >
> > >
> >
> >
> >
>
>

From: "Shapira, Noam" <[email-masked]>
To: [email-masked]
Subject: FW: SNAP progress and request for comment
Date: Thu, 13 Dec 2001 01:35:05 +0200
Sender: [email-masked]

As I am not sure it arrived

-----Original Message-----
From: Shapira, Noam(Wakefield) 
Sent: Wednesday, December 12, 2001 5:27 PM
To: [email-masked]; Shapira, Noam; [email-masked];
[email-masked]; [email-masked]
Subject: RE: SNAP progress and request for comment

Thanks for your comment

See my comments in text:

> I have a few comments about the current draft, and some larger comments
> about the scope of the ID
> 
> In section 3.5.11 and 3.5.12 regarding attachment names and number of
> attachments, using Content Disposition isn't a very reliable way of
gaining
> this information. Perhaps an IMAP-like bodystructure that's annotated with
> attachment information would be more useful.
Basically I agree that Content Disposition isn't the best thing. But, your
alternative will make the work very "expensive". If for each email entering
the system we will need to do this annotation - it will be a killer for the
SMTP process on the email server side. Any one - thoughts on the issue?

> 
> 3.5.14 - Body should enable sending non-text body content - the decision
on
> what is appropriate content is outside the scope of SNAP.
I am not sure I agree with you. This is a notification protocol and not a
messaging transferring  protocol. The notification protocol should be rich
enough in order to allow the notification server (or the UA that the
notification server usses to notify the user) to retrieve the new message.
The fact that we added the text (and maybe we shouldn't have..) was because
of the facts that some of the UA are primitive and can't retrieve the
message.

> 
> 3.6 - counters group - specific message type counters are very limiting,
it
> would be better to have an extensible mechanism.
See my later comment on the issue
> 
> General comment:
> 
> This protocol is very specific to notification of mailbox status but
mailbox
> status is just one of the many applications that use notification.  It
seems
> that there should be application specific payload descriptions in the body
> of these messages one of them related to MWI and other mailbox related
> information and other related to other notification events.  The interface
> to the notification service should handle more than mailbox events.
> 
> I strongly encourage you to expand the capabilities of the notification ID
> by generalizing payload, counters and by adding an area for application
> specific metadata.   As application developers or future IETF working
groups
> adopt the notification standard, they would publish the definition of that
> application specific usage.
> 
The idea of having one notification protocol for a range of notification
events has been talked about in the past. The problem with this is that
trying to have a generic notification protocol has been tried in the past
and failed. What we are trying to do is to attack the problem - one after
the other - starting with the messaging arena. I understand the wish to have
a multi-purpose protocol for notification (I share it) but it will be
impossible to close it ever. We might need to add a header that will help us
to extend the protocol later on. What do you think?

> Milt Roselinsky
> Openwave Systems
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Shapira, Noam
> > Sent: Tuesday, December 04, 2001 10:39 PM
> > To: [email-masked]
> > Subject: SNAP progress and request for comment
> >
> >
> >
> > Hi all,
> >
> > As you know, a new SNAP draft has been submitted to (can be found in
> > http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).
> >
> > As one can recall, the SNAP describes a notification protocol between a
> > Messaging Server (e.g. Email Server) and a Notification server
> > (as specified
> > in the draft).
> >
> > I would like to share some of the changes / decisions made and ask for
> > comment on them:
> >
> > 1. Bind the SNAP to HTTP. This was a very big issue that we closed
(after
> > putting it in the SNAP mailing list). There where 3 alternatives:
> > 	- HTTP
> > 	- BEEP
> > 	- No binding (and leaving the decision to the implementers).
> >     Comments?
> >
> > 2. Choose 2822 like as the format of the SNAP payload. Again,
> > there where a
> > few alternatives:
> > 	- 2822 Like,
> > 	- XML
> > 	- In the HTTP query string (in the format of "attribute = value&)
> >     2822 like format was chosen as it is more "friendly" to email
servers.
> > XML has a great deal of supporters as well so it was hard to
> > decide. I would
> > be happy to get comments.
> >
> > 3. Make sure that the SNAP is compatible with 2822.
> >
> > 4. Made sure that message-Context is compatible with
> > http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt
> >
> > 5. Draft structural changes:
> > 	- Added top-level requirements,
> > 	- Partitioned the draft to 3 main part: Transport Layer, Semantics
> > and format.
> > 	- Better define the scope of the SNAP.
> > 	- Added both IANA and Security considerations
> > 	- Added extended terminology
> >
> >
> > I would be happy to get comments and suggestions
> >
> > Thanks
> >
> > Noam
> >
> >
> >
> 
> 
> 

Date: Wed, 12 Dec 2001 22:05:16 +0200
From: John Neystadt <[email-masked]>
Subject: Some thoughts about IMAP and Unified Messaging
To: [email-masked], [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_/6nOZTVEQlKXkBJUwktN3w)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi!

Analyzing a set of internal IMAP uses/abuses and recent developments in VPIM
group I've came with a list of few modification that can make IMAP ore
friendly with Unified Messaging. If they make sense and represent an
interest for others, I am ready to formulate them and submit as drafts.

1. IMAP: Extend SORT to support Message-Context
IMAP-SORT draft supports sorting by a number of keywords (To, Date, Subject,
etc). In order to support sorting per message type it should be extended to
support either arbitrary MIME header or at least Message-Context header
(vpim-hint).

2. IMAP: Add support for UIDs in unsolicited events

Currently unsolicited events in IMAP return Sequence ids of messages. This
requires User-Agent to query server upon receiving unsolicited event for
whole message list if it did not yet fetched list of all messages. Supplying
UIDs will allow server to fetch information only the message that has
changed and reflect it in UI.

3. IMAP: Add support of per Message-Context counters in STATUS command

Currently STATUS Command includes TOTAL and UNSEEN counters. Since UM
user-Agent wants to present counters per Message-Context they should be
included.

4. IMAP: Add support for STATUS of multiple folders

Often User-Agents present a list of folders with counters of a new messages
per each of them. Today STATUS command per folder must be issued. The idea
is to extend STATUS to receive a list of folders as a parameter and produce
single response for all of them.

5. IMAP: Add support for IDLE of multiple folders

Today User-Agents display a list of folders with counters. In order to
maintain list of counters they continuously poll the server with STATUS
command. Instead IDLE with list of folders could enable it to be processed
in a push mode.

6. IMAP: Standardize English names for standard (system) folders in addition
to INBOX - Sent Items, Drafts, Outbox, Deleted Items

Currently localization of INBOX occurs on User-Agent side, while rest of
folders are create directly in local agent. This requires the user to
configure the names of the folders in the User-Agent. The idea is to
standardize English names for all standard folders and make the User-Agent
only to display them in local language.

7. Add support of two new system IMAP flags - to mark messages with \Spam
and \Adult content.

Today SMTP-MTAs often support SPAM and Adult content filtering. Not always
it is possible to remove a message with wrong content, since sometimes a
doubt exist regarding the correctness of the identification. By marking the
message in doubt with system-flag, it will allow User-Agents to process such
messages differently (i.e. color them or put in special folder).

John Neystadt
[email-masked]
http://www.neystadt.org/john/

--Boundary_(ID_/6nOZTVEQlKXkBJUwktN3w)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY dir=ltr bgColor=#ffffff background="">
<DIV><FONT face=Arial size=2>Hi!<BR><BR>Analyzing a set of internal IMAP 
uses/abuses and recent developments in VPIM group I've came with a list of few 
modification that can make IMAP ore friendly with Unified Messaging. If they 
make sense and represent an interest for others, I am ready to formulate them 
and submit as drafts.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>1. IMAP: Extend SORT to support 
Message-Context</FONT></DIV>
<DIV>
<P><FONT face=Arial size=2>IMAP-SORT draft supports sorting by a number of 
keywords (To, Date, Subject, etc). In order to support sorting per message type 
it should be extended to support either arbitrary MIME header or at least 
Message-Context header (vpim-hint).</FONT></P>
<P><FONT face=Arial size=2>2. IMAP: Add support for UIDs in unsolicited 
events</FONT></P>
<P><FONT face=Arial size=2>Currently unsolicited events in IMAP return Sequence 
ids of messages. This requires User-Agent to query server upon receiving 
unsolicited event for whole message list if it did not yet fetched list of all 
messages. Supplying UIDs will allow server to fetch information only the message 
that has changed and reflect it in UI.</FONT></P>
<P><FONT face=Arial size=2>3. IMAP: Add support of per Message-Context counters 
in STATUS command</FONT></P>
<P><FONT face=Arial size=2>Currently STATUS Command includes TOTAL and UNSEEN 
counters. Since UM user-Agent wants to present counters per Message-Context they 
should be included.</FONT></P>
<P><FONT face=Arial size=2>4. IMAP: Add support for STATUS of multiple 
folders</FONT></P>
<P><FONT face=Arial size=2>Often User-Agents present a list of folders with 
counters of a new messages per each of them. Today STATUS command per folder 
must be issued. The idea is to extend STATUS to receive a list of folders as a 
parameter and produce single response for all of them.</FONT></P>
<P><FONT face=Arial size=2>5. IMAP: Add support for IDLE of multiple 
folders</FONT></P>
<P><FONT face=Arial size=2>Today User-Agents display a list of folders with 
counters. In order to maintain list of counters they continuously poll the 
server with STATUS command. Instead IDLE with list of folders could enable it to 
be processed in a push mode.</FONT></P>
<P><FONT face=Arial size=2>6. IMAP: Standardize English names for standard 
(system) folders in addition to INBOX - Sent Items, Drafts, Outbox, Deleted 
Items</FONT></P>
<P><FONT face=Arial size=2>Currently localization of INBOX occurs on User-Agent 
side, while rest of folders are create directly in local agent. This requires 
the user to configure the names of the folders in the User-Agent. The idea is to 
standardize English names for all standard folders and make the User-Agent only 
to display them in local language.</FONT></P>
<P><FONT face=Arial size=2>7. Add support of two new system IMAP flags - to mark 
messages with \Spam and \Adult content.</FONT></P>
<P><FONT face=Arial size=2>Today SMTP-MTAs often support SPAM and Adult content 
filtering. Not always it is possible to remove a message with wrong content, 
since sometimes a doubt exist regarding the correctness of the identification. 
By marking the message in doubt with system-flag, it will allow User-Agents to 
process such messages differently (i.e. color them or put in special 
folder).</FONT></P>
<P><FONT face=Arial size=2>John Neystadt<BR>[email-masked]<BR><A 
href="http://www.neystadt.org/john/">http://www.neystadt.org/john/</A></FONT></P>
<P><FONT face=Arial size=2></FONT>&nbsp;</P></DIV></BODY></HTML>

--Boundary_(ID_/6nOZTVEQlKXkBJUwktN3w)--

From: "Milt Roselinsky" <[email-masked]>
To: "Shapira, Noam" <[email-masked]>, <[email-masked]>
Subject: RE: SNAP progress and request for comment
Date: Tue, 11 Dec 2001 07:53:34 -0800
Importance: Normal
Sender: [email-masked]

I have a few comments about the current draft, and some larger comments
about the scope of the ID

In section 3.5.11 and 3.5.12 regarding attachment names and number of
attachments, using Content Disposition isn't a very reliable way of gaining
this information. Perhaps an IMAP-like bodystructure that's annotated with
attachment information would be more useful.

3.5.14 - Body should enable sending non-text body content - the decision on
what is appropriate content is outside the scope of SNAP.

3.6 - counters group - specific message type counters are very limiting, it
would be better to have an extensible mechanism.

General comment:

This protocol is very specific to notification of mailbox status but mailbox
status is just one of the many applications that use notification.  It seems
that there should be application specific payload descriptions in the body
of these messages one of them related to MWI and other mailbox related
information and other related to other notification events.  The interface
to the notification service should handle more than mailbox events.

I strongly encourage you to expand the capabilities of the notification ID
by generalizing payload, counters and by adding an area for application
specific metadata.   As application developers or future IETF working groups
adopt the notification standard, they would publish the definition of that
application specific usage.

Milt Roselinsky
Openwave Systems

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Shapira, Noam
> Sent: Tuesday, December 04, 2001 10:39 PM
> To: [email-masked]
> Subject: SNAP progress and request for comment
>
>
>
> Hi all,
>
> As you know, a new SNAP draft has been submitted to (can be found in
> http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).
>
> As one can recall, the SNAP describes a notification protocol between a
> Messaging Server (e.g. Email Server) and a Notification server
> (as specified
> in the draft).
>
> I would like to share some of the changes / decisions made and ask for
> comment on them:
>
> 1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
> putting it in the SNAP mailing list). There where 3 alternatives:
> 	- HTTP
> 	- BEEP
> 	- No binding (and leaving the decision to the implementers).
>     Comments?
>
> 2. Choose 2822 like as the format of the SNAP payload. Again,
> there where a
> few alternatives:
> 	- 2822 Like,
> 	- XML
> 	- In the HTTP query string (in the format of "attribute = value&)
>     2822 like format was chosen as it is more "friendly" to email servers.
> XML has a great deal of supporters as well so it was hard to
> decide. I would
> be happy to get comments.
>
> 3. Make sure that the SNAP is compatible with 2822.
>
> 4. Made sure that message-Context is compatible with
> http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt
>
> 5. Draft structural changes:
> 	- Added top-level requirements,
> 	- Partitioned the draft to 3 main part: Transport Layer, Semantics
> and format.
> 	- Better define the scope of the SNAP.
> 	- Added both IANA and Security considerations
> 	- Added extended terminology
>
>
> I would be happy to get comments and suggestions
>
> Thanks
>
> Noam
>
>
>

Date: Sun, 09 Dec 2001 16:16:23 -0700
From: Chris Newman <[email-masked]>
To: "Shapira, Noam" <[email-masked]>, [email-masked]
Subject: Re: SNAP progress and request for comment
Sender: [email-masked]

--On Wednesday, December 5, 2001 8:39 +0200 "Shapira, Noam" 
<[email-masked]> wrote:
> 1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
> putting it in the SNAP mailing list). There where 3 alternatives:
> 	- HTTP
> 	- BEEP
> 	- No binding (and leaving the decision to the implementers).
>     Comments?

I strongly prefer BEEP because this is the sort of thing BEEP was designed 
for.  I am strongly opposed to an HTTP-only option, because HTTP is two or 
three times the complexity of BEEP and provides less functionality when 
abused as a protocol framework.  In particular, HTTP has an inflexible 
security model, complex and spotty support for persistant connections, and 
complex proxy semantics.  You'll have to write a lot of text to justify the 
abuse of HTTP and there's a good chance the IESG will reject it, especially 
given the experience with IPP.  BEEP would be a slam-dunk.

> 2. Choose 2822 like as the format of the SNAP payload. Again, there where
> a few alternatives:
> 	- 2822 Like,
> 	- XML
> 	- In the HTTP query string (in the format of "attribute = value&)
>     2822 like format was chosen as it is more "friendly" to email servers.
> XML has a great deal of supporters as well so it was hard to decide. I
> would be happy to get comments.

I'd lean slightly towards XML, since I think all email servers will 
eventually end up with an XML parser for one reason or another, but there's 
really no reason for a notification server to have anything other than an 
XML parser.  Having written an XML and a 2822 parser, they're about the 
same complexity although XML is slightly more flexible with respect to 
structure.  Of course we're talking about one moderate-sized .c file either 
way so it just doesn't matter much in the big picture.

		- Chris

From: "Shapira, Noam" <[email-masked]>
To: [email-masked]
Subject: SNAP progress and request for comment
Date: Wed, 5 Dec 2001 08:39:21 +0200 
Sender: [email-masked]

Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.

4. Made sure that message-Context is compatible with
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt

5. Draft structural changes: 
	- Added top-level requirements, 
	- Partitioned the draft to 3 main part: Transport Layer, Semantics
and format.
	- Better define the scope of the SNAP.
	- Added both IANA and Security considerations
	- Added extended terminology		

I would be happy to get comments and suggestions

Thanks

Noam

From: "Shapira, Noam" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SNAP progress and request for comment
Date: Wed, 5 Dec 2001 08:13:24 +0200 
Sender: [email-masked]

Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.

4. Made sure that message-Context is compatible with
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt

5. Draft structural changes: 
	- Added top-level requirements, 
	- Partitioned the draft to 3 main part: Transport Layer, Semantics
and format.
	- Better define the scope of the SNAP.
	- Added both IANA and Security considerations
	- Added extended terminology		

I would be happy to get comments and suggestions

Thanks

Noam

From: "Shapira, Noam" <[email-masked]>
To: [email-masked]
Subject: SNAP progress and request for comment
Date: Tue, 4 Dec 2001 19:38:38 +0200 
Sender: [email-masked]

Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.

4. Made sure that message-Context is compatible with
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt

5. Draft structural changes: 
	- Added top-level requirements, 
	- Partitioned the draft to 3 main part: Transport Layer, Semantics
and format.
	- Better define the scope of the SNAP.
	- Added both IANA and Security considerations
	- Added extended terminology		

I would be happy to get comments and suggestions

Thanks

Noam

Date: Tue, 04 Dec 2001 00:37:10 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

> We can also discuss LISTEXT if there is enough interest (Barry, are you
> coming to Salt Lake?)

I'm not, no -- no travel money.  If you discuss it, though, send me notes
and I'll make adjustments to the draft, and we can continue discussion on
the mailing list -- 's been pretty quiet of late.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Mon, 03 Dec 2001 22:13:56 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

Cyrus Daboo wrote:

> --On Monday, December 3, 2001 12:11 PM -0600 Pete Resnick
> <[email-masked]> wrote:
>
> > What are we talking about other than ANNOTATE and ACL?
>
> Conditional store - since ANNOTATE references that. Also we should discuss
> the issue of i18n for SORT/THREAD (which was a requirement from the last
> meeting). There is an i18n for internet protocols boff earlier in the week
> which I think will be relevant to this.

I tend to agree with Cyrus.

We can also discuss LISTEXT if there is enough interest (Barry, are you coming
to Salt Lake?)

On a related note, what happend to WINDOW?

Alexey

Date: Mon, 03 Dec 2001 13:55:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

--On Monday, December 3, 2001 12:11 PM -0600 Pete Resnick 
<[email-masked]> wrote:

> What are we talking about other than ANNOTATE and ACL?

Conditional store - since ANNOTATE references that. Also we should discuss 
the issue of i18n for SORT/THREAD (which was a requirement from the last 
meeting). There is an i18n for internet protocols boff earlier in the week 
which I think will be relevant to this.

-- 
Cyrus Daboo

Date: Mon, 3 Dec 2001 12:49:47 -0600
To: "Shapira, Noam" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: Agenda
Cc: [email-masked]
Sender: [email-masked]

On 12/3/01 at 8:39 PM +0200, you wrote:

>I would be happy if I could get the opportunity to present the new version
>of SNAP (Simple Notification and Alarm Protocol) - discuss some of the
>decisions taken in the new draft (some of which where raised in this mailing
>list and in other mailing list).

There won't be presentations in the WG session. I'd be happy to give 
you time on the agenda if you write up and send out to the WG list 
(in the next day or so) the decisions taken in the new draft that you 
wish to discuss. We don't need to waste the time having you present 
this in the WG session itself. Send a message, let people comment on 
the list, and those items that don't get satisfactory review can be 
discussed at the WG meeting.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: "Shapira, Noam" <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: RE: Agenda
Date: Mon, 3 Dec 2001 20:39:46 +0200 
Sender: [email-masked]

Hi,

I would be happy if I could get the opportunity to present the new version
of SNAP (Simple Notification and Alarm Protocol) - discuss some of the
decisions taken in the new draft (some of which where raised in this mailing
list and in other mailing list).

The new draft is available in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt.

Noam

> -----Original Message-----
> From: Pete Resnick [mailto:[email-masked]]
> Sent: Monday, December 03, 2001 8:12 PM
> To: [email-masked]
> Subject: Agenda
> 
> 
> 
> What are we talking about other than ANNOTATE and ACL?
> 
> pr
> -- 
> Pete Resnick <mailto:[email-masked]>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: 
> (858)651-1102
> 

Date: Mon, 3 Dec 2001 12:11:57 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Agenda
Sender: [email-masked]

What are we talking about other than ANNOTATE and ACL?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-02.txt
Date: Mon, 03 Dec 2001 08:37:55 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-02.txt
	Pages		: 19
	Date		: 30-Nov-01
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-annotate-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-annotate-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-annotate-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--