Subject: Minutes of the IMAPEXT meeting at London
From: Pete Resnick <[email-masked]>
To: [email-masked]
Cc: IMAP Extensions <[email-masked]>
Date: Thu, 30 Aug 2001 09:14:35 -0500
List-Id: <ietf-imapext.imc.org>

Minutes of the IMAPEXT Working Group
51st IETF - London

Chair: Pete Resnick
Minutes taker: Lawrence Greenfield (edited by Pete Resnick)

Issues discussed:

1. Access Control List document

Chair notes that the current document editor has been unable to spend 
enough time on it and is therefore handing it off to Alexey Melnikov. 
Alexey will submit a new draft soon accounting for earlier comments 
as possible. Chair will assure that notes taken from a bar-BOF at 
Minneapolis (taken by Chris Newman, we think) will be forwarded to 
Alexey.

2. ANNOTATE document (Cyrus Daboo)

a) Should IMAP flags be mirrored in annotations?

Clearly opposed: Crispin, Nerenberg, Gahrns

- Having two ways to do things is bad with no real benefit
- Additional flags can be done in current protocol which is superior
- Will cause increased complexity (what kinds of responses, do they 
always store to old/new)

Clearly supporting: Resnick, Stebbens

- Clients would prefer to use one mechanism for all annotation-like 
data if it is available
- Easier extensibility
- Features are available that don't exist in base flags (personal v. shared)

Issue to be taken to the list

b) Should there be a suffix default capability (.priv/.shared/nothing)

- List consensus: Explicit statement necessary
- No argument in room

- If system flags are mapped on annotations (see (a)), do they get 
defaults? Room reamined depressed on the matter.

c) Unsolicited annotation responses

- Room agreeds that unsolicited responses are only cache 
invalidations, they aren't the data
- Take to list the issue of whether they should they come only after 
an annotate command has been issued

d) Should the 's' bit be used for "can store private annotations?" 
Should the 'w' bit be used for "can store shared annotations?"

- Greenfield and Daboo debate issue of more bits vs. overloading bits discussed
- Crispin and Resnick agree that since private annotations are 
private to the one storing the annotations and should be stored in 
the space of the annotator, there is no reason for the mailbox owner 
to grant permission for those annotations to exist
- Further discussion indicates that ACL is not where this belongs

3. SORT/THREAD

- IESG has given pushback that some sort of internationalized 
comparison/collation need to exist
- Some folks indicated that a global command that set up 
comaparison/collation for all other commands might not be desirable
- AD (Patrik) indicates that a reasonable default is at least need. 
Unicode technical standard #10 is a good candidate
- Crispin will take two issues to the list: a) What is the default 
comparator? b) What is the correct way of choosing comparators?

4. CONDSTORE

a) MODTIME is currently like ACAP, based off a timestamp
- move it to a 64-bit number, strictly ascending, opaque
- make sure time goes forward if it's used

b) Highest modtime for mailbox added
- Base spec doesn't allow 64-bit numbers in status, but we'll deal.

c) Do we want per message or per flag modtime?
- No opposition to per message.
- No opposition to dropping per flag.

d) Do we need to unify flags & annotations?
- No, but it creates syntax problems.

e) Should we return all items that have changed or just one?
- Alexey wants all.
- Some concerns for servers, but hey, what's a few more comparisons?

5. WINDOW

- Discussion of whether WINDOW/SORT need to move together. Chair 
indicates that extensive cross references aren't needed.

6. LIST extensions

- Greenfield wants to allow "()" at the end of a LIST response to 
allow for extensibility such as referrals or arbitrary status 
information
- Gahrns notes that referrals should be optional

7. BINARY

[Minutes taker notes something was said, but not available]

8. CHANNEL

- Issue is settling down

9. ANNOTATEMORE

So far, no objections

10. LITERAL+/MULTIAPPEND

- Crispin indicates that there are reasons for LITERAL+ that he understands
- Some discussion about whether TRANSACTIONS are necessary, or 
whether they will address some folks concerns in IESG/IAB about the 
complication of the protocol

11. LANGUAGE

Issues brought up:

- server responses
- matching (search/thread)
- collation (sort/list/thread?)
- [annotate]

Some light discussion of going from mUTF-7 to UTF-8

Meeting adjourned.

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

To: Simon Josefsson <[email-masked]>
Cc: <[email-masked]>
Subject: Re: 2086 Access Controls
From: Tim Showalter <[email-masked]>
Date: 27 Aug 2001 11:26:38 -0700
Lines: 19
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

> > Rather than reinvent the wheel, RFC2086 looked like a reasonable baseline,
> > but we have some queries: 
> > *	Which right would grant or deny the ability to rename mailboxes? 
> > *	Similarly, which right enables mailboxes to be deleted?  d seems to
> > be at message level rather than mailbox level 
> 
> I remember a draft updating RFC 2086 that said:
> 
> ;;;    c - create and delete mailbox (CREATE new sub-mailboxes in any
> ;;;        implementation-defined hierarchy, RENAME or DELETE mailbox)
> 
> But I can't find it.  Anyone?

I remember that one, too, but someone objected, and it was changed.  (I
don't like it, but I don't think it was me.)

Tim

Date: Tue, 21 Aug 2001 13:49:19 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: 2086 Access Controls
To: Simon Josefsson <[email-masked]>
cc: Mark Nevins <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 21 Aug 2001 22:44:00 +0200, Simon Josefsson wrote:
> I also remember old discussion about redesigning the ACL extension to
> be less of an AFS-clone.

That discussion is supposedly still alive, and it needs to be completed.  The
current ACL extension lacks some important functionality.

Date: Tue, 21 Aug 2001 15:49:48 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Minutes soon....
Sender: [email-masked]

Sorry for the delay. I will have the meeting minutes submitted by the 
end of this week.

(Thanks, Larry, for getting them to me quickly.)

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

To: "Mark Nevins" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: 2086 Access Controls
From: Simon Josefsson <[email-masked]>
Date: Tue, 21 Aug 2001 22:44:00 +0200
Lines: 17
Sender: [email-masked]

"Mark Nevins" <[email-masked]> writes:

> Rather than reinvent the wheel, RFC2086 looked like a reasonable baseline,
> but we have some queries: 
> *	Which right would grant or deny the ability to rename mailboxes? 
> *	Similarly, which right enables mailboxes to be deleted?  d seems to
> be at message level rather than mailbox level 

I remember a draft updating RFC 2086 that said:

;;;    c - create and delete mailbox (CREATE new sub-mailboxes in any
;;;        implementation-defined hierarchy, RENAME or DELETE mailbox)

But I can't find it.  Anyone?

I also remember old discussion about redesigning the ACL extension to
be less of an AFS-clone.

Date: Tue, 21 Aug 2001 13:31:38 -0700
From: Chris Newman <[email-masked]>
Subject: Re: 2086 Access Controls
To: Mark Nevins <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Tuesday, August 21, 2001 10:57 +0100 Mark Nevins <[email-masked]> 
wrote:
> Rather than reinvent the wheel, RFC2086 looked like a reasonable baseline,
> but we have some queries:
> *	Which right would grant or deny the ability to rename mailboxes?

You need "d" ("x" in next version) on the old name and "c" on the parent of 
the new name.

> *	Similarly, which right enables mailboxes to be deleted?  d seems to
> be at message level rather than mailbox level

Unfortunately, it's "d".  The next revision will add an "x" right for 
mailbox deletion.

> *	Is there a convention for initial rights for a child mailbox.  Would
> the parent's rights be rippled down or are would there only be rights for
> the creator?
> *	Is there a convention for ownership of a child mailbox created under
> a different users parent.  Is the owner the creating user or the parent's
> user.

The implementations I've worked with always inherit the ACL from the parent 
mailbox.

> We hoped to get Cyrus up to see an example of the rights in action but
> have hit some issues.  Where should I go for FAQs / discussion of
> implementation. I've been looking around and found references to a new
> draft for 2086, but have not been able to find it, could anyone let me
> know where I can find this.

Looks like the draft for the revised spec expired.

		- Chris

From: "Mark Nevins" <[email-masked]>
To: <[email-masked]>
Subject: 2086 Access Controls
Date: Tue, 21 Aug 2001 10:57:18 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C12A30.0BD6FC40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi

We're currently implementing access controls for an IMAP server which stores
mail in a database rather than using an operating system's file system.

Rather than reinvent the wheel, RFC2086 looked like a reasonable baseline,
but we have some queries: 
*	Which right would grant or deny the ability to rename mailboxes? 
*	Similarly, which right enables mailboxes to be deleted?  d seems to
be at message level rather than mailbox level 
*	Is there a convention for initial rights for a child mailbox.  Would
the parent's rights be rippled down or are would there only be rights for
the creator? 
*	Is there a convention for ownership of a child mailbox created under
a different users parent.  Is the owner the creating user or the parent's
user. 

We hoped to get Cyrus up to see an example of the rights in action but have
hit some issues.  Where should I go for FAQs / discussion of implementation.
I've been looking around and found references to a new draft for 2086, but
have not been able to find it, could anyone let me know where I can find
this.

Thanks

Mark Nevins
Opsol Integrators Europe Ltd.
Tel:  020 7253 3300
Fax: 020 7253 3353
mailto: [email-masked]
web: www.opsol.co.uk

------=_NextPart_000_000F_01C12A30.0BD6FC40
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_000F_01C12A30.0BD6FC40--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-07.txt
Date: Fri, 17 Aug 2001 07:03:16 -0400
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		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-thread-07.txt
	Pages		: 13
	Date		: 16-Aug-01
	
This document describes the server-based threading extension to the
IMAP4rev1 protocol.  This extension provides substantial performance
improvements for IMAP clients which offer threaded views.
A server which supports this extension indicates this with more or
more capability names consisting of 'THREAD-' followed by a supported
threading algorithm name as described in this document.  This
provides for future upwards-compatible extensions.

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

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-thread-07.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-thread-07.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-thread-07.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-07.txt
Date: Fri, 17 Aug 2001 07:03:11 -0400
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		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-07.txt
	Pages		: 10
	Date		: 16-Aug-01
	
This document describes an experimental server-based sorting
extension to the IMAP4rev1 protocol, as implemented by the University
of Washington's IMAP toolkit.  This extension provides substantial
performance improvements for IMAP clients which offer sorted views.
A server which supports this extension indicates this with a
capability name of 'SORT'.  Client implementations SHOULD accept any
capability name which begins with 'SORT' as indicating support for
the extension described in this document.  This provides for future
upwards-compatible extensions.
At the time of this document was written, the IMAP Extensions Working
Group (IETF-IMAPEXT) was considering upwards-compatible additions to
the SORT extension described in this document, tenatively called the
SORT2 extension.

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

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-sort-07.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-sort-07.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-sort-07.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 15 Aug 2001 18:05:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: IMAPV, MULTIAPPEND, SORT, and THREAD drafts submitted
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I have submitted the above-mentioned four drafts, which I couldn't prior to
the London IETF due to the cut-off.

Please note that the SORT and THREAD drafts do NOT have the new specification
for non-ASCII collation which IESG has indicated that they will require.  The
purpose of this submission is simply to have current drafts on the repository
to replace those which have expired.  There *WILL* be follow-on drafts to SORT
and THREAD with proposed new wording on collation, so please do not assume
that I'm ignoring what was agreed in London.

The same is true with the MULTIAPPEND draft.  There was a suggestion that it
needs to be clarified that MULTIAPPEND is not a new command, but rather a
logical extension to the existing APPEND command.  I like this idea, and will
reflect it in a subsequent draft.  This draft is just to replace the expired
one.

Date: Thu, 9 Aug 2001 14:08:06 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SORT and THREAD collation issues
Sender: [email-masked]

Chris Newman <[email-masked]>
> Validation is a tricky issue that resulted in over a year of debate on the 
> ACAP list.  Given that ACAP reached a rough concensus on the issue, I'd 
> prefer to stick with that (validation is done by the data consumer, not the 
> server).

In that case, distinguishing an int from a bignum isn't the server's job
either, your big-id attribute is quite properly a text/plain, and SORT
needs extra collation cleverness.

And if Cyrus is kind and considerate, he puts in a paragraph about how the
server need not verify STORE ANNOTATION data, and what the client may and
may not expect from FETCH ANNOTATION. Well-formed parentheses and nothing
else, I'd say?

--Arnt

Date: Wed, 08 Aug 2001 15:50:25 -0700
From: Chris Newman <[email-masked]>
Subject: Re: SORT and THREAD collation issues
To: Arnt Gulbrandsen <[email-masked]>
Cc: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

--On Wednesday, August 8, 2001 22:13 +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

> Chris Newman <[email-masked]>
>> We have one annotation which is the bug number associated with a
>> message.  A second annotation is the "user-supplied subject" (akin to
>> what Eudora's  POP client does).  Now suppose you want to sort first by
>> bug number, then  by subject?
>>
>> The problem is they are both string annotations, so you need different
>> collations within the same SORT command (one a numeric collation, the
>> other  an alphabetic collation).
>
> The example sounds reasonable, but what exactly does it lead to? That you
> should be able to store your numbers as numbers instead of text/plain, or
> that sort needs flexible collation?

This is why there's an IMAPEXT WG rather than individual submissions. 
There are cross-dependancies between the individual proposals that need to 
be resolved before advancement.

> Which raises the issue of what clients and servers should do about pretend
> types, and illegal values in general. What should the server do if a
> client writes the five-byte string "crash" into the value of
> /message/flags/forwarded, or another semi-boolean attribute? What should a
> client do if it sees that string there?
>
> It's late and I'm tired, but I also don't see what happens if I try to set
> the content-type of an annotation to e.g. NIL.

Validation is a tricky issue that resulted in over a year of debate on the 
ACAP list.  Given that ACAP reached a rough concensus on the issue, I'd 
prefer to stick with that (validation is done by the data consumer, not the 
server).

		- Chris

Date: Wed, 8 Aug 2001 22:13:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SORT and THREAD collation issues
Sender: [email-masked]

Chris Newman <[email-masked]>
> We have one annotation which is the bug number associated with a message. 
> A second annotation is the "user-supplied subject" (akin to what Eudora's 
> POP client does).  Now suppose you want to sort first by bug number, then 
> by subject?
> 
> The problem is they are both string annotations, so you need different 
> collations within the same SORT command (one a numeric collation, the other 
> an alphabetic collation).

The example sounds reasonable, but what exactly does it lead to? That you
should be able to store your numbers as numbers instead of text/plain, or
that sort needs flexible collation?

Which raises the issue of what clients and servers should do about pretend
types, and illegal values in general. What should the server do if a
client writes the five-byte string "crash" into the value of
/message/flags/forwarded, or another semi-boolean attribute? What should a
client do if it sees that string there?

It's late and I'm tired, but I also don't see what happens if I try to set
the content-type of an annotation to e.g. NIL.

--Arnt

Date: Wed, 08 Aug 2001 16:01:47 -0400
From: Tony Hansen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: SORT and THREAD collation issues
Sender: [email-masked]

The example I think of is being able to do some sorts case dependently
and others case independently. I could see setting a default globally,
but you still need to be able to override that default on occassion.

	Tony

Chris Newman wrote:
> 
> --On Wednesday, August 8, 2001 7:00 -0700 Mike Gahrns
> <[email-masked]> wrote:
> > Chris Newman writes:
> >> Having a collation function that is set
> >> once by some separate command and always used by SORT/THREAD doesn't
> >> seem sufficiently flexible.
> > *** Wouldn't the 99% case be that a user would configure a client once,
> > and then use these settings for the remainder of their IMAP sessions?
> > Admittedly there could be some scenarios where a user might be changing
> > these on the fly between various different SORTS, but it seems that this
> > scenario would be much less common.
> > Setting the Collation function initially at the start of a session via
> > something like the LANGUAGE command, nicely removes some complexity and
> > overhead from SORT/THREAD by not having to repeatedly send the same
> > information over and over again on each SORT/THREAD command.
> > Scenarios that need to change this information, could still do so, by
> > issuing a new LANG command before the next SORT/THREAD command.
> 
> Ok, let me give you a specific example:
> 
> We have one annotation which is the bug number associated with a message.
> A second annotation is the "user-supplied subject" (akin to what Eudora's
> POP client does).  Now suppose you want to sort first by bug number, then
> by subject?
> 
> The problem is they are both string annotations, so you need different
> collations within the same SORT command (one a numeric collation, the other
> an alphabetic collation).
> 
> I agree that changing languages/locales within a session is highly unlikely
> and probably doesn't need to be supported.  But I think changing collation
> functions within a SORT command does need to be supported.
> 
>                 - Chris

Date: Wed, 08 Aug 2001 12:19:28 -0700
From: Chris Newman <[email-masked]>
Subject: RE: SORT and THREAD collation issues
To: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

--On Wednesday, August 8, 2001 7:00 -0700 Mike Gahrns 
<[email-masked]> wrote:
> Chris Newman writes:
>> Having a collation function that is set
>> once by some separate command and always used by SORT/THREAD doesn't
>> seem sufficiently flexible.
> *** Wouldn't the 99% case be that a user would configure a client once,
> and then use these settings for the remainder of their IMAP sessions?
> Admittedly there could be some scenarios where a user might be changing
> these on the fly between various different SORTS, but it seems that this
> scenario would be much less common.
> Setting the Collation function initially at the start of a session via
> something like the LANGUAGE command, nicely removes some complexity and
> overhead from SORT/THREAD by not having to repeatedly send the same
> information over and over again on each SORT/THREAD command.
> Scenarios that need to change this information, could still do so, by
> issuing a new LANG command before the next SORT/THREAD command.

Ok, let me give you a specific example:

We have one annotation which is the bug number associated with a message. 
A second annotation is the "user-supplied subject" (akin to what Eudora's 
POP client does).  Now suppose you want to sort first by bug number, then 
by subject?

The problem is they are both string annotations, so you need different 
collations within the same SORT command (one a numeric collation, the other 
an alphabetic collation).

I agree that changing languages/locales within a session is highly unlikely 
and probably doesn't need to be supported.  But I think changing collation 
functions within a SORT command does need to be supported.

		- Chris

content-class: urn:content-classes:message
Subject: RE: SORT and THREAD collation issues
Date: Wed, 8 Aug 2001 07:00:59 -0700
From: "Mike Gahrns" <[email-masked]>
To: "Chris Newman" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

Chris Newman writes:
> Having a collation function that is set 
> once by some separate command and always used by SORT/THREAD doesn't
seem 
> sufficiently flexible.
*** Wouldn't the 99% case be that a user would configure a client once,
and then use these settings for the remainder of their IMAP sessions?
Admittedly there could be some scenarios where a user might be changing
these on the fly between various different SORTS, but it seems that this
scenario would be much less common.
Setting the Collation function initially at the start of a session via
something like the LANGUAGE command, nicely removes some complexity and
overhead from SORT/THREAD by not having to repeatedly send the same
information over and over again on each SORT/THREAD command.
Scenarios that need to change this information, could still do so, by
issuing a new LANG command before the next SORT/THREAD command.

Date: Mon, 06 Aug 2001 15:27:11 -0700
From: Chris Newman <[email-masked]>
Subject: Re: SORT and THREAD collation issues
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

--On Monday, August 6, 2001 21:16 +0100 Mark Crispin 
<[email-masked]> wrote:
> The next question has to do with the specification of a non-default
> comparison/collation mechanism.  SORT/THREAD anticipate that an external
> mechanism, such as a LANGUAGE extension, would take on the responsibility
> of setting this; meaning that an implementation of both extensions would
> be required to implement the ability to set localized comparison and
> collations.  We assume that this is the desired end state in any case.

Collation is a combination of many factors, including language, locale and 
the type of data one is collating.  Having a collation function that is set 
once by some separate command and always used by SORT/THREAD doesn't seem 
sufficiently flexible.

I suspect we'll need to support more than one collation in a given 
SORT/THREAD command once annotations are added to the mix (since 
annotations make no distinction between numeric and text data).  So my 
inclination would be to use text strings to describe collation functions 
(as in RFC 2244), and use a "COLLATE <tag>" in-line SORT/THREAD criteria 
that sets collation algorithm for the applicable criteria in the remainder 
of the SORT/THREAD program.

I don't really care what document(s) this mechanism ends up in.

		- Chris

Date: Mon, 6 Aug 2001 21:16:46 +0100 (GMT Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SORT and THREAD collation issues
Organization: Networks & Distributed Computing
Sender: [email-masked]

IESG brought up in London the issue of how localized SEARCH, SORT, and
THREAD comparison and collation are to be specified.  Furthermore, the
current non-specification (implying that a UTF-8 binary compare is
alright) of the default comparison/collation will prevent advancement of
SORT and possibly also THREAD.

It has been proposed that adoption of Unicode Technical Standard 10
(TR-10) as the default will address the issue of a satisfactory default
comparison/collation.  The tenative concensus was that, barring some
unexpected showstopper, we should change the wording in SORT/THREAD to
adopt TR-10 as the default.

Is there any known reason why we should not do this?  Are there issues
with implementing TR-10 that we may be unaware of?

The next question has to do with the specification of a non-default
comparison/collation mechanism.  SORT/THREAD anticipate that an external
mechanism, such as a LANGUAGE extension, would take on the responsibility
of setting this; meaning that an implementation of both extensions would
be required to implement the ability to set localized comparison and
collations.  We assume that this is the desired end state in any case.

An alternative has been proposed that SORT, THREAD, and each other
extension dealing with this take on the responsibility itself; e.g. that
there should be an additional argument to specify this.  I am not in favor
of this alternative, but I feel that the exact mechanism to specify the
non-default comparison/collation is "syntactic sugar" -- it really doesn't
matter.  We ought to be able to move forward with a tenative understanding
that we eventually need to pick our favorite sugar...

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Sat, 04 Aug 2001 23:20:47 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Proposal for ANNOTATEMORE extension
Sender: [email-masked]

Cyrus, your proposal sounds like a good idea. IMHO, we should discuss it if we
have enough time.

Cyrus Daboo wrote:

> Hi folks,
> Since we're getting close to completing ANNOTATE (some issues are still
> unresolved on the list), I'd like to propose an extension to add
> annotations for mailboxes and the server. I'm calling this ANNOTATEMORE.
>
> The idea with this is to allow annotations to be attached to each mailbox,
> and for a set of 'global' annotations associated with the server itself.
> Examples of use include a 'message of the day' server annotation, an
> annotation on mailboxes indicating the default sort order to use when
> displaying the mailbox to the user etc.

Do we want private/shared annotations (for mailbox - probably yes, server -
likely not)

> My proposal is to use the same entry/attribute/value data model that
> ANNOTATE uses. In this case we would have /server and /mailbox/<mailbox
> name> top level entries. We would have to have two new commands for reading
> and writing annotations, and a new untagged response for returning the
> annotation data, e.g.:
>
> a SETANNOTATION ("/mailbox/INBOX/sort" ("value" "SUBJECT"))
> a OK SETANNOTATION complete
>
> a GETANNOTATION ("/server/motd" "value"))
> * ANNOTATION ("/server/motd" ("value" "Server maintenance at 10 pm"))
> a OK GETANNOTATION complete

I believe a lot of servers will choose not to implement SETANNOTATION (i.e. it
will always return NO), but this is probably reasonable to expect.

> I believe this is a logical extension to the message annotation capability
> that ANNOTATE introduces, and there is already one server that has its own
> equivalent of the server annotation mechanism, so it would be good to
> standardise this.
>
> I'm prepared to describe this in more detail in London next week, if we
> agree to put it on the agenda.

> Comments?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 03 Aug 2001 15:33:55 -0700
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-01.txt
To: [email-masked]
Sender: [email-masked]

If we're serious about deprecating RLIST and RLSUB, don't we need a new 
capability to advertise support for referrals and LIST (REFERRAL) without 
implying support for RLIST and RLSUB?

		- Chris

--On Tuesday, July 24, 2001 6:31 -0400 [email-masked] wrote:
> 	Title		: IMAP4 LIST Command Extensions
> 	Author(s)	: B. Leiba
> 	Filename	: draft-ietf-imapext-list-extensions-01.txt
> 	Pages		: 8
> 	Date		: 23-Jul-01
> 	
> IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
> add extensions that require specialized lists (see [MboxRefer] for an
> example) we expand the number of list commands, as each extension
> must add its function to both LIST and LSUB.  This document describes
> extensions to the LIST command that allow these additions to be done
> in mutually compatible options to the LIST command, avoiding the
> exponential increase in specialized list commands.
>
> A URL for this Internet-Draft is:
> 
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-01.t
xt

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-01.txt
Date: Tue, 24 Jul 2001 06:31:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Notification and Alarm Protocol (SNAP)
	Author(s)	: N. Shapira
	Filename	: draft-shapira-snap-01.txt
	Pages		: 22
	Date		: 23-Jul-01
	
This memo suggests a protocol for mail status notification in 
which an email server notifies a notification gateway that changes 
have occurred in a mailbox (new message arrived, mailbox is full, 
etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shapira-snap-01.txt

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-shapira-snap-01.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-shapira-snap-01.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-shapira-snap-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-01.txt
Date: Tue, 24 Jul 2001 06:31:33 -0400
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		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-01.txt
	Pages		: 8
	Date		: 23-Jul-01
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
add extensions that require specialized lists (see [MboxRefer] for an
example) we expand the number of list commands, as each extension
must add its function to both LIST and LSUB.  This document describes
extensions to the LIST command that allow these additions to be done
in mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

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

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-list-extensions-01.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-list-extensions-01.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-list-extensions-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-01.txt
Date: Tue, 24 Jul 2001 06:31:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Notification and Alarm Protocol (SNAP)
	Author(s)	: N. Shapira
	Filename	: draft-shapira-snap-01.txt
	Pages		: 22
	Date		: 23-Jul-01
	
This memo suggests a protocol for mail status notification in 
which an email server notifies a notification gateway that changes 
have occurred in a mailbox (new message arrived, mailbox is full, 
etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shapira-snap-01.txt

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-shapira-snap-01.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-shapira-snap-01.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-shapira-snap-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-01.txt
Date: Tue, 24 Jul 2001 06:31:33 -0400
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		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-01.txt
	Pages		: 8
	Date		: 23-Jul-01
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
add extensions that require specialized lists (see [MboxRefer] for an
example) we expand the number of list commands, as each extension
must add its function to both LIST and LSUB.  This document describes
extensions to the LIST command that allow these additions to be done
in mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

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

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-list-extensions-01.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-list-extensions-01.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-list-extensions-01.txt

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

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

--OtherAccess--

--NextPart--

From: "Shapira, Noam" <[email-masked]>
To: [email-masked]
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: SNAP draft- questioned issues
Date: Fri, 3 Aug 2001 01:59:38 +0300 
Sender: [email-masked]

Hi all, 

I would like to address some of the comment passed to me on the issues of
the SNAP draft and hope to get comments / advise.

The SNAP proposal is a proposal for a protocol between the ES and
centralistic notification service. This protocol is supposed to support very
large scale system . This are the some of the basic considerations taken in
the proposal. Following are the issues that raise repeatedly:

1. The SNAP is supposed to be based on pre-configured (provisioned) set of
users. This is a basic concept that is different from a subscription model,
where the end user / agent subscribes for the notifications. As far as I see
it - a non-subscription model is less expensive and is mandatory for large
scale systems. 

2.  The SNAP is "push oriented" - rather then "pull oriented" notification
protocol. Meaning that the notification are pushed from the ES to the
notification service that is responsible for sending it to the end user /
end user agent (for example to SMS). Again, the main considerations that
came in to mind, in this case, where the issue of very large scale systems.
Pulling of thousands of subscribers on an ES - all the time is a performance
hazarded.

3. Another issue about the SNAP is that the SNAP proposal sends a great deal
of information to the notification service (email headers and other parts of
the deposit /retrieving session). This is different from an approach that
says to send only the notification state to the end user - and make sure
that the end user / end agent enter the ES (or any other notification
source) and get the information. The reason for sending a great deal of
information is that -  (1) let the end user get as much information that he
needs before entering the ES for retrieving. (2) Let the notification
service - the centralistic service hold a decision mechanism that can be
helped by the information passed in the notification request.

I would be most happy to get your comment on the questioned issues raised in
this email. It will be great if you know some references (other then the
ones sent in in the draft) that discussed these issues  before and send it
to me.

Thanks,

Noam Shapira

P.S.

You can find the draft at
http://search.ietf.org/internet-drafts/draft-shapira-snap-01.txt.

A mailing list was opened - [email-masked] for this issue - you can
register by 
either do it through Web interface:
	http://www.neystadt.org/cgi-bin/majordomo
or send mail with 'subscribe snap' to  majordomo@@lists.neystadt.org

Date: Thu, 02 Aug 2001 12:50:14 -0700
From: Chris Newman <[email-masked]>
Subject: Strawman for GROUP=ATOMICAPPEND
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Here's a strawman alternative to MULTIAPPEND called "GROUP=ATOMICAPPEND".

Advantages relative to MULTIAPPEND:
 * with LITERAL+ it achieves full streaming _and_ intermediate server 
results.
 * MULTIAPPEND is a single-purpose extension with fixed syntax.  There is no
   way to make it support more complex transactions without throwing out the
   syntax and starting over.  "GROUP=ATOMICAPPEND" is extensible.
Disadvantages relative to MULTIAPPEND:
 * more complex syntax

This would introduce three commands:
   GROUP ATOMIC
   GROUP CANCEL
   GROUP END

All commands between a "GROUP ATOMIC" and a "GROUP CANCEL", or all commands 
between a "GROUP ATOMIC" and "GROUP END" are treated as an atomic command 
group.

Within an atomic command group:
* all commands are processed in order
* multiple APPEND operations in a command group must result in those 
messages
  appearing in strict order with no messages from external delivery or 
APPEND
  tasks interleaved
* when a command within a group succeeds and returns "OK" this represents
  tentative success which is not confirmed unless an "OK" response is 
received
  to a "GROUP END" command terminating the group.
* if any command within the group fails (with a "NO" or "BAD"), all 
subsequent
  commands in the group must fail with a "NO [GROUPFAIL]" (or "BAD").
* if any command within the group fails or the group is terminated with a
  "GROUP CANCEL" command, then the server MUST revert to the state it
  would be in if the command group had not been issued.
* "* BYE" from the server implicitly cancels any atomic command group in
  progress

The capability "GROUP=ATOMICAPPEND" by itself only permits the use of the 
"APPEND" command within the atomic command group (other commands would 
result in a BAD).  Furthermore, unless the server advertises the 
"GROUP=MULTIMAILBOX" capability, the server MUST fail a second or 
subsequent APPEND command within an atomic command group that refers to a 
mailbox different from the one in the first APPEND command.

Servers MAY implement an atomic command group by exclusively locking the 
mailbox for the duration of the atomic command group, but such an 
implementation is encouraged to have a mechanism to prevent denial of 
service by a client that begins an atomic command group and ceases to 
communicate (e.g., due to network failure).

Status results:

  GROUP ATOMIC
       OK  -- beginning an atomic command group
       BAD -- command unknown or command group already in progress
  GROUP CANCEL
       OK  -- command group cancelled
       BAD -- command unknown or command group not in progress
  GROUP END
       OK  -- successfully completed entire command group
       NO  -- command group cancelled
       BAD -- command unknown or command group not in progress

Servers are not permitted to return a "NO" response to "GROUP ATOMIC" for 
any reason (a failed "GROUP ATOMIC" should succeed, but result in failure 
of all commands within the group).

Servers MAY defer UIDPLUS information to the "OK" response to "GROUP END" 
using syntax proposed in MULTIAPPEND draft.

		- Chris

Date: Thu, 02 Aug 2001 11:44:43 -0700
From: Chris Newman <[email-masked]>
Subject: Comments on WINDOW/SORT/THREAD
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Since I won't be at the London IETF I thought I'd post my comments on 
WINDOW/SORT/THREAD.

On the open issue:

>4 Open Issues
>    - Should we have WINDOW FETCH and WINDOW STORE commands to allow
>    accessing messages by output position?

I have a slight preference against adding WINDOW FETCH and WINDOW STORE for 
complexity reasons, but don't feel strongly.

I suspect a carefully constructed general purpose macro facility which 
permitted selected use of the outputs of a previous command as the input to 
a later command would suffice to save round-trips throughout the IMAP 
protocol without the need of a specific facility for this "WINDOW 
FETCH/STORE" situation.

And a quick comment on the fact that this WINDOW draft does not support 
THREAD.  While I do believe it's possible to window THREAD, I don't believe 
the complexity is worth the effort.  WINDOW with SORT by SUBJECT provides 
"good enough" threading for thin clients or very large mailboxes accessed 
over low bandwidth links.  A protocol to window hierarchical data does not 
provide sufficient benefit over WINDOW with SORT by SUBJECT to justify the 
additional complexity.

I am comfortable with advancing WINDOW/SORT/THREAD on the standards track 
at the same time, although I would prefer that the SORT draft encourage 
server vendors to also implement WINDOW in order to support scalability on 
the basis of mailbox size.  I do not support advancing SORT/THREAD by 
themselves as their bandwidth use is linked to the size of the mailbox 
(order n) and without WINDOW there is no order 1 alternative.

		- Chris

Date: Thu, 30 Aug 2001 09:14:35 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Minutes of the IMAPEXT meeting at London
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

Minutes of the IMAPEXT Working Group
51st IETF - London

Chair: Pete Resnick
Minutes taker: Lawrence Greenfield (edited by Pete Resnick)

Issues discussed:

1. Access Control List document

Chair notes that the current document editor has been unable to spend 
enough time on it and is therefore handing it off to Alexey Melnikov. 
Alexey will submit a new draft soon accounting for earlier comments 
as possible. Chair will assure that notes taken from a bar-BOF at 
Minneapolis (taken by Chris Newman, we think) will be forwarded to 
Alexey.

2. ANNOTATE document (Cyrus Daboo)

a) Should IMAP flags be mirrored in annotations?

Clearly opposed: Crispin, Nerenberg, Gahrns

- Having two ways to do things is bad with no real benefit
- Additional flags can be done in current protocol which is superior
- Will cause increased complexity (what kinds of responses, do they 
always store to old/new)

Clearly supporting: Resnick, Stebbens

- Clients would prefer to use one mechanism for all annotation-like 
data if it is available
- Easier extensibility
- Features are available that don't exist in base flags (personal v. shared)

Issue to be taken to the list

b) Should there be a suffix default capability (.priv/.shared/nothing)

- List consensus: Explicit statement necessary
- No argument in room

- If system flags are mapped on annotations (see (a)), do they get 
defaults? Room reamined depressed on the matter.

c) Unsolicited annotation responses

- Room agreeds that unsolicited responses are only cache 
invalidations, they aren't the data
- Take to list the issue of whether they should they come only after 
an annotate command has been issued

d) Should the 's' bit be used for "can store private annotations?" 
Should the 'w' bit be used for "can store shared annotations?"

- Greenfield and Daboo debate issue of more bits vs. overloading bits discussed
- Crispin and Resnick agree that since private annotations are 
private to the one storing the annotations and should be stored in 
the space of the annotator, there is no reason for the mailbox owner 
to grant permission for those annotations to exist
- Further discussion indicates that ACL is not where this belongs

3. SORT/THREAD

- IESG has given pushback that some sort of internationalized 
comparison/collation need to exist
- Some folks indicated that a global command that set up 
comaparison/collation for all other commands might not be desirable
- AD (Patrik) indicates that a reasonable default is at least need. 
Unicode technical standard #10 is a good candidate
- Crispin will take two issues to the list: a) What is the default 
comparator? b) What is the correct way of choosing comparators?

4. CONDSTORE

a) MODTIME is currently like ACAP, based off a timestamp
- move it to a 64-bit number, strictly ascending, opaque
- make sure time goes forward if it's used

b) Highest modtime for mailbox added
- Base spec doesn't allow 64-bit numbers in status, but we'll deal.

c) Do we want per message or per flag modtime?
- No opposition to per message.
- No opposition to dropping per flag.

d) Do we need to unify flags & annotations?
- No, but it creates syntax problems.

e) Should we return all items that have changed or just one?
- Alexey wants all.
- Some concerns for servers, but hey, what's a few more comparisons?

5. WINDOW

- Discussion of whether WINDOW/SORT need to move together. Chair 
indicates that extensive cross references aren't needed.

6. LIST extensions

- Greenfield wants to allow "()" at the end of a LIST response to 
allow for extensibility such as referrals or arbitrary status 
information
- Gahrns notes that referrals should be optional

7. BINARY

[Minutes taker notes something was said, but not available]

8. CHANNEL

- Issue is settling down

9. ANNOTATEMORE

So far, no objections

10. LITERAL+/MULTIAPPEND

- Crispin indicates that there are reasons for LITERAL+ that he understands
- Some discussion about whether TRANSACTIONS are necessary, or 
whether they will address some folks concerns in IESG/IAB about the 
complication of the protocol

11. LANGUAGE

Issues brought up:

- server responses
- matching (search/thread)
- collation (sort/list/thread?)
- [annotate]

Some light discussion of going from mUTF-7 to UTF-8

Meeting adjourned.

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

To: Simon Josefsson <[email-masked]>
Cc: <[email-masked]>
Subject: Re: 2086 Access Controls
From: Tim Showalter <[email-masked]>
Date: 27 Aug 2001 11:26:38 -0700
Lines: 19
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

> > Rather than reinvent the wheel, RFC2086 looked like a reasonable baseline,
> > but we have some queries: 
> > *	Which right would grant or deny the ability to rename mailboxes? 
> > *	Similarly, which right enables mailboxes to be deleted?  d seems to
> > be at message level rather than mailbox level 
> 
> I remember a draft updating RFC 2086 that said:
> 
> ;;;    c - create and delete mailbox (CREATE new sub-mailboxes in any
> ;;;        implementation-defined hierarchy, RENAME or DELETE mailbox)
> 
> But I can't find it.  Anyone?

I remember that one, too, but someone objected, and it was changed.  (I
don't like it, but I don't think it was me.)

Tim

Date: Tue, 21 Aug 2001 13:49:19 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: 2086 Access Controls
To: Simon Josefsson <[email-masked]>
cc: Mark Nevins <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 21 Aug 2001 22:44:00 +0200, Simon Josefsson wrote:
> I also remember old discussion about redesigning the ACL extension to
> be less of an AFS-clone.

That discussion is supposedly still alive, and it needs to be completed.  The
current ACL extension lacks some important functionality.

Date: Tue, 21 Aug 2001 15:49:48 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Minutes soon....
Sender: [email-masked]

Sorry for the delay. I will have the meeting minutes submitted by the 
end of this week.

(Thanks, Larry, for getting them to me quickly.)

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

To: "Mark Nevins" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: 2086 Access Controls
From: Simon Josefsson <[email-masked]>
Date: Tue, 21 Aug 2001 22:44:00 +0200
Lines: 17
Sender: [email-masked]

"Mark Nevins" <[email-masked]> writes:

> Rather than reinvent the wheel, RFC2086 looked like a reasonable baseline,
> but we have some queries: 
> *	Which right would grant or deny the ability to rename mailboxes? 
> *	Similarly, which right enables mailboxes to be deleted?  d seems to
> be at message level rather than mailbox level 

I remember a draft updating RFC 2086 that said:

;;;    c - create and delete mailbox (CREATE new sub-mailboxes in any
;;;        implementation-defined hierarchy, RENAME or DELETE mailbox)

But I can't find it.  Anyone?

I also remember old discussion about redesigning the ACL extension to
be less of an AFS-clone.

Date: Tue, 21 Aug 2001 13:31:38 -0700
From: Chris Newman <[email-masked]>
Subject: Re: 2086 Access Controls
To: Mark Nevins <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Tuesday, August 21, 2001 10:57 +0100 Mark Nevins <[email-masked]> 
wrote:
> Rather than reinvent the wheel, RFC2086 looked like a reasonable baseline,
> but we have some queries:
> *	Which right would grant or deny the ability to rename mailboxes?

You need "d" ("x" in next version) on the old name and "c" on the parent of 
the new name.

> *	Similarly, which right enables mailboxes to be deleted?  d seems to
> be at message level rather than mailbox level

Unfortunately, it's "d".  The next revision will add an "x" right for 
mailbox deletion.

> *	Is there a convention for initial rights for a child mailbox.  Would
> the parent's rights be rippled down or are would there only be rights for
> the creator?
> *	Is there a convention for ownership of a child mailbox created under
> a different users parent.  Is the owner the creating user or the parent's
> user.

The implementations I've worked with always inherit the ACL from the parent 
mailbox.

> We hoped to get Cyrus up to see an example of the rights in action but
> have hit some issues.  Where should I go for FAQs / discussion of
> implementation. I've been looking around and found references to a new
> draft for 2086, but have not been able to find it, could anyone let me
> know where I can find this.

Looks like the draft for the revised spec expired.

		- Chris

From: "Mark Nevins" <[email-masked]>
To: <[email-masked]>
Subject: 2086 Access Controls
Date: Tue, 21 Aug 2001 10:57:18 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C12A30.0BD6FC40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi

We're currently implementing access controls for an IMAP server which stores
mail in a database rather than using an operating system's file system.

Rather than reinvent the wheel, RFC2086 looked like a reasonable baseline,
but we have some queries: 
*	Which right would grant or deny the ability to rename mailboxes? 
*	Similarly, which right enables mailboxes to be deleted?  d seems to
be at message level rather than mailbox level 
*	Is there a convention for initial rights for a child mailbox.  Would
the parent's rights be rippled down or are would there only be rights for
the creator? 
*	Is there a convention for ownership of a child mailbox created under
a different users parent.  Is the owner the creating user or the parent's
user. 

We hoped to get Cyrus up to see an example of the rights in action but have
hit some issues.  Where should I go for FAQs / discussion of implementation.
I've been looking around and found references to a new draft for 2086, but
have not been able to find it, could anyone let me know where I can find
this.

Thanks

Mark Nevins
Opsol Integrators Europe Ltd.
Tel:  020 7253 3300
Fax: 020 7253 3353
mailto: [email-masked]
web: www.opsol.co.uk

------=_NextPart_000_000F_01C12A30.0BD6FC40
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_000F_01C12A30.0BD6FC40--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-07.txt
Date: Fri, 17 Aug 2001 07:03:16 -0400
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		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-thread-07.txt
	Pages		: 13
	Date		: 16-Aug-01
	
This document describes the server-based threading extension to the
IMAP4rev1 protocol.  This extension provides substantial performance
improvements for IMAP clients which offer threaded views.
A server which supports this extension indicates this with more or
more capability names consisting of 'THREAD-' followed by a supported
threading algorithm name as described in this document.  This
provides for future upwards-compatible extensions.

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

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-thread-07.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-thread-07.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-thread-07.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-07.txt
Date: Fri, 17 Aug 2001 07:03:11 -0400
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		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-07.txt
	Pages		: 10
	Date		: 16-Aug-01
	
This document describes an experimental server-based sorting
extension to the IMAP4rev1 protocol, as implemented by the University
of Washington's IMAP toolkit.  This extension provides substantial
performance improvements for IMAP clients which offer sorted views.
A server which supports this extension indicates this with a
capability name of 'SORT'.  Client implementations SHOULD accept any
capability name which begins with 'SORT' as indicating support for
the extension described in this document.  This provides for future
upwards-compatible extensions.
At the time of this document was written, the IMAP Extensions Working
Group (IETF-IMAPEXT) was considering upwards-compatible additions to
the SORT extension described in this document, tenatively called the
SORT2 extension.

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

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-sort-07.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-sort-07.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-sort-07.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 15 Aug 2001 18:05:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: IMAPV, MULTIAPPEND, SORT, and THREAD drafts submitted
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I have submitted the above-mentioned four drafts, which I couldn't prior to
the London IETF due to the cut-off.

Please note that the SORT and THREAD drafts do NOT have the new specification
for non-ASCII collation which IESG has indicated that they will require.  The
purpose of this submission is simply to have current drafts on the repository
to replace those which have expired.  There *WILL* be follow-on drafts to SORT
and THREAD with proposed new wording on collation, so please do not assume
that I'm ignoring what was agreed in London.

The same is true with the MULTIAPPEND draft.  There was a suggestion that it
needs to be clarified that MULTIAPPEND is not a new command, but rather a
logical extension to the existing APPEND command.  I like this idea, and will
reflect it in a subsequent draft.  This draft is just to replace the expired
one.

Date: Thu, 9 Aug 2001 14:08:06 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SORT and THREAD collation issues
Sender: [email-masked]

Chris Newman <[email-masked]>
> Validation is a tricky issue that resulted in over a year of debate on the 
> ACAP list.  Given that ACAP reached a rough concensus on the issue, I'd 
> prefer to stick with that (validation is done by the data consumer, not the 
> server).

In that case, distinguishing an int from a bignum isn't the server's job
either, your big-id attribute is quite properly a text/plain, and SORT
needs extra collation cleverness.

And if Cyrus is kind and considerate, he puts in a paragraph about how the
server need not verify STORE ANNOTATION data, and what the client may and
may not expect from FETCH ANNOTATION. Well-formed parentheses and nothing
else, I'd say?

--Arnt

Date: Wed, 08 Aug 2001 15:50:25 -0700
From: Chris Newman <[email-masked]>
Subject: Re: SORT and THREAD collation issues
To: Arnt Gulbrandsen <[email-masked]>
Cc: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

--On Wednesday, August 8, 2001 22:13 +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

> Chris Newman <[email-masked]>
>> We have one annotation which is the bug number associated with a
>> message.  A second annotation is the "user-supplied subject" (akin to
>> what Eudora's  POP client does).  Now suppose you want to sort first by
>> bug number, then  by subject?
>>
>> The problem is they are both string annotations, so you need different
>> collations within the same SORT command (one a numeric collation, the
>> other  an alphabetic collation).
>
> The example sounds reasonable, but what exactly does it lead to? That you
> should be able to store your numbers as numbers instead of text/plain, or
> that sort needs flexible collation?

This is why there's an IMAPEXT WG rather than individual submissions. 
There are cross-dependancies between the individual proposals that need to 
be resolved before advancement.

> Which raises the issue of what clients and servers should do about pretend
> types, and illegal values in general. What should the server do if a
> client writes the five-byte string "crash" into the value of
> /message/flags/forwarded, or another semi-boolean attribute? What should a
> client do if it sees that string there?
>
> It's late and I'm tired, but I also don't see what happens if I try to set
> the content-type of an annotation to e.g. NIL.

Validation is a tricky issue that resulted in over a year of debate on the 
ACAP list.  Given that ACAP reached a rough concensus on the issue, I'd 
prefer to stick with that (validation is done by the data consumer, not the 
server).

		- Chris

Date: Wed, 8 Aug 2001 22:13:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: SORT and THREAD collation issues
Sender: [email-masked]

Chris Newman <[email-masked]>
> We have one annotation which is the bug number associated with a message. 
> A second annotation is the "user-supplied subject" (akin to what Eudora's 
> POP client does).  Now suppose you want to sort first by bug number, then 
> by subject?
> 
> The problem is they are both string annotations, so you need different 
> collations within the same SORT command (one a numeric collation, the other 
> an alphabetic collation).

The example sounds reasonable, but what exactly does it lead to? That you
should be able to store your numbers as numbers instead of text/plain, or
that sort needs flexible collation?

Which raises the issue of what clients and servers should do about pretend
types, and illegal values in general. What should the server do if a
client writes the five-byte string "crash" into the value of
/message/flags/forwarded, or another semi-boolean attribute? What should a
client do if it sees that string there?

It's late and I'm tired, but I also don't see what happens if I try to set
the content-type of an annotation to e.g. NIL.

--Arnt

Date: Wed, 08 Aug 2001 16:01:47 -0400
From: Tony Hansen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: SORT and THREAD collation issues
Sender: [email-masked]

The example I think of is being able to do some sorts case dependently
and others case independently. I could see setting a default globally,
but you still need to be able to override that default on occassion.

	Tony

Chris Newman wrote:
> 
> --On Wednesday, August 8, 2001 7:00 -0700 Mike Gahrns
> <[email-masked]> wrote:
> > Chris Newman writes:
> >> Having a collation function that is set
> >> once by some separate command and always used by SORT/THREAD doesn't
> >> seem sufficiently flexible.
> > *** Wouldn't the 99% case be that a user would configure a client once,
> > and then use these settings for the remainder of their IMAP sessions?
> > Admittedly there could be some scenarios where a user might be changing
> > these on the fly between various different SORTS, but it seems that this
> > scenario would be much less common.
> > Setting the Collation function initially at the start of a session via
> > something like the LANGUAGE command, nicely removes some complexity and
> > overhead from SORT/THREAD by not having to repeatedly send the same
> > information over and over again on each SORT/THREAD command.
> > Scenarios that need to change this information, could still do so, by
> > issuing a new LANG command before the next SORT/THREAD command.
> 
> Ok, let me give you a specific example:
> 
> We have one annotation which is the bug number associated with a message.
> A second annotation is the "user-supplied subject" (akin to what Eudora's
> POP client does).  Now suppose you want to sort first by bug number, then
> by subject?
> 
> The problem is they are both string annotations, so you need different
> collations within the same SORT command (one a numeric collation, the other
> an alphabetic collation).
> 
> I agree that changing languages/locales within a session is highly unlikely
> and probably doesn't need to be supported.  But I think changing collation
> functions within a SORT command does need to be supported.
> 
>                 - Chris

Date: Wed, 08 Aug 2001 12:19:28 -0700
From: Chris Newman <[email-masked]>
Subject: RE: SORT and THREAD collation issues
To: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

--On Wednesday, August 8, 2001 7:00 -0700 Mike Gahrns 
<[email-masked]> wrote:
> Chris Newman writes:
>> Having a collation function that is set
>> once by some separate command and always used by SORT/THREAD doesn't
>> seem sufficiently flexible.
> *** Wouldn't the 99% case be that a user would configure a client once,
> and then use these settings for the remainder of their IMAP sessions?
> Admittedly there could be some scenarios where a user might be changing
> these on the fly between various different SORTS, but it seems that this
> scenario would be much less common.
> Setting the Collation function initially at the start of a session via
> something like the LANGUAGE command, nicely removes some complexity and
> overhead from SORT/THREAD by not having to repeatedly send the same
> information over and over again on each SORT/THREAD command.
> Scenarios that need to change this information, could still do so, by
> issuing a new LANG command before the next SORT/THREAD command.

Ok, let me give you a specific example:

We have one annotation which is the bug number associated with a message. 
A second annotation is the "user-supplied subject" (akin to what Eudora's 
POP client does).  Now suppose you want to sort first by bug number, then 
by subject?

The problem is they are both string annotations, so you need different 
collations within the same SORT command (one a numeric collation, the other 
an alphabetic collation).

I agree that changing languages/locales within a session is highly unlikely 
and probably doesn't need to be supported.  But I think changing collation 
functions within a SORT command does need to be supported.

		- Chris

content-class: urn:content-classes:message
Subject: RE: SORT and THREAD collation issues
Date: Wed, 8 Aug 2001 07:00:59 -0700
From: "Mike Gahrns" <[email-masked]>
To: "Chris Newman" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

Chris Newman writes:
> Having a collation function that is set 
> once by some separate command and always used by SORT/THREAD doesn't
seem 
> sufficiently flexible.
*** Wouldn't the 99% case be that a user would configure a client once,
and then use these settings for the remainder of their IMAP sessions?
Admittedly there could be some scenarios where a user might be changing
these on the fly between various different SORTS, but it seems that this
scenario would be much less common.
Setting the Collation function initially at the start of a session via
something like the LANGUAGE command, nicely removes some complexity and
overhead from SORT/THREAD by not having to repeatedly send the same
information over and over again on each SORT/THREAD command.
Scenarios that need to change this information, could still do so, by
issuing a new LANG command before the next SORT/THREAD command.

Date: Mon, 06 Aug 2001 15:27:11 -0700
From: Chris Newman <[email-masked]>
Subject: Re: SORT and THREAD collation issues
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

--On Monday, August 6, 2001 21:16 +0100 Mark Crispin 
<[email-masked]> wrote:
> The next question has to do with the specification of a non-default
> comparison/collation mechanism.  SORT/THREAD anticipate that an external
> mechanism, such as a LANGUAGE extension, would take on the responsibility
> of setting this; meaning that an implementation of both extensions would
> be required to implement the ability to set localized comparison and
> collations.  We assume that this is the desired end state in any case.

Collation is a combination of many factors, including language, locale and 
the type of data one is collating.  Having a collation function that is set 
once by some separate command and always used by SORT/THREAD doesn't seem 
sufficiently flexible.

I suspect we'll need to support more than one collation in a given 
SORT/THREAD command once annotations are added to the mix (since 
annotations make no distinction between numeric and text data).  So my 
inclination would be to use text strings to describe collation functions 
(as in RFC 2244), and use a "COLLATE <tag>" in-line SORT/THREAD criteria 
that sets collation algorithm for the applicable criteria in the remainder 
of the SORT/THREAD program.

I don't really care what document(s) this mechanism ends up in.

		- Chris

Date: Mon, 6 Aug 2001 21:16:46 +0100 (GMT Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SORT and THREAD collation issues
Organization: Networks & Distributed Computing
Sender: [email-masked]

IESG brought up in London the issue of how localized SEARCH, SORT, and
THREAD comparison and collation are to be specified.  Furthermore, the
current non-specification (implying that a UTF-8 binary compare is
alright) of the default comparison/collation will prevent advancement of
SORT and possibly also THREAD.

It has been proposed that adoption of Unicode Technical Standard 10
(TR-10) as the default will address the issue of a satisfactory default
comparison/collation.  The tenative concensus was that, barring some
unexpected showstopper, we should change the wording in SORT/THREAD to
adopt TR-10 as the default.

Is there any known reason why we should not do this?  Are there issues
with implementing TR-10 that we may be unaware of?

The next question has to do with the specification of a non-default
comparison/collation mechanism.  SORT/THREAD anticipate that an external
mechanism, such as a LANGUAGE extension, would take on the responsibility
of setting this; meaning that an implementation of both extensions would
be required to implement the ability to set localized comparison and
collations.  We assume that this is the desired end state in any case.

An alternative has been proposed that SORT, THREAD, and each other
extension dealing with this take on the responsibility itself; e.g. that
there should be an additional argument to specify this.  I am not in favor
of this alternative, but I feel that the exact mechanism to specify the
non-default comparison/collation is "syntactic sugar" -- it really doesn't
matter.  We ought to be able to move forward with a tenative understanding
that we eventually need to pick our favorite sugar...

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Sat, 04 Aug 2001 23:20:47 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Proposal for ANNOTATEMORE extension
Sender: [email-masked]

Cyrus, your proposal sounds like a good idea. IMHO, we should discuss it if we
have enough time.

Cyrus Daboo wrote:

> Hi folks,
> Since we're getting close to completing ANNOTATE (some issues are still
> unresolved on the list), I'd like to propose an extension to add
> annotations for mailboxes and the server. I'm calling this ANNOTATEMORE.
>
> The idea with this is to allow annotations to be attached to each mailbox,
> and for a set of 'global' annotations associated with the server itself.
> Examples of use include a 'message of the day' server annotation, an
> annotation on mailboxes indicating the default sort order to use when
> displaying the mailbox to the user etc.

Do we want private/shared annotations (for mailbox - probably yes, server -
likely not)

> My proposal is to use the same entry/attribute/value data model that
> ANNOTATE uses. In this case we would have /server and /mailbox/<mailbox
> name> top level entries. We would have to have two new commands for reading
> and writing annotations, and a new untagged response for returning the
> annotation data, e.g.:
>
> a SETANNOTATION ("/mailbox/INBOX/sort" ("value" "SUBJECT"))
> a OK SETANNOTATION complete
>
> a GETANNOTATION ("/server/motd" "value"))
> * ANNOTATION ("/server/motd" ("value" "Server maintenance at 10 pm"))
> a OK GETANNOTATION complete

I believe a lot of servers will choose not to implement SETANNOTATION (i.e. it
will always return NO), but this is probably reasonable to expect.

> I believe this is a logical extension to the message annotation capability
> that ANNOTATE introduces, and there is already one server that has its own
> equivalent of the server annotation mechanism, so it would be good to
> standardise this.
>
> I'm prepared to describe this in more detail in London next week, if we
> agree to put it on the agenda.

> Comments?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 03 Aug 2001 15:33:55 -0700
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-01.txt
To: [email-masked]
Sender: [email-masked]

If we're serious about deprecating RLIST and RLSUB, don't we need a new 
capability to advertise support for referrals and LIST (REFERRAL) without 
implying support for RLIST and RLSUB?

		- Chris

--On Tuesday, July 24, 2001 6:31 -0400 [email-masked] wrote:
> 	Title		: IMAP4 LIST Command Extensions
> 	Author(s)	: B. Leiba
> 	Filename	: draft-ietf-imapext-list-extensions-01.txt
> 	Pages		: 8
> 	Date		: 23-Jul-01
> 	
> IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
> add extensions that require specialized lists (see [MboxRefer] for an
> example) we expand the number of list commands, as each extension
> must add its function to both LIST and LSUB.  This document describes
> extensions to the LIST command that allow these additions to be done
> in mutually compatible options to the LIST command, avoiding the
> exponential increase in specialized list commands.
>
> A URL for this Internet-Draft is:
> 
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-01.t
xt

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-01.txt
Date: Tue, 24 Jul 2001 06:31:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Notification and Alarm Protocol (SNAP)
	Author(s)	: N. Shapira
	Filename	: draft-shapira-snap-01.txt
	Pages		: 22
	Date		: 23-Jul-01
	
This memo suggests a protocol for mail status notification in 
which an email server notifies a notification gateway that changes 
have occurred in a mailbox (new message arrived, mailbox is full, 
etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shapira-snap-01.txt

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-shapira-snap-01.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-shapira-snap-01.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-shapira-snap-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-01.txt
Date: Tue, 24 Jul 2001 06:31:33 -0400
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		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-01.txt
	Pages		: 8
	Date		: 23-Jul-01
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
add extensions that require specialized lists (see [MboxRefer] for an
example) we expand the number of list commands, as each extension
must add its function to both LIST and LSUB.  This document describes
extensions to the LIST command that allow these additions to be done
in mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

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

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-list-extensions-01.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-list-extensions-01.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-list-extensions-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-01.txt
Date: Tue, 24 Jul 2001 06:31:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Notification and Alarm Protocol (SNAP)
	Author(s)	: N. Shapira
	Filename	: draft-shapira-snap-01.txt
	Pages		: 22
	Date		: 23-Jul-01
	
This memo suggests a protocol for mail status notification in 
which an email server notifies a notification gateway that changes 
have occurred in a mailbox (new message arrived, mailbox is full, 
etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shapira-snap-01.txt

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-shapira-snap-01.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-shapira-snap-01.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-shapira-snap-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-01.txt
Date: Tue, 24 Jul 2001 06:31:33 -0400
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		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-01.txt
	Pages		: 8
	Date		: 23-Jul-01
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
add extensions that require specialized lists (see [MboxRefer] for an
example) we expand the number of list commands, as each extension
must add its function to both LIST and LSUB.  This document describes
extensions to the LIST command that allow these additions to be done
in mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

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

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-list-extensions-01.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-list-extensions-01.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-list-extensions-01.txt

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

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

--OtherAccess--

--NextPart--

From: "Shapira, Noam" <[email-masked]>
To: [email-masked]
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: SNAP draft- questioned issues
Date: Fri, 3 Aug 2001 01:59:38 +0300 
Sender: [email-masked]

Hi all, 

I would like to address some of the comment passed to me on the issues of
the SNAP draft and hope to get comments / advise.

The SNAP proposal is a proposal for a protocol between the ES and
centralistic notification service. This protocol is supposed to support very
large scale system . This are the some of the basic considerations taken in
the proposal. Following are the issues that raise repeatedly:

1. The SNAP is supposed to be based on pre-configured (provisioned) set of
users. This is a basic concept that is different from a subscription model,
where the end user / agent subscribes for the notifications. As far as I see
it - a non-subscription model is less expensive and is mandatory for large
scale systems. 

2.  The SNAP is "push oriented" - rather then "pull oriented" notification
protocol. Meaning that the notification are pushed from the ES to the
notification service that is responsible for sending it to the end user /
end user agent (for example to SMS). Again, the main considerations that
came in to mind, in this case, where the issue of very large scale systems.
Pulling of thousands of subscribers on an ES - all the time is a performance
hazarded.

3. Another issue about the SNAP is that the SNAP proposal sends a great deal
of information to the notification service (email headers and other parts of
the deposit /retrieving session). This is different from an approach that
says to send only the notification state to the end user - and make sure
that the end user / end agent enter the ES (or any other notification
source) and get the information. The reason for sending a great deal of
information is that -  (1) let the end user get as much information that he
needs before entering the ES for retrieving. (2) Let the notification
service - the centralistic service hold a decision mechanism that can be
helped by the information passed in the notification request.

I would be most happy to get your comment on the questioned issues raised in
this email. It will be great if you know some references (other then the
ones sent in in the draft) that discussed these issues  before and send it
to me.

Thanks,

Noam Shapira

P.S.

You can find the draft at
http://search.ietf.org/internet-drafts/draft-shapira-snap-01.txt.

A mailing list was opened - [email-masked] for this issue - you can
register by 
either do it through Web interface:
	http://www.neystadt.org/cgi-bin/majordomo
or send mail with 'subscribe snap' to  majordomo@@lists.neystadt.org

Date: Thu, 02 Aug 2001 12:50:14 -0700
From: Chris Newman <[email-masked]>
Subject: Strawman for GROUP=ATOMICAPPEND
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Here's a strawman alternative to MULTIAPPEND called "GROUP=ATOMICAPPEND".

Advantages relative to MULTIAPPEND:
 * with LITERAL+ it achieves full streaming _and_ intermediate server 
results.
 * MULTIAPPEND is a single-purpose extension with fixed syntax.  There is no
   way to make it support more complex transactions without throwing out the
   syntax and starting over.  "GROUP=ATOMICAPPEND" is extensible.
Disadvantages relative to MULTIAPPEND:
 * more complex syntax

This would introduce three commands:
   GROUP ATOMIC
   GROUP CANCEL
   GROUP END

All commands between a "GROUP ATOMIC" and a "GROUP CANCEL", or all commands 
between a "GROUP ATOMIC" and "GROUP END" are treated as an atomic command 
group.

Within an atomic command group:
* all commands are processed in order
* multiple APPEND operations in a command group must result in those 
messages
  appearing in strict order with no messages from external delivery or 
APPEND
  tasks interleaved
* when a command within a group succeeds and returns "OK" this represents
  tentative success which is not confirmed unless an "OK" response is 
received
  to a "GROUP END" command terminating the group.
* if any command within the group fails (with a "NO" or "BAD"), all 
subsequent
  commands in the group must fail with a "NO [GROUPFAIL]" (or "BAD").
* if any command within the group fails or the group is terminated with a
  "GROUP CANCEL" command, then the server MUST revert to the state it
  would be in if the command group had not been issued.
* "* BYE" from the server implicitly cancels any atomic command group in
  progress

The capability "GROUP=ATOMICAPPEND" by itself only permits the use of the 
"APPEND" command within the atomic command group (other commands would 
result in a BAD).  Furthermore, unless the server advertises the 
"GROUP=MULTIMAILBOX" capability, the server MUST fail a second or 
subsequent APPEND command within an atomic command group that refers to a 
mailbox different from the one in the first APPEND command.

Servers MAY implement an atomic command group by exclusively locking the 
mailbox for the duration of the atomic command group, but such an 
implementation is encouraged to have a mechanism to prevent denial of 
service by a client that begins an atomic command group and ceases to 
communicate (e.g., due to network failure).

Status results:

  GROUP ATOMIC
       OK  -- beginning an atomic command group
       BAD -- command unknown or command group already in progress
  GROUP CANCEL
       OK  -- command group cancelled
       BAD -- command unknown or command group not in progress
  GROUP END
       OK  -- successfully completed entire command group
       NO  -- command group cancelled
       BAD -- command unknown or command group not in progress

Servers are not permitted to return a "NO" response to "GROUP ATOMIC" for 
any reason (a failed "GROUP ATOMIC" should succeed, but result in failure 
of all commands within the group).

Servers MAY defer UIDPLUS information to the "OK" response to "GROUP END" 
using syntax proposed in MULTIAPPEND draft.

		- Chris

Date: Thu, 02 Aug 2001 11:44:43 -0700
From: Chris Newman <[email-masked]>
Subject: Comments on WINDOW/SORT/THREAD
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Since I won't be at the London IETF I thought I'd post my comments on 
WINDOW/SORT/THREAD.

On the open issue:

>4 Open Issues
>    - Should we have WINDOW FETCH and WINDOW STORE commands to allow
>    accessing messages by output position?

I have a slight preference against adding WINDOW FETCH and WINDOW STORE for 
complexity reasons, but don't feel strongly.

I suspect a carefully constructed general purpose macro facility which 
permitted selected use of the outputs of a previous command as the input to 
a later command would suffice to save round-trips throughout the IMAP 
protocol without the need of a specific facility for this "WINDOW 
FETCH/STORE" situation.

And a quick comment on the fact that this WINDOW draft does not support 
THREAD.  While I do believe it's possible to window THREAD, I don't believe 
the complexity is worth the effort.  WINDOW with SORT by SUBJECT provides 
"good enough" threading for thin clients or very large mailboxes accessed 
over low bandwidth links.  A protocol to window hierarchical data does not 
provide sufficient benefit over WINDOW with SORT by SUBJECT to justify the 
additional complexity.

I am comfortable with advancing WINDOW/SORT/THREAD on the standards track 
at the same time, although I would prefer that the SORT draft encourage 
server vendors to also implement WINDOW in order to support scalability on 
the basis of mailbox size.  I do not support advancing SORT/THREAD by 
themselves as their bandwidth use is linked to the size of the mailbox 
(order n) and without WINDOW there is no order 1 alternative.

		- Chris