Subject: draft-szego-wcor-imap-00.txt
From: Mark Crispin <[email-masked]>
To: [email-masked], IMAP Extensions WG <[email-masked]>
Date: Fri, 31 Mar 2006 15:53:15 -0800 (Pacific Standard Time)
List-Id: <ietf-imapext.imc.org>

I just became aware of this document.  I don't think that IMAP is the 
right place for this functionality.

-- Mark --

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

Date: Fri, 31 Mar 2006 13:10:23 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: CONDSTORE
Sender: [email-masked]

Alexey Melnikov wrote:
> Ken Murchison wrote:

>> And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
>> doesn't support CONDSTORE?  I assume that the server should just 
>> ignore the HIGHESTMODSEQ status item, in the same way that it will 
>> have to ignore the SELECT/EXAMINE CONDSTORE parameter.
> 
> Right.

Hmm, the ABNF for the STATUS response requires at least one status-att. 
  So what should we do for:

a STATUS mailbox (HIGHESTMODSEQ)

Return a HIGHESTMODSEQ of zero, or don't return * STATUS for the 
mailbox?  I'm assuming the latter.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Fri, 31 Mar 2006 13:05:06 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Dave Cridland <[email-masked]>
CC: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: CONDSTORE
Sender: [email-masked]

Dave Cridland wrote:
> On Fri Mar 31 16:15:34 2006, Ken Murchison wrote:
>>
>> Alexey Melnikov wrote:
>>> Ken Murchison wrote:
>>>
>>>> I'm in the process of finalizing my CONDSTORE implementation, and 
>>>> I'm wondering what is the correct behavior when a client sends a 
>>>> CONDSTORE-specific command when the server has already responded to 
>>>> SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
>>>> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a 
>>>> syntax error (BAD), an operational error (NO), or ignored (OK)?
>>>
>>> A client that doesn't pay attention to NOMODSEQ is broken. So BAD 
>>> would be appropriate.
>>
>> BAD would be easier for me to implement, but I'm fine with parse but 
>> ignore.
>>
>>
> BAD would be better for clients, too.

OK, I'll go along with the client implementor.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Fri, 31 Mar 2006 18:25:07 +0100
Subject: Re: CONDSTORE
From: Dave Cridland <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

On Fri Mar 31 16:15:34 2006, Ken Murchison wrote:
> 
> Alexey Melnikov wrote:
>> Ken Murchison wrote:
>> 
>>> I'm in the process of finalizing my CONDSTORE implementation, and 
>>> I'm wondering what is the correct behavior when a client sends a 
>>> CONDSTORE-specific command when the server has already responded 
>>> to SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
>>> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a 
>>> syntax error (BAD), an operational error (NO), or ignored (OK)?
>> 
>> A client that doesn't pay attention to NOMODSEQ is broken. So BAD 
>> would be appropriate.
> 
> BAD would be easier for me to implement, but I'm fine with parse 
> but ignore.
> 
> 
BAD would be better for clients, too.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Fri, 31 Mar 2006 10:15:34 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: CONDSTORE
Sender: [email-masked]

Alexey Melnikov wrote:
> Ken Murchison wrote:
> 
>> I'm in the process of finalizing my CONDSTORE implementation, and I'm 
>> wondering what is the correct behavior when a client sends a 
>> CONDSTORE-specific command when the server has already responded to 
>> SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
>> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a 
>> syntax error (BAD), an operational error (NO), or ignored (OK)?
> 
> A client that doesn't pay attention to NOMODSEQ is broken. So BAD would 
> be appropriate.

BAD would be easier for me to implement, but I'm fine with parse but ignore.

Do you think that this should be spelled out in the I-D?

> However, in order to simplify implementations, how about allowing the 
> following behavior:
> STORE UNCHANGEDSINCE - always fails with NO.
> FETCH CHANGEDSINCE - assume all messages have changed (i.e. CHANGEDSINCE 
> is ignored)
> FETCH/SEARCH/SORT MODSEQ - ignore the MODSEQ parameter
> 
>> And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
>> doesn't support CONDSTORE?  I assume that the server should just 
>> ignore the HIGHESTMODSEQ status item, in the same way that it will 
>> have to ignore the SELECT/EXAMINE CONDSTORE parameter.
> 
> Right.
> 
> 

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Fri, 31 Mar 2006 06:34:38 -0800
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked]
Subject: Re: CONDSTORE
Sender: [email-masked]

Ken Murchison wrote:

> I'm in the process of finalizing my CONDSTORE implementation, and I'm 
> wondering what is the correct behavior when a client sends a 
> CONDSTORE-specific command when the server has already responded to 
> SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a 
> syntax error (BAD), an operational error (NO), or ignored (OK)?

A client that doesn't pay attention to NOMODSEQ is broken. So BAD would 
be appropriate.

However, in order to simplify implementations, how about allowing the 
following behavior:
 STORE UNCHANGEDSINCE - always fails with NO.
 FETCH CHANGEDSINCE - assume all messages have changed (i.e. 
CHANGEDSINCE is ignored)
 FETCH/SEARCH/SORT MODSEQ - ignore the MODSEQ parameter

> And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
> doesn't support CONDSTORE?  I assume that the server should just 
> ignore the HIGHESTMODSEQ status item, in the same way that it will 
> have to ignore the SELECT/EXAMINE CONDSTORE parameter.

Right.

Date: Thu, 30 Mar 2006 19:44:29 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-daboo-imap-annotatemore-09.txt  (fwd)
Sender: [email-masked]

--==========31CD27FFB5F3F22B1453==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
FYI new version of ANNOTATEMORE (now known as METADATA) extension is out. 
Major changes are:

1) Changed to new capability/command names using METADATA (NB I chose not 
to change the draft name to maintain consistency in the data tracker).
2) Now uses LISTEXT for retrieval of mailbox annotations.

Please review...

------------ Forwarded Message -----------
Date: March 30, 2006 6:50:01 PM -0500
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-daboo-imap-annotatemore-09.txt

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

	Title		: IMAP METADATA Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-09.txt
	Pages		: 32
	Date		: 2006-3-30

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

--==========31CD27FFB5F3F22B1453==========
Content-Type: message/rfc822;
 name="I-D ACTION:draft-daboo-imap-annotatemore-09.txt "

To: [email-masked]
Cc: 
From: [email-masked]
Date: Thu, 30 Mar 2006 18:50:01 -0500
Subject: I-D ACTION:draft-daboo-imap-annotatemore-09.txt 
Reply-To: [email-masked]

--NextPart

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

	Title		: IMAP METADATA Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-09.txt
	Pages		: 32
	Date		: 2006-3-30
	
The METADATA extension to the Internet Message Access Protocol
permits clients and servers to maintain "annotations" or "meta data"
on IMAP servers.  It is possible to have annotations on a per-mailbox
basis or on the server as a whole.  For example, this would allow
comments about the purpose of a particular mailbox to be "attached"
to that mailbox, or a "message of the day" containing server status
information to be made available to anyone logging in to the server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-daboo-imap-annotatemore-09.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-daboo-imap-annotatemore-09.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-daboo-imap-annotatemore-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-daboo-imap-annotatemore-09.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--==========31CD27FFB5F3F22B1453==========--

Date: Wed, 29 Mar 2006 17:48:35 -0800
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: LISTEXT + METADATA issues
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On March 23, 2006 11:08:20 AM -0800 Alexey Melnikov 
> <[email-masked]> wrote:
>
>>> 3) The new SELECTION option effectively requires comparisons - i.e. we
>>> need to take comparators into account. I'm not sure whether a
>>> statement to that effect belongs in the METADATA extension or whether
>>> LISTEXT itself should have some general statement about how selection
>>> options that use text comparisons should interact with i18n draft. I
>>> think a general statement in LISTEXT would be better...
>>
>> Can you suggest some text?
>
>    Internationalization Considerations
>
>    The LIST command selection option types defined in this specification
>    involve simple tests of mailbox properties. However, future extensions
>    to LISTEXT may define SELECTION options that do more sophisticated
>    tests. In the case of a test that requires matching text, in the
>    presence of the COMPARATOR [I18N] extension, the active comparator 
> MUST
>    be used to do comparisons. Such LISTEXT extensions MUST indicate in
>    their specification the interaction with the COMPARATOR [I18N]
>    extension.
>
> + add informative reference to draft-ietf-imapext-i18n-06.txt

Thanks!

> One more question: does it make sense to use RECURSIVEMATCH when 
> matching annotations?

This can be quite difficult to implement in servers, especially if the 
client can specify * in annotation names.

Can you think of a use case for this?

Date: Wed, 29 Mar 2006 20:11:06 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-15.txt  (fwd)
Sender: [email-masked]

--==========EFD712C2E7BF93890F62==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
This revision includes all the items discussed at the meeting last week. It 
should be ready for submission to IESG as experimental status as per 
discussion.

------------ Forwarded Message -----------
Date: March 29, 2006 6:50:02 PM -0500
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-15.txt

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

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-15.txt
	Pages		: 36
	Date		: 2006-3-29

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

--==========EFD712C2E7BF93890F62==========
Content-Type: message/rfc822;
 name="I-D ACTION:draft-ietf-imapext-annotate-15.txt "

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-15.txt 
Date: Wed, 29 Mar 2006 18:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-15.txt
	Pages		: 36
	Date		: 2006-3-29
	
The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "meta data" for messages, or
   individual message parts, stored in a mailbox on the server.  For
   example, this can be used to attach comments and other useful
   information to a message.  It is also possible to attach annotations
   to specific parts of a message, so that, for example, they could be
   marked as seen or important, or a comment added.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

--==========EFD712C2E7BF93890F62==========--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-15.txt 
Date: Wed, 29 Mar 2006 18:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-15.txt
	Pages		: 36
	Date		: 2006-3-29
	
The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "meta data" for messages, or
   individual message parts, stored in a mailbox on the server.  For
   example, this can be used to attach comments and other useful
   information to a message.  It is also possible to attach annotations
   to specific parts of a message, so that, for example, they could be
   marked as seen or important, or a comment added.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 29 Mar 2006 22:54:43 +0100
Subject: Re: More on LISTEXT (fwd)
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Mar 29 22:22:05 2006, Arnt Gulbrandsen wrote:
> (I dislike 3 mostly because I think "do that" is a better sort of 
> command than "don't do that".)

I sympathise, but option 2 is not "do that" either, it's an explicit 
revocation of the implicit "don't do that" caused by the explicit 
(but not implicit) use of another return option. The default is still 
"do that".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 29 Mar 2006 23:22:05 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: More on LISTEXT (fwd)
Sender: [email-masked]

Cyrus Daboo writes:
> Solutions:
...

I don't have a strong opinion. 2 is best, 3 worst, but I'll listen to 
Dave's arguments wrt. where to to specify.

(I dislike 3 mostly because I think "do that" is a better sort of 
command than "don't do that".)

Arnt

Date: Wed, 29 Mar 2006 16:02:52 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Dave Cridland <[email-masked]>, Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: CONDSTORE
Sender: [email-masked]

Since people seem to be in a talkative mood today, can I get your 
thoughts on this issue?  The draft doesn't discuss it at all.

Ken Murchison wrote:
> 
> I'm in the process of finalizing my CONDSTORE implementation, and I'm 
> wondering what is the correct behavior when a client sends a 
> CONDSTORE-specific command when the server has already responded to 
> SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a syntax 
> error (BAD), an operational error (NO), or ignored (OK)?
> 
> And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
> doesn't support CONDSTORE?  I assume that the server should just ignore 
> the HIGHESTMODSEQ status item, in the same way that it will have to 
> ignore the SELECT/EXAMINE CONDSTORE parameter.
> 

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Wed, 29 Mar 2006 21:58:25 +0100
Subject: Re: More on LISTEXT (fwd)
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Mar 29 21:47:04 2006, Cyrus Daboo wrote:
>>> 2) Add a new STDFLAGs return option such that if a RETURN is
>>> specified,
>>> then standard flags are only returned if STDFLAG is present as one
>>> of the
>>> return options. If there is no return option, then the normal
>>> behaviour
>>> occurs.
>>> 
>>> 
>> This involves changing the behaviour of LIST-EXTENDED quite 
>> heavily - in
>> particular, you need to differentiate between implicit and explicit
>> RETURN options. I don't like this.
> 
> But you have to do that already - std. flags are implicit with any 
> RETURN as are others like \Remote.
> 
> 
No... \Subscribed is only given by the SUBSCRIBED return option, 
which in turn is implied by the SUBSCRIBED selection option. You're 
saying that LIST (SUBSCRIBED) "" * RETURN (SUBSCRIBED) would behave 
differently to LIST (SUBSCRIBED) "" *.

Implementation-wise, either (2) or (3) is just as easy, but 
specification-wise, I think (3) is much easier to explain.

>>> 3) Add a new NOSTDFLAGS return option such that if specified in
>>> RETURN, the
>>> standard flags are not returned.
>> 
>> Although this is quite ugly, I think this is cleaner to implement, 
>> and
>> has the additional advantage that you can specify it either in 
>> METADATA
>> (or SONOFANNOTATEMORE, or ANNOTATEMORE2THEREVENGE, or...) or as a 
>> small
>> standalone extension.
> 
> Why not in base LISTEXT? Other extensions to LISTEXT might well use 
> it (e.g. an extension that replaces STATUS behaviour by adding 
> SEEN, RECENT etc selection/return options).

Because it's a significant technical change, and I suspect it would 
force a WGLC again.

I agree it might be useful outside of METADATA, though.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 29 Mar 2006 15:47:04 -0500
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: More on LISTEXT (fwd)
Sender: [email-masked]

Hi Dave,

--On March 29, 2006 9:36:44 PM +0100 Dave Cridland <[email-masked]> 
wrote:

>> 2) Add a new STDFLAGs return option such that if a RETURN is
>> specified,
>> then standard flags are only returned if STDFLAG is present as one
>> of the
>> return options. If there is no return option, then the normal
>> behaviour
>> occurs.
>>
>>
> This involves changing the behaviour of LIST-EXTENDED quite heavily - in
> particular, you need to differentiate between implicit and explicit
> RETURN options. I don't like this.

But you have to do that already - std. flags are implicit with any RETURN 
as are others like \Remote.

>> 3) Add a new NOSTDFLAGS return option such that if specified in
>> RETURN, the
>> standard flags are not returned.
>
> Although this is quite ugly, I think this is cleaner to implement, and
> has the additional advantage that you can specify it either in METADATA
> (or SONOFANNOTATEMORE, or ANNOTATEMORE2THEREVENGE, or...) or as a small
> standalone extension.

Why not in base LISTEXT? Other extensions to LISTEXT might well use it 
(e.g. an extension that replaces STATUS behaviour by adding SEEN, RECENT 
etc selection/return options).

-- 
Cyrus Daboo

Date: Wed, 29 Mar 2006 21:36:44 +0100
Subject: Re: More on LISTEXT (fwd)
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Mar 29 21:23:33 2006, Cyrus Daboo wrote:
> Hi folks,
> I'd like to get some sort of feedback on the issue below as I want 
> to submit a new annotatemore draft with LISTEXT dependency soon.
> 
> 
Sorry, I'd meant to reply to this sooner.

> 1) Leave things as they are - getting annotations will result in 
> getting
> the standard flags all over again.
> 
> 
I always want this behaviour.

> 2) Add a new STDFLAGs return option such that if a RETURN is 
> specified,
> then standard flags are only returned if STDFLAG is present as one 
> of the
> return options. If there is no return option, then the normal 
> behaviour
> occurs.
> 
> 
This involves changing the behaviour of LIST-EXTENDED quite heavily - 
in particular, you need to differentiate between implicit and 
explicit RETURN options. I don't like this.

> 3) Add a new NOSTDFLAGS return option such that if specified in 
> RETURN, the
> standard flags are not returned.

Although this is quite ugly, I think this is cleaner to implement, 
and has the additional advantage that you can specify it either in 
METADATA (or SONOFANNOTATEMORE, or ANNOTATEMORE2THEREVENGE, or...) or 
as a small standalone extension.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 29 Mar 2006 15:34:32 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: More on LISTEXT
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> Hi,
> I believe this was discussed before: currently with LISTEXT there is no 
> way for the client to tell the server not to return the 'standard' IMAP 
> mailbox flags such as \NoInferiors, \Marked etc. However, when listing 
> annotations, it would be nice to be able to list those without getting 
> the standard flag data again.
> 
> Solutions:
> 
> 1) Leave things as they are - getting annotations will result in getting 
> the standard flags all over again.
> 
> 2) Add a new STDFLAGs return option such that if a RETURN is specified, 
> then standard flags are only returned if STDFLAG is present as one of 
> the return options. If there is no return option, then the normal 
> behaviour occurs.
> 
> 3) Add a new NOSTDFLAGS return option such that if specified in RETURN, 
> the standard flags are not returned.
> 
> Personally I prefer (2), but could live with (3). I do not find the 
> current situation acceptable though.

I'm in favor of (2) as well.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Cc: [email-masked]
From: Timo Sirainen <[email-masked]>
Subject: Re: More on LISTEXT (fwd)
Date: Wed, 29 Mar 2006 23:34:30 +0300
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-10-1029484
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Mar 29, 2006, at 11:23 PM, Cyrus Daboo wrote:

> 2) Add a new STDFLAGs return option such that if a RETURN is  
> specified,
> then standard flags are only returned if STDFLAG is present as one  
> of the
> return options. If there is no return option, then the normal  
> behaviour
> occurs.
..
> Personally I prefer (2), but could live with (3). I do not find the  
> current
> situation acceptable though.

I prefer 2 too.

--Apple-Mail-10-1029484
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-10-1029484--

Date: Wed, 29 Mar 2006 15:23:33 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More on LISTEXT (fwd)
Sender: [email-masked]

--==========C8E17952152E61629ECD==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
I'd like to get some sort of feedback on the issue below as I want to 
submit a new annotatemore draft with LISTEXT dependency soon.

------------ Forwarded Message -----------
Date: March 23, 2006 9:13:34 PM -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More on LISTEXT

Hi,
I believe this was discussed before: currently with LISTEXT there is no way
for the client to tell the server not to return the 'standard' IMAP mailbox
flags such as \NoInferiors, \Marked etc. However, when listing annotations,
it would be nice to be able to list those without getting the standard flag
data again.

Solutions:

1) Leave things as they are - getting annotations will result in getting
the standard flags all over again.

2) Add a new STDFLAGs return option such that if a RETURN is specified,
then standard flags are only returned if STDFLAG is present as one of the
return options. If there is no return option, then the normal behaviour
occurs.

3) Add a new NOSTDFLAGS return option such that if specified in RETURN, the
standard flags are not returned.

Personally I prefer (2), but could live with (3). I do not find the current
situation acceptable though.

-- 
Cyrus Daboo

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

--==========C8E17952152E61629ECD==========
Content-Type: message/rfc822; name="More on LISTEXT"

Date: Thu, 23 Mar 2006 21:13:34 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More on LISTEXT
Sender: [email-masked]

Hi,
I believe this was discussed before: currently with LISTEXT there is no way 
for the client to tell the server not to return the 'standard' IMAP mailbox 
flags such as \NoInferiors, \Marked etc. However, when listing annotations, 
it would be nice to be able to list those without getting the standard flag 
data again.

Solutions:

1) Leave things as they are - getting annotations will result in getting 
the standard flags all over again.

2) Add a new STDFLAGs return option such that if a RETURN is specified, 
then standard flags are only returned if STDFLAG is present as one of the 
return options. If there is no return option, then the normal behaviour 
occurs.

3) Add a new NOSTDFLAGS return option such that if specified in RETURN, the 
standard flags are not returned.

Personally I prefer (2), but could live with (3). I do not find the current 
situation acceptable though.

-- 
Cyrus Daboo

--==========C8E17952152E61629ECD==========--

Date: Tue, 28 Mar 2006 16:20:02 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
CC: Alexey Melnikov <[email-masked]>
Subject: CONDSTORE
Sender: [email-masked]

I'm in the process of finalizing my CONDSTORE implementation, and I'm 
wondering what is the correct behavior when a client sends a 
CONDSTORE-specific command when the server has already responded to 
SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a syntax 
error (BAD), an operational error (NO), or ignored (OK)?

And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
doesn't support CONDSTORE?  I assume that the server should just ignore 
the HIGHESTMODSEQ status item, in the same way that it will have to 
ignore the SELECT/EXAMINE CONDSTORE parameter.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Mon, 27 Mar 2006 09:40:06 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

Hi Arnt,

--On March 27, 2006 4:07:42 PM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> I don't now remember exactly what Arnt's comments about annotate's
>> problems were, but I remember silently agreeing with them, so they
>> probably should be fixed before it gets to be RFC.
>
> (To be fair, draft-13 fixes most of them. Perhaps all that I mentioned.)

I'm working on ANNOTATEMORE (aka METADATA) right now and some of my other 
drafts, but will get around to ANNOTATE again in a couple of weeks. So 
please take the time now to look over it again and send comments. The only 
changes remaining to do from the -14 draft are:

1) Remove content-language attribute.
2) Add statement about experimental status.
3) Only allow sorting by value attribute - remove size.

-- 
Cyrus Daboo

Date: Mon, 27 Mar 2006 16:07:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

Timo Sirainen writes:
> I don't now remember exactly what Arnt's comments about annotate's 
> problems were, but I remember silently agreeing with them, so they 
> probably should be fixed before it gets to be RFC.

(To be fair, draft-13 fixes most of them. Perhaps all that I mentioned.)

Arnt

Subject: Re: Agenda: annotate etc
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: Mon, 27 Mar 2006 16:59:19 +0300
Sender: [email-masked]

On Mon, 2006-03-13 at 09:27 -0800, Mark Crispin wrote:
> Another troubling sign is that several implementors are conspicuous by 
> their absence from the technical discussion.  Perhaps this simply means 
> that the specification is going so well that they have nothing more to 
> add, but I doubt it.  When a specification is going well, everybody and 
> their grandmother wants to add something to it.

Well, I've been silent mostly because it looked complex enough that I
didn't have any plans to implement it for a long time yet. Now I think
my server is slowly getting ready for new features, so I may try
implementing annotate (and maybe others) in a few months.

I don't now remember exactly what Arnt's comments about annotate's
problems were, but I remember silently agreeing with them, so they
probably should be fixed before it gets to be RFC.

Date: Thu, 23 Mar 2006 21:13:34 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More on LISTEXT
Sender: [email-masked]

Hi,
I believe this was discussed before: currently with LISTEXT there is no way 
for the client to tell the server not to return the 'standard' IMAP mailbox 
flags such as \NoInferiors, \Marked etc. However, when listing annotations, 
it would be nice to be able to list those without getting the standard flag 
data again.

Solutions:

1) Leave things as they are - getting annotations will result in getting 
the standard flags all over again.

2) Add a new STDFLAGs return option such that if a RETURN is specified, 
then standard flags are only returned if STDFLAG is present as one of the 
return options. If there is no return option, then the normal behaviour 
occurs.

3) Add a new NOSTDFLAGS return option such that if specified in RETURN, the 
standard flags are not returned.

Personally I prefer (2), but could live with (3). I do not find the current 
situation acceptable though.

-- 
Cyrus Daboo

Date: Thu, 23 Mar 2006 20:34:31 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: LISTEXT + METADATA issues
Sender: [email-masked]

Hi Alexey,

--On March 23, 2006 11:08:20 AM -0800 Alexey Melnikov 
<[email-masked]> wrote:

>> 3) The new SELECTION option effectively requires comparisons - i.e. we
>> need to take comparators into account. I'm not sure whether a
>> statement to that effect belongs in the METADATA extension or whether
>> LISTEXT itself should have some general statement about how selection
>> options that use text comparisons should interact with i18n draft. I
>> think a general statement in LISTEXT would be better...
>
> Can you suggest some text?
>
>

    Internationalization Considerations

    The LIST command selection option types defined in this specification
    involve simple tests of mailbox properties. However, future extensions
    to LISTEXT may define SELECTION options that do more sophisticated
    tests. In the case of a test that requires matching text, in the
    presence of the COMPARATOR [I18N] extension, the active comparator MUST
    be used to do comparisons. Such LISTEXT extensions MUST indicate in
    their specification the interaction with the COMPARATOR [I18N]
    extension.

+ add informative reference to draft-ietf-imapext-i18n-06.txt

One more question: does it make sense to use RECURSIVEMATCH when matching 
annotations?

-- 
Cyrus Daboo

Date: Thu, 23 Mar 2006 12:08:20 -0800
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: LISTEXT + METADATA issues
Sender: [email-masked]

Cyrus Daboo wrote:

>
> Hi folks,
> Following the meeting of yesterday, I have been working on changes to 
> ANNOTATEMORE - now known as METADATA (though I won't change the file 
> name). The big one is switching over to LISTEXT for retrieval of 
> annotations on mailboxes. Some issues have come up whilst doing that:
>
> 1) I intend to implement both a LISTEXT SELECTION and RETURN option 
> type. Strictly speaking the RETURN option is all that is needed to 
> directly replace the old GETANNOTATION behviour, however the SELECTION 
> option adds the ability to search for mailboxes with specific 
> annotations.

Sounds good to me.

> 2) As part of extending the syntax for LISTEXT I found the 
> option-extension formal syntax element to not be sufficient, so 
> instead directly added to the list-select-base-opt and return-option 
> elements. Because of that I do wonder whether having option-extension 
> is worth it.

The option-extension non terminal specifies generic (or recommended) 
syntax. What you did seems reasonable, but I need to see your revised 
draft to confirm.

> 3) The new SELECTION option effectively requires comparisons - i.e. we 
> need to take comparators into account. I'm not sure whether a 
> statement to that effect belongs in the METADATA extension or whether 
> LISTEXT itself should have some general statement about how selection 
> options that use text comparisons should interact with i18n draft. I 
> think a general statement in LISTEXT would be better...

Can you suggest some text?

Date: Thu, 23 Mar 2006 12:46:12 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: LISTEXT + METADATA issues
Sender: [email-masked]

Hi folks,
Following the meeting of yesterday, I have been working on changes to 
ANNOTATEMORE - now known as METADATA (though I won't change the file name). 
The big one is switching over to LISTEXT for retrieval of annotations on 
mailboxes. Some issues have come up whilst doing that:

1) I intend to implement both a LISTEXT SELECTION and RETURN option type. 
Strictly speaking the RETURN option is all that is needed to directly 
replace the old GETANNOTATION behviour, however the SELECTION option adds 
the ability to search for mailboxes with specific annotations.

2) As part of extending the syntax for LISTEXT I found the option-extension 
formal syntax element to not be sufficient, so instead directly added to 
the list-select-base-opt and return-option elements. Because of that I do 
wonder whether having option-extension is worth it.

3) The new SELECTION option effectively requires comparisons - i.e. we need 
to take comparators into account. I'm not sure whether a statement to that 
effect belongs in the METADATA extension or whether LISTEXT itself should 
have some general statement about how selection options that use text 
comparisons should interact with i18n draft. I think a general statement in 
LISTEXT would be better...

-- 
Cyrus Daboo

Date: Wed, 22 Mar 2006 10:53:57 -0800
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: List of open issues with LIST-EXTENDED]
Sender: [email-masked]

--------------020806010003040506060808
Content-type: text/plain; charset="us-ascii"

Appologies for sending this too late, but here is the list of remaining 
open issues for LIST-EXTENDED.
I really hope to get closure on this document right after the Dallas 
meeting.

--------------020806010003040506060808
Content-type: message/rfc822; name="List of open issues with LIST-EXTENDED"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="List of open issues with LIST-EXTENDED"

Date: Tue, 14 Mar 2006 22:59:59 +0000
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
Subject: List of open issues with LIST-EXTENDED

Hi Barry,
Below is the list of all issues I have. If you agree, I will forward it 
to the mailing list.

The list of major open issues with LIST-EXTENDED:

1). "The server can ignore CHILDREN option if it likes". I think this is 
wrong and needs reviewing. The whole section about 
\HasChildren/\HasNoChildren was taken from the document that didn't have 
any way to request the attributes. Now we have an option, so I think the 
section has to be rewritten accordingly.

2). From Rob's message:

 >>In particular, some servers may not be able to combine the SUBSCRIBED 
selection option and CHILDREN return option. <<
 >
 >We need to seriously consider this.
 >
 >What if in the future we find another combination that some 
implementations find computationally expensive?
 >Are we going to have to declare a hierarchy of priorities for the 
servers to process these in
 >("REMOTE SUBSCRIBED CHILDREN is hard for me, so I'll just do 
SUBSCRIBED....")?
 >
 >Additionally, clients that want this information are still going to 
have to figure it out somehow
 >(and based on what I've seen, its likely they will do a separate LIST 
command for each one).

I tend to agree with Rob on this.

=========
The remaining issues from Rob are mostly editorial and more or less 
straightforward:

3).

> Can we break up section 3.[nil] into subsections (overview, selection 
> options, return options).

I agree, that might help with readability and this change should be easy.

4).

> The REMOTE selection option section states "The '\Remote' attribute 
> MUST be accurately computed..."
>
> It would be nice if a note was in there stating that if the server 
> presents this flag it MAY, in fact, not issue a referral when the 
> mailbox is accessed (for example, if the mailbox has become local in 
> the intervening time). Likewise, a mailbox previously noted as local 
> MAY get a referral anyway (since the mailbox may have been made 
> non-local in the interim).

Even though LIST-EXTENDED doesn't support referrals, the comment is 
still valid. I've already added similar text about \HasChildren (it is 
not a 100% guaranty that by the time the client access the mailbox it 
will still have children).

5).

> In the description of the HasChildren flag we suddenly start talking 
> about access permissions -- yet elsewhere in the document we haven't 
> mentioned it at all.  I don't think that we need to worry about it 
> here, and we can just say that in some implementations it may be 
> expensive to compute the existence of child mailboxes, and that 
> \HasChildren is only a hint to clients.
>
> If we really want to talk about access permissions in this document, 
> we should think carefully about where else they may be hard to 
> complute (\Remote?)

I am not sure if anything is needed in this area. What do you think?

--------------020806010003040506060808--

Date: Tue, 21 Mar 2006 07:22:01 -0600
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Splitting Binary
Sender: [email-masked]

Hi Lyndon,

--On March 20, 2006 8:49:46 PM -0800 Lyndon Nerenberg <[email-masked]> 
wrote:

>> Of course per-mailbox capabilities could be advertised via
>> ANNOTATEMORE. That is something that we could formalize:
>
> But what do you do when the server doesn't support annotatemore?  The
> problem is still there.

At that point the client has to fall back to a 'try it and be prepared for 
it fail' behaviour. At least it will know to expect that if 
'OPTIONAL-FOOBAR' is advertised.

-- 
Cyrus Daboo

Cc: [email-masked], [email-masked]
From: Lyndon Nerenberg <[email-masked]>
Subject: Re: Splitting Binary
Date: Mon, 20 Mar 2006 20:49:46 -0800
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> Of course per-mailbox capabilities could be advertised via  
> ANNOTATEMORE. That is something that we could formalize:

But what do you do when the server doesn't support annotatemore?  The  
problem is still there.

--lyndon

Date: Mon, 20 Mar 2006 18:37:52 -0600
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Splitting Binary
Sender: [email-masked]

Hi Lyndon,

--On March 20, 2006 4:06:18 PM -0800 Lyndon Nerenberg <[email-masked]> 
wrote:

> The big issue I have is with servers that don't support the append side,
> or do, but only on a subset of mailboxes.  I just don't see a clean way
> for the server to advertise the append-side capability.

Of course per-mailbox capabilities could be advertised via ANNOTATEMORE. 
That is something that we could formalize:

e.g. for an extension that may be offered on a per-mailbox bases, a server 
that advertises 'FOOBAR' in the CAPABILITY response always supports the 
foobar extension on all mailboxes. Whereas if the server advertises 
'OPTIONAL-FOOBAR' then it only supports foobar on a per-mailbox basis. In 
that case a new /capability annotation on mailboxes supporting foobar would 
list 'FOOBAR' as one of the capabilities - or its part of LISTEXT. This use 
of the 'OPTIONAL-' capability prefix can be used as a generalized way to 
handle cases like this. I don't know whether there is a benefit to 
separating these two cases like this...

-- 
Cyrus Daboo

Date: Mon, 20 Mar 2006 16:06:18 -0800
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], [email-masked]
Subject: Splitting Binary
Sender: [email-masked]

Some food for thought before Wednesdays sessions ...

Most (all?) of the issues with Binary seem to be with the append side. I 
think fetch can be cleaned up with a grammar fix to clarify literal+ 
interactions, and text explicitly calling out that you can only binary 
fetch terminals.

The big issue I have is with servers that don't support the append side, 
or do, but only on a subset of mailboxes.  I just don't see a clean way 
for the server to advertise the append-side capability.

I'm mulling the idea of splitting the current 'binary' into two new 
capabilities: 'bfetch' and 'bappend'.  This would solve the problem for 
those servers that can't or won't implement the append side.  It still 
doesn't handle the case where some mailboxes can handle bappend, but 
others can't.  My feeling here is that since the server now has the 
option of punting on bappend, if it *does* advertise the capability it 
*must* deal with it on *all* mailboxes.  Since bappend is an 
optimization for the client, I feel it's incumbent on the server to do 
whatever is necessary to actually optimize things for the client. 
Requiring the client to probe for validity is a non-starter in my books. 
  And it was always my intent in binary that servers would go out of the 
way to make bappend work everywhere if it worked at all; the new 
behaviour would make that a requirement.

I realize this is out of scope for both the WGs, but if we're starting 
anew there's a better chance of being able to tailor things to meet some 
of the requirements the Lemonade folks have been talking about.

--lyndon

From: "Stephane H. Maes" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Comments on draft-gulbrandsen-imap-view-00.txt
Date: Fri, 17 Mar 2006 22:01:23 -0800
Sender: [email-masked]

I am ok to merge. Just not sure why such overlap are taking place.

Stephane 

_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger) or [email-masked] (Google)
 
-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Friday, March 17, 2006 9:57 PM
To: [email-masked]
Cc: Arnt Gulbrandsen; Stephane Maes
Subject: Re: Comments on draft-gulbrandsen-imap-view-00.txt

Something I've mentioned to Arnt and which is worth repeating on the mailing list:

Arnt's VIEW extension overlaps with Lemonade VFOLDER extension. They essentially solving the same problem, so I would like to see a single
(merged?) draft.

Date: Sat, 18 Mar 2006 05:56:59 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Arnt Gulbrandsen <[email-masked]>, Stephane Maes <[email-masked]>
Subject: Re: Comments on draft-gulbrandsen-imap-view-00.txt
Sender: [email-masked]

Something I've mentioned to Arnt and which is worth repeating on the 
mailing list:

Arnt's VIEW extension overlaps with Lemonade VFOLDER extension. They 
essentially solving the same problem, so I would like to see a single 
(merged?) draft.

Date: Tue, 14 Mar 2006 19:16:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-gulbrandsen-imap-view-00.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Hi Arnt,
>> Feel free to forward the following comments to the mailing list:
>>
>> 1). Is there an expectation that UIDs must persist in a view between 
>> multiple selects of the VIEW? I would say so, but the document 
>> doesn't say that.
>
> Hm. I thought there was a sentence saying that a view should be 
> indistinguishable from a mailbox by a client which doesn't support 
> VIEW, but now I can't find it.

That might be too subtle.

> I'll add one.

Please.

>> 2).
>> >The VIEW CREATE Command
>> >
>> >    Arguments: Name of underlying mailbox
>> >               Name of view to be created
>> >               Search expression
>>
>> I would slightly prefer usage of CREATE <mailbox> ("VIEW" <criteria>) 
>> syntax, see VFOLDER for an example.
>
> Why?

I want to see consistent syntax. As you are using different command, 
this is not a big deal. But if one wants to extend both CREATE and VIEW 
CREATE in the same manner, you might as well have a single command from 
the start. Think about LIST and LSUB.

> (I'm not disagreeing. I have no preference, really. We just did 
> something that looked like FETCH/UID FETCH.)
>
>> 3).
>> >    The DELETE Command (RFC 3501 section 6.3.4) offers a special 
>> problem
>> >    if a mailbox is deleted while there are views onto that mailbox. In
>> >    order to simplify implementation, no particular behaviour is
>> >    mandated in that case.  However, servers MUST NOT show messages in
>> >    deleted mailboxes to clients.
>>
>> This paragraph is effectively mandating a behaviour: the view is not 
>> deleted,
>> but contains no messages. That is fine with me. I would rather you 
>> change the text to say that.
>
> There are three possible behaviours:
>
> a) Existing sessions onto such views are forcibly terminated by the 
> servers.
> b) Existing sessions are left alone, but no messages are accessible 
> through them.
> c) The view is left alone, and can even be selected, but contains no 
> messages.

Whether existing sessions are allowed or terminated is orthogonal to 
allowing new clients to select the view.
I am fine with either saying that when you delete the backing mailbox 
all views are deleted or kept around as empty mailbox. I think 
implementing one way or another is about the same amount of effort. So I 
suggest you make a choice.

If you want to delete views when backing mailbox is deleted, you can 
allow implementations to delay deleting the view till next 
select/examine/status.

> This is much like RFC 2180.

I advise you to at least describe allowed choices.

>> 4).
>> >    The RENAME Command (RFC 3501 section 6.3.5) has a similar problem:
>> >    If a mailbox is renamed, what happens to views onto that mailbox?
>> >    Again, no particular behaviour is mandated.
>>
>> I don't like that. Treat as "DELETE <original name>"?
>
> Why don't you like that?

I want some predictability. This will improve interoperability.

> Having all views follow the rename was easy for us, and seemed useful 
> at the time.

Ok. This seems like a better choice, but I want to see more text 
describing different choices.

>> But if the new name is a base for another view, this will "populate 
>> the view"?
>
> (It cannot be, since if the RENAME suceeds the new name does not 
> exist, and creating a view needs a mailbox.)

I was thinking about the following sequence of events:
1). Create view based on mailbox FOO
2). Delete the mailbox FOO (assuming the server keeps all derived views 
around).
3). Renamed mailbox JAR to FOO.

>> 5).
>> >    The APPEND Command (RFC 3501 section 6.3.11) and the COPY Command
>> >    (RFC 3501 section 6.4.7) cannot be used to append/copy messages to
>> >    views.
>>
>> Why not just copy the message to the backend mailbox?
>
> a) Didn't fit the use-cases we had while writing the code. b) It's 
> easy to change towards being more permissive, harder to change the 
> other way. c) It seemed a bit naughty to permit a J. Random Client to 
> append a message and apparently have it vanish into thin air.

Ah, I haven't thought about that. But you can describe this possibility 
in the draft.

However if you say that ordinary client can use VIEWs as if they are 
regular mailboxes, you should allow them to perform all commands that 
take mailbox name parameter.

> Arguments welcome.
>
>> Without ACL support there is no easy way for the server to tell that 
>> it doesn't support APPEND/COPY to the mailbox.
>
> That's a general argument in favour of ACL. Not particularly pertinent 
> to this extension.
>
>> 6).
>> >    The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying
>> >    mailbox to be expunged when a view is expunged. Servers MAY expunge
>> >    only the messages visible in the view, or MAY expunge the entire
>> >    mailbox. The former is more desirable, if possible.
>>
>> I would prefer to mandate the former. Implementing UID EXPUNGE is not 
>> that difficult.
>
> How about making it a SHOULD?

SHOULD is not sufficient. If you allow servers to perform EXPUNGE on the 
whole mailboxes, some users will be upset.
(If I have it might way, I would deprecate the EXPUNGE command).

>> 7).
>> >ACL Commands
>> >
>> [...]
>> >
>> >    MYRIGHTS computes access as for mailboxes. However, it may or may
>> >    not consider the underlying mailbox ACL, depending on how a server
>> >    implements VIEW.
>>
>> Can you pick a behaviour? E.g. always use ACL for the underlying 
>> mailbox, but can allow for a subset of rights.
>
> I can't, really. There are good arguments in both directions. I'm also 
> not convinced that one behaviour can be implemented by all current-day 
> servers. (See the security considerations.)

Once again, please describe available choices in the document.

Alexey

Date: Tue, 14 Mar 2006 19:52:31 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Comments on draft-gulbrandsen-imap-view-00.txt
Cc: [email-masked]
Sender: [email-masked]

Alexey Melnikov writes:
> Hi Arnt,
> Feel free to forward the following comments to the mailing list:
>
> 1). Is there an expectation that UIDs must persist in a view between 
> multiple selects of the VIEW? I would say so, but the document 
> doesn't say that.

Hm. I thought there was a sentence saying that a view should be 
indistinguishable from a mailbox by a client which doesn't support 
VIEW, but now I can't find it. I'll add one.

> 2).
> >The VIEW CREATE Command
> >
> >    Arguments: Name of underlying mailbox
> >               Name of view to be created
> >               Search expression
>
> I would slightly prefer usage of CREATE <mailbox> ("VIEW" <criteria>) 
> syntax, see VFOLDER for an example.

Why?

(I'm not disagreeing. I have no preference, really. We just did 
something that looked like FETCH/UID FETCH.)

> 3).
> >    The DELETE Command (RFC 3501 section 6.3.4) offers a special problem
> >    if a mailbox is deleted while there are views onto that mailbox. In
> >    order to simplify implementation, no particular behaviour is
> >    mandated in that case.  However, servers MUST NOT show messages in
> >    deleted mailboxes to clients.
>
> This paragraph is effectively mandating a behaviour: the view is not deleted,
> but contains no messages. That is fine with me. I would rather you 
> change the text to say that.

There are three possible behaviours:

a) Existing sessions onto such views are forcibly terminated by the servers.
b) Existing sessions are left alone, but no messages are accessible 
through them.
c) The view is left alone, and can even be selected, but contains no messages.

This is much like RFC 2180.

> 4).
> >    The RENAME Command (RFC 3501 section 6.3.5) has a similar problem:
> >    If a mailbox is renamed, what happens to views onto that mailbox?
> >    Again, no particular behaviour is mandated.
>
> I don't like that. Treat as "DELETE <original name>"?

Why don't you like that?

Having all views follow the rename was easy for us, and seemed useful at 
the time.

> But if the new name is a base for another view, this will "populate 
> the view"?

(It cannot be, since if the RENAME suceeds the new name does not exist, 
and creating a view needs a mailbox.)

> 5).
> >    The APPEND Command (RFC 3501 section 6.3.11) and the COPY Command
> >    (RFC 3501 section 6.4.7) cannot be used to append/copy messages to
> >    views.
>
> Why not just copy the message to the backend mailbox?

a) Didn't fit the use-cases we had while writing the code. b) It's easy 
to change towards being more permissive, harder to change the other 
way. c) It seemed a bit naughty to permit a J. Random Client to append 
a message and apparently have it vanish into thin air.

Arguments welcome.

> Without ACL support there is no easy way for the server to tell that 
> it doesn't support APPEND/COPY to the mailbox.

That's a general argument in favour of ACL. Not particularly pertinent 
to this extension.

> 6).
> >    The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying
> >    mailbox to be expunged when a view is expunged. Servers MAY expunge
> >    only the messages visible in the view, or MAY expunge the entire
> >    mailbox. The former is more desirable, if possible.
>
> I would prefer to mandate the former. Implementing UID EXPUNGE is not 
> that difficult.

How about making it a SHOULD?

> 7).
> >ACL Commands
> >
> [...]
> >
> >    MYRIGHTS computes access as for mailboxes. However, it may or may
> >    not consider the underlying mailbox ACL, depending on how a server
> >    implements VIEW.
>
> Can you pick a behaviour? E.g. always use ACL for the underlying 
> mailbox, but can allow for a subset of rights.

I can't, really. There are good arguments in both directions. I'm also 
not convinced that one behaviour can be implemented by all current-day 
servers. (See the security considerations.)

> 8).
> >Examples
> >
> >         C: e LIST (views) "" "%" return (views)
> >         S: * LIST (\hasnochildren \view) "." IMAP-announcements ((view
> >            (INBOX "HEADER \"Sender\" \"<ietf-announce-
> >            [email-masked]>\" OR BODY imap BODY smtp")))
>
> Drop extra () around view return data (as per latest LIST-EXTENDED)

OK.

> >Formal Syntax
> [...]
> >        view-extended-item = "VIEW" SP "(" mailbox SP nstring ")"
> >                      ; see the open issues section
>
> This is fixed in the latest LIST-EXTENDED, so you can update the grammar.

Thanks.

Arnt

Date: Mon, 13 Mar 2006 18:42:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Cc: Rob Siemborski <[email-masked]>, Pete Resnick <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> So what is it that's keeping you from thinking it's done?

Speaking just for me:

I found too many problems per day when implementing. Once that rate 
slows down, I think it'll be okay. Not perfect, but okay.

Arnt

Date: Mon, 13 Mar 2006 09:27:52 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Dave Cridland <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

On Mon, 13 Mar 2006, Lisa Dusseault wrote:
> So what is it that's keeping you from thinking it's done?

It is a highly-complex specification with minimal implementation, 
interoperability testing, or operational experience.  Put bluntly, it has 
yet to show that it has a purpose for being.

Another troubling sign is that several implementors are conspicuous by 
their absence from the technical discussion.  Perhaps this simply means 
that the specification is going so well that they have nothing more to 
add, but I doubt it.  When a specification is going well, everybody and 
their grandmother wants to add something to it.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Mon, 13 Mar 2006 09:09:08 -0800
To: "Dave Cridland" <[email-masked]>
Subject: Re: Agenda: annotate etc
Cc: "Pete Resnick" <[email-masked]>, [email-masked], "Arnt Gulbrandsen" <[email-masked]>, "Rob Siemborski" <[email-masked]>
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

So what is it that's keeping you from thinking it's done?  For me, it's  
the per-user annotations, which I've never implemented although you're  
correct that I've implemented WebDAV resource properties a couple times.   
I recall hearing some concerns that the per-user annotations could get out  
of control.  Still, I'm not convinced that the per-user annotations are a  
flaw, either -- it's exactly the kind of feature that gets server  
implementors worried about the "theoretical" problems with the feature,  
but if they actually got down and implemented it ( and put some reasonable  
limits on the use of the feature) it would work out fine in practice.

lisa

On Mon, 13 Mar 2006 00:58:37 -0800, Dave Cridland <[email-masked]>  
wrote:

> On Sun Mar 12 23:48:58 2006, Lisa Dusseault wrote:
>>    I don't have a strong opinion on whether we haven't done the  right  
>> things to make it feasible for servers to implement, or whether the   
>> protocol's good enough and just needs to have an RFC # of some kind.
>>
> Right.
>
> What you've just said there makes me more wary of publishing this on the  
> Standards Track.
>
> Both WebDAV and ACAP store arbitrary metadata, as does this  
> specification. You've implemented WebDAV on the server a few times, as I  
> understand it, I've done ACAP on the server, and neither of us hold a  
> strong "This is ready" opinion. The only implementation attempt by an  
> IMAP server guy has left no such opinion either.
>
> This ought to be sounding klaxons, let alone alarm bells.
>
> Dave.

Date: Mon, 13 Mar 2006 14:29:04 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Cc: Rob Siemborski <[email-masked]>, Pete Resnick <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> It did seem when we discussed this last year, that there were several  
> interested client implementors.  However, there were very few 
> interested  server implementors, and if I recall correctly I think 
> one of them was  Arnt who is now raising some issues.

Not now.

I raised issues last year, as many as I thought advisable. Cyrus and 
Randy dealt with them later last year.

(If you'd like concrete issues again, I can bring my code into alignment 
with -13 and see what comes up in the process. I haven't so far, 
because I'm not sure how much time I want to put into this extension 
unless there's someone around with which my code might interoperate.)

Arnt

Date: Mon, 13 Mar 2006 08:58:37 +0000
Subject: Re: Agenda: annotate etc
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Pete Resnick <[email-masked]>, <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Rob Siemborski <[email-masked]>
Sender: [email-masked]

On Sun Mar 12 23:48:58 2006, Lisa Dusseault wrote:
>    I don't have a strong opinion on whether we haven't done the  
> right things to make it feasible for servers to implement, or 
> whether the  protocol's good enough and just needs to have an RFC # 
> of some kind.
> 
> 
Right.

What you've just said there makes me more wary of publishing this on 
the Standards Track.

Both WebDAV and ACAP store arbitrary metadata, as does this 
specification. You've implemented WebDAV on the server a few times, 
as I understand it, I've done ACAP on the server, and neither of us 
hold a strong "This is ready" opinion. The only implementation 
attempt by an IMAP server guy has left no such opinion either.

This ought to be sounding klaxons, let alone alarm bells.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Sun, 12 Mar 2006 15:48:58 -0800
To: "Rob Siemborski" <[email-masked]>, "Dave Cridland" <[email-masked]>
Subject: Re: Agenda: annotate etc
Cc: "Pete Resnick" <[email-masked]>, [email-masked], "Arnt Gulbrandsen" <[email-masked]>
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

It did seem when we discussed this last year, that there were several  
interested client implementors.  However, there were very few interested  
server implementors, and if I recall correctly I think one of them was  
Arnt who is now raising some issues.

Speaking as a client implementor: even though I'd like this standardized,  
I'd prefer it to be implemented by servers.  Usually servers need to  
implement a protocol like this before clients can even think of  
following.   I don't have a strong opinion on whether we haven't done the  
right things to make it feasible for servers to implement, or whether the  
protocol's good enough and just needs to have an RFC # of some kind.

Lisa

On Sun, 12 Mar 2006 12:06:30 -0800, Rob Siemborski <[email-masked]>  
wrote:

>
> On 3/12/06, Dave Cridland <[email-masked]> wrote:
>
>> I'm not convinced that without some basic prototyping work, we can
>> claim it's well understood or stable.
>
> Didn't we also see this with BINARY, where a few key questions came up
> only after it was published (and the first few implementations were
> made)?
>
> I'm nervous about pushing to publish just for the sake of publishing
> if no one has implemented it.
>
> -Rob
>
> --
> Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
> Software Engineer     |                       |            650-623-6925
>

Date: Mon, 13 Mar 2006 00:40:34 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Cc: Pete Resnick <[email-masked]>, Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Sun, 12 Mar 2006, Dave Cridland wrote:
>> I'm entirely happy to go for Experimental, and revisit this as 
>> Proposed sometime down the line when we have implementation 
>> experience.
>
> I agree with this suggestion.

And I... don't disagree.

Arnt

Date: Mon, 13 Mar 2006 00:34:13 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Cc: Pete Resnick <[email-masked]>
Sender: [email-masked]

Hi Pete,

please don't read more into my words than I meant to put there. I'm not 
trying to attack the general RFC process, or even this WG's drafts in 
general. All I'm saying is: When I worked on an implementation of 
_this_ document, I found so many issues so quickly that I think the 
next chap along will find real stuff, too.

Now, if someone here takes a few days to do a first rough implementation 
and comes back to say «Arnt found all the major problems there was, we 
can go along», I shall be happy. If that someone comes back with some 
problems to fix, that's excellent too. And finally, if noone cares 
enough to implement it, getting annotate to RFC isn't terribly urgent 
anyway, is it?

Please also observe that annotate is the only case in which I use such 
strong words. For example, I mutter about listext a bit now and then, 
but at the same time, I think listext is good enough to go to RFC. 
Listext is good. Best is the enemy of good.

Arnt

Date: Sun, 12 Mar 2006 12:06:30 -0800
From: "Rob Siemborski" <[email-masked]>
To: "Dave Cridland" <[email-masked]>
Subject: Re: Agenda: annotate etc
Cc: "Pete Resnick" <[email-masked]>, [email-masked], "Arnt Gulbrandsen" <[email-masked]>
Sender: [email-masked]

On 3/12/06, Dave Cridland <[email-masked]> wrote:

> I'm not convinced that without some basic prototyping work, we can
> claim it's well understood or stable.

Didn't we also see this with BINARY, where a few key questions came up
only after it was published (and the first few implementations were
made)?

I'm nervous about pushing to publish just for the sake of publishing
if no one has implemented it.

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

Date: Sun, 12 Mar 2006 12:06:15 -0800
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: Agenda: annotate etc
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Sun, 12 Mar 2006, Dave Cridland wrote:
> I don't think ANNOTATE has, currently, enough community interest *in 
> implementing it* to be viable.

Sadly, I agree.

> I'm entirely happy to go for Experimental, and revisit this as Proposed 
> sometime down the line when we have implementation experience.

I agree with this suggestion.

-- Mark --

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

Date: Sun, 12 Mar 2006 19:45:35 +0000
Subject: Re: Agenda: annotate etc
From: Dave Cridland <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

Pete,

On Sun Mar 12 16:55:19 2006, Pete Resnick wrote:
> 
> On 3/10/06 at 12:27 PM +0100, Arnt Gulbrandsen wrote:
> 
>> I hereby propose that we block ANNOTATE from going forward until 
>> someone steps up to say «I implemented the draft as it stands, and 
>> I'm happy with it» - or that we change the draft until someone 
>> will implement it and be happy.
> 
> OK, I'm a delusional person

I'm sufficiently delusional to implement, and use, ACAP, which is a 
protocol suffering from lack of implementation. So I out-delusion you 
by several orders of magnitude. :-)

Yet I agree with Arnt in this instance.

> Section 4.1.1:
> 
>    A Proposed Standard specification is generally stable, has 
> resolved
>    known design choices, is believed to be well-understood, has 
> received
>    significant community review, and appears to enjoy enough 
> community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.
> 
> 
I don't think ANNOTATE has, currently, enough community interest *in 
implementing it* to be viable. Traditionally, the problem with mail 
protocol extensions has always been early implementations, causing an 
older version of the specification to be fixed in implementation. 
SORT, THREAD, imapflags, LISTEXT, etc. It alarms me greatly to see 
the reverse problem, which was most obviously seen with ACAP.

I do think that some mechanism allowing clients to attach arbitrary 
metadata to messages in the store is important, and if ANNOTATE is 
sufficiently worrying to put people off implementing, we'll blow that 
chance. Note that I cannot do this even with my secret weapon of ACAP.

I'm not convinced that without some basic prototyping work, we can 
claim it's well understood or stable.

>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed 
> Standard
>    designation.
> 
> 
I believe we need that argument in this case.

I'm entirely happy to go for Experimental, and revisit this as 
Proposed sometime down the line when we have implementation 
experience.

If this revisiting happens when it's still in the queue, that's cool 
with me too.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Sun, 12 Mar 2006 13:58:05 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

> OK, I'm a delusional person

That's true, but no more so than some of the rest of us.

> Let's get the document published with what we think is "OK" now, without 
> requiring implementations, let implementation experience guide where we 
> need to make changes, and make those changes as necessary.

I'm not usually a "me too" guy, but to make sure that we don't wind up 
wondering which side silence is on:  I agree with Pete, delusions and all.

Barry

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

Date: Sun, 12 Mar 2006 10:55:19 -0600
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Agenda: annotate etc
Cc: [email-masked]
Sender: [email-masked]

On 3/10/06 at 12:27 PM +0100, Arnt Gulbrandsen wrote:

>I hereby propose that we block ANNOTATE from going forward until 
>someone steps up to say «I implemented the draft as it stands, and 
>I'm happy with it» - or that we change the draft until someone will 
>implement it and be happy.

OK, I'm a delusional person and understand that "the Internet runs on 
Proposed Standards", but since the IMAP community is pretty 
tight-knit and can communicate about what stage in development any 
document might be at, let me suggest that we actually try to live up 
to RFC 2026:

Section 4.1.1:

    A Proposed Standard specification is generally stable, has resolved
    known design choices, is believed to be well-understood, has received
    significant community review, and appears to enjoy enough community
    interest to be considered valuable.  However, further experience
    might result in a change or even retraction of the specification
    before it advances.

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable, and will
    usually represent a strong argument in favor of a Proposed Standard
    designation.

Let's get the document published with what we think is "OK" now, 
without requiring implementations, let implementation experience 
guide where we need to make changes, and make those changes as 
necessary. And when we put out a new version of ANNOTATE while the 
one we're about to publish is still in the RFC Editor's queue, we 
give more ammunition to the people who want to fix the publication 
process.

If there are *current* outstanding issues in the ANNOTATE document 
which can be fixed during WG last call, let's get them on the table 
now.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 10 Mar 2006 12:27:53 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

Cyrus Daboo writes:
> The bottom line is the current ANNOTATE document has gone through WG 
> last call and revisions since then, so in theory it ought to be ready 
> for the IESG.

Yes, in theory. Practice is about implementation.

When I implemented most of it, I was very unhappy and brought up a 
number of problems. It would have been much better if I or someone else 
had brought up these issues earlier, before WGLC. But I didn't see the 
issues until I implemented. Sorry.

I hereby propose that we block ANNOTATE from going forward until someone 
steps up to say «I implemented the draft as it stands, and I'm happy 
with it» - or that we change the draft until someone will implement it 
and be happy.

Arnt

To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE 
Date: Thu, 09 Mar 2006 14:03:40 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
...
>I've used the audio feeds over the last few meetings and it has worked 
>pretty well with the exception of people not going to the mike to make 
>comments. The WG chairs do need to enforce that when we know there are 
>audiophiles present!

IMHO, they should enforce that even if there aren't remote listeners.
I for one have found the audio archives quite useful for refreshing the
details of the discussions beyond what was documented in the minutes.

Philip Guenther

Date: Thu, 09 Mar 2006 16:30:44 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Agenda: annotate etc
Sender: [email-masked]

Hi Pete,
Obviously there needs to be a serious discussion of ANNOTATE and 
ANNOTATEMORE. Things were left somewhat up in the air after the last 
exchange on the mailing list

The bottom line is the current ANNOTATE document has gone through WG last 
call and revisions since then, so in theory it ought to be ready for the 
IESG.

ANNOTATEMORE sparked discussions first about what it should be called based 
on what it is doing and that then lead to a discussion of a whole new 
extension that encompasses a more 'generic' metadata solution using LISTEXT 
etc. That debate did not come to any firm conclusions and we ought to try 
and have a concrete proposal coming out of Dallas.

-- 
Cyrus Daboo

Date: Thu, 09 Mar 2006 16:26:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

Hi Arnt,

--On March 9, 2006 10:23:41 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> I won't be in Dallas, but I should be able to attend via Jabber (ugh).
>
> How does the audio feed work? Is there any practical way to test that
> ahead of time?
>
> (My ISP, chosen for its IPv6 support and general competence, also offers
> multicast.)

I've used the audio feeds over the last few meetings and it has worked 
pretty well with the exception of people not going to the mike to make 
comments. The WG chairs do need to enforce that when we know there are 
audiophiles present! As for testing, try firing it up for the first session 
on Monday for the room imapext will be in and see what it is like.

-- 
Cyrus Daboo

Date: Thu, 9 Mar 2006 22:23:41 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

Lyndon Nerenberg writes:
> I won't be in Dallas, but I should be able to attend via Jabber (ugh).

How does the audio feed work? Is there any practical way to test that 
ahead of time?

(My ISP, chosen for its IPv6 support and general competence, also offers 
multicast.)

Arnt

Date: Thu, 09 Mar 2006 12:39:34 -0800
From: Lyndon Nerenberg <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked], Enhancements to Internet email to support diverse service enivronments <[email-masked]>, Ken Murchison <[email-masked]>
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

> BINARY is on the cards for a revision, I think, perhaps it could be
> added to that? Might be able to get it all sorted out quicker.

I have started on the update, and plan to push a draft soon after the 
freeze is over.  I'm not sure this can be fixed in the BINARY document, 
but work out what you need and I'll see what can be done.

I won't be in Dallas, but I should be able to attend via Jabber (ugh).

--lyndon

Date: Thu, 09 Mar 2006 20:08:47 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

Ken Murchison wrote:

> Pete Resnick wrote:
>
>> On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote:
>>
>>> I'm now wondering if I need to support BINARY (literal8) for 
>>> CATENATE (TEXT parts)?  I don't see any mention of BINARY or 
>>> literal8 in the CATENATE draft.
>>
>> Damn! How did I miss that?
>>
>> I'd sure like you to add the support for it and we'll fix CATENATE 
>> the next time around.
>
> Is this something that we should put on the agenda for one/both WG at 
> the upcoming meetings?

We should address this in Lemonade Profile Phase 2. So discussing this 
in Lemonade seems appropriate.

Date: Thu, 09 Mar 2006 15:06:16 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Pete Resnick <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

Pete Resnick wrote:
> On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote:
> 
>> I'm now wondering if I need to support BINARY (literal8) for CATENATE 
>> (TEXT parts)?  I don't see any mention of BINARY or literal8 in the 
>> CATENATE draft.
> 
> 
> Damn! How did I miss that?
> 
> I'd sure like you to add the support for it and we'll fix CATENATE the 
> next time around.

Is this something that we should put on the agenda for one/both WG at 
the upcoming meetings?

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Thu, 09 Mar 2006 20:04:04 +0000
Subject: Re: [lemonade] BINARY & CATENATE
From: Dave Cridland <[email-masked]>
To: Pete Resnick <[email-masked]>, Lyndon Nerenberg <[email-masked]>
Cc: <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

On Thu Mar  9 19:31:48 2006, Pete Resnick wrote:
> On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote:
> 
>> I'm now wondering if I need to support BINARY (literal8) for 
>> CATENATE (TEXT parts)?  I don't see any mention of BINARY or 
>> literal8 in the CATENATE draft.
> 
> Damn! How did I miss that?
> 
> I'd sure like you to add the support for it and we'll fix CATENATE 
> the next time around.

BINARY is on the cards for a revision, I think, perhaps it could be 
added to that? Might be able to get it all sorted out quicker.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Thu, 9 Mar 2006 11:31:48 -0800
To: Ken Murchison <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [lemonade] BINARY & CATENATE
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote:

>I'm now wondering if I need to support BINARY (literal8) for 
>CATENATE (TEXT parts)?  I don't see any mention of BINARY or 
>literal8 in the CATENATE draft.

Damn! How did I miss that?

I'd sure like you to add the support for it and we'll fix CATENATE 
the next time around.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 9 Mar 2006 14:41:31 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda items for Dallas
Sender: [email-masked]

5) If in scope, I'd like some comments on draft-gulbrandsen-imap-view-00.txt.

Arnt

Date: Wed, 08 Mar 2006 21:30:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked], [email-masked]
Subject: BINARY & CATENATE
Sender: [email-masked]

With the help of the good folks at Lucent I've been working on adding 
support for BINARY APPEND to Cyrus (to go along with its existing 
support for BINARY FETCH).

I'm now wondering if I need to support BINARY (literal8) for CATENATE 
(TEXT parts)?  I don't see any mention of BINARY or literal8 in the 
CATENATE draft.

And what about CTE=binary in messages/parts fetched via URLs?

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Wed, 08 Mar 2006 20:27:58 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Agenda items for Dallas
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 3) ANNOTATE.
>
> Do we go forward or start again from scratch? I want, no, I _need_ 
> annotations. My needs are basically: Storing named variables whose 
> types are numbers, bools, enums and string variables. Bools I can do 
> with flags.

4). I've talked to Lisa and suggested to poll people what extensions 
they want to work on, as opposed to what in our charter. I've promised 
to write down some suggestions/questions.

Date: Wed, 8 Mar 2006 21:13:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda items for Dallas
Sender: [email-masked]

3) ANNOTATE.

Do we go forward or start again from scratch? I want, no, I _need_ 
annotations. My needs are basically: Storing named variables whose 
types are numbers, bools, enums and string variables. Bools I can do 
with flags.

Arnt

Date: Wed, 08 Mar 2006 20:05:41 +0000
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: Agenda items for Dallas
Sender: [email-masked]

Pete Resnick wrote:

> As of now, we are meeting on Wednesday from 1300-1500.
>
> Document authors: Please send agenda items ASAP.

May I suggest:
1). Review remaining issues with LIST-EXTENDED (I will send a list of 
issues separately).
2). Review Chris'/Arnt's comparators draft and I18N draft.

Date: Wed, 8 Mar 2006 11:43:28 -0800
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Agenda items for Dallas
Sender: [email-masked]

As of now, we are meeting on Wednesday from 1300-1500.

Document authors: Please send agenda items ASAP.

Thanks,

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 8 Mar 2006 20:40:51 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: condstore will come out as an RFC in its present form?
Sender: [email-masked]

Lisa Dusseault writes:
> Better to start working on a brand new condstore and obsolete  the one 
> that eventually makes it out of the RFC process.

Even better to start implementing ;)

Arnt

To: "Arnt Gulbrandsen" <[email-masked]>, [email-masked]
Subject: Re: condstore will come out as an RFC in its present form?
Date: Wed, 08 Mar 2006 11:31:20 -0800
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

It's gone, dude!

You can check the status with the datatracker tool:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=10164

There would have to be serious flaws to bring it back through the IESG  
approval process again as we did it twice with that document, quite  
unusually.  Better to start working on a brand new condstore and obsolete  
the one that eventually makes it out of the RFC process.

We can fix nits while the document is in RFC Ed queue -- the authors get a  
last chance to fix typos, small errors or formatting problems in Author's  
48 hr review at the end of the process.

Lisa

On Wed, 08 Mar 2006 10:27:22 -0800, Arnt Gulbrandsen  
<[email-masked]> wrote:

>
> Or can it still change?
>
> I feel like implementing it. Been spending too much time editing  
> documents and not enough writing code, and I know some neat and  
> convenient things I could do with condstore ;)
>
> Arnt
>

Date: Wed, 8 Mar 2006 20:12:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: condstore will come out as an RFC in its present form?
Sender: [email-masked]

Alexey Melnikov writes:
> It just got approved the second time in the last 2 years ;-).

I noticed.

> Do you have any specific changes/suggestions you want to do to Condstore?

No, I quite like it, I was just worried that it might still change. 
(Shrink to 32 bits, perhaps. A total put-off from my point of view.)

If I come across any misplaced commas or other auth48 items for you, 
I'll send you and Steve mail privately.

Arnt

From: "Scott Hollenbeck" <[email-masked]>
To: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked]
Subject: RE: condstore will come out as an RFC in its present form?
Date: Wed, 8 Mar 2006 13:58:22 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Arnt Gulbrandsen [mailto:[email-masked]] 
> Sent: Wednesday, March 08, 2006 1:27 PM
> To: [email-masked]
> Subject: condstore will come out as an RFC in its present form?
> 
> 
> Or can it still change?
> 
> I feel like implementing it. Been spending too much time editing 
> documents and not enough writing code, and I know some neat and 
> convenient things I could do with condstore ;)

The IESG just re-approved it last week.  As far as the IESG is concerned,
the current version is what will be published as an RFC.

-Scott-

Date: Wed, 08 Mar 2006 18:58:13 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: condstore will come out as an RFC in its present form?
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Or can it still change?

It just got approved the second time in the last 2 years ;-).

There might be some minor tweaks to Condstore caused by interaction with 
ESEARCH extension, but this is most likely be a separate extension.

Do you have any specific changes/suggestions you want to do to 
Condstore? If they are minor editorial things, they can be addressed 
when moving to Draft [Alexey is being overly optimistic, please ignore him].

Date: Wed, 8 Mar 2006 19:27:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: condstore will come out as an RFC in its present form?
Sender: [email-masked]

Or can it still change?

I feel like implementing it. Been spending too much time editing 
documents and not enough writing code, and I know some neat and 
convenient things I could do with condstore ;)

Arnt

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, imapext mailing list <[email-masked]>, imapext chair <[email-masked]>, imapext chair <[email-masked]>
Subject: Protocol Action: 'IMAP Extension for Conditional STORE  operation' to Proposed Standard 
Date: Mon, 06 Mar 2006 16:16:09 -0500
Sender: [email-masked]

The IESG has approved the following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-09.txt> as a Proposed Standard

This document is the product of the Internet Message Access Protocol Extension Working Group.  The IESG approved version -05 of this document in August 2003,
but the working group revised the document to correct some issues that were
discovered after IESG approval.

The IESG contact persons are Scott Hollenbeck and Ted Hardie.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-09.txt

Technical Summary

Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox.  Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients need a
mechanism to synchronize state changes for messages within the mailbox.
They must be able to guarantee that only one client can change message
state (e.g., message flags or annotations) at any time.  An example of
such an application is use of an IMAP mailbox as a message queue with
multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism 
for message state information that can detect and resolve conflicts 
between multiple writing mail clients.
  
Working Group Summary
 
This document is a product of the imapext working group.  An earlier
version of this document (draft-ietf-imapext-condstore-05) was approved
by the IESG for publication as a Proposed Standard RFC in December
2003, but the working group decided that changes needed to be made
before the document was published as an RFC.  The rationale for the
changes is described in a comment archived in the I-D Tracker.
 
Protocol Quality
 
Ned Freed and Scott Hollenbeck reviewed this specification for the IESG.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-16.txt 
Date: Mon, 06 Mar 2006 15:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-16.txt
	Pages		: 36
	Date		: 2006-3-6
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions, such as Mailbox Referrals, that have required
specialized lists we have had to expand the number of list commands,
since each extension must add its function to both LIST and LSUB, and
these commands are not, as they are defined, extensible.  If we've
needed the extensions to work together, we've had to add a set of
commands to mix the different options, the set increasing in size
with each new extension.  This document describes an extension to the
base LIST command that will allow these additions to be done with
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-16.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-16.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-16.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-16.txt

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

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

--OtherAccess--

--NextPart--

From: "Spencer Dawkins" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Scott Hollenbeck" <[email-masked]>, "General Area Review Team" <[email-masked]>, <[email-masked]>
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Date: Mon, 6 Mar 2006 07:00:12 -0600
Sender: [email-masked]

Hi, Arnt,

I'm ok with most of your responses - just to follow up on a couple of places 
where my comment may not have been well-explained...

Spencer

From: "Arnt Gulbrandsen" <[email-masked]>

> Spencer Dawkins writes:
>> I was selected as General Area Review Team reviewer for this 
>> specification
>> (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> Is the following text
>> saying, "MAY return either "error" or "no-match" if the input strings are
>> not valid character strings ..."? The current text doesn't seem to say 
>> what
>> happens when the input strings aren't valid and the equality function
>> doesn't return "error", which is only a MAY strength ("so don't be 
>> surprised
>> when your server does this").
>>
>>   The equality function always returns "match" or "no-match" when
>>   supplied valid input, and MAY return "error" if the input strings are
>>   not valid character strings or violate other collation constraints.
>
> I'll have to think about this some more.
>
> The question is, should a collation be required to report "error" for 
> input outside its domain, or should it do whatever comes easiest?

I was thinking about this from the client's perspective (if the collation 
doesn't report "error", how does the client know to report anything to 
someone who might be able to fix the input?).

>> 7.1.  Collation Registration Procedure
>>
>> Spencer: I'm not trying to change existing practice, but the IESG is 
>> having
>> enough fun reviewing appeals these days that if the appeal track started
>> with the APPS area directors, I'm sure that the other ADs would be 
>> thrilled.
>> :-(
>
> I think I see what you're trying to say, but I'm feeling uncertain enough 
> that I'd appreciate some elaboration.
>
> Did you perhaps read the following text as saying that the designated 
> expert needs to be an IESG member?

No, I'm sorry that I wasn't clearer. I was trying to say that if the 
designated expert fumbles the evaluation, perhaps talking to an APPS-area AD 
would be sufficient to resolve most appeals, without involving the rest of 
the IESG, unless the APPS-area AD fumbles the first-level appeal.

If this stuff is already being appealed directly to IESG without a one-AD 
stop, I'm not trying to change anything. Scott, can you inject clue here?

>>   The IETF will create a mailing list, [email-masked], which can be
>>   used for public discussion of collation proposals prior to
>>   registration.  Use of the mailing list is encouraged but not
>>   required.  The actual registration procedure will not begin until the
>>   completed registration template is sent to [email-masked].  The IESG
>>   will appoint a designated expert who will monitor the
>>   [email-masked] mailing list and review registrations forwarded
>>   from IANA.  The designated expert is expected to tell IANA and the
>>   submitter of the registration within two weeks whether the
>>   registration is approved, approved with minor changes, or rejected
>>   with cause.  When a registration is rejected with cause, it can be
>>   re-submitted if the concerns listed in the cause are addressed.
>>   Decisions made by the designated expert can be appealed to the IESG
>>   and subsequently follow the normal appeals procedure for IESG
>>   decisions. 

Date: Thu, 02 Mar 2006 20:23:29 +0000
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Chris Newman <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Thu Mar  2 12:36:38 2006, Arnt Gulbrandsen wrote:
> 1. No way to change comparator within the search command. Simple to 
> implement for servers. Clients must change comparator before/after 
> the search command.
> 
> 
I think this is just too weak. A command to set (and return) a 
default comparator is good.

> 2. Comparator can be set at the start, much like CHARSET. A bit 
> tricky to do in the syntax, if I remember correctly, and saves a 
> roundtrip or two. Otherwise identical to the previous option.
> 
> 
This is what I was suggesting, in case that's not clear.

The syntax to specify this is in IMAP ABNF, I checked - it would look 
like COMPARATOR (i;octet) - the argument to the COMPARATOR search 
option has to be a list.

> 3. A comparator thingy which can go between any two search-keys and 
> which changes the comparator used from that point onwards. (This is 
> what we had, if I remember correctly.)
> 
> 
That's truly vile. I agree with you and Mark.

> 4. A new search-key which takes a comparator name and a search-key, 
> and executes that search-key with that collation.
> 
> 
Okay, this would be best, but I think it's going to be very ugly 
retrofitting this kind of mechanism onto IMAP. There's lots of 
obvious use-cases for it, but I strongly suspect the simpler route to 
go is to allow a Sieve test command to be wrapped in an astring and 
used as a search-key, essentially deprecating the string-orientated 
IMAP search keys. This is probably controversial, and doesn't belong 
in this document.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Thu, 2 Mar 2006 19:49:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-newman-i18n-comparator-07.txt just submitted
Cc: Chris Newman <[email-masked]>, Martin =?iso-8859-1?q?D=FCrst?= <[email-masked]>, Mark Davis <[email-masked]>, [email-masked]
Sender: [email-masked]

---
Content-Type: text/plain; format=flowed

Mark Davis writes:
> Can you send out or post a copy, so we can see it before monday?

Sure. (Some people are awfully sensitive about large list mail, that's 
why I didn't send it right away.)

Arnt

---
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; size=72465;
  filename=draft-newman-i18n-comparator-07.txt

Network Working Group                                          C. Newman
Internet-Draft                                          Sun Microsystems
Expires: September 3, 2006                                     M. Duerst
                                                                     AGU
                                                          A. Gulbrandsen
                                                                    Oryx
                                                           March 2, 2006

            Internet Application Protocol Collation Registry
                  draft-newman-i18n-comparator-07.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Many Internet application protocols include string-based lookup,
   searching, or sorting operations.  However the problem space for
   searching and sorting international strings is large, not fully
   explored, and is outside the area of expertise for the Internet
   Engineering Task Force (IETF).  Rather than attempt to solve such a

Newman, et al.          Expires September 3, 2006               [Page 1]
=0C
Internet-Draft             Collation Registry                 March 2006

   large problem, this specification creates an abstraction framework so
   that application protocols can precisely identify a comparison
   function and the repertoire of comparison functions can be extended
   in the future.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used in this Document  . . . . . . . . . . . .  4
   2.  Collation Definition and Purpose . . . . . . . . . . . . . . .  4
     2.1.  Definition . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Some Other Terms Used in this Document . . . . . . . . . .  5
     2.4.  Sort Keys  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Collation Name Syntax  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Basic Syntax . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Ordering Direction . . . . . . . . . . . . . . . . . . . .  6
     3.4.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.5.  Naming Guidelines  . . . . . . . . . . . . . . . . . . . .  7
   4.  Collation Specification Requirements . . . . . . . . . . . . .  7
     4.1.  API  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Operations Supported . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  Equality . . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.2.  Substring  . . . . . . . . . . . . . . . . . . . . . .  9
       4.2.3.  Ordering . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Internal Canonicalization Algorithm  . . . . . . . . . . . 10
     4.4.  Use of Lookup Tables . . . . . . . . . . . . . . . . . . . 10
     4.5.  Multi-Value Attributes . . . . . . . . . . . . . . . . . . 10
   5.  Application Protocol Requirements  . . . . . . . . . . . . . . 11
     5.1.  Character Encoding . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Operations . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  Canonicalization Function  . . . . . . . . . . . . . . . . 12
     5.5.  Disconnected Clients . . . . . . . . . . . . . . . . . . . 12
     5.6.  Error Codes  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.7.  Octet Collation  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Use by Existing Protocols  . . . . . . . . . . . . . . . . . . 13
   7.  Collation Registration . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Collation Registration Procedure . . . . . . . . . . . . . 13
     7.2.  Collation Registration Format  . . . . . . . . . . . . . . 14
       7.2.1.  Registration Template  . . . . . . . . . . . . . . . . 14
       7.2.2.  The collation Element  . . . . . . . . . . . . . . . . 14
       7.2.3.  The name Element . . . . . . . . . . . . . . . . . . . 15
       7.2.4.  The title Element  . . . . . . . . . . . . . . . . . . 15
       7.2.5.  The functions Element  . . . . . . . . . . . . . . . . 15
       7.2.6.  The specification Element  . . . . . . . . . . . . . . 15

Newman, et al.          Expires September 3, 2006               [Page 2]
=0C
Internet-Draft             Collation Registry                 March 2006

       7.2.7.  The submitter Element  . . . . . . . . . . . . . . . . 15
       7.2.8.  The owner Element  . . . . . . . . . . . . . . . . . . 15
       7.2.9.  The version Element  . . . . . . . . . . . . . . . . . 16
       7.2.10. The UnicodeVersion Element . . . . . . . . . . . . . . 16
       7.2.11. The UCAVersion Element . . . . . . . . . . . . . . . . 16
       7.2.12. The UCAMatchLevel Element  . . . . . . . . . . . . . . 16
     7.3.  DTD for Collation Registration . . . . . . . . . . . . . . 17
     7.4.  Structure of Collation Registry  . . . . . . . . . . . . . 17
     7.5.  Example Initial Registry Summary . . . . . . . . . . . . . 18
   8.  Guidelines for Expert Reviewer . . . . . . . . . . . . . . . . 18
   9.  Initial Collations . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  ASCII Numeric Collation  . . . . . . . . . . . . . . . . . 19
       9.1.1.  ASCII Numeric Collation Description  . . . . . . . . . 19
       9.1.2.  ASCII Numeric Collation Registration . . . . . . . . . 20
     9.2.  ASCII Casemap Collation  . . . . . . . . . . . . . . . . . 20
       9.2.1.  ASCII Casemap Collation Description  . . . . . . . . . 20
       9.2.2.  Legacy English Casemap Collation Registration  . . . . 21
       9.2.3.  English Casemap Collation Registration . . . . . . . . 21
     9.3.  Nameprep Collation . . . . . . . . . . . . . . . . . . . . 21
       9.3.1.  Nameprep Collation Description . . . . . . . . . . . . 21
       9.3.2.  Nameprep Collation Registration  . . . . . . . . . . . 22
     9.4.  Basic Collation  . . . . . . . . . . . . . . . . . . . . . 22
       9.4.1.  Basic Collation Description  . . . . . . . . . . . . . 22
       9.4.2.  Basic Collation Registration . . . . . . . . . . . . . 24
       9.4.3.  Basic Accent Sensitive Match Collation Registration  . 25
       9.4.4.  Basic Case Sensitive Match Collation Registration  . . 25
     9.5.  Octet Collation  . . . . . . . . . . . . . . . . . . . . . 25
       9.5.1.  Octet Collation Description  . . . . . . . . . . . . . 25
       9.5.2.  Octet Collation Registration . . . . . . . . . . . . . 26
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   12. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 27
   13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     13.1. Changes From -06 . . . . . . . . . . . . . . . . . . . . . 27
     13.2. Changes From -05 . . . . . . . . . . . . . . . . . . . . . 28
     13.3. Changes From -04 . . . . . . . . . . . . . . . . . . . . . 28
     13.4. Changes From -03 . . . . . . . . . . . . . . . . . . . . . 28
     13.5. Changes From -02 . . . . . . . . . . . . . . . . . . . . . 29
     13.6. Changes From -01 . . . . . . . . . . . . . . . . . . . . . 29
     13.7. Changes From -00 . . . . . . . . . . . . . . . . . . . . . 29
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 30
     14.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33

Newman, et al.          Expires September 3, 2006               [Page 3]
=0C
Internet-Draft             Collation Registry                 March 2006

1.  Introduction

   The ACAP [12] specification introduced the concept of a comparator
   (which we call collation in this document), but failed to create an
   IANA registry.  With the introduction of stringprep [6] and the
   Unicode Collation Algorithm [8], it is now time to create that
   registry and populate it with some initial values appropriate for an
   international community.  This specification replaces and generalizes
   the definition of a comparator in ACAP and creates a collation
   registry.

1.1.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [1].

   The attribute syntax specifications use the Augmented Backus-Naur
   Form (ABNF) [2] notation including the core rules defined in Appendix
   A. This also inherits ABNF rules from Language Tags [5].

2.  Collation Definition and Purpose

2.1.  Definition

   A collation is a named function which takes two arbitrary length
   strings as input and can be used to perform one or more of three
   basic comparison operations: equality test, substring match, and
   ordering test.

2.2.  Purpose

   Collations provide a multi-protocol abstraction layer for comparison
   functions so the details of a particular comparison operation can be
   specified by someone with appropriate expertise independent of the
   application protocol that consumes that collation.  This is similar
   to the way a charset [14] separates the details of octet to character
   mapping from a protocol specification such as MIME [10] or the way
   SASL [11] separates the details of an authentication mechanism from a
   protocol specification such as ACAP [12].

Newman, et al.          Expires September 3, 2006               [Page 4]
=0C
Internet-Draft             Collation Registry                 March 2006

   Here is a small diagram to help illustrate the value of this
   abstraction layer:

   +-------------------+                         +-----------------+
   | IMAP i18n SEARCH  |--+                      | Basic           |
   +-------------------+  |                   +--| Collation Spec  |
                          |                   |  +-----------------+
   +-------------------+  |  +-------------+  |  +-----------------+
   | ACAP i18n SEARCH  |--+--| Collation   |--+--| A stringprep    |
   +-------------------+  |  | Registry    |  |  | Collation Spec  |
                          |  +-------------+  |  +-----------------+
   +-------------------+  |                   |  +-----------------+
   | ...other protocol |--+                   |  | locale-specific |
   +-------------------+                      +--| Collation Spec  |
                                                 +-----------------+

   Thus IMAP, ACAP and future application protocols with international
   search capability simply specify how to interface to the collation
   registry instead of each protocol specification having to specify all
   the collations it supports.

2.3.  Some Other Terms Used in this Document

   The terms client, server and protocol are used in somewhat unusual
   senses.

   Client means a user, or a program acting directly on behalf of a
   user.  This may be an mail reader acting as an IMAP client, or it may
   be an interactive shell where the user can type protocol directly, or
   it may be a script or program written by the user.

   Server means a program that performs services requested by the
   client.  This may be a traditional server such as an HTTP server, or
   it may be a Sieve [15] interpreter running a Sieve script written by
   a user.  A server needs to use the operations provided by collations
   in order to fulfil the client's requests.

   The protocol describes how the client informs the server what it
   wants done, and (if applicable) how the server tells the client about
   the results.  IMAP is a protocol by this definition, and so is the
   Sieve language.

2.4.  Sort Keys

   One component of a collation is a transformation which turns a string
   into a sort key, which is then used while sorting.

   The transformation can range from an identity mapping (e.g., the

Newman, et al.          Expires September 3, 2006               [Page 5]
=0C
Internet-Draft             Collation Registry                 March 2006

   i;octet collation Section 9.5) to a mapping which makes the string
   unreadable to a human (e.g., the basic collation Section 9.4).

   This is an implementation detail of collations or servers.  A
   protocol SHOULD NOT expose it, since some collations leave the sort
   key's format up to the implementation, and current conformant
   implementations are known to use different formats.

3.  Collation Name Syntax

3.1.  Basic Syntax

   The collation name itself is a single US-ASCII string beginning with
   a letter and made up of letters, digits, or one of the following 4
   symbols: "-", ";", "=3D" or ".".  The name MUST NOT be longer than 254
   characters.

     collation-char  =3D  ALPHA / DIGIT / "-" / ";" / "=3D" / "."

     collation-name  =3D  ALPHA *253collation-char

3.2.  Wildcards

   The string a client uses to select a collation MAY contain a wildcard
   ("*") character which matches zero or more collation-chars.  Wildcard
   characters MUST NOT be adjacent.  If the wildcard string matches
   multiple collations, the server SHOULD select the collation with the
   broadest scope (preferably international scope), the most recent
   table versions and the greatest number of supported operations.

     collation-wild  =3D  ("*" / (ALPHA ["*"])) *(collation-char ["*"])
                         ; MUST NOT exceed 254 characters total

3.3.  Ordering Direction

   When used as a protocol element for ordering, the collation name MAY
   be prefixed by either "+" or "-" to explicitly specify an ordering
   direction.  As mentioned previously, "+" has no effect on the
   ordering operation, while "-" negates the result of the ordering
   operation.  In general, collation-order is used when a client
   requests a collation, and collation-sel is used when the server
   informs the client of the selected collation.

     collation-sel   =3D  ["+" / "-"] collation-name

     collation-order =3D  ["+" / "-"] collation-wild

Newman, et al.          Expires September 3, 2006               [Page 6]
=0C
Internet-Draft             Collation Registry                 March 2006

3.4.  URIs

   Some protocols are designed to use URIs [4] to refer to collations
   rather than simple tokens.  A special section of the IANA web page is
   reserved for such usage.  The "collation-uri" form is used to refer
   to a specific IANA registry entry for a specific named collation (the
   collation registration may not actually be present if it is
   experimental).  The "collation-auri" form is an abstract name for an
   ordering, a collation pattern or a vendor private collatorn.

     collation-uri   =3D  "http://www.iana.org/assignments/collation/"
                        collation-name ".xml"

     collation-auri  =3D  ( "http://www.iana.org/assignments/collation/"
                        collation-order [".xml"]) / other-uri

     other-uri       =3D  <absoluteURI>
                     ;  excluding the IANA collation namespace.

3.5.  Naming Guidelines

   While this specification makes no absolute requirements on the
   structure of collation names, naming consistency is important, so the
   following initial guidelines are provided.

   Collation names with an international audience typically begin with
   "i;".  Collation names intended for a particular language or locale
   typically begin with a language tag [5] followed by a ";".  After the
   first ";" is normally the name of the general collation algorithm,
   followed by a series of algorithm modifications separated by the ";"
   delimiter.  Parameterized modifications will use "=3D" to delimit the
   parameter from the value.  The version numbers of any lookup tables
   used by the algorithm SHOULD be present as parameterized
   modifications.

   Collation names of the form *;vnd-domain.com;* are reserved for
   vendor-specific collations created by the owner of the domain name
   following the "vnd-" prefix (e.g. vnd-example.com for the vendor
   example.com).  Registration of such collations (or the name space as
   a whole) with intended use of "Vendor" is encouraged when a public
   specification or open-source implementation is available, but is not
   required.

4.  Collation Specification Requirements

Newman, et al.          Expires September 3, 2006               [Page 7]
=0C
Internet-Draft             Collation Registry                 March 2006

4.1.  API

   The collation itself decides what it operates on.  Most collations
   are expected to operate on character strings.  The i;octet
   (Section 9.5) collation operates on octet strings.  The i;ascii-
   numeric (Section 9.1) operation operates on numbers.

   This specification defines the collation interface in terms of octet
   strings, however, implementations may choose to use character strings
   instead.  Such implementations may not be able to implement e.g.
   i;octet.  Since i;octet is not currently mandatory to implement for
   any protocol, this should not be a problem.

4.2.  Operations Supported

   A collation specification MUST state which of the three basic
   operations are supported (equality, substring, ordering) and how to
   perform each of the supported operations on any two input character
   strings including empty strings.  Collations must be deterministic,
   i.e. given a collation with a specific name, and any two fixed input
   strings, the result MUST be the same for the same operation.

   In general, collation operations should behave as their names
   suggest.  While a collation may be new, the operations are not, so
   the new collation's algorithm for each operation should be as similar
   as possible to those of older collations.  For example, a collation
   should not provide a "substring" operator that would morph IMAP
   substring SEARCH into another kind of search.

   Note that for any single collation, either none or all of the
   operations can return "error".  For example, it is not possible to
   have an equality operator that never returns "error" and a substring
   operator that occasionally does.

4.2.1.  Equality

   The equality test always returns "match" or "no-match" when supplied
   valid input, and MAY return "error" if one or both input strings are
   not valid character strings or violate other collation constraints.

   The equality test MUST be reflexive, symmetric and transitive.

   If a collation provides either a substring or an ordering test, it
   MUST also provide an equality test.  The substring and/or ordering
   tests MUST be consistent with the equality test.

   In this specification, the return values of the equality test are
   called "match", "no-match" and "error".  This is not a specification,

Newman, et al.          Expires September 3, 2006               [Page 8]
=0C
Internet-Draft             Collation Registry                 March 2006

   merely a choice of phrasing.

4.2.2.  Substring

   The substring matching operation determines if the first string is a
   substring of the second string, ie. if the second string contains any
   string which is equal to the first, as defined by the collation's
   equality operator.

   A collation which supports substring matching will automatically
   support two special cases of substring matching: prefix and suffix
   matching if those special cases are supported by the application
   protocol.  It returns "match" or "no-match" when supplied valid input
   and returns "error" when supplied invalid input.

   Application protocols MAY return position information for substring
   matches.  If this is done, the position information SHOULD include
   both the starting offset and the ending offset for each match.  All
   matching substrings should be reported, even overlapping matches.

   A string is a substring of itself.  The empty string is a substring
   of all strings.  "Contain" is not defined by this specification.

   Note that the substring operation of some collations can match
   strings of unequal length.  For example, a pre-composed accented
   character can match a decomposed accented character.  Unicode
   Collation Algorithm [8] discusses this in more detail.

   In this specification, the return values of the substring operator
   are called "match", "no-match" and "error".  This is not a
   specification, merely a choice of phrasing.

4.2.3.  Ordering

   The ordering operator determines how two character strings are
   ordered.  It MUST be transitive and trichotomous.

   Ordering returns "less" if the first string is listed before the
   second string according to the collation, "greater" if the second
   string is listed before the first string, and "equal" if the two
   strings are equal as defined by the collation's equality operator.
   If the order of the two strings is reversed, the result of the
   ordering operator of the collation MUST be reversed, i.e. results
   which would be "greater" are instead "less" and results which would
   be "less" are instead "greater", while results which would be "equal"
   stay "equal".

   Since ordering is normally used to sort a list of items, "error" is

Newman, et al.          Expires September 3, 2006               [Page 9]
=0C
Internet-Draft             Collation Registry                 March 2006

   not a useful return value from the ordering operator.  Strings with
   errors that prevent the sorting algorithm from functioning correctly
   should sort to the end of the list.  Thus if the first string is
   invalid while the second string is valid, the result will be
   "greater".  If the second string is invalid while the first string is
   valid, the result will be "less".  If both strings are invalid, the
   result SHOULD match the result from the "i;octet" collation.

   When the collation is used with a "+" prefix, the behavior is the
   same as when used with no prefix.  When the collation is used with a
   "-" prefix, the result of the ordering operator of the collation MUST
   be reversed.

   In this specification, the return values of the ordering operator are
   called "less", "equal", "greater" and "error".  This is not a
   specification, merely a choice of phrasing.

4.3.  Internal Canonicalization Algorithm

   A collation specification MUST describe the internal canonicalization
   algorithm.  This algorithm can be applied to individual strings and
   the result can be stored to potentially optimize future comparison
   operations.  A collation MAY specify that the canonicalization
   algorithm is the identity function.  The output of the
   canonicalization algorithm MAY have no meaning to a human.

4.4.  Use of Lookup Tables

   Collations which use more than one customizable lookup table in a
   documented format MUST assign numbers to the tables they use.  This
   permits an application protocol command to access the tables used by
   a server collation.

4.5.  Multi-Value Attributes

   Some application protocols will permit the use of multi-value
   attributes with a collation.  This paragraph describes the rules that
   apply unless otherwise specified by the collation or application
   protocol.  In the case of the equality and substring operation, the
   operations are applied over each pair of single values from the two
   inputs.  If any combination produces an error, the result is an
   error.  Otherwise, if any combination produces a "match", the result
   is a match.  Otherwise the result is "no-match".  For the ordering
   operator, the smallest ordinal character string from the first set of
   values is compared to the smallest ordinal character string from the
   second set of values.

Newman, et al.          Expires September 3, 2006              [Page 10]
=0C
Internet-Draft             Collation Registry                 March 2006

5.  Application Protocol Requirements

   This section describes the requirements and issues that an
   application protocol needs to consider if it offers searching,
   substring matching and/or sorting, and permits the use of characters
   outside the US-ASCII charset.

5.1.  Character Encoding

   The protocol specification has to make sure that it is clear on which
   characters (rather than just octets) the collations are used.  This
   can be done by specifying the protocol itself in terms of characters
   (e.g. in the case of a query language), by specifying a single
   character encoding for the protocol (e.g.  UTF-8 [3]), or by
   carefully describing the relevant issues of character encoding
   labeling and conversion.  In the later case, details to consider
   include how to handle unknown charsets, any charsets which are
   mandatory-to-implement, any issues with byte-order that might apply,
   and any transfer encodings which need to be supported.

5.2.  Operations

   The protocol must specify which of the operations defined in this
   specification (equality matching, substring matching and ordering)
   can be invoked in the protocol, and how they are invoked.  There may
   be more than one way to invoke an operation.

   The protocol MUST provide a mechanism for the client to select the
   collation to use with equality matching, substring matching and
   ordering.

   If the protocol provides positional information for the results of a
   substring match, that positional information SHOULD fully specify the
   substring in the result that matches independent of the length of the
   search string.  For example, returning both the starting and ending
   offset of the match would suffice, as would the starting offset and a
   length.  Returning just the starting offset is not acceptable.  This
   rule is necessary because advanced collations can treat strings of
   different lengths as equal (for example, pre-composed and decomposed
   accented characters).

5.3.  Wildcards

   The protocol MUST specify whether it allows the use of wildcards in
   collation identifiers or not.  If the protocol allows wildcards,
   then:

Newman, et al.          Expires September 3, 2006              [Page 11]
=0C
Internet-Draft             Collation Registry                 March 2006

      The protocol MUST specify how comparisons behave in the absence of
      explicit collation negotiation or when a collation of "*" is
      requested.  The protocol MAY specify that the default collation
      used in such circumstances is sensitive to server configuration.
      The protocol SHOULD provide a way to list available collations
      matching a given wildcard pattern or patterns.

5.4.  Canonicalization Function

   If the protocol uses a canonicalization function for strings, then
   use of collations MAY be appropriate for that function.  As an
   example, many protocols use case independent strings.  In most cases,
   a simple ASCII mapping to upper/lower case works well.  However, in
   some cases a collation may be better, e.g. to handle Turkish dotted/
   dotless i.

5.5.  Disconnected Clients

   If the protocol supports disconnected clients, then a mechanism for
   the client to precisely replicate the server's collation algorithm is
   likely desirable.  Thus the protocol MAY wish to provide a command to
   fetch lookup tables used by charset conversions and collations.

5.6.  Error Codes

   The protocol specification should consider assigning protocol error
   codes for the following circumstances:
   o  The client requests the use of a collation by name or pattern, but
      no implemented collation matches that pattern.
   o  The client attempts to use a collation for an operation that is
      not supported by that collation.  For example, attempting to use
      the "i;ascii-numeric" collation for substring matching.
   o  The client uses an equality or substring matching collation and
      the result is an error.  It may be appropriate to distinguish
      between the two input strings, particularly when one is supplied
      by the client and one is stored by the server.  It might also be
      appropriate to distinguish the specific case of an invalid UTF-8
      string.

5.7.  Octet Collation

   The i;octet (Section 9.5) collation is only usable with protocols
   based on octet-strings.  Clients and servers MUST NOT use i;octet
   with other protocols.

   If the protocol permits the use of collations with data structures
   other than strings, the protocol MUST describe the default behavior
   for a collation with that data structure.

Newman, et al.          Expires September 3, 2006              [Page 12]
=0C
Internet-Draft             Collation Registry                 March 2006

6.  Use by Existing Protocols

   Both ACAP [12] and Sieve [15] are standards track specifications
   which used collations prior to the creation of this specification and
   registry.  Those standards do not meet all the application protocol
   requirements described in Section 5.  For backwards compatibility,
   those protocols use the "i;ascii-casemap" instead of "en;ascii-
   casemap".  These protocols allow the use of the i;octet (Section 9.5)
   collation working directly on UTF-8 data as used in these protocols.

   IMAP [16] also uses collation, although the use is explicit only when
   the COMPARATOR [18] extension is used.  The built-in IMAP substring
   operation and the ordering provided by the SORT [17] extension may
   not meet the requirements made in this document.

   Other protocols may be in a similar position.

7.  Collation Registration

7.1.  Collation Registration Procedure

   The IETF will create a mailing list, [email-masked], which can be
   used for public discussion of collation proposals prior to
   registration.  Use of the mailing list is encouraged but not
   required.  The actual registration procedure will not begin until the
   completed registration template is sent to [email-masked].  The IESG
   will appoint a designated expert who will monitor the
   [email-masked] mailing list and review registrations forwarded
   from IANA.  The designated expert is expected to tell IANA and the
   submitter of the registration within two weeks whether the
   registration is approved, approved with minor changes, or rejected
   with cause.  When a registration is rejected with cause, it can be
   re-submitted if the concerns listed in the cause are addressed.
   Decisions made by the designated expert can be appealed to the IESG
   and subsequently follow the normal appeals procedure for IESG
   decisions.

   Collation registrations in a standards track, BCP or IESG-approved
   experimental RFC are owned by the IETF, and changes to the
   registration follow normal procedures for updating such documents.
   Collation registrations in other RFCs are owned by the RFC author(s).
   Other collation registrations are owned by the individual(s) listed
   in the contact field of the registration and IANA will preserve this
   information.  Changes to a registration MUST be approved by the
   owner.  In the event the owner cannot be contacted for a period of
   one month and a change is deemed necessary, the IESG MAY re-assign
   ownership to an appropriate party.

Newman, et al.          Expires September 3, 2006              [Page 13]
=0C
Internet-Draft             Collation Registry                 March 2006

7.2.  Collation Registration Format

   Registration of a collation is done by sending a well-formed XML
   document that validates with collationreg.dtd (Section 7.3).

7.2.1.  Registration Template

   Here is a template for the registration:

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"YYYY" scope=3D"i18n" intendedUse=3D"common">
     <name>collation name</name>
     <title>technical title for collation</title>
     <functions>equality order substring</functions>
     <specification>specification reference</specification>
     <owner>email address of owner or IETF</owner>
     <submitter>email address of submitter<submitter>
     <version>1</version>
     <UnicodeVersion>3.2</UnicodeVersion>
     <UCAVersion>3.1.1</UCAVersion>
   </collation>

7.2.2.  The collation Element

   The root of the registration document MUST be a <collation> element.
   The collation element contains the other elements in the
   registration, which are described in the following sub-subsections,
   in the order given here.

   The <collation> element MAY include an "rfc=3D" attribute if the
   specification is in an RFC.  The "rfc=3D" attribute gives only the
   number of the RFC, without any prefix, such as "RFC", or suffix, such
   as ".txt".

   The <collation> element MUST include a "scope=3D" attribute, which MUST
   have one of the values "i18n", "local" or "other".

   The <collation> element MUST include an "intendedUse=3D" attribute,
   which must have one of the values "common", "limited", "vendor", or
   "deprecated".  Collation specifications intended for "common" use are
   expected to reference standards from standards bodies with
   significant experience dealing with the details of international
   character sets.

   Be aware that future revisions of this specification may add
   additional function types, as well as additional XML attributes and
   values.  Any system which automatically parses these XML documents

Newman, et al.          Expires September 3, 2006              [Page 14]
=0C
Internet-Draft             Collation Registry                 March 2006

   MUST take this into account to preserve future compatibility.  A DTD
   for the current definition of the collation registration template is
   given in Section 7.3.

7.2.3.  The name Element

   The <name> element gives the precise name of the collation.  The
   <name> element is mandatory.

7.2.4.  The title Element

   The <title> element gives the title of the collation.  The <title>
   element is mandatory.

7.2.5.  The functions Element

   The <functions> element lists which of the three operators
   ("equality", "order" or "substring") the collation provides.  The
   <functions> element is mandatory.

7.2.6.  The specification Element

   The <specification> element describes where to find the
   specification.  The <specification> element is mandatory.  It MAY
   have a URI attribute.  There may be more than one <specification>
   elements.  (For example, a collation which has previously been
   specified by a vendor may have been published on that vendor's web
   site, and subsequently by a standards organization.)

   In case the different specifications differ, the RFC is the
   definitive specification.

7.2.7.  The submitter Element

   The <submitter> element provides an RFC 2822 [13] email address for
   the person who submitted the registration.  It is optional if the
   <owner> element contains an email address.

   There may be more than one <submitter> element.

7.2.8.  The owner Element

   The <owner> element contains either the four letters "IETF" or an
   email address of the owner of the registration.  The <owner> element
   is mandatory.  There may be more than one <owner> element.  If so,
   all owners are equal.  Each owner can speak for all.

Newman, et al.          Expires September 3, 2006              [Page 15]
=0C
Internet-Draft             Collation Registry                 March 2006

7.2.9.  The version Element

   The <version> element is included when the registration is likely to
   be revised or has been revised in such a way that the results change
   for certain input strings.  The <version> element is optional.

7.2.10.  The UnicodeVersion Element

   The <UnicodeVersion> element indicates the version number of the
   UnicodeData file on which the collation is based.  The
   <UnicodeVersion> element is optional.

7.2.11.  The UCAVersion Element

   The <UCAVersion> element specifics the version of the Unicode
   Collation Algorithm on which the collation is based.  The
   <UCAVersion> element is optional.

7.2.12.  The UCAMatchLevel Element

   The <UCAMatchLevel> element specifies the number of Unicode Collation
   Algorithm sort key levels used for the equality and substring
   operations.  The <UCAMatchLevel> element is optional.

Newman, et al.          Expires September 3, 2006              [Page 16]
=0C
Internet-Draft             Collation Registry                 March 2006

7.3.  DTD for Collation Registration

   <!-
     DTD for Collation Registration Document

     Data types:

     entity      description
     =3D=3D=3D=3D=3D=3D      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     NUMBER      [0-9]+
     URI         As defined in RFC 3986
     CTEXT       printable ASCII text (no line-terminators)
     TEXT        character data
     ->
   <!ENTITY % NUMBER        "CDATA">
   <!ENTITY % URI           "CDATA">
   <!ENTITY % CTEXT         "#PCDATA">
   <!ENTITY % TEXT          "#PCDATA">
   <!ELEMENT collation      (name,title,functions,specification+,owner+,
                             submitter*,version?,UnicodeVersion?,
                             UCAVersion?,UCAMatchLevel?)>
   <!ATTLIST collation
             rfc            %NUMBER;                           "0"
             scope          (i18n|local|other)                 #IMPLIED
             intendedUse    (common|limited|vendor|deprecated) #IMPLIED>
   <!ELEMENT name           (%CTEXT;)>
   <!ELEMENT title          (%CTEXT;)>
   <!ELEMENT functions      (%CTEXT;)>
   <!ELEMENT specification  (%TEXT;)>
   <!ATTLIST specification
             uri            %URI;                              "">
   <!ELEMENT owner          (%CTEXT;)>
   <!ELEMENT submitter      (%CTEXT;)>
   <!ELEMENT version        (%CTEXT;)>
   <!ELEMENT UnicodeVersion (%CTEXT;)>
   <!ELEMENT UCAVersion     (%CTEXT;)>
   <!ELEMENT UCAMatchLevel  (%CTEXT;)>

7.4.  Structure of Collation Registry

   Once the registration is approved, IANA will store each XML
   registration document in a URL of the form
   http://www.iana.org/assignments/collation/collation-name.xml where
   collation-name is the contents of the name element in the
   registration.  Both the submitter and the designated expert is
   responsible for verifying that the XML is well-formed and complies
   with the DTD.

Newman, et al.          Expires September 3, 2006              [Page 17]
=0C
Internet-Draft             Collation Registry                 March 2006

   IANA will also maintain a text summary of the registry under the name
   http://www.iana.org/assignments/collation/summary.txt.  This summary
   is divided into four sections.  The first section is for collations
   intended for common use.  This section is intended for collation
   registrations published in IESG approved RFCs or for locally scoped
   collations from the primary standards body for that locale.  The
   designated expert is encouraged to reject collation registrations
   with an intended use of "common" if the expert believes it should be
   "limited", as it is desirable to keep the number of "common"
   registrations small and high quality.  The second section is reserved
   for limited use collations.  The third section is reserved for
   registered vendor specific collations.  The final section is reserved
   for deprecated collations.

7.5.  Example Initial Registry Summary

   The following is an example of how IANA might structure the initial
   registry summary.txt file:

     Collation                              Functions Scope Reference
     ---------                              --------- ----- ---------
   Common Use Collations:
     i;nameprep;v=3D1;uv=3D3.2                  e, o, s   i18n  [RFC XXXX]
     i;basic;uca=3D3.1.1;uv=3D3.2               e, o, s   i18n  [RFC XXXX]
     i;basic;uca=3D3.1.1;uv=3D3.2;match=3Daccent  e, o, s   i18n  [RFC XXXX]
     i;basic;uca=3D3.1.1;uv=3D3.2;match=3Dcase    e, o, s   i18n  [RFC XXXX]
     en;ascii-casemap                       e, o, s   Local [RFC XXXX]

   Limited Use Collations:
     i;octet                                e, o, s   Other [RFC XXXX]
     i;ascii-numeric                        e, o      Other [RFC XXXX]

   Vendor Collations:

   Deprecated Collations:
     i;ascii-casemap                        e, o, s   Local [RFC XXXX]

   References
   ----------
   [RFC XXXX]  Newman, C., "Internet Application Protocol Collation
               Registry", RFC XXXX, Sun Microsystems, October 2003.

8.  Guidelines for Expert Reviewer

   The expert reviewer appointed by the IESG has fairly broad latitude
   for this registry.  While a number of collations are expected

Newman, et al.          Expires September 3, 2006              [Page 18]
=0C
Internet-Draft             Collation Registry                 March 2006

   (particularly customizations of the basic collation for localized
   use), an explosion of collations (particularly common use collations)
   is not desirable for widespread interoperability.  However, it is
   important for the expert reviewer to provide cause when rejecting a
   registration, and when possible to describe corrective action to
   permit the registration to proceed.  The following table includes
   some example reasons to reject a registration with cause:
   o  The registration is not a well-formed XML document that follows
      the DTD.
   o  The registration has an intended use of "common", but there is no
      evidence the collation will be widely deployed, so it should be
      listed as "limited".
   o  The registration has an intended use of "common", but it is
      redundant with the functionality of a previously registered
      "common" collation.
   o  The registration has an intended use of "common", but the
      specification is not detailed enough to allow interoperable
      implementations by others.
   o  The collation name fails to precisely identify the version numbers
      of relevant tables to use.
   o  The registration fails to meet one of the "MUST" requirements in
      Section 4.
   o  The collation name fails to meet the syntax in Section 3.
   o  The collation specification referenced in the registration is
      vague or has optional features without a clear behavior specified.
   o  The referenced specification does not adequately address security
      considerations specific to that collation.
   o  The regitration's operations are needlessly different from those
      of traditional operations.

9.  Initial Collations

   This section describes an initial set of collations for the collation
   registry.

9.1.  ASCII Numeric Collation

9.1.1.  ASCII Numeric Collation Description

   The "i;ascii-numeric" collation is a simple collation intended for
   use with arbitrary sized unsigned decimal integer numbers stored as
   octet strings of US-ASCII digits (0x30 to 0x39).  It supports
   equality and ordering, but does not support the substring operator.

   The equality operator returns "match" if the two strings represent
   the same number (ie. leading zeroes are disregarded), "no-match" if
   the two strings represent different numbers, and "error" if either

Newman, et al.          Expires September 3, 2006              [Page 19]
=0C
Internet-Draft             Collation Registry                 March 2006

   string is empty or contains nondigits.

   The ordering operator returns "less" if the first string represents a
   smaller number than the second, "equal" if they represent the same
   number, and "greater" if the first string represents a larger number
   than the second.  If either string is empty or contains nondigits,
   the ordering operator returns the result of the i;octet ordering
   function.

   The associated canonicalization algorithm is to truncate the input
   string at the first non-digit character.

9.1.2.  ASCII Numeric Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"other" intendedUse=3D"limited">
     <name>i;ascii-numeric</name>
     <title>ASCII Numeric</title>
     <functions>equality order</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
   </collation>

9.2.  ASCII Casemap Collation

9.2.1.  ASCII Casemap Collation Description

   The "en;ascii-casemap" collation is a simple collation intended for
   use with English language text in pure US-ASCII.  It provides
   equality, substring and ordering operators.  The algorithm first
   applies a canonicalization algorithm to both input strings which
   subtracts 32 (0x20) from all octet values between 97 (0x61) and 122
   (0x7A) inclusive.  The result of the collation is then the same as
   the result of the "i;octet" collation for the canonicalized strings.
   Care should be taken when using OS-supplied functions to implement
   this collation as this is not locale sensitive, but functions such as
   strcasecmp and toupper are sometimes locale sensitive.

   For historical reasons, in the context of ACAP and Sieve, the name
   "i;ascii-casemap" is a synonym for this collation.

Newman, et al.          Expires September 3, 2006              [Page 20]
=0C
Internet-Draft             Collation Registry                 March 2006

9.2.2.  Legacy English Casemap Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"local" intendedUse=3D"deprecated">
     <name>i;ascii-casemap</name>
     <title>Legacy English Casemap</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
   </collation>

9.2.3.  English Casemap Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"local" intendedUse=3D"common">
     <name>en;ascii-casemap</name>
     <title>English Casemap</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
   </collation>

9.3.  Nameprep Collation

9.3.1.  Nameprep Collation Description

   The "i;nameprep;v=3D1;uv=3D3.2" collation is an implementation of the
   nameprep [7] specification based on normalization tables from Unicode
   version 3.2.  This collation applies the nameprep canoncialization
   function to both input strings and then returns the result of the
   i;octet collation on the canonicalized strings.  While this collation
   offers all three operators, the ordering operator it provides is
   inadequate for use by the majority of the world.

   Version number 1 is applied to nameprep as specified in RFC 3491.  If
   the nameprep specification is revised without any changes that would
   produce different results when given the same pair of input octet
   strings, then the version number will remain unchanged.

Newman, et al.          Expires September 3, 2006              [Page 21]
=0C
Internet-Draft             Collation Registry                 March 2006

       The table numbers for tables used by nameprep are as follows:

                 +--------------+-----------------------+
                 | Table Number | Table Name            |
                 +--------------+-----------------------+
                 |            1 | UnicodeData-3.2.0.txt |
                 |            2 | Table B.1             |
                 |            3 | Table B.2             |
                 |            4 | Table C.1.2           |
                 |            5 | Table C.2.2           |
                 |            6 | Table C.3             |
                 |            7 | Table C.4             |
                 |            8 | Table C.5             |
                 |            9 | Table C.6             |
                 |           10 | Table C.7             |
                 |           11 | Table C.8             |
                 |           12 | Table C.9             |
                 +--------------+-----------------------+

9.3.2.  Nameprep Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"common">
     <name>i;nameprep;v=3D1;uv=3D3.2</name>
     <title>Nameprep</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
     <version>1</version>
     <UnicodeVersion>3.2</UnicodeVersion>
   </collation>

9.4.  Basic Collation

9.4.1.  Basic Collation Description

   The basic collation is intended to provide tolerable results for a
   number of languages for all three operators (equality, substring and
   ordering) so it is suitable as a mandatory-to-implement collation for
   protocols which include ordering support.  The ordering operator of
   the basic collation is the Unicode Collation Algorithm [8] version 9
   (UCAv9).

   The equality and substring operators are created as described in
   UCAv9 section 8.  While that section is informative to UCAv9, it is
   normative to this collation specification.

Newman, et al.          Expires September 3, 2006              [Page 22]
=0C
Internet-Draft             Collation Registry                 March 2006

   This collation is based on Unicode version 3.2, with the following
   tables relevant:
   1.  For the normalization step,
       <http://www.unicode.org/Public/3.2-Update/UnicodeData-3.2.0.txt>
       is used.  Column 5 is used to determine the canonical
       decomposition, while column 3 contains the canonical combining
       classes necessary to attain canonical order.
   2.  The table of characters which require a logical order exception
       is a subset of the table in
       <http://www.unicode.org/Public/3.2-Update/PropList-3.2.0.txt> and
       is included here:

   0E40..0E44    ; Logical_Order_Exception
   # Lo   [5] THAI CHARACTER SARA E..THAI CHARACTER SARA AI MAIMALAI
   0EC0..0EC4    ; Logical_Order_Exception
   # Lo   [5] LAO VOWEL SIGN E..LAO VOWEL SIGN AI

   # Total code points: 10

   3.  The table used to translate normalized code points to a sort key
       is <http://www.unicode.org/reports/tr10/allkeys-3.1.1.txt>.

   UCAv9 includes a number of configurable parameters and steps labelled
   as potentially optional.  The following list summarizes the defaults
   used by this collation:
   o  The logical order exception step is mandatory by default to
      support the largest number of languages.
   o  Steps 2.1.1 to 2.1.3 are mandatory as the repertoire of the basic
      collation is intended to be large.
   o  The second level in the sort key is evaluated forwards by default.
   o  The variable weighting uses the "non-ignorable" option by default.
   o  The semi-stable option is not used by default.
   o  Support for exactly three levels of collation is the default
      behavior.
   o  No preprocessing step is used by the basic collation prior to
      applying the UCAv9 algorithm.  Note that an application protocol
      specification MAY require pre-processing prior to the use of any
      collations.
   o  The equality and substring algorithms exclude differences at level
      2 and 3 by default (thus it is case-insensitive and ignores
      accentual distinctions.
   o  The equality and substring algorithms use the "Whole Characters
      Only" feature described in UCAv9 section 8 by default.

   The exact collation name with these defaults is
   "i;basic;uca=3D3.1.1;uv=3D3.2".  When a specification states that the
   basic collation is mandatory-to-implement, only this specific name is
   mandatory-to-implement.

Newman, et al.          Expires September 3, 2006              [Page 23]
=0C
Internet-Draft             Collation Registry                 March 2006

   In order to allow modification of the optional behaviors, the
   following ABNF is used for variations of the basic collation:

     basic-collation  =3D  ("i" / Language-Tag) ";basic;uca=3D3.1.1;uv=3D3.=
2"
                         [";match=3Daccent" / ";match=3Dcase"]
                         [";tailor=3D" 1*collation-char ]

   If multiple modifiers appear, they MUST appear in the order described
   above.  The modifiers have the following meanings:
   match=3Daccent   Both the first and second levels of the sort keys are
                  considered relevant to the equality and substring
                  operations (rather than the default of first level
                  only).  This makes the matching functions sensitive to
                  accentual distinctions.
   match=3Dcase     The first three levels of sort keys are considered
                  relevant to the equality and substring operations.
                  This makes the matching functions sensitive to both
                  case and accentual distinctions.

   The default weighting option is "non-ignorable".  The "semi-stable"
   sort key option is not used by default.

   The canonicalization algorithm associated with this collation is the
   output of step 3 of the UCAv9 algorithm (described in section 4.3 of
   the UCA specification).  This canonicalization is not suitable for
   human consumption.

   Finally, the UCAv9 algorithm permits the "allkeys" table to be
   tailored to a language.  People who make quality tailorings are
   encouraged to register those tailorings using the collation registry.
   Tailoring names beginning with "x" are reserved for experimental use,
   are treated as "Limited use" and MUST NOT match wildcards if any
   registered collation is available that does match.

9.4.2.  Basic Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"common">
     <name>i;basic;uca=3D3.1.1;uv=3D3.2</name>
     <title>Basic</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
     <UnicodeVersion>3.2</UnicodeVersion>
     <UCAVersion>3.1.1</UCAVersion>
     <UCAMatchLevel>1</UCAMatchLevel>

Newman, et al.          Expires September 3, 2006              [Page 24]
=0C
Internet-Draft             Collation Registry                 March 2006

   </collation>

9.4.3.  Basic Accent Sensitive Match Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"common">
     <name>i;basic;uca=3D3.1.1;uv=3D3.2;match=3Daccent</name>
     <title>Basic Accent Sensitive Match</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
     <UnicodeVersion>3.2</UnicodeVersion>
     <UCAVersion>3.1.1</UCAVersion>
     <UCAMatchLevel>2</UCAMatchLevel>
   </collation>

9.4.4.  Basic Case Sensitive Match Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"common">
     <name>i;basic;uca=3D3.1.1;uv=3D3.2;match=3Dcase</name>
     <title>Basic Case Sensitive Match</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
     <UnicodeVersion>3.2</UnicodeVersion>
     <UCAVersion>3.1.1</UCAVersion>
     <UCAMatchLevel>3</UCAMatchLevel>
   </collation>

9.5.  Octet Collation

9.5.1.  Octet Collation Description

   The "i;octet" collation is a simple and fast collation intended for
   use on binary octet strings rather than on character data.  It is the
   only such collation; it is not possible to register additional
   collations with this property.  Protocols that want to make this
   collation available have to do so by explicitly allowing it.  If not
   explicitly allowed, it MUST NOT be used.  It never returns an "error"
   result.  It provides equality, substring and ordering operators.

   The ordering algorithm is as follows:

Newman, et al.          Expires September 3, 2006              [Page 25]
=0C
Internet-Draft             Collation Registry                 March 2006

   1.  If both strings are the empty string, return the result "equal".
   2.  If the first string is empty and the second is not, return the
       result "less".
   3.  If the second string is empty and the first is not, return the
       result "greater".
   4.  If both strings begin with the same octet value, remove the first
       octet from both strings and repeat this algorithm from step 1.
   5.  If the unsigned value (0 to 255) of the first octet of the first
       string is less than the unsigned value of the first octet of the
       second string, then return "less".
   6.  If this step is reached, return "greater".

   This algorithm is roughly equivalent to the C library function memcmp
   with appropriate length checks added.

   The matching operator returns "match" if the sorting algorithm would
   return "equal".  Otherwise the matching operator returns "no-match".

   The substring operator returns "match" if the first string is the
   empty string, or if there exists a substring of the second string of
   length equal to the length of the first string which would result in
   a "match" result from the equality function.  Otherwise the substring
   operator returns "no-match".

   The associated canonicalization algorithm is the identity operator.

9.5.2.  Octet Collation Registration

   This collation is defined with intendedUse=3D"limited" because it can
   only be used by protocols that explicitly allow it.

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"limited">
     <name>i;octet</name>
     <title>Octet</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
   </collation>

10.  IANA Considerations

   Section 7 defines how to register collations with IANA.  Section 9
   defines a list of predefined collations, which should be registered
   when this document is approved and published as an RFC.

Newman, et al.          Expires September 3, 2006              [Page 26]
=0C
Internet-Draft             Collation Registry                 March 2006

11.  Security Considerations

   Collations will normally be used with UTF-8 strings.  Thus the
   security considerations for UTF-8 [3], stringprep [6] and Unicode
   TR-36 [9] also apply and are normative to this specification.

12.  Open Issues

   Mark Davis writes:

   The sample registry would suffer a combinatorial explosion if
   parameters are not handled differently.  For example, with CLDR
   collations, there can be hundreds of locales, six different strength
   settings; four different case-first settings; three different
   alternate settings, backwards settings, normalization settings, case
   level settings, hiragana settings, and numeric settings; plus a
   variable-top setting which has a string as an operand.  Registering
   the combinations that people are allowed to use would be untenable.

   Use UCAv9 or UCAvLatest (14)?  Instead of using UCAv9, it sounds
   sensible to use "UCA", "UCA version x" or "UCA version x or greater"

   The change to en;ascii-casemap indicates that its use is local.  It's
   not.  The collation is not suitable to English since it doesn't
   handle common typography, signs like the pound sign, and even some
   words.  And it's not local, since many protocols (like SMTP) use
   ASCII casemapping even when used in non-English locales.

   Can the text on lookup tables be simplified greatly, to remove all
   the MUSTs related to e.g. downloading tables?  The client could get
   its tables from the collation spec rather than indirectly via the
   server.

   Should there be some text which references RFC 2434?  If not, the
   reference should die.

   The section on multi-value attributes seems to be a solution looking
   for a problem.  Frank Ellermann had questions about what it means.

13.  Change Log

13.1.  Changes From -06
   1.  Clarified equality and identity: equality is as defined by a
       collation, identity is stronger.

Newman, et al.          Expires September 3, 2006              [Page 27]
=0C
Internet-Draft             Collation Registry                 March 2006

   2.  Added reference to
       http://www.unicode.org/reports/tr10/#Searching.
   3.  Don't describe sort keys as a canonical representation of the
       string.
   4.  Permit disconnected clients to use wildcards.  (A disconnected
       client has to resolve the wildcard itself, in the same way that a
       server would.)
   5.  Change collation-wild to have the same length limit as collation.
   6.  Change to use "less" instead of "-1", etc., and specify that it's
       just phrasing, not specification.
   7.  Don't describe the equality, substring and ordering operations as
       functions.  The definition of collation uses the word function
       about the collation itself.  A function that has three functions?
       Something has to give.
   8.  Strike a requirement that selecting '*' is the same as not
       selecting any collation.  It restricted the protocol's default
       too much.  Existing code wasn't listening.
   9.  Left out the canonicalization/sort keys.

13.2.  Changes From -05
   1.  Added definitions of client, server and protocol, and prose to
       specify that while the IANA registrations of collations are
       written in terms octet strings, implementations may do it
       differently.
   2.  Changed the wording for ascii-numeric to treat the numbers as
       numbers, etc.
   3.  Added explicit property requirements for the three functions,
       e.g. that equality be symmetric.  Added requirements that the
       three functions be consistent, and that if any operations are
       present, equality must be (needed for consistency).
   4.  Random editing, e.g. changing 'numbers' for ascii-numeric to
       'integer numbers'.
   5.  Gave IMAP/SORT/COMPARATOR the same grandfather treatment as ACAP
       and SIEVE.

13.3.  Changes From -04

   Grammar and clarity changes only.  One (weak) example added.  No
   substantive changes.

13.4.  Changes From -03

   (This does not include all changes made.)
   1.  Checked and resolved most issues marked 'check whether this is
       true' or similar.
   2.  Resolved nameprep issue: No.

Newman, et al.          Expires September 3, 2006              [Page 28]
=0C
Internet-Draft             Collation Registry                 March 2006

   3.  Removed NULL for compatibility with existing collations (IMAP
       SORT, Sieve).
   4.  There can be multiple owners and submitters.  Say how.
   5.  Added a requirement that common collations must now be
       interoperable.  Insufficiently detailed specs cannot be "common".
   6.  Added a guideline that the operations provided by new collations
       should be reminiscent of similar operations on existing
       collations.

13.5.  Changes From -02

   1.  Changed from data being octet sequences (in UTF-8) to data being
       character sequences (with octet collation as an exception).
   2.  Made XML format description much more structured.
   3.  Changed <submittor> to <submitter>, because this spelling is much
       more common.
   4.  Defined 'protocol' to include query languages.
   5.  Reorganized document, in particular IANA considerations section
       (which newly is just a list of pointers).
   6.  Added subsections, and a 'Structure of this Document' section.
   7.  Updated references.
   8.  Created a 'Change Log' chapter, with sections for each draft.
   9.  Reduced 'Open issues' section, open issues are now maintained at
       http://www.w3.org/2004/08/ietf-collation.

13.6.  Changes From -01

   Add IANA comment to open issues.  Otherwise this is just a re-publish
   to keep the document alive.

13.7.  Changes From -00

   1.  Replaced the term comparator with collation.  While comparator is
       somewhat more precise because these abstract functions are used
       for matching as well as ordering, collation is the term used by
       other parts of the industry.  Thus I have changed the name to
       collation for consistency.
   2.  Remove all modifiers to the basic collation except for the
       customization and the match rules.  The other behavior
       modifications can be specified in a customization of the
       collation.
   3.  Use ";" instead of "-" as delimiter between parameters to make
       names more URL-ish.
   4.  Add URL form for comparator reference.
   5.  Switched registration template to use XML document.
   6.  Added a number of useful registration template elements related
       to the Unicode Collation Algorithm.

Newman, et al.          Expires September 3, 2006              [Page 29]
=0C
Internet-Draft             Collation Registry                 March 2006

   7.  Switched language from "custom" to "tailor" to match UCA language
       for tailoring of the collation algorithm.

14.  References

14.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [3]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        STD 63, RFC 3629, November 2003.

   [4]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", RFC 3986,
        January 2005.

   [5]  Alvestrand, H., "Tags for the Identification of Languages",
        BCP 47, RFC 3066, January 2001.

   [6]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
        Strings ("stringprep")", RFC 3454, December 2002.

   [7]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for
        Internationalized Domain Names (IDN)", RFC 3491, March 2003.

   [8]  Davis, M. and K. Whistler, "Unicode Collation Algorithm version
        9", July 2002,
        <http://www.unicode.org/reports/tr10/tr10-9.html>.

   [9]  Davis, M. and M. Suignard, "Unicode Security Considerations",
        February 2006, <http://www.unicode.org/reports/tr36/>.

14.2.  Informative References

   [10]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [11]  Myers, J., "Simple Authentication and Security Layer (SASL)",
         RFC 2222, October 1997.

   [12]  Newman, C. and J. Myers, "ACAP -- Application Configuration
         Access Protocol", RFC 2244, November 1997.

Newman, et al.          Expires September 3, 2006              [Page 30]
=0C
Internet-Draft             Collation Registry                 March 2006

   [13]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [14]  Freed, N. and J. Postel, "IANA Charset Registration
         Procedures", BCP 19, RFC 2978, October 2000.

   [15]  Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
         January 2001.

   [16]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
         4rev1", RFC 3501, March 2003.

   [17]  Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL
         - SORT AND THREAD EXTENSIONS", draft-ietf-imapext-sort-17.txt
         (work in progress), May 2004.

   [18]  Newman, C. and A. Gulbrandsen, "Internet Message Access
         Protocol Internationalization", draft-ietf-imapext-i18n-06.txt
         (work in progress), January 2006.

Newman, et al.          Expires September 3, 2006              [Page 31]
=0C
Internet-Draft             Collation Registry                 March 2006

Authors' Addresses

   Chris Newman
   Sun Microsystems
   1050 Lakes Drive
   West Covina, CA  91790
   US

   Email: [email-masked]

   Martin Duerst
   Aoyama Gakuin University
   5-10-1 Fuchinobe
   Sagamihara, Kanagawa  229-8558
   Japan

   Phone: +81 466 49 1170
   Fax:   +81 466 49 1171
   Email: [email-masked]
   URI:   http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/

  Note:   Please write "Duerst" with u-umlaut wherever possible, for
          example as "D&#252;rst" in XML and HTML.)

   Arnt Gulbrandsen
   Oryx Mail Systems GmbH
   Schweppermannstr. 8
   Munich  81671
   Germany

   Phone: +49 89 4502 9757
   Fax:   +49 89 4502 9758
   Email: [email-masked]
   URI:   http://www.oryx.com/arnt/

Newman, et al.          Expires September 3, 2006              [Page 32]
=0C
Internet-Draft             Collation Registry                 March 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Newman, et al.          Expires September 3, 2006              [Page 33]
=0C

-----

Date: Thu, 02 Mar 2006 10:26:41 -0800
From: Mark Davis <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Chris Newman <[email-masked]>, =?UTF-8?B?TWFydGluIETDvHJzdA==?= <[email-masked]>, [email-masked]
Subject: Re: draft-newman-i18n-comparator-07.txt just submitted
Sender: [email-masked]

Can you send out or post a copy, so we can see it before monday?

Arnt Gulbrandsen wrote:
> Arnt Gulbrandsen writes:
>   
>> Early next week, I hope.
>>     
>
> No. Just before the cutoff, early Monday afternoon by my time.
>
> Wait for that to comment, or get a copy from  me by email.
>
> Arnt
>
>
>
>   

Date: Thu, 2 Mar 2006 08:59:41 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Sender: [email-masked]

On Thu, 2 Mar 2006, Arnt Gulbrandsen wrote:
>> 3. A comparator thingy which can go between any two search-keys and which 
>> changes the comparator used from that point onwards.
> Speaking only for myself, 3 leaves a bad taste in my mouth. Feels like bad 
> design.

I agree.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Thu, 02 Mar 2006 15:37:09 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>> Related to this. The second paragraph says:
>>
>>    When AUTHENTICATE is used, some servers may support userids and
>>    passwords in Unicode [13]. However, such userids cannot be used as
>>    email addresses, and at present also seem to be incompatible with
>>    the current latest ACL drafts. Unless the ACL drafts resolve this,
>>    server authors are cautioned against supporting ACL and unicode
>>    userids simultaneously.
>>
>> The updated ACL got published as RFC 4314. So the end of this 
>> paragraph is wrong.
>
> Simplify my life. Give me text ;)

Delete everything till the end of paragraph, starting from ",and at 
present also seem to be incompatible".

Date: Thu, 2 Mar 2006 16:41:50 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-newman-i18n-comparator-07.txt just submitted
Cc: Chris Newman <[email-masked]>, Martin =?iso-8859-1?q?D=FCrst?= <[email-masked]>, [email-masked]
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Early next week, I hope.

No. Just before the cutoff, early Monday afternoon by my time.

Wait for that to comment, or get a copy from  me by email.

Arnt

Date: Thu, 2 Mar 2006 16:32:56 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Chris Newman <[email-masked]>, Martin =?iso-8859-1?q?D=FCrst?= <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>, [email-masked]
Subject: draft-newman-i18n-comparator-07.txt just submitted
Sender: [email-masked]

The internet-drafts edit seems to have a 2-3 day lag right now.

It's not complete. I'm not happy. I know I have comments from Martin 
Dürst that I haven't worked in yet (very sorry, Martin), and some other 
people's comments are also incompletely processed.

But I wanted to get this submitted. There were so many comments in the 
past week, and the diff is big. The only way to get a new revision out 
was to send it out incomplete.

$ diff -u /tmp/draft-newman-i18n-comparator-0[67].txt | wc -l
1380

There will be another draft fairly soon where I resolve the sort-key 
situation, work in Martin's comments and hopefully use a better DTD. 
The DTD change will also necessitate some textual changes. Early next 
week, I hope.

Now I have to do some of my own work.

Arnt

Date: Thu, 2 Mar 2006 14:17:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Cc: Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Dave Cridland wrote:
>> A simpler solution might be to promote SASL PLAIN as the i18n 
>> plaintext login, since that either will be, or has been, fixed, and 
>> deprecate LOGIN for even that.
>
> I would rather the document just state that both LOGIN usernames and 
> passwords are UTF-8 now.

Much as I'm in favour of that, I feel that this document is the wrong 
place for it. This document specifies two extensions. Making an 
unconditional change to 3501 in the same document feels bad. A bit like 
the way RFC 2231 modifies RFC 2060: Two lines changing 2060 buried in 
the middle of a ten-page document.

I suppose section 5 could be beefed up, so it's not such a tiny change. 
It could allow UTF-8 logins, passwords and mailbox names?

> Related to this. The second paragraph says:
>
>    When AUTHENTICATE is used, some servers may support userids and
>    passwords in Unicode [13]. However, such userids cannot be used as
>    email addresses, and at present also seem to be incompatible with
>    the current latest ACL drafts. Unless the ACL drafts resolve this,
>    server authors are cautioned against supporting ACL and unicode
>    userids simultaneously.
>
> The updated ACL got published as RFC 4314. So the end of this 
> paragraph is wrong.

Simplify my life. Give me text ;)

Arnt

Date: Thu, 02 Mar 2006 12:43:13 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Sender: [email-masked]

Dave Cridland wrote:

> Okay, a handful of comments and notes:
>
> 1) Section 3.2, the LANGUAGE command allows only a single language tag.
>
> This is problematic, because it means the client has to discover the 
> list of supported languages, and select a suitable one. Is there 
> anything against allowing a client to list languages the user can 
> handle, in order? This would eliminate a round-trip, whilst still 
> allowing clients to discover supported languages.
>
> For example, given the examples, one might add:
>
> < Server does not speak French, but does speak English. User speaks 
> Canadian French and Canadian English. >
>
> C: A008 LANGUAGE FR-CA EN-CA
> S: * LANGUAGE (EN)
> S: A008 OK Now speaking English

I like that.

[...]

> 5) Section 5.1:
>
> Isn't this out of date WRT saslprep?

> A simpler solution might be to promote SASL PLAIN as the i18n 
> plaintext login, since that either will be, or has been, fixed, and 
> deprecate LOGIN for even that.

I would rather the document just state that both LOGIN usernames and 
passwords are UTF-8 now.

Related to this. The second paragraph says:

    When AUTHENTICATE is used, some servers may support userids and
    passwords in Unicode [13]. However, such userids cannot be used as
    email addresses, and at present also seem to be incompatible with
    the current latest ACL drafts. Unless the ACL drafts resolve this,
    server authors are cautioned against supporting ACL and unicode
    userids simultaneously.

The updated ACL got published as RFC 4314. So the end of this paragraph 
is wrong.

Date: Thu, 2 Mar 2006 13:41:31 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Cc: Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

> 3. A comparator thingy which can go between any two search-keys and 
> which changes the comparator used from that point onwards.
>
> ...
>
> Discussion, please.

Speaking only for myself, 3 leaves a bad taste in my mouth. Feels like 
bad design.

I don't care much about 1/2/4.

Arnt

Date: Thu, 2 Mar 2006 13:36:38 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Cc: Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> 4) Section 4.4:
>
> I suspect that COMPARATOR is weak, but good enough for some 
> circumstances, albeit I'd prefer a more complex SEARCH. One problem 
> is that as specified, the example sequence B123 to B125 cannot be 
> pipelined.
>
> Could we add a COMPARATOR SEARCH option, which would override the 
> comparator used for that command only? Something like:
>
> B123 SEARCH COMPARATOR (i;octet) OR BODY GIF87A BODY GIF89A
>
> I think Alexey's IMAP ABNF has the template syntax present for a 
> search option.

We had this and dropped it. 18 months ago? There weren't any good 
examples, which always makes me feel bad. If one can't dream up at 
least one good example for an extension, maybe that extension isn't so 
useful in practice... so I asked whether any clients would use this and 
whether anything would be lost by omitting the COMPARATOR search-key. 
As I recall, noone stepped forward to speak in favour of the extra 
search-key, and Mark spoke in favour of simplicity.

There are four options:

1. No way to change comparator within the search command. Simple to 
implement for servers. Clients must change comparator before/after the 
search command.

2. Comparator can be set at the start, much like CHARSET. A bit tricky 
to do in the syntax, if I remember correctly, and saves a roundtrip or 
two. Otherwise identical to the previous option.

3. A comparator thingy which can go between any two search-keys and 
which changes the comparator used from that point onwards. (This is 
what we had, if I remember correctly.)

4. A new search-key which takes a comparator name and a search-key, and 
executes that search-key with that collation.

3 and 4 are subtly different. 3 is more like a preprocessor directive in 
C, 4 is more like a wrapper function. To show the difference between 
them, take this command:

     a search or or body arnt or from arnt to arnt cc arnt

I'm using a MUA with proportional spacing, so no ASCII art, sorry. 
You'll have to draw your own tree diagrams of this search.

Here are three variants with COMPARATOR:

     b search comparator i;octet or or body arnt or from arnt to arnt cc arnt
     c search or comparator i;octet or body arnt or from arnt to arnt cc arnt
     d search or or comparator i;octet body arnt or from arnt to arnt cc arnt

Using 3, all these are the same. The 'comparator' is before the first 
leaf node, so all four conditions are handled using i;octet. Using 4, 
they're different. For b, all four conditions are handled using 
i;octet. For c, i;octet is used only for body, from and to, while cc is 
handled by the active comparator. For d, only the body condition is 
subject to i;octet.

Which approach is the better one, 2, 3 or 4?

Is it good enough to be worth the bother? Will any client actually use 
it? (Will it deter any server from offering the extension?)

Discussion, please.

Arnt

Date: Wed, 1 Mar 2006 15:17:10 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Chris Newman <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt 
Sender: [email-masked]

On Wed, 1 Mar 2006, Dave Cridland wrote:
> 1) Section 3.2, the LANGUAGE command allows only a single language tag.
> This is problematic, because it means the client has to discover the list of 
> supported languages, and select a suitable one. Is there anything against 
> allowing a client to list languages the user can handle, in order?

I agree.  I also believe that the use of language-range adds unnecessary 
complexity, and that adding an untagged response is unnecessary.

I also note that the language-data rule is dangling, and RFC 3066 is being 
replaced.

Suggest the following:

 	command-any =/ language-cmd
 	resp-text-code =/ resp-lang / resp-langs

 	language = "LANGUAGE" *[SP lang-tag]

 	resp-langs = "LANGUAGES" [SP "(" lang-tag *(SP lang-tag) ")" ]
 	resp-lang = "LANGUAGE" SP lang-tag

 	lang-tag = astring
 		;; contains language-tag as described in [5]

Command semantics as follows:

LANGUAGE command with no argument: Return tagged OK with resp-langs 
containing the list of languages.

LANGUAGE command with arguments: Return BAD if violates syntax in any 
way.  Otherwise, selects language according to rules of section 2.5 of 
[5]; if success returns resp-lang with the selected language in a tagged 
OK response, otherwise returns resp-lang in a tagged NO with the server's 
preferred language (not necessarily "i-default").

i-default is mandatory to implement.  All other languages are optional.

> 2) Section 3.4:
> What's paragraph 1 for?

Agreed.  This dependency is not good.

IMHO, the LANGUAGE command should NOT localize namespaces.  Instead, if 
such as desired, the NAMESPACE command itself should be extended to take 
an argument.  I can see cases in which a user may want error messages in 
his preferred language but retain mailbox paths in i-default.

This doesn't add an additional RTT since the client has to do a NAMESPACE 
command anyway if it purposes to use namespaces.

> 3) Section 4.2:
> I think this *should* end up reiterating stuff that's currently an open issue 
> in the Comparator draft. Interestingly, this is almost exactly what I think 
> the comparator draft should be reading.

Should we split this off into the COMPARATOR document, and make this 
document focus entirely on localization of error messages and namespaces?

An "IMAP i18n document" should be a broader overview, pointing to all the 
other documents, but not getting into the nuts and bolts the way this one 
does.

> Could we add a COMPARATOR SEARCH option, which would override the comparator 
> used for that command only? Something like:
> B123 SEARCH COMPARATOR (i;octet) OR BODY GIF87A BODY GIF89A

This sounds like a good idea.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 01 Mar 2006 21:52:22 +0000
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt 
From: Dave Cridland <[email-masked]>
To: Chris Newman <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I did a quick review of this, really to compare it against the 
comparator draft, and partly to see how "ready" it's looking. The 
summary is pretty ready, but not quite there yet.

On Wed Mar  1 20:50:01 2006, [email-masked] wrote:
> 	Title		: Internet Message Access Protocol Internationalization
> 	Author(s)	: C. Newman, et al.
> 	Filename	: draft-ietf-imapext-i18n-06.txt
> 	Pages		: 16
> 	Date		: 2006-3-1
> 	
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-06.txt

Okay, a handful of comments and notes:

1) Section 3.2, the LANGUAGE command allows only a single language 
tag.

This is problematic, because it means the client has to discover the 
list of supported languages, and select a suitable one. Is there 
anything against allowing a client to list languages the user can 
handle, in order? This would eliminate a round-trip, whilst still 
allowing clients to discover supported languages.

For example, given the examples, one might add:

< Server does not speak French, but does speak English. User speaks 
Canadian French and Canadian English. >

C: A008 LANGUAGE FR-CA EN-CA
S: * LANGUAGE (EN)
S: A008 OK Now speaking English

2) Section 3.4:

What's paragraph 1 for? Surely most clients will use LANG early in 
the connection in order to switch troublesome authentication errors 
into the user's native language if possible. If LANG is used later, 
then the client can always use NAMESPACE pipelined itself. This adds 
a requirement to both client and server to support both, and I think 
it's making things more complex than they need to be.

Otherwise a note that this can also provide human readable names, 
rather than translations, per se - for instance "user." might be 
translated as "Other Users." or something.

3) Section 4.2:

I think this *should* end up reiterating stuff that's currently an 
open issue in the Comparator draft. Interestingly, this is almost 
exactly what I think the comparator draft should be reading.

4) Section 4.4:

I suspect that COMPARATOR is weak, but good enough for some 
circumstances, albeit I'd prefer a more complex SEARCH. One problem 
is that as specified, the example sequence B123 to B125 cannot be 
pipelined.

Could we add a COMPARATOR SEARCH option, which would override the 
comparator used for that command only? Something like:

B123 SEARCH COMPARATOR (i;octet) OR BODY GIF87A BODY GIF89A

I think Alexey's IMAP ABNF has the template syntax present for a 
search option.

5) Section 5.1:

Isn't this out of date WRT saslprep? A simpler solution might be to 
promote SASL PLAIN as the i18n plaintext login, since that either 
will be, or has been, fixed, and deprecate LOGIN for even that.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-06.txt 
Date: Wed, 01 Mar 2006 15:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, et al.
	Filename	: draft-ietf-imapext-i18n-06.txt
	Pages		: 16
	Date		: 2006-3-1
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search
substrings.  It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions
(MIME).  This specification defines a collection of IMAP extensions
which improve international support including comparator negotiation
for search, sort and thread, language negotiation for international
error text, and translations for namespace prefixes.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-i18n-06.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-i18n-06.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-i18n-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 31 Mar 2006 15:53:15 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: draft-szego-wcor-imap-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

I just became aware of this document.  I don't think that IMAP is the 
right place for this functionality.

-- Mark --

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

Date: Fri, 31 Mar 2006 13:10:23 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: CONDSTORE
Sender: [email-masked]

Alexey Melnikov wrote:
> Ken Murchison wrote:

>> And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
>> doesn't support CONDSTORE?  I assume that the server should just 
>> ignore the HIGHESTMODSEQ status item, in the same way that it will 
>> have to ignore the SELECT/EXAMINE CONDSTORE parameter.
> 
> Right.

Hmm, the ABNF for the STATUS response requires at least one status-att. 
  So what should we do for:

a STATUS mailbox (HIGHESTMODSEQ)

Return a HIGHESTMODSEQ of zero, or don't return * STATUS for the 
mailbox?  I'm assuming the latter.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Fri, 31 Mar 2006 13:05:06 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Dave Cridland <[email-masked]>
CC: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: CONDSTORE
Sender: [email-masked]

Dave Cridland wrote:
> On Fri Mar 31 16:15:34 2006, Ken Murchison wrote:
>>
>> Alexey Melnikov wrote:
>>> Ken Murchison wrote:
>>>
>>>> I'm in the process of finalizing my CONDSTORE implementation, and 
>>>> I'm wondering what is the correct behavior when a client sends a 
>>>> CONDSTORE-specific command when the server has already responded to 
>>>> SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
>>>> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a 
>>>> syntax error (BAD), an operational error (NO), or ignored (OK)?
>>>
>>> A client that doesn't pay attention to NOMODSEQ is broken. So BAD 
>>> would be appropriate.
>>
>> BAD would be easier for me to implement, but I'm fine with parse but 
>> ignore.
>>
>>
> BAD would be better for clients, too.

OK, I'll go along with the client implementor.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Fri, 31 Mar 2006 18:25:07 +0100
Subject: Re: CONDSTORE
From: Dave Cridland <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

On Fri Mar 31 16:15:34 2006, Ken Murchison wrote:
> 
> Alexey Melnikov wrote:
>> Ken Murchison wrote:
>> 
>>> I'm in the process of finalizing my CONDSTORE implementation, and 
>>> I'm wondering what is the correct behavior when a client sends a 
>>> CONDSTORE-specific command when the server has already responded 
>>> to SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
>>> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a 
>>> syntax error (BAD), an operational error (NO), or ignored (OK)?
>> 
>> A client that doesn't pay attention to NOMODSEQ is broken. So BAD 
>> would be appropriate.
> 
> BAD would be easier for me to implement, but I'm fine with parse 
> but ignore.
> 
> 
BAD would be better for clients, too.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Fri, 31 Mar 2006 10:15:34 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: CONDSTORE
Sender: [email-masked]

Alexey Melnikov wrote:
> Ken Murchison wrote:
> 
>> I'm in the process of finalizing my CONDSTORE implementation, and I'm 
>> wondering what is the correct behavior when a client sends a 
>> CONDSTORE-specific command when the server has already responded to 
>> SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
>> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a 
>> syntax error (BAD), an operational error (NO), or ignored (OK)?
> 
> A client that doesn't pay attention to NOMODSEQ is broken. So BAD would 
> be appropriate.

BAD would be easier for me to implement, but I'm fine with parse but ignore.

Do you think that this should be spelled out in the I-D?

> However, in order to simplify implementations, how about allowing the 
> following behavior:
> STORE UNCHANGEDSINCE - always fails with NO.
> FETCH CHANGEDSINCE - assume all messages have changed (i.e. CHANGEDSINCE 
> is ignored)
> FETCH/SEARCH/SORT MODSEQ - ignore the MODSEQ parameter
> 
>> And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
>> doesn't support CONDSTORE?  I assume that the server should just 
>> ignore the HIGHESTMODSEQ status item, in the same way that it will 
>> have to ignore the SELECT/EXAMINE CONDSTORE parameter.
> 
> Right.
> 
> 

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Fri, 31 Mar 2006 06:34:38 -0800
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked]
Subject: Re: CONDSTORE
Sender: [email-masked]

Ken Murchison wrote:

> I'm in the process of finalizing my CONDSTORE implementation, and I'm 
> wondering what is the correct behavior when a client sends a 
> CONDSTORE-specific command when the server has already responded to 
> SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a 
> syntax error (BAD), an operational error (NO), or ignored (OK)?

A client that doesn't pay attention to NOMODSEQ is broken. So BAD would 
be appropriate.

However, in order to simplify implementations, how about allowing the 
following behavior:
 STORE UNCHANGEDSINCE - always fails with NO.
 FETCH CHANGEDSINCE - assume all messages have changed (i.e. 
CHANGEDSINCE is ignored)
 FETCH/SEARCH/SORT MODSEQ - ignore the MODSEQ parameter

> And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
> doesn't support CONDSTORE?  I assume that the server should just 
> ignore the HIGHESTMODSEQ status item, in the same way that it will 
> have to ignore the SELECT/EXAMINE CONDSTORE parameter.

Right.

Date: Thu, 30 Mar 2006 19:44:29 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-daboo-imap-annotatemore-09.txt  (fwd)
Sender: [email-masked]

--==========31CD27FFB5F3F22B1453==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
FYI new version of ANNOTATEMORE (now known as METADATA) extension is out. 
Major changes are:

1) Changed to new capability/command names using METADATA (NB I chose not 
to change the draft name to maintain consistency in the data tracker).
2) Now uses LISTEXT for retrieval of mailbox annotations.

Please review...

------------ Forwarded Message -----------
Date: March 30, 2006 6:50:01 PM -0500
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-daboo-imap-annotatemore-09.txt

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

	Title		: IMAP METADATA Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-09.txt
	Pages		: 32
	Date		: 2006-3-30

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

--==========31CD27FFB5F3F22B1453==========
Content-Type: message/rfc822;
 name="I-D ACTION:draft-daboo-imap-annotatemore-09.txt "

To: [email-masked]
Cc: 
From: [email-masked]
Date: Thu, 30 Mar 2006 18:50:01 -0500
Subject: I-D ACTION:draft-daboo-imap-annotatemore-09.txt 
Reply-To: [email-masked]

--NextPart

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

	Title		: IMAP METADATA Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-09.txt
	Pages		: 32
	Date		: 2006-3-30
	
The METADATA extension to the Internet Message Access Protocol
permits clients and servers to maintain "annotations" or "meta data"
on IMAP servers.  It is possible to have annotations on a per-mailbox
basis or on the server as a whole.  For example, this would allow
comments about the purpose of a particular mailbox to be "attached"
to that mailbox, or a "message of the day" containing server status
information to be made available to anyone logging in to the server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-daboo-imap-annotatemore-09.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-daboo-imap-annotatemore-09.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-daboo-imap-annotatemore-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-daboo-imap-annotatemore-09.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--==========31CD27FFB5F3F22B1453==========--

Date: Wed, 29 Mar 2006 17:48:35 -0800
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: LISTEXT + METADATA issues
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On March 23, 2006 11:08:20 AM -0800 Alexey Melnikov 
> <[email-masked]> wrote:
>
>>> 3) The new SELECTION option effectively requires comparisons - i.e. we
>>> need to take comparators into account. I'm not sure whether a
>>> statement to that effect belongs in the METADATA extension or whether
>>> LISTEXT itself should have some general statement about how selection
>>> options that use text comparisons should interact with i18n draft. I
>>> think a general statement in LISTEXT would be better...
>>
>> Can you suggest some text?
>
>    Internationalization Considerations
>
>    The LIST command selection option types defined in this specification
>    involve simple tests of mailbox properties. However, future extensions
>    to LISTEXT may define SELECTION options that do more sophisticated
>    tests. In the case of a test that requires matching text, in the
>    presence of the COMPARATOR [I18N] extension, the active comparator 
> MUST
>    be used to do comparisons. Such LISTEXT extensions MUST indicate in
>    their specification the interaction with the COMPARATOR [I18N]
>    extension.
>
> + add informative reference to draft-ietf-imapext-i18n-06.txt

Thanks!

> One more question: does it make sense to use RECURSIVEMATCH when 
> matching annotations?

This can be quite difficult to implement in servers, especially if the 
client can specify * in annotation names.

Can you think of a use case for this?

Date: Wed, 29 Mar 2006 20:11:06 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-15.txt  (fwd)
Sender: [email-masked]

--==========EFD712C2E7BF93890F62==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
This revision includes all the items discussed at the meeting last week. It 
should be ready for submission to IESG as experimental status as per 
discussion.

------------ Forwarded Message -----------
Date: March 29, 2006 6:50:02 PM -0500
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-15.txt

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

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-15.txt
	Pages		: 36
	Date		: 2006-3-29

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

--==========EFD712C2E7BF93890F62==========
Content-Type: message/rfc822;
 name="I-D ACTION:draft-ietf-imapext-annotate-15.txt "

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-15.txt 
Date: Wed, 29 Mar 2006 18:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-15.txt
	Pages		: 36
	Date		: 2006-3-29
	
The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "meta data" for messages, or
   individual message parts, stored in a mailbox on the server.  For
   example, this can be used to attach comments and other useful
   information to a message.  It is also possible to attach annotations
   to specific parts of a message, so that, for example, they could be
   marked as seen or important, or a comment added.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

--==========EFD712C2E7BF93890F62==========--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-15.txt 
Date: Wed, 29 Mar 2006 18:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-15.txt
	Pages		: 36
	Date		: 2006-3-29
	
The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "meta data" for messages, or
   individual message parts, stored in a mailbox on the server.  For
   example, this can be used to attach comments and other useful
   information to a message.  It is also possible to attach annotations
   to specific parts of a message, so that, for example, they could be
   marked as seen or important, or a comment added.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 29 Mar 2006 22:54:43 +0100
Subject: Re: More on LISTEXT (fwd)
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Mar 29 22:22:05 2006, Arnt Gulbrandsen wrote:
> (I dislike 3 mostly because I think "do that" is a better sort of 
> command than "don't do that".)

I sympathise, but option 2 is not "do that" either, it's an explicit 
revocation of the implicit "don't do that" caused by the explicit 
(but not implicit) use of another return option. The default is still 
"do that".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 29 Mar 2006 23:22:05 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: More on LISTEXT (fwd)
Sender: [email-masked]

Cyrus Daboo writes:
> Solutions:
...

I don't have a strong opinion. 2 is best, 3 worst, but I'll listen to 
Dave's arguments wrt. where to to specify.

(I dislike 3 mostly because I think "do that" is a better sort of 
command than "don't do that".)

Arnt

Date: Wed, 29 Mar 2006 16:02:52 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Dave Cridland <[email-masked]>, Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: CONDSTORE
Sender: [email-masked]

Since people seem to be in a talkative mood today, can I get your 
thoughts on this issue?  The draft doesn't discuss it at all.

Ken Murchison wrote:
> 
> I'm in the process of finalizing my CONDSTORE implementation, and I'm 
> wondering what is the correct behavior when a client sends a 
> CONDSTORE-specific command when the server has already responded to 
> SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
> UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a syntax 
> error (BAD), an operational error (NO), or ignored (OK)?
> 
> And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
> doesn't support CONDSTORE?  I assume that the server should just ignore 
> the HIGHESTMODSEQ status item, in the same way that it will have to 
> ignore the SELECT/EXAMINE CONDSTORE parameter.
> 

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Wed, 29 Mar 2006 21:58:25 +0100
Subject: Re: More on LISTEXT (fwd)
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Mar 29 21:47:04 2006, Cyrus Daboo wrote:
>>> 2) Add a new STDFLAGs return option such that if a RETURN is
>>> specified,
>>> then standard flags are only returned if STDFLAG is present as one
>>> of the
>>> return options. If there is no return option, then the normal
>>> behaviour
>>> occurs.
>>> 
>>> 
>> This involves changing the behaviour of LIST-EXTENDED quite 
>> heavily - in
>> particular, you need to differentiate between implicit and explicit
>> RETURN options. I don't like this.
> 
> But you have to do that already - std. flags are implicit with any 
> RETURN as are others like \Remote.
> 
> 
No... \Subscribed is only given by the SUBSCRIBED return option, 
which in turn is implied by the SUBSCRIBED selection option. You're 
saying that LIST (SUBSCRIBED) "" * RETURN (SUBSCRIBED) would behave 
differently to LIST (SUBSCRIBED) "" *.

Implementation-wise, either (2) or (3) is just as easy, but 
specification-wise, I think (3) is much easier to explain.

>>> 3) Add a new NOSTDFLAGS return option such that if specified in
>>> RETURN, the
>>> standard flags are not returned.
>> 
>> Although this is quite ugly, I think this is cleaner to implement, 
>> and
>> has the additional advantage that you can specify it either in 
>> METADATA
>> (or SONOFANNOTATEMORE, or ANNOTATEMORE2THEREVENGE, or...) or as a 
>> small
>> standalone extension.
> 
> Why not in base LISTEXT? Other extensions to LISTEXT might well use 
> it (e.g. an extension that replaces STATUS behaviour by adding 
> SEEN, RECENT etc selection/return options).

Because it's a significant technical change, and I suspect it would 
force a WGLC again.

I agree it might be useful outside of METADATA, though.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 29 Mar 2006 15:47:04 -0500
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: More on LISTEXT (fwd)
Sender: [email-masked]

Hi Dave,

--On March 29, 2006 9:36:44 PM +0100 Dave Cridland <[email-masked]> 
wrote:

>> 2) Add a new STDFLAGs return option such that if a RETURN is
>> specified,
>> then standard flags are only returned if STDFLAG is present as one
>> of the
>> return options. If there is no return option, then the normal
>> behaviour
>> occurs.
>>
>>
> This involves changing the behaviour of LIST-EXTENDED quite heavily - in
> particular, you need to differentiate between implicit and explicit
> RETURN options. I don't like this.

But you have to do that already - std. flags are implicit with any RETURN 
as are others like \Remote.

>> 3) Add a new NOSTDFLAGS return option such that if specified in
>> RETURN, the
>> standard flags are not returned.
>
> Although this is quite ugly, I think this is cleaner to implement, and
> has the additional advantage that you can specify it either in METADATA
> (or SONOFANNOTATEMORE, or ANNOTATEMORE2THEREVENGE, or...) or as a small
> standalone extension.

Why not in base LISTEXT? Other extensions to LISTEXT might well use it 
(e.g. an extension that replaces STATUS behaviour by adding SEEN, RECENT 
etc selection/return options).

-- 
Cyrus Daboo

Date: Wed, 29 Mar 2006 21:36:44 +0100
Subject: Re: More on LISTEXT (fwd)
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Mar 29 21:23:33 2006, Cyrus Daboo wrote:
> Hi folks,
> I'd like to get some sort of feedback on the issue below as I want 
> to submit a new annotatemore draft with LISTEXT dependency soon.
> 
> 
Sorry, I'd meant to reply to this sooner.

> 1) Leave things as they are - getting annotations will result in 
> getting
> the standard flags all over again.
> 
> 
I always want this behaviour.

> 2) Add a new STDFLAGs return option such that if a RETURN is 
> specified,
> then standard flags are only returned if STDFLAG is present as one 
> of the
> return options. If there is no return option, then the normal 
> behaviour
> occurs.
> 
> 
This involves changing the behaviour of LIST-EXTENDED quite heavily - 
in particular, you need to differentiate between implicit and 
explicit RETURN options. I don't like this.

> 3) Add a new NOSTDFLAGS return option such that if specified in 
> RETURN, the
> standard flags are not returned.

Although this is quite ugly, I think this is cleaner to implement, 
and has the additional advantage that you can specify it either in 
METADATA (or SONOFANNOTATEMORE, or ANNOTATEMORE2THEREVENGE, or...) or 
as a small standalone extension.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 29 Mar 2006 15:34:32 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: More on LISTEXT
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> Hi,
> I believe this was discussed before: currently with LISTEXT there is no 
> way for the client to tell the server not to return the 'standard' IMAP 
> mailbox flags such as \NoInferiors, \Marked etc. However, when listing 
> annotations, it would be nice to be able to list those without getting 
> the standard flag data again.
> 
> Solutions:
> 
> 1) Leave things as they are - getting annotations will result in getting 
> the standard flags all over again.
> 
> 2) Add a new STDFLAGs return option such that if a RETURN is specified, 
> then standard flags are only returned if STDFLAG is present as one of 
> the return options. If there is no return option, then the normal 
> behaviour occurs.
> 
> 3) Add a new NOSTDFLAGS return option such that if specified in RETURN, 
> the standard flags are not returned.
> 
> Personally I prefer (2), but could live with (3). I do not find the 
> current situation acceptable though.

I'm in favor of (2) as well.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Cc: [email-masked]
From: Timo Sirainen <[email-masked]>
Subject: Re: More on LISTEXT (fwd)
Date: Wed, 29 Mar 2006 23:34:30 +0300
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-10-1029484
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Mar 29, 2006, at 11:23 PM, Cyrus Daboo wrote:

> 2) Add a new STDFLAGs return option such that if a RETURN is  
> specified,
> then standard flags are only returned if STDFLAG is present as one  
> of the
> return options. If there is no return option, then the normal  
> behaviour
> occurs.
..
> Personally I prefer (2), but could live with (3). I do not find the  
> current
> situation acceptable though.

I prefer 2 too.

--Apple-Mail-10-1029484
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-10-1029484--

Date: Wed, 29 Mar 2006 15:23:33 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More on LISTEXT (fwd)
Sender: [email-masked]

--==========C8E17952152E61629ECD==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
I'd like to get some sort of feedback on the issue below as I want to 
submit a new annotatemore draft with LISTEXT dependency soon.

------------ Forwarded Message -----------
Date: March 23, 2006 9:13:34 PM -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More on LISTEXT

Hi,
I believe this was discussed before: currently with LISTEXT there is no way
for the client to tell the server not to return the 'standard' IMAP mailbox
flags such as \NoInferiors, \Marked etc. However, when listing annotations,
it would be nice to be able to list those without getting the standard flag
data again.

Solutions:

1) Leave things as they are - getting annotations will result in getting
the standard flags all over again.

2) Add a new STDFLAGs return option such that if a RETURN is specified,
then standard flags are only returned if STDFLAG is present as one of the
return options. If there is no return option, then the normal behaviour
occurs.

3) Add a new NOSTDFLAGS return option such that if specified in RETURN, the
standard flags are not returned.

Personally I prefer (2), but could live with (3). I do not find the current
situation acceptable though.

-- 
Cyrus Daboo

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

--==========C8E17952152E61629ECD==========
Content-Type: message/rfc822; name="More on LISTEXT"

Date: Thu, 23 Mar 2006 21:13:34 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More on LISTEXT
Sender: [email-masked]

Hi,
I believe this was discussed before: currently with LISTEXT there is no way 
for the client to tell the server not to return the 'standard' IMAP mailbox 
flags such as \NoInferiors, \Marked etc. However, when listing annotations, 
it would be nice to be able to list those without getting the standard flag 
data again.

Solutions:

1) Leave things as they are - getting annotations will result in getting 
the standard flags all over again.

2) Add a new STDFLAGs return option such that if a RETURN is specified, 
then standard flags are only returned if STDFLAG is present as one of the 
return options. If there is no return option, then the normal behaviour 
occurs.

3) Add a new NOSTDFLAGS return option such that if specified in RETURN, the 
standard flags are not returned.

Personally I prefer (2), but could live with (3). I do not find the current 
situation acceptable though.

-- 
Cyrus Daboo

--==========C8E17952152E61629ECD==========--

Date: Tue, 28 Mar 2006 16:20:02 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
CC: Alexey Melnikov <[email-masked]>
Subject: CONDSTORE
Sender: [email-masked]

I'm in the process of finalizing my CONDSTORE implementation, and I'm 
wondering what is the correct behavior when a client sends a 
CONDSTORE-specific command when the server has already responded to 
SELECT/EXAMINE with NOMODSEQ?  Specifically, should STORE 
UNCHANGEDSINCE, FETCH CHANGEDSINCE, FETCH/SEARCH/SORT MODSEQ be a syntax 
error (BAD), an operational error (NO), or ignored (OK)?

And what should be done for STATUS HIGHESTMODSEQ when the mailbox 
doesn't support CONDSTORE?  I assume that the server should just ignore 
the HIGHESTMODSEQ status item, in the same way that it will have to 
ignore the SELECT/EXAMINE CONDSTORE parameter.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Mon, 27 Mar 2006 09:40:06 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

Hi Arnt,

--On March 27, 2006 4:07:42 PM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> I don't now remember exactly what Arnt's comments about annotate's
>> problems were, but I remember silently agreeing with them, so they
>> probably should be fixed before it gets to be RFC.
>
> (To be fair, draft-13 fixes most of them. Perhaps all that I mentioned.)

I'm working on ANNOTATEMORE (aka METADATA) right now and some of my other 
drafts, but will get around to ANNOTATE again in a couple of weeks. So 
please take the time now to look over it again and send comments. The only 
changes remaining to do from the -14 draft are:

1) Remove content-language attribute.
2) Add statement about experimental status.
3) Only allow sorting by value attribute - remove size.

-- 
Cyrus Daboo

Date: Mon, 27 Mar 2006 16:07:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

Timo Sirainen writes:
> I don't now remember exactly what Arnt's comments about annotate's 
> problems were, but I remember silently agreeing with them, so they 
> probably should be fixed before it gets to be RFC.

(To be fair, draft-13 fixes most of them. Perhaps all that I mentioned.)

Arnt

Subject: Re: Agenda: annotate etc
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: Mon, 27 Mar 2006 16:59:19 +0300
Sender: [email-masked]

On Mon, 2006-03-13 at 09:27 -0800, Mark Crispin wrote:
> Another troubling sign is that several implementors are conspicuous by 
> their absence from the technical discussion.  Perhaps this simply means 
> that the specification is going so well that they have nothing more to 
> add, but I doubt it.  When a specification is going well, everybody and 
> their grandmother wants to add something to it.

Well, I've been silent mostly because it looked complex enough that I
didn't have any plans to implement it for a long time yet. Now I think
my server is slowly getting ready for new features, so I may try
implementing annotate (and maybe others) in a few months.

I don't now remember exactly what Arnt's comments about annotate's
problems were, but I remember silently agreeing with them, so they
probably should be fixed before it gets to be RFC.

Date: Thu, 23 Mar 2006 21:13:34 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: More on LISTEXT
Sender: [email-masked]

Hi,
I believe this was discussed before: currently with LISTEXT there is no way 
for the client to tell the server not to return the 'standard' IMAP mailbox 
flags such as \NoInferiors, \Marked etc. However, when listing annotations, 
it would be nice to be able to list those without getting the standard flag 
data again.

Solutions:

1) Leave things as they are - getting annotations will result in getting 
the standard flags all over again.

2) Add a new STDFLAGs return option such that if a RETURN is specified, 
then standard flags are only returned if STDFLAG is present as one of the 
return options. If there is no return option, then the normal behaviour 
occurs.

3) Add a new NOSTDFLAGS return option such that if specified in RETURN, the 
standard flags are not returned.

Personally I prefer (2), but could live with (3). I do not find the current 
situation acceptable though.

-- 
Cyrus Daboo

Date: Thu, 23 Mar 2006 20:34:31 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: LISTEXT + METADATA issues
Sender: [email-masked]

Hi Alexey,

--On March 23, 2006 11:08:20 AM -0800 Alexey Melnikov 
<[email-masked]> wrote:

>> 3) The new SELECTION option effectively requires comparisons - i.e. we
>> need to take comparators into account. I'm not sure whether a
>> statement to that effect belongs in the METADATA extension or whether
>> LISTEXT itself should have some general statement about how selection
>> options that use text comparisons should interact with i18n draft. I
>> think a general statement in LISTEXT would be better...
>
> Can you suggest some text?
>
>

    Internationalization Considerations

    The LIST command selection option types defined in this specification
    involve simple tests of mailbox properties. However, future extensions
    to LISTEXT may define SELECTION options that do more sophisticated
    tests. In the case of a test that requires matching text, in the
    presence of the COMPARATOR [I18N] extension, the active comparator MUST
    be used to do comparisons. Such LISTEXT extensions MUST indicate in
    their specification the interaction with the COMPARATOR [I18N]
    extension.

+ add informative reference to draft-ietf-imapext-i18n-06.txt

One more question: does it make sense to use RECURSIVEMATCH when matching 
annotations?

-- 
Cyrus Daboo

Date: Thu, 23 Mar 2006 12:08:20 -0800
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: LISTEXT + METADATA issues
Sender: [email-masked]

Cyrus Daboo wrote:

>
> Hi folks,
> Following the meeting of yesterday, I have been working on changes to 
> ANNOTATEMORE - now known as METADATA (though I won't change the file 
> name). The big one is switching over to LISTEXT for retrieval of 
> annotations on mailboxes. Some issues have come up whilst doing that:
>
> 1) I intend to implement both a LISTEXT SELECTION and RETURN option 
> type. Strictly speaking the RETURN option is all that is needed to 
> directly replace the old GETANNOTATION behviour, however the SELECTION 
> option adds the ability to search for mailboxes with specific 
> annotations.

Sounds good to me.

> 2) As part of extending the syntax for LISTEXT I found the 
> option-extension formal syntax element to not be sufficient, so 
> instead directly added to the list-select-base-opt and return-option 
> elements. Because of that I do wonder whether having option-extension 
> is worth it.

The option-extension non terminal specifies generic (or recommended) 
syntax. What you did seems reasonable, but I need to see your revised 
draft to confirm.

> 3) The new SELECTION option effectively requires comparisons - i.e. we 
> need to take comparators into account. I'm not sure whether a 
> statement to that effect belongs in the METADATA extension or whether 
> LISTEXT itself should have some general statement about how selection 
> options that use text comparisons should interact with i18n draft. I 
> think a general statement in LISTEXT would be better...

Can you suggest some text?

Date: Thu, 23 Mar 2006 12:46:12 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: LISTEXT + METADATA issues
Sender: [email-masked]

Hi folks,
Following the meeting of yesterday, I have been working on changes to 
ANNOTATEMORE - now known as METADATA (though I won't change the file name). 
The big one is switching over to LISTEXT for retrieval of annotations on 
mailboxes. Some issues have come up whilst doing that:

1) I intend to implement both a LISTEXT SELECTION and RETURN option type. 
Strictly speaking the RETURN option is all that is needed to directly 
replace the old GETANNOTATION behviour, however the SELECTION option adds 
the ability to search for mailboxes with specific annotations.

2) As part of extending the syntax for LISTEXT I found the option-extension 
formal syntax element to not be sufficient, so instead directly added to 
the list-select-base-opt and return-option elements. Because of that I do 
wonder whether having option-extension is worth it.

3) The new SELECTION option effectively requires comparisons - i.e. we need 
to take comparators into account. I'm not sure whether a statement to that 
effect belongs in the METADATA extension or whether LISTEXT itself should 
have some general statement about how selection options that use text 
comparisons should interact with i18n draft. I think a general statement in 
LISTEXT would be better...

-- 
Cyrus Daboo

Date: Wed, 22 Mar 2006 10:53:57 -0800
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: List of open issues with LIST-EXTENDED]
Sender: [email-masked]

--------------020806010003040506060808
Content-type: text/plain; charset="us-ascii"

Appologies for sending this too late, but here is the list of remaining 
open issues for LIST-EXTENDED.
I really hope to get closure on this document right after the Dallas 
meeting.

--------------020806010003040506060808
Content-type: message/rfc822; name="List of open issues with LIST-EXTENDED"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="List of open issues with LIST-EXTENDED"

Date: Tue, 14 Mar 2006 22:59:59 +0000
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
Subject: List of open issues with LIST-EXTENDED

Hi Barry,
Below is the list of all issues I have. If you agree, I will forward it 
to the mailing list.

The list of major open issues with LIST-EXTENDED:

1). "The server can ignore CHILDREN option if it likes". I think this is 
wrong and needs reviewing. The whole section about 
\HasChildren/\HasNoChildren was taken from the document that didn't have 
any way to request the attributes. Now we have an option, so I think the 
section has to be rewritten accordingly.

2). From Rob's message:

 >>In particular, some servers may not be able to combine the SUBSCRIBED 
selection option and CHILDREN return option. <<
 >
 >We need to seriously consider this.
 >
 >What if in the future we find another combination that some 
implementations find computationally expensive?
 >Are we going to have to declare a hierarchy of priorities for the 
servers to process these in
 >("REMOTE SUBSCRIBED CHILDREN is hard for me, so I'll just do 
SUBSCRIBED....")?
 >
 >Additionally, clients that want this information are still going to 
have to figure it out somehow
 >(and based on what I've seen, its likely they will do a separate LIST 
command for each one).

I tend to agree with Rob on this.

=========
The remaining issues from Rob are mostly editorial and more or less 
straightforward:

3).

> Can we break up section 3.[nil] into subsections (overview, selection 
> options, return options).

I agree, that might help with readability and this change should be easy.

4).

> The REMOTE selection option section states "The '\Remote' attribute 
> MUST be accurately computed..."
>
> It would be nice if a note was in there stating that if the server 
> presents this flag it MAY, in fact, not issue a referral when the 
> mailbox is accessed (for example, if the mailbox has become local in 
> the intervening time). Likewise, a mailbox previously noted as local 
> MAY get a referral anyway (since the mailbox may have been made 
> non-local in the interim).

Even though LIST-EXTENDED doesn't support referrals, the comment is 
still valid. I've already added similar text about \HasChildren (it is 
not a 100% guaranty that by the time the client access the mailbox it 
will still have children).

5).

> In the description of the HasChildren flag we suddenly start talking 
> about access permissions -- yet elsewhere in the document we haven't 
> mentioned it at all.  I don't think that we need to worry about it 
> here, and we can just say that in some implementations it may be 
> expensive to compute the existence of child mailboxes, and that 
> \HasChildren is only a hint to clients.
>
> If we really want to talk about access permissions in this document, 
> we should think carefully about where else they may be hard to 
> complute (\Remote?)

I am not sure if anything is needed in this area. What do you think?

--------------020806010003040506060808--

Date: Tue, 21 Mar 2006 07:22:01 -0600
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Splitting Binary
Sender: [email-masked]

Hi Lyndon,

--On March 20, 2006 8:49:46 PM -0800 Lyndon Nerenberg <[email-masked]> 
wrote:

>> Of course per-mailbox capabilities could be advertised via
>> ANNOTATEMORE. That is something that we could formalize:
>
> But what do you do when the server doesn't support annotatemore?  The
> problem is still there.

At that point the client has to fall back to a 'try it and be prepared for 
it fail' behaviour. At least it will know to expect that if 
'OPTIONAL-FOOBAR' is advertised.

-- 
Cyrus Daboo

Cc: [email-masked], [email-masked]
From: Lyndon Nerenberg <[email-masked]>
Subject: Re: Splitting Binary
Date: Mon, 20 Mar 2006 20:49:46 -0800
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> Of course per-mailbox capabilities could be advertised via  
> ANNOTATEMORE. That is something that we could formalize:

But what do you do when the server doesn't support annotatemore?  The  
problem is still there.

--lyndon

Date: Mon, 20 Mar 2006 18:37:52 -0600
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Splitting Binary
Sender: [email-masked]

Hi Lyndon,

--On March 20, 2006 4:06:18 PM -0800 Lyndon Nerenberg <[email-masked]> 
wrote:

> The big issue I have is with servers that don't support the append side,
> or do, but only on a subset of mailboxes.  I just don't see a clean way
> for the server to advertise the append-side capability.

Of course per-mailbox capabilities could be advertised via ANNOTATEMORE. 
That is something that we could formalize:

e.g. for an extension that may be offered on a per-mailbox bases, a server 
that advertises 'FOOBAR' in the CAPABILITY response always supports the 
foobar extension on all mailboxes. Whereas if the server advertises 
'OPTIONAL-FOOBAR' then it only supports foobar on a per-mailbox basis. In 
that case a new /capability annotation on mailboxes supporting foobar would 
list 'FOOBAR' as one of the capabilities - or its part of LISTEXT. This use 
of the 'OPTIONAL-' capability prefix can be used as a generalized way to 
handle cases like this. I don't know whether there is a benefit to 
separating these two cases like this...

-- 
Cyrus Daboo

Date: Mon, 20 Mar 2006 16:06:18 -0800
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], [email-masked]
Subject: Splitting Binary
Sender: [email-masked]

Some food for thought before Wednesdays sessions ...

Most (all?) of the issues with Binary seem to be with the append side. I 
think fetch can be cleaned up with a grammar fix to clarify literal+ 
interactions, and text explicitly calling out that you can only binary 
fetch terminals.

The big issue I have is with servers that don't support the append side, 
or do, but only on a subset of mailboxes.  I just don't see a clean way 
for the server to advertise the append-side capability.

I'm mulling the idea of splitting the current 'binary' into two new 
capabilities: 'bfetch' and 'bappend'.  This would solve the problem for 
those servers that can't or won't implement the append side.  It still 
doesn't handle the case where some mailboxes can handle bappend, but 
others can't.  My feeling here is that since the server now has the 
option of punting on bappend, if it *does* advertise the capability it 
*must* deal with it on *all* mailboxes.  Since bappend is an 
optimization for the client, I feel it's incumbent on the server to do 
whatever is necessary to actually optimize things for the client. 
Requiring the client to probe for validity is a non-starter in my books. 
  And it was always my intent in binary that servers would go out of the 
way to make bappend work everywhere if it worked at all; the new 
behaviour would make that a requirement.

I realize this is out of scope for both the WGs, but if we're starting 
anew there's a better chance of being able to tailor things to meet some 
of the requirements the Lemonade folks have been talking about.

--lyndon

From: "Stephane H. Maes" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Comments on draft-gulbrandsen-imap-view-00.txt
Date: Fri, 17 Mar 2006 22:01:23 -0800
Sender: [email-masked]

I am ok to merge. Just not sure why such overlap are taking place.

Stephane 

_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger) or [email-masked] (Google)
 
-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Friday, March 17, 2006 9:57 PM
To: [email-masked]
Cc: Arnt Gulbrandsen; Stephane Maes
Subject: Re: Comments on draft-gulbrandsen-imap-view-00.txt

Something I've mentioned to Arnt and which is worth repeating on the mailing list:

Arnt's VIEW extension overlaps with Lemonade VFOLDER extension. They essentially solving the same problem, so I would like to see a single
(merged?) draft.

Date: Sat, 18 Mar 2006 05:56:59 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Arnt Gulbrandsen <[email-masked]>, Stephane Maes <[email-masked]>
Subject: Re: Comments on draft-gulbrandsen-imap-view-00.txt
Sender: [email-masked]

Something I've mentioned to Arnt and which is worth repeating on the 
mailing list:

Arnt's VIEW extension overlaps with Lemonade VFOLDER extension. They 
essentially solving the same problem, so I would like to see a single 
(merged?) draft.

Date: Tue, 14 Mar 2006 19:16:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-gulbrandsen-imap-view-00.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Hi Arnt,
>> Feel free to forward the following comments to the mailing list:
>>
>> 1). Is there an expectation that UIDs must persist in a view between 
>> multiple selects of the VIEW? I would say so, but the document 
>> doesn't say that.
>
> Hm. I thought there was a sentence saying that a view should be 
> indistinguishable from a mailbox by a client which doesn't support 
> VIEW, but now I can't find it.

That might be too subtle.

> I'll add one.

Please.

>> 2).
>> >The VIEW CREATE Command
>> >
>> >    Arguments: Name of underlying mailbox
>> >               Name of view to be created
>> >               Search expression
>>
>> I would slightly prefer usage of CREATE <mailbox> ("VIEW" <criteria>) 
>> syntax, see VFOLDER for an example.
>
> Why?

I want to see consistent syntax. As you are using different command, 
this is not a big deal. But if one wants to extend both CREATE and VIEW 
CREATE in the same manner, you might as well have a single command from 
the start. Think about LIST and LSUB.

> (I'm not disagreeing. I have no preference, really. We just did 
> something that looked like FETCH/UID FETCH.)
>
>> 3).
>> >    The DELETE Command (RFC 3501 section 6.3.4) offers a special 
>> problem
>> >    if a mailbox is deleted while there are views onto that mailbox. In
>> >    order to simplify implementation, no particular behaviour is
>> >    mandated in that case.  However, servers MUST NOT show messages in
>> >    deleted mailboxes to clients.
>>
>> This paragraph is effectively mandating a behaviour: the view is not 
>> deleted,
>> but contains no messages. That is fine with me. I would rather you 
>> change the text to say that.
>
> There are three possible behaviours:
>
> a) Existing sessions onto such views are forcibly terminated by the 
> servers.
> b) Existing sessions are left alone, but no messages are accessible 
> through them.
> c) The view is left alone, and can even be selected, but contains no 
> messages.

Whether existing sessions are allowed or terminated is orthogonal to 
allowing new clients to select the view.
I am fine with either saying that when you delete the backing mailbox 
all views are deleted or kept around as empty mailbox. I think 
implementing one way or another is about the same amount of effort. So I 
suggest you make a choice.

If you want to delete views when backing mailbox is deleted, you can 
allow implementations to delay deleting the view till next 
select/examine/status.

> This is much like RFC 2180.

I advise you to at least describe allowed choices.

>> 4).
>> >    The RENAME Command (RFC 3501 section 6.3.5) has a similar problem:
>> >    If a mailbox is renamed, what happens to views onto that mailbox?
>> >    Again, no particular behaviour is mandated.
>>
>> I don't like that. Treat as "DELETE <original name>"?
>
> Why don't you like that?

I want some predictability. This will improve interoperability.

> Having all views follow the rename was easy for us, and seemed useful 
> at the time.

Ok. This seems like a better choice, but I want to see more text 
describing different choices.

>> But if the new name is a base for another view, this will "populate 
>> the view"?
>
> (It cannot be, since if the RENAME suceeds the new name does not 
> exist, and creating a view needs a mailbox.)

I was thinking about the following sequence of events:
1). Create view based on mailbox FOO
2). Delete the mailbox FOO (assuming the server keeps all derived views 
around).
3). Renamed mailbox JAR to FOO.

>> 5).
>> >    The APPEND Command (RFC 3501 section 6.3.11) and the COPY Command
>> >    (RFC 3501 section 6.4.7) cannot be used to append/copy messages to
>> >    views.
>>
>> Why not just copy the message to the backend mailbox?
>
> a) Didn't fit the use-cases we had while writing the code. b) It's 
> easy to change towards being more permissive, harder to change the 
> other way. c) It seemed a bit naughty to permit a J. Random Client to 
> append a message and apparently have it vanish into thin air.

Ah, I haven't thought about that. But you can describe this possibility 
in the draft.

However if you say that ordinary client can use VIEWs as if they are 
regular mailboxes, you should allow them to perform all commands that 
take mailbox name parameter.

> Arguments welcome.
>
>> Without ACL support there is no easy way for the server to tell that 
>> it doesn't support APPEND/COPY to the mailbox.
>
> That's a general argument in favour of ACL. Not particularly pertinent 
> to this extension.
>
>> 6).
>> >    The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying
>> >    mailbox to be expunged when a view is expunged. Servers MAY expunge
>> >    only the messages visible in the view, or MAY expunge the entire
>> >    mailbox. The former is more desirable, if possible.
>>
>> I would prefer to mandate the former. Implementing UID EXPUNGE is not 
>> that difficult.
>
> How about making it a SHOULD?

SHOULD is not sufficient. If you allow servers to perform EXPUNGE on the 
whole mailboxes, some users will be upset.
(If I have it might way, I would deprecate the EXPUNGE command).

>> 7).
>> >ACL Commands
>> >
>> [...]
>> >
>> >    MYRIGHTS computes access as for mailboxes. However, it may or may
>> >    not consider the underlying mailbox ACL, depending on how a server
>> >    implements VIEW.
>>
>> Can you pick a behaviour? E.g. always use ACL for the underlying 
>> mailbox, but can allow for a subset of rights.
>
> I can't, really. There are good arguments in both directions. I'm also 
> not convinced that one behaviour can be implemented by all current-day 
> servers. (See the security considerations.)

Once again, please describe available choices in the document.

Alexey

Date: Tue, 14 Mar 2006 19:52:31 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Comments on draft-gulbrandsen-imap-view-00.txt
Cc: [email-masked]
Sender: [email-masked]

Alexey Melnikov writes:
> Hi Arnt,
> Feel free to forward the following comments to the mailing list:
>
> 1). Is there an expectation that UIDs must persist in a view between 
> multiple selects of the VIEW? I would say so, but the document 
> doesn't say that.

Hm. I thought there was a sentence saying that a view should be 
indistinguishable from a mailbox by a client which doesn't support 
VIEW, but now I can't find it. I'll add one.

> 2).
> >The VIEW CREATE Command
> >
> >    Arguments: Name of underlying mailbox
> >               Name of view to be created
> >               Search expression
>
> I would slightly prefer usage of CREATE <mailbox> ("VIEW" <criteria>) 
> syntax, see VFOLDER for an example.

Why?

(I'm not disagreeing. I have no preference, really. We just did 
something that looked like FETCH/UID FETCH.)

> 3).
> >    The DELETE Command (RFC 3501 section 6.3.4) offers a special problem
> >    if a mailbox is deleted while there are views onto that mailbox. In
> >    order to simplify implementation, no particular behaviour is
> >    mandated in that case.  However, servers MUST NOT show messages in
> >    deleted mailboxes to clients.
>
> This paragraph is effectively mandating a behaviour: the view is not deleted,
> but contains no messages. That is fine with me. I would rather you 
> change the text to say that.

There are three possible behaviours:

a) Existing sessions onto such views are forcibly terminated by the servers.
b) Existing sessions are left alone, but no messages are accessible 
through them.
c) The view is left alone, and can even be selected, but contains no messages.

This is much like RFC 2180.

> 4).
> >    The RENAME Command (RFC 3501 section 6.3.5) has a similar problem:
> >    If a mailbox is renamed, what happens to views onto that mailbox?
> >    Again, no particular behaviour is mandated.
>
> I don't like that. Treat as "DELETE <original name>"?

Why don't you like that?

Having all views follow the rename was easy for us, and seemed useful at 
the time.

> But if the new name is a base for another view, this will "populate 
> the view"?

(It cannot be, since if the RENAME suceeds the new name does not exist, 
and creating a view needs a mailbox.)

> 5).
> >    The APPEND Command (RFC 3501 section 6.3.11) and the COPY Command
> >    (RFC 3501 section 6.4.7) cannot be used to append/copy messages to
> >    views.
>
> Why not just copy the message to the backend mailbox?

a) Didn't fit the use-cases we had while writing the code. b) It's easy 
to change towards being more permissive, harder to change the other 
way. c) It seemed a bit naughty to permit a J. Random Client to append 
a message and apparently have it vanish into thin air.

Arguments welcome.

> Without ACL support there is no easy way for the server to tell that 
> it doesn't support APPEND/COPY to the mailbox.

That's a general argument in favour of ACL. Not particularly pertinent 
to this extension.

> 6).
> >    The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying
> >    mailbox to be expunged when a view is expunged. Servers MAY expunge
> >    only the messages visible in the view, or MAY expunge the entire
> >    mailbox. The former is more desirable, if possible.
>
> I would prefer to mandate the former. Implementing UID EXPUNGE is not 
> that difficult.

How about making it a SHOULD?

> 7).
> >ACL Commands
> >
> [...]
> >
> >    MYRIGHTS computes access as for mailboxes. However, it may or may
> >    not consider the underlying mailbox ACL, depending on how a server
> >    implements VIEW.
>
> Can you pick a behaviour? E.g. always use ACL for the underlying 
> mailbox, but can allow for a subset of rights.

I can't, really. There are good arguments in both directions. I'm also 
not convinced that one behaviour can be implemented by all current-day 
servers. (See the security considerations.)

> 8).
> >Examples
> >
> >         C: e LIST (views) "" "%" return (views)
> >         S: * LIST (\hasnochildren \view) "." IMAP-announcements ((view
> >            (INBOX "HEADER \"Sender\" \"<ietf-announce-
> >            [email-masked]>\" OR BODY imap BODY smtp")))
>
> Drop extra () around view return data (as per latest LIST-EXTENDED)

OK.

> >Formal Syntax
> [...]
> >        view-extended-item = "VIEW" SP "(" mailbox SP nstring ")"
> >                      ; see the open issues section
>
> This is fixed in the latest LIST-EXTENDED, so you can update the grammar.

Thanks.

Arnt

Date: Mon, 13 Mar 2006 18:42:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Cc: Rob Siemborski <[email-masked]>, Pete Resnick <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> So what is it that's keeping you from thinking it's done?

Speaking just for me:

I found too many problems per day when implementing. Once that rate 
slows down, I think it'll be okay. Not perfect, but okay.

Arnt

Date: Mon, 13 Mar 2006 09:27:52 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Dave Cridland <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

On Mon, 13 Mar 2006, Lisa Dusseault wrote:
> So what is it that's keeping you from thinking it's done?

It is a highly-complex specification with minimal implementation, 
interoperability testing, or operational experience.  Put bluntly, it has 
yet to show that it has a purpose for being.

Another troubling sign is that several implementors are conspicuous by 
their absence from the technical discussion.  Perhaps this simply means 
that the specification is going so well that they have nothing more to 
add, but I doubt it.  When a specification is going well, everybody and 
their grandmother wants to add something to it.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Mon, 13 Mar 2006 09:09:08 -0800
To: "Dave Cridland" <[email-masked]>
Subject: Re: Agenda: annotate etc
Cc: "Pete Resnick" <[email-masked]>, [email-masked], "Arnt Gulbrandsen" <[email-masked]>, "Rob Siemborski" <[email-masked]>
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

So what is it that's keeping you from thinking it's done?  For me, it's  
the per-user annotations, which I've never implemented although you're  
correct that I've implemented WebDAV resource properties a couple times.   
I recall hearing some concerns that the per-user annotations could get out  
of control.  Still, I'm not convinced that the per-user annotations are a  
flaw, either -- it's exactly the kind of feature that gets server  
implementors worried about the "theoretical" problems with the feature,  
but if they actually got down and implemented it ( and put some reasonable  
limits on the use of the feature) it would work out fine in practice.

lisa

On Mon, 13 Mar 2006 00:58:37 -0800, Dave Cridland <[email-masked]>  
wrote:

> On Sun Mar 12 23:48:58 2006, Lisa Dusseault wrote:
>>    I don't have a strong opinion on whether we haven't done the  right  
>> things to make it feasible for servers to implement, or whether the   
>> protocol's good enough and just needs to have an RFC # of some kind.
>>
> Right.
>
> What you've just said there makes me more wary of publishing this on the  
> Standards Track.
>
> Both WebDAV and ACAP store arbitrary metadata, as does this  
> specification. You've implemented WebDAV on the server a few times, as I  
> understand it, I've done ACAP on the server, and neither of us hold a  
> strong "This is ready" opinion. The only implementation attempt by an  
> IMAP server guy has left no such opinion either.
>
> This ought to be sounding klaxons, let alone alarm bells.
>
> Dave.

Date: Mon, 13 Mar 2006 14:29:04 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Cc: Rob Siemborski <[email-masked]>, Pete Resnick <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> It did seem when we discussed this last year, that there were several  
> interested client implementors.  However, there were very few 
> interested  server implementors, and if I recall correctly I think 
> one of them was  Arnt who is now raising some issues.

Not now.

I raised issues last year, as many as I thought advisable. Cyrus and 
Randy dealt with them later last year.

(If you'd like concrete issues again, I can bring my code into alignment 
with -13 and see what comes up in the process. I haven't so far, 
because I'm not sure how much time I want to put into this extension 
unless there's someone around with which my code might interoperate.)

Arnt

Date: Mon, 13 Mar 2006 08:58:37 +0000
Subject: Re: Agenda: annotate etc
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Pete Resnick <[email-masked]>, <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Rob Siemborski <[email-masked]>
Sender: [email-masked]

On Sun Mar 12 23:48:58 2006, Lisa Dusseault wrote:
>    I don't have a strong opinion on whether we haven't done the  
> right things to make it feasible for servers to implement, or 
> whether the  protocol's good enough and just needs to have an RFC # 
> of some kind.
> 
> 
Right.

What you've just said there makes me more wary of publishing this on 
the Standards Track.

Both WebDAV and ACAP store arbitrary metadata, as does this 
specification. You've implemented WebDAV on the server a few times, 
as I understand it, I've done ACAP on the server, and neither of us 
hold a strong "This is ready" opinion. The only implementation 
attempt by an IMAP server guy has left no such opinion either.

This ought to be sounding klaxons, let alone alarm bells.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Sun, 12 Mar 2006 15:48:58 -0800
To: "Rob Siemborski" <[email-masked]>, "Dave Cridland" <[email-masked]>
Subject: Re: Agenda: annotate etc
Cc: "Pete Resnick" <[email-masked]>, [email-masked], "Arnt Gulbrandsen" <[email-masked]>
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

It did seem when we discussed this last year, that there were several  
interested client implementors.  However, there were very few interested  
server implementors, and if I recall correctly I think one of them was  
Arnt who is now raising some issues.

Speaking as a client implementor: even though I'd like this standardized,  
I'd prefer it to be implemented by servers.  Usually servers need to  
implement a protocol like this before clients can even think of  
following.   I don't have a strong opinion on whether we haven't done the  
right things to make it feasible for servers to implement, or whether the  
protocol's good enough and just needs to have an RFC # of some kind.

Lisa

On Sun, 12 Mar 2006 12:06:30 -0800, Rob Siemborski <[email-masked]>  
wrote:

>
> On 3/12/06, Dave Cridland <[email-masked]> wrote:
>
>> I'm not convinced that without some basic prototyping work, we can
>> claim it's well understood or stable.
>
> Didn't we also see this with BINARY, where a few key questions came up
> only after it was published (and the first few implementations were
> made)?
>
> I'm nervous about pushing to publish just for the sake of publishing
> if no one has implemented it.
>
> -Rob
>
> --
> Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
> Software Engineer     |                       |            650-623-6925
>

Date: Mon, 13 Mar 2006 00:40:34 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Cc: Pete Resnick <[email-masked]>, Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Sun, 12 Mar 2006, Dave Cridland wrote:
>> I'm entirely happy to go for Experimental, and revisit this as 
>> Proposed sometime down the line when we have implementation 
>> experience.
>
> I agree with this suggestion.

And I... don't disagree.

Arnt

Date: Mon, 13 Mar 2006 00:34:13 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Cc: Pete Resnick <[email-masked]>
Sender: [email-masked]

Hi Pete,

please don't read more into my words than I meant to put there. I'm not 
trying to attack the general RFC process, or even this WG's drafts in 
general. All I'm saying is: When I worked on an implementation of 
_this_ document, I found so many issues so quickly that I think the 
next chap along will find real stuff, too.

Now, if someone here takes a few days to do a first rough implementation 
and comes back to say «Arnt found all the major problems there was, we 
can go along», I shall be happy. If that someone comes back with some 
problems to fix, that's excellent too. And finally, if noone cares 
enough to implement it, getting annotate to RFC isn't terribly urgent 
anyway, is it?

Please also observe that annotate is the only case in which I use such 
strong words. For example, I mutter about listext a bit now and then, 
but at the same time, I think listext is good enough to go to RFC. 
Listext is good. Best is the enemy of good.

Arnt

Date: Sun, 12 Mar 2006 12:06:30 -0800
From: "Rob Siemborski" <[email-masked]>
To: "Dave Cridland" <[email-masked]>
Subject: Re: Agenda: annotate etc
Cc: "Pete Resnick" <[email-masked]>, [email-masked], "Arnt Gulbrandsen" <[email-masked]>
Sender: [email-masked]

On 3/12/06, Dave Cridland <[email-masked]> wrote:

> I'm not convinced that without some basic prototyping work, we can
> claim it's well understood or stable.

Didn't we also see this with BINARY, where a few key questions came up
only after it was published (and the first few implementations were
made)?

I'm nervous about pushing to publish just for the sake of publishing
if no one has implemented it.

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

Date: Sun, 12 Mar 2006 12:06:15 -0800
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: Agenda: annotate etc
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Sun, 12 Mar 2006, Dave Cridland wrote:
> I don't think ANNOTATE has, currently, enough community interest *in 
> implementing it* to be viable.

Sadly, I agree.

> I'm entirely happy to go for Experimental, and revisit this as Proposed 
> sometime down the line when we have implementation experience.

I agree with this suggestion.

-- Mark --

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

Date: Sun, 12 Mar 2006 19:45:35 +0000
Subject: Re: Agenda: annotate etc
From: Dave Cridland <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

Pete,

On Sun Mar 12 16:55:19 2006, Pete Resnick wrote:
> 
> On 3/10/06 at 12:27 PM +0100, Arnt Gulbrandsen wrote:
> 
>> I hereby propose that we block ANNOTATE from going forward until 
>> someone steps up to say «I implemented the draft as it stands, and 
>> I'm happy with it» - or that we change the draft until someone 
>> will implement it and be happy.
> 
> OK, I'm a delusional person

I'm sufficiently delusional to implement, and use, ACAP, which is a 
protocol suffering from lack of implementation. So I out-delusion you 
by several orders of magnitude. :-)

Yet I agree with Arnt in this instance.

> Section 4.1.1:
> 
>    A Proposed Standard specification is generally stable, has 
> resolved
>    known design choices, is believed to be well-understood, has 
> received
>    significant community review, and appears to enjoy enough 
> community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.
> 
> 
I don't think ANNOTATE has, currently, enough community interest *in 
implementing it* to be viable. Traditionally, the problem with mail 
protocol extensions has always been early implementations, causing an 
older version of the specification to be fixed in implementation. 
SORT, THREAD, imapflags, LISTEXT, etc. It alarms me greatly to see 
the reverse problem, which was most obviously seen with ACAP.

I do think that some mechanism allowing clients to attach arbitrary 
metadata to messages in the store is important, and if ANNOTATE is 
sufficiently worrying to put people off implementing, we'll blow that 
chance. Note that I cannot do this even with my secret weapon of ACAP.

I'm not convinced that without some basic prototyping work, we can 
claim it's well understood or stable.

>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed 
> Standard
>    designation.
> 
> 
I believe we need that argument in this case.

I'm entirely happy to go for Experimental, and revisit this as 
Proposed sometime down the line when we have implementation 
experience.

If this revisiting happens when it's still in the queue, that's cool 
with me too.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Sun, 12 Mar 2006 13:58:05 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

> OK, I'm a delusional person

That's true, but no more so than some of the rest of us.

> Let's get the document published with what we think is "OK" now, without 
> requiring implementations, let implementation experience guide where we 
> need to make changes, and make those changes as necessary.

I'm not usually a "me too" guy, but to make sure that we don't wind up 
wondering which side silence is on:  I agree with Pete, delusions and all.

Barry

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

Date: Sun, 12 Mar 2006 10:55:19 -0600
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Agenda: annotate etc
Cc: [email-masked]
Sender: [email-masked]

On 3/10/06 at 12:27 PM +0100, Arnt Gulbrandsen wrote:

>I hereby propose that we block ANNOTATE from going forward until 
>someone steps up to say «I implemented the draft as it stands, and 
>I'm happy with it» - or that we change the draft until someone will 
>implement it and be happy.

OK, I'm a delusional person and understand that "the Internet runs on 
Proposed Standards", but since the IMAP community is pretty 
tight-knit and can communicate about what stage in development any 
document might be at, let me suggest that we actually try to live up 
to RFC 2026:

Section 4.1.1:

    A Proposed Standard specification is generally stable, has resolved
    known design choices, is believed to be well-understood, has received
    significant community review, and appears to enjoy enough community
    interest to be considered valuable.  However, further experience
    might result in a change or even retraction of the specification
    before it advances.

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable, and will
    usually represent a strong argument in favor of a Proposed Standard
    designation.

Let's get the document published with what we think is "OK" now, 
without requiring implementations, let implementation experience 
guide where we need to make changes, and make those changes as 
necessary. And when we put out a new version of ANNOTATE while the 
one we're about to publish is still in the RFC Editor's queue, we 
give more ammunition to the people who want to fix the publication 
process.

If there are *current* outstanding issues in the ANNOTATE document 
which can be fixed during WG last call, let's get them on the table 
now.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 10 Mar 2006 12:27:53 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda: annotate etc
Sender: [email-masked]

Cyrus Daboo writes:
> The bottom line is the current ANNOTATE document has gone through WG 
> last call and revisions since then, so in theory it ought to be ready 
> for the IESG.

Yes, in theory. Practice is about implementation.

When I implemented most of it, I was very unhappy and brought up a 
number of problems. It would have been much better if I or someone else 
had brought up these issues earlier, before WGLC. But I didn't see the 
issues until I implemented. Sorry.

I hereby propose that we block ANNOTATE from going forward until someone 
steps up to say «I implemented the draft as it stands, and I'm happy 
with it» - or that we change the draft until someone will implement it 
and be happy.

Arnt

To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE 
Date: Thu, 09 Mar 2006 14:03:40 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
...
>I've used the audio feeds over the last few meetings and it has worked 
>pretty well with the exception of people not going to the mike to make 
>comments. The WG chairs do need to enforce that when we know there are 
>audiophiles present!

IMHO, they should enforce that even if there aren't remote listeners.
I for one have found the audio archives quite useful for refreshing the
details of the discussions beyond what was documented in the minutes.

Philip Guenther

Date: Thu, 09 Mar 2006 16:30:44 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Agenda: annotate etc
Sender: [email-masked]

Hi Pete,
Obviously there needs to be a serious discussion of ANNOTATE and 
ANNOTATEMORE. Things were left somewhat up in the air after the last 
exchange on the mailing list

The bottom line is the current ANNOTATE document has gone through WG last 
call and revisions since then, so in theory it ought to be ready for the 
IESG.

ANNOTATEMORE sparked discussions first about what it should be called based 
on what it is doing and that then lead to a discussion of a whole new 
extension that encompasses a more 'generic' metadata solution using LISTEXT 
etc. That debate did not come to any firm conclusions and we ought to try 
and have a concrete proposal coming out of Dallas.

-- 
Cyrus Daboo

Date: Thu, 09 Mar 2006 16:26:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

Hi Arnt,

--On March 9, 2006 10:23:41 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> I won't be in Dallas, but I should be able to attend via Jabber (ugh).
>
> How does the audio feed work? Is there any practical way to test that
> ahead of time?
>
> (My ISP, chosen for its IPv6 support and general competence, also offers
> multicast.)

I've used the audio feeds over the last few meetings and it has worked 
pretty well with the exception of people not going to the mike to make 
comments. The WG chairs do need to enforce that when we know there are 
audiophiles present! As for testing, try firing it up for the first session 
on Monday for the room imapext will be in and see what it is like.

-- 
Cyrus Daboo

Date: Thu, 9 Mar 2006 22:23:41 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

Lyndon Nerenberg writes:
> I won't be in Dallas, but I should be able to attend via Jabber (ugh).

How does the audio feed work? Is there any practical way to test that 
ahead of time?

(My ISP, chosen for its IPv6 support and general competence, also offers 
multicast.)

Arnt

Date: Thu, 09 Mar 2006 12:39:34 -0800
From: Lyndon Nerenberg <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked], Enhancements to Internet email to support diverse service enivronments <[email-masked]>, Ken Murchison <[email-masked]>
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

> BINARY is on the cards for a revision, I think, perhaps it could be
> added to that? Might be able to get it all sorted out quicker.

I have started on the update, and plan to push a draft soon after the 
freeze is over.  I'm not sure this can be fixed in the BINARY document, 
but work out what you need and I'll see what can be done.

I won't be in Dallas, but I should be able to attend via Jabber (ugh).

--lyndon

Date: Thu, 09 Mar 2006 20:08:47 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

Ken Murchison wrote:

> Pete Resnick wrote:
>
>> On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote:
>>
>>> I'm now wondering if I need to support BINARY (literal8) for 
>>> CATENATE (TEXT parts)?  I don't see any mention of BINARY or 
>>> literal8 in the CATENATE draft.
>>
>> Damn! How did I miss that?
>>
>> I'd sure like you to add the support for it and we'll fix CATENATE 
>> the next time around.
>
> Is this something that we should put on the agenda for one/both WG at 
> the upcoming meetings?

We should address this in Lemonade Profile Phase 2. So discussing this 
in Lemonade seems appropriate.

Date: Thu, 09 Mar 2006 15:06:16 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Pete Resnick <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] BINARY & CATENATE
Sender: [email-masked]

Pete Resnick wrote:
> On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote:
> 
>> I'm now wondering if I need to support BINARY (literal8) for CATENATE 
>> (TEXT parts)?  I don't see any mention of BINARY or literal8 in the 
>> CATENATE draft.
> 
> 
> Damn! How did I miss that?
> 
> I'd sure like you to add the support for it and we'll fix CATENATE the 
> next time around.

Is this something that we should put on the agenda for one/both WG at 
the upcoming meetings?

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Thu, 09 Mar 2006 20:04:04 +0000
Subject: Re: [lemonade] BINARY & CATENATE
From: Dave Cridland <[email-masked]>
To: Pete Resnick <[email-masked]>, Lyndon Nerenberg <[email-masked]>
Cc: <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

On Thu Mar  9 19:31:48 2006, Pete Resnick wrote:
> On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote:
> 
>> I'm now wondering if I need to support BINARY (literal8) for 
>> CATENATE (TEXT parts)?  I don't see any mention of BINARY or 
>> literal8 in the CATENATE draft.
> 
> Damn! How did I miss that?
> 
> I'd sure like you to add the support for it and we'll fix CATENATE 
> the next time around.

BINARY is on the cards for a revision, I think, perhaps it could be 
added to that? Might be able to get it all sorted out quicker.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Thu, 9 Mar 2006 11:31:48 -0800
To: Ken Murchison <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [lemonade] BINARY & CATENATE
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On 3/8/06 at 9:30 PM -0500, Ken Murchison wrote:

>I'm now wondering if I need to support BINARY (literal8) for 
>CATENATE (TEXT parts)?  I don't see any mention of BINARY or 
>literal8 in the CATENATE draft.

Damn! How did I miss that?

I'd sure like you to add the support for it and we'll fix CATENATE 
the next time around.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 9 Mar 2006 14:41:31 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda items for Dallas
Sender: [email-masked]

5) If in scope, I'd like some comments on draft-gulbrandsen-imap-view-00.txt.

Arnt

Date: Wed, 08 Mar 2006 21:30:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked], [email-masked]
Subject: BINARY & CATENATE
Sender: [email-masked]

With the help of the good folks at Lucent I've been working on adding 
support for BINARY APPEND to Cyrus (to go along with its existing 
support for BINARY FETCH).

I'm now wondering if I need to support BINARY (literal8) for CATENATE 
(TEXT parts)?  I don't see any mention of BINARY or literal8 in the 
CATENATE draft.

And what about CTE=binary in messages/parts fetched via URLs?

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Wed, 08 Mar 2006 20:27:58 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Agenda items for Dallas
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 3) ANNOTATE.
>
> Do we go forward or start again from scratch? I want, no, I _need_ 
> annotations. My needs are basically: Storing named variables whose 
> types are numbers, bools, enums and string variables. Bools I can do 
> with flags.

4). I've talked to Lisa and suggested to poll people what extensions 
they want to work on, as opposed to what in our charter. I've promised 
to write down some suggestions/questions.

Date: Wed, 8 Mar 2006 21:13:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda items for Dallas
Sender: [email-masked]

3) ANNOTATE.

Do we go forward or start again from scratch? I want, no, I _need_ 
annotations. My needs are basically: Storing named variables whose 
types are numbers, bools, enums and string variables. Bools I can do 
with flags.

Arnt

Date: Wed, 08 Mar 2006 20:05:41 +0000
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: Agenda items for Dallas
Sender: [email-masked]

Pete Resnick wrote:

> As of now, we are meeting on Wednesday from 1300-1500.
>
> Document authors: Please send agenda items ASAP.

May I suggest:
1). Review remaining issues with LIST-EXTENDED (I will send a list of 
issues separately).
2). Review Chris'/Arnt's comparators draft and I18N draft.

Date: Wed, 8 Mar 2006 11:43:28 -0800
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Agenda items for Dallas
Sender: [email-masked]

As of now, we are meeting on Wednesday from 1300-1500.

Document authors: Please send agenda items ASAP.

Thanks,

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 8 Mar 2006 20:40:51 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: condstore will come out as an RFC in its present form?
Sender: [email-masked]

Lisa Dusseault writes:
> Better to start working on a brand new condstore and obsolete  the one 
> that eventually makes it out of the RFC process.

Even better to start implementing ;)

Arnt

To: "Arnt Gulbrandsen" <[email-masked]>, [email-masked]
Subject: Re: condstore will come out as an RFC in its present form?
Date: Wed, 08 Mar 2006 11:31:20 -0800
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

It's gone, dude!

You can check the status with the datatracker tool:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=10164

There would have to be serious flaws to bring it back through the IESG  
approval process again as we did it twice with that document, quite  
unusually.  Better to start working on a brand new condstore and obsolete  
the one that eventually makes it out of the RFC process.

We can fix nits while the document is in RFC Ed queue -- the authors get a  
last chance to fix typos, small errors or formatting problems in Author's  
48 hr review at the end of the process.

Lisa

On Wed, 08 Mar 2006 10:27:22 -0800, Arnt Gulbrandsen  
<[email-masked]> wrote:

>
> Or can it still change?
>
> I feel like implementing it. Been spending too much time editing  
> documents and not enough writing code, and I know some neat and  
> convenient things I could do with condstore ;)
>
> Arnt
>

Date: Wed, 8 Mar 2006 20:12:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: condstore will come out as an RFC in its present form?
Sender: [email-masked]

Alexey Melnikov writes:
> It just got approved the second time in the last 2 years ;-).

I noticed.

> Do you have any specific changes/suggestions you want to do to Condstore?

No, I quite like it, I was just worried that it might still change. 
(Shrink to 32 bits, perhaps. A total put-off from my point of view.)

If I come across any misplaced commas or other auth48 items for you, 
I'll send you and Steve mail privately.

Arnt

From: "Scott Hollenbeck" <[email-masked]>
To: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked]
Subject: RE: condstore will come out as an RFC in its present form?
Date: Wed, 8 Mar 2006 13:58:22 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Arnt Gulbrandsen [mailto:[email-masked]] 
> Sent: Wednesday, March 08, 2006 1:27 PM
> To: [email-masked]
> Subject: condstore will come out as an RFC in its present form?
> 
> 
> Or can it still change?
> 
> I feel like implementing it. Been spending too much time editing 
> documents and not enough writing code, and I know some neat and 
> convenient things I could do with condstore ;)

The IESG just re-approved it last week.  As far as the IESG is concerned,
the current version is what will be published as an RFC.

-Scott-

Date: Wed, 08 Mar 2006 18:58:13 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: condstore will come out as an RFC in its present form?
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Or can it still change?

It just got approved the second time in the last 2 years ;-).

There might be some minor tweaks to Condstore caused by interaction with 
ESEARCH extension, but this is most likely be a separate extension.

Do you have any specific changes/suggestions you want to do to 
Condstore? If they are minor editorial things, they can be addressed 
when moving to Draft [Alexey is being overly optimistic, please ignore him].

Date: Wed, 8 Mar 2006 19:27:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: condstore will come out as an RFC in its present form?
Sender: [email-masked]

Or can it still change?

I feel like implementing it. Been spending too much time editing 
documents and not enough writing code, and I know some neat and 
convenient things I could do with condstore ;)

Arnt

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, imapext mailing list <[email-masked]>, imapext chair <[email-masked]>, imapext chair <[email-masked]>
Subject: Protocol Action: 'IMAP Extension for Conditional STORE  operation' to Proposed Standard 
Date: Mon, 06 Mar 2006 16:16:09 -0500
Sender: [email-masked]

The IESG has approved the following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-09.txt> as a Proposed Standard

This document is the product of the Internet Message Access Protocol Extension Working Group.  The IESG approved version -05 of this document in August 2003,
but the working group revised the document to correct some issues that were
discovered after IESG approval.

The IESG contact persons are Scott Hollenbeck and Ted Hardie.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-09.txt

Technical Summary

Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox.  Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients need a
mechanism to synchronize state changes for messages within the mailbox.
They must be able to guarantee that only one client can change message
state (e.g., message flags or annotations) at any time.  An example of
such an application is use of an IMAP mailbox as a message queue with
multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism 
for message state information that can detect and resolve conflicts 
between multiple writing mail clients.
  
Working Group Summary
 
This document is a product of the imapext working group.  An earlier
version of this document (draft-ietf-imapext-condstore-05) was approved
by the IESG for publication as a Proposed Standard RFC in December
2003, but the working group decided that changes needed to be made
before the document was published as an RFC.  The rationale for the
changes is described in a comment archived in the I-D Tracker.
 
Protocol Quality
 
Ned Freed and Scott Hollenbeck reviewed this specification for the IESG.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-16.txt 
Date: Mon, 06 Mar 2006 15:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-16.txt
	Pages		: 36
	Date		: 2006-3-6
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions, such as Mailbox Referrals, that have required
specialized lists we have had to expand the number of list commands,
since each extension must add its function to both LIST and LSUB, and
these commands are not, as they are defined, extensible.  If we've
needed the extensions to work together, we've had to add a set of
commands to mix the different options, the set increasing in size
with each new extension.  This document describes an extension to the
base LIST command that will allow these additions to be done with
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-16.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-16.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-16.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-16.txt

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

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

--OtherAccess--

--NextPart--

From: "Spencer Dawkins" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Scott Hollenbeck" <[email-masked]>, "General Area Review Team" <[email-masked]>, <[email-masked]>
Subject: Re: Gen-ART Review of draft-newman-i18n-comparator-06.txt
Date: Mon, 6 Mar 2006 07:00:12 -0600
Sender: [email-masked]

Hi, Arnt,

I'm ok with most of your responses - just to follow up on a couple of places 
where my comment may not have been well-explained...

Spencer

From: "Arnt Gulbrandsen" <[email-masked]>

> Spencer Dawkins writes:
>> I was selected as General Area Review Team reviewer for this 
>> specification
>> (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> Is the following text
>> saying, "MAY return either "error" or "no-match" if the input strings are
>> not valid character strings ..."? The current text doesn't seem to say 
>> what
>> happens when the input strings aren't valid and the equality function
>> doesn't return "error", which is only a MAY strength ("so don't be 
>> surprised
>> when your server does this").
>>
>>   The equality function always returns "match" or "no-match" when
>>   supplied valid input, and MAY return "error" if the input strings are
>>   not valid character strings or violate other collation constraints.
>
> I'll have to think about this some more.
>
> The question is, should a collation be required to report "error" for 
> input outside its domain, or should it do whatever comes easiest?

I was thinking about this from the client's perspective (if the collation 
doesn't report "error", how does the client know to report anything to 
someone who might be able to fix the input?).

>> 7.1.  Collation Registration Procedure
>>
>> Spencer: I'm not trying to change existing practice, but the IESG is 
>> having
>> enough fun reviewing appeals these days that if the appeal track started
>> with the APPS area directors, I'm sure that the other ADs would be 
>> thrilled.
>> :-(
>
> I think I see what you're trying to say, but I'm feeling uncertain enough 
> that I'd appreciate some elaboration.
>
> Did you perhaps read the following text as saying that the designated 
> expert needs to be an IESG member?

No, I'm sorry that I wasn't clearer. I was trying to say that if the 
designated expert fumbles the evaluation, perhaps talking to an APPS-area AD 
would be sufficient to resolve most appeals, without involving the rest of 
the IESG, unless the APPS-area AD fumbles the first-level appeal.

If this stuff is already being appealed directly to IESG without a one-AD 
stop, I'm not trying to change anything. Scott, can you inject clue here?

>>   The IETF will create a mailing list, [email-masked], which can be
>>   used for public discussion of collation proposals prior to
>>   registration.  Use of the mailing list is encouraged but not
>>   required.  The actual registration procedure will not begin until the
>>   completed registration template is sent to [email-masked].  The IESG
>>   will appoint a designated expert who will monitor the
>>   [email-masked] mailing list and review registrations forwarded
>>   from IANA.  The designated expert is expected to tell IANA and the
>>   submitter of the registration within two weeks whether the
>>   registration is approved, approved with minor changes, or rejected
>>   with cause.  When a registration is rejected with cause, it can be
>>   re-submitted if the concerns listed in the cause are addressed.
>>   Decisions made by the designated expert can be appealed to the IESG
>>   and subsequently follow the normal appeals procedure for IESG
>>   decisions. 

Date: Thu, 02 Mar 2006 20:23:29 +0000
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Chris Newman <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Thu Mar  2 12:36:38 2006, Arnt Gulbrandsen wrote:
> 1. No way to change comparator within the search command. Simple to 
> implement for servers. Clients must change comparator before/after 
> the search command.
> 
> 
I think this is just too weak. A command to set (and return) a 
default comparator is good.

> 2. Comparator can be set at the start, much like CHARSET. A bit 
> tricky to do in the syntax, if I remember correctly, and saves a 
> roundtrip or two. Otherwise identical to the previous option.
> 
> 
This is what I was suggesting, in case that's not clear.

The syntax to specify this is in IMAP ABNF, I checked - it would look 
like COMPARATOR (i;octet) - the argument to the COMPARATOR search 
option has to be a list.

> 3. A comparator thingy which can go between any two search-keys and 
> which changes the comparator used from that point onwards. (This is 
> what we had, if I remember correctly.)
> 
> 
That's truly vile. I agree with you and Mark.

> 4. A new search-key which takes a comparator name and a search-key, 
> and executes that search-key with that collation.
> 
> 
Okay, this would be best, but I think it's going to be very ugly 
retrofitting this kind of mechanism onto IMAP. There's lots of 
obvious use-cases for it, but I strongly suspect the simpler route to 
go is to allow a Sieve test command to be wrapped in an astring and 
used as a search-key, essentially deprecating the string-orientated 
IMAP search keys. This is probably controversial, and doesn't belong 
in this document.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Thu, 2 Mar 2006 19:49:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-newman-i18n-comparator-07.txt just submitted
Cc: Chris Newman <[email-masked]>, Martin =?iso-8859-1?q?D=FCrst?= <[email-masked]>, Mark Davis <[email-masked]>, [email-masked]
Sender: [email-masked]

---
Content-Type: text/plain; format=flowed

Mark Davis writes:
> Can you send out or post a copy, so we can see it before monday?

Sure. (Some people are awfully sensitive about large list mail, that's 
why I didn't send it right away.)

Arnt

---
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; size=72465;
  filename=draft-newman-i18n-comparator-07.txt

Network Working Group                                          C. Newman
Internet-Draft                                          Sun Microsystems
Expires: September 3, 2006                                     M. Duerst
                                                                     AGU
                                                          A. Gulbrandsen
                                                                    Oryx
                                                           March 2, 2006

            Internet Application Protocol Collation Registry
                  draft-newman-i18n-comparator-07.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Many Internet application protocols include string-based lookup,
   searching, or sorting operations.  However the problem space for
   searching and sorting international strings is large, not fully
   explored, and is outside the area of expertise for the Internet
   Engineering Task Force (IETF).  Rather than attempt to solve such a

Newman, et al.          Expires September 3, 2006               [Page 1]
=0C
Internet-Draft             Collation Registry                 March 2006

   large problem, this specification creates an abstraction framework so
   that application protocols can precisely identify a comparison
   function and the repertoire of comparison functions can be extended
   in the future.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used in this Document  . . . . . . . . . . . .  4
   2.  Collation Definition and Purpose . . . . . . . . . . . . . . .  4
     2.1.  Definition . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Some Other Terms Used in this Document . . . . . . . . . .  5
     2.4.  Sort Keys  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Collation Name Syntax  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Basic Syntax . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Ordering Direction . . . . . . . . . . . . . . . . . . . .  6
     3.4.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.5.  Naming Guidelines  . . . . . . . . . . . . . . . . . . . .  7
   4.  Collation Specification Requirements . . . . . . . . . . . . .  7
     4.1.  API  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Operations Supported . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  Equality . . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.2.  Substring  . . . . . . . . . . . . . . . . . . . . . .  9
       4.2.3.  Ordering . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Internal Canonicalization Algorithm  . . . . . . . . . . . 10
     4.4.  Use of Lookup Tables . . . . . . . . . . . . . . . . . . . 10
     4.5.  Multi-Value Attributes . . . . . . . . . . . . . . . . . . 10
   5.  Application Protocol Requirements  . . . . . . . . . . . . . . 11
     5.1.  Character Encoding . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Operations . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  Canonicalization Function  . . . . . . . . . . . . . . . . 12
     5.5.  Disconnected Clients . . . . . . . . . . . . . . . . . . . 12
     5.6.  Error Codes  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.7.  Octet Collation  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Use by Existing Protocols  . . . . . . . . . . . . . . . . . . 13
   7.  Collation Registration . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Collation Registration Procedure . . . . . . . . . . . . . 13
     7.2.  Collation Registration Format  . . . . . . . . . . . . . . 14
       7.2.1.  Registration Template  . . . . . . . . . . . . . . . . 14
       7.2.2.  The collation Element  . . . . . . . . . . . . . . . . 14
       7.2.3.  The name Element . . . . . . . . . . . . . . . . . . . 15
       7.2.4.  The title Element  . . . . . . . . . . . . . . . . . . 15
       7.2.5.  The functions Element  . . . . . . . . . . . . . . . . 15
       7.2.6.  The specification Element  . . . . . . . . . . . . . . 15

Newman, et al.          Expires September 3, 2006               [Page 2]
=0C
Internet-Draft             Collation Registry                 March 2006

       7.2.7.  The submitter Element  . . . . . . . . . . . . . . . . 15
       7.2.8.  The owner Element  . . . . . . . . . . . . . . . . . . 15
       7.2.9.  The version Element  . . . . . . . . . . . . . . . . . 16
       7.2.10. The UnicodeVersion Element . . . . . . . . . . . . . . 16
       7.2.11. The UCAVersion Element . . . . . . . . . . . . . . . . 16
       7.2.12. The UCAMatchLevel Element  . . . . . . . . . . . . . . 16
     7.3.  DTD for Collation Registration . . . . . . . . . . . . . . 17
     7.4.  Structure of Collation Registry  . . . . . . . . . . . . . 17
     7.5.  Example Initial Registry Summary . . . . . . . . . . . . . 18
   8.  Guidelines for Expert Reviewer . . . . . . . . . . . . . . . . 18
   9.  Initial Collations . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  ASCII Numeric Collation  . . . . . . . . . . . . . . . . . 19
       9.1.1.  ASCII Numeric Collation Description  . . . . . . . . . 19
       9.1.2.  ASCII Numeric Collation Registration . . . . . . . . . 20
     9.2.  ASCII Casemap Collation  . . . . . . . . . . . . . . . . . 20
       9.2.1.  ASCII Casemap Collation Description  . . . . . . . . . 20
       9.2.2.  Legacy English Casemap Collation Registration  . . . . 21
       9.2.3.  English Casemap Collation Registration . . . . . . . . 21
     9.3.  Nameprep Collation . . . . . . . . . . . . . . . . . . . . 21
       9.3.1.  Nameprep Collation Description . . . . . . . . . . . . 21
       9.3.2.  Nameprep Collation Registration  . . . . . . . . . . . 22
     9.4.  Basic Collation  . . . . . . . . . . . . . . . . . . . . . 22
       9.4.1.  Basic Collation Description  . . . . . . . . . . . . . 22
       9.4.2.  Basic Collation Registration . . . . . . . . . . . . . 24
       9.4.3.  Basic Accent Sensitive Match Collation Registration  . 25
       9.4.4.  Basic Case Sensitive Match Collation Registration  . . 25
     9.5.  Octet Collation  . . . . . . . . . . . . . . . . . . . . . 25
       9.5.1.  Octet Collation Description  . . . . . . . . . . . . . 25
       9.5.2.  Octet Collation Registration . . . . . . . . . . . . . 26
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   12. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 27
   13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     13.1. Changes From -06 . . . . . . . . . . . . . . . . . . . . . 27
     13.2. Changes From -05 . . . . . . . . . . . . . . . . . . . . . 28
     13.3. Changes From -04 . . . . . . . . . . . . . . . . . . . . . 28
     13.4. Changes From -03 . . . . . . . . . . . . . . . . . . . . . 28
     13.5. Changes From -02 . . . . . . . . . . . . . . . . . . . . . 29
     13.6. Changes From -01 . . . . . . . . . . . . . . . . . . . . . 29
     13.7. Changes From -00 . . . . . . . . . . . . . . . . . . . . . 29
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 30
     14.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33

Newman, et al.          Expires September 3, 2006               [Page 3]
=0C
Internet-Draft             Collation Registry                 March 2006

1.  Introduction

   The ACAP [12] specification introduced the concept of a comparator
   (which we call collation in this document), but failed to create an
   IANA registry.  With the introduction of stringprep [6] and the
   Unicode Collation Algorithm [8], it is now time to create that
   registry and populate it with some initial values appropriate for an
   international community.  This specification replaces and generalizes
   the definition of a comparator in ACAP and creates a collation
   registry.

1.1.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [1].

   The attribute syntax specifications use the Augmented Backus-Naur
   Form (ABNF) [2] notation including the core rules defined in Appendix
   A. This also inherits ABNF rules from Language Tags [5].

2.  Collation Definition and Purpose

2.1.  Definition

   A collation is a named function which takes two arbitrary length
   strings as input and can be used to perform one or more of three
   basic comparison operations: equality test, substring match, and
   ordering test.

2.2.  Purpose

   Collations provide a multi-protocol abstraction layer for comparison
   functions so the details of a particular comparison operation can be
   specified by someone with appropriate expertise independent of the
   application protocol that consumes that collation.  This is similar
   to the way a charset [14] separates the details of octet to character
   mapping from a protocol specification such as MIME [10] or the way
   SASL [11] separates the details of an authentication mechanism from a
   protocol specification such as ACAP [12].

Newman, et al.          Expires September 3, 2006               [Page 4]
=0C
Internet-Draft             Collation Registry                 March 2006

   Here is a small diagram to help illustrate the value of this
   abstraction layer:

   +-------------------+                         +-----------------+
   | IMAP i18n SEARCH  |--+                      | Basic           |
   +-------------------+  |                   +--| Collation Spec  |
                          |                   |  +-----------------+
   +-------------------+  |  +-------------+  |  +-----------------+
   | ACAP i18n SEARCH  |--+--| Collation   |--+--| A stringprep    |
   +-------------------+  |  | Registry    |  |  | Collation Spec  |
                          |  +-------------+  |  +-----------------+
   +-------------------+  |                   |  +-----------------+
   | ...other protocol |--+                   |  | locale-specific |
   +-------------------+                      +--| Collation Spec  |
                                                 +-----------------+

   Thus IMAP, ACAP and future application protocols with international
   search capability simply specify how to interface to the collation
   registry instead of each protocol specification having to specify all
   the collations it supports.

2.3.  Some Other Terms Used in this Document

   The terms client, server and protocol are used in somewhat unusual
   senses.

   Client means a user, or a program acting directly on behalf of a
   user.  This may be an mail reader acting as an IMAP client, or it may
   be an interactive shell where the user can type protocol directly, or
   it may be a script or program written by the user.

   Server means a program that performs services requested by the
   client.  This may be a traditional server such as an HTTP server, or
   it may be a Sieve [15] interpreter running a Sieve script written by
   a user.  A server needs to use the operations provided by collations
   in order to fulfil the client's requests.

   The protocol describes how the client informs the server what it
   wants done, and (if applicable) how the server tells the client about
   the results.  IMAP is a protocol by this definition, and so is the
   Sieve language.

2.4.  Sort Keys

   One component of a collation is a transformation which turns a string
   into a sort key, which is then used while sorting.

   The transformation can range from an identity mapping (e.g., the

Newman, et al.          Expires September 3, 2006               [Page 5]
=0C
Internet-Draft             Collation Registry                 March 2006

   i;octet collation Section 9.5) to a mapping which makes the string
   unreadable to a human (e.g., the basic collation Section 9.4).

   This is an implementation detail of collations or servers.  A
   protocol SHOULD NOT expose it, since some collations leave the sort
   key's format up to the implementation, and current conformant
   implementations are known to use different formats.

3.  Collation Name Syntax

3.1.  Basic Syntax

   The collation name itself is a single US-ASCII string beginning with
   a letter and made up of letters, digits, or one of the following 4
   symbols: "-", ";", "=3D" or ".".  The name MUST NOT be longer than 254
   characters.

     collation-char  =3D  ALPHA / DIGIT / "-" / ";" / "=3D" / "."

     collation-name  =3D  ALPHA *253collation-char

3.2.  Wildcards

   The string a client uses to select a collation MAY contain a wildcard
   ("*") character which matches zero or more collation-chars.  Wildcard
   characters MUST NOT be adjacent.  If the wildcard string matches
   multiple collations, the server SHOULD select the collation with the
   broadest scope (preferably international scope), the most recent
   table versions and the greatest number of supported operations.

     collation-wild  =3D  ("*" / (ALPHA ["*"])) *(collation-char ["*"])
                         ; MUST NOT exceed 254 characters total

3.3.  Ordering Direction

   When used as a protocol element for ordering, the collation name MAY
   be prefixed by either "+" or "-" to explicitly specify an ordering
   direction.  As mentioned previously, "+" has no effect on the
   ordering operation, while "-" negates the result of the ordering
   operation.  In general, collation-order is used when a client
   requests a collation, and collation-sel is used when the server
   informs the client of the selected collation.

     collation-sel   =3D  ["+" / "-"] collation-name

     collation-order =3D  ["+" / "-"] collation-wild

Newman, et al.          Expires September 3, 2006               [Page 6]
=0C
Internet-Draft             Collation Registry                 March 2006

3.4.  URIs

   Some protocols are designed to use URIs [4] to refer to collations
   rather than simple tokens.  A special section of the IANA web page is
   reserved for such usage.  The "collation-uri" form is used to refer
   to a specific IANA registry entry for a specific named collation (the
   collation registration may not actually be present if it is
   experimental).  The "collation-auri" form is an abstract name for an
   ordering, a collation pattern or a vendor private collatorn.

     collation-uri   =3D  "http://www.iana.org/assignments/collation/"
                        collation-name ".xml"

     collation-auri  =3D  ( "http://www.iana.org/assignments/collation/"
                        collation-order [".xml"]) / other-uri

     other-uri       =3D  <absoluteURI>
                     ;  excluding the IANA collation namespace.

3.5.  Naming Guidelines

   While this specification makes no absolute requirements on the
   structure of collation names, naming consistency is important, so the
   following initial guidelines are provided.

   Collation names with an international audience typically begin with
   "i;".  Collation names intended for a particular language or locale
   typically begin with a language tag [5] followed by a ";".  After the
   first ";" is normally the name of the general collation algorithm,
   followed by a series of algorithm modifications separated by the ";"
   delimiter.  Parameterized modifications will use "=3D" to delimit the
   parameter from the value.  The version numbers of any lookup tables
   used by the algorithm SHOULD be present as parameterized
   modifications.

   Collation names of the form *;vnd-domain.com;* are reserved for
   vendor-specific collations created by the owner of the domain name
   following the "vnd-" prefix (e.g. vnd-example.com for the vendor
   example.com).  Registration of such collations (or the name space as
   a whole) with intended use of "Vendor" is encouraged when a public
   specification or open-source implementation is available, but is not
   required.

4.  Collation Specification Requirements

Newman, et al.          Expires September 3, 2006               [Page 7]
=0C
Internet-Draft             Collation Registry                 March 2006

4.1.  API

   The collation itself decides what it operates on.  Most collations
   are expected to operate on character strings.  The i;octet
   (Section 9.5) collation operates on octet strings.  The i;ascii-
   numeric (Section 9.1) operation operates on numbers.

   This specification defines the collation interface in terms of octet
   strings, however, implementations may choose to use character strings
   instead.  Such implementations may not be able to implement e.g.
   i;octet.  Since i;octet is not currently mandatory to implement for
   any protocol, this should not be a problem.

4.2.  Operations Supported

   A collation specification MUST state which of the three basic
   operations are supported (equality, substring, ordering) and how to
   perform each of the supported operations on any two input character
   strings including empty strings.  Collations must be deterministic,
   i.e. given a collation with a specific name, and any two fixed input
   strings, the result MUST be the same for the same operation.

   In general, collation operations should behave as their names
   suggest.  While a collation may be new, the operations are not, so
   the new collation's algorithm for each operation should be as similar
   as possible to those of older collations.  For example, a collation
   should not provide a "substring" operator that would morph IMAP
   substring SEARCH into another kind of search.

   Note that for any single collation, either none or all of the
   operations can return "error".  For example, it is not possible to
   have an equality operator that never returns "error" and a substring
   operator that occasionally does.

4.2.1.  Equality

   The equality test always returns "match" or "no-match" when supplied
   valid input, and MAY return "error" if one or both input strings are
   not valid character strings or violate other collation constraints.

   The equality test MUST be reflexive, symmetric and transitive.

   If a collation provides either a substring or an ordering test, it
   MUST also provide an equality test.  The substring and/or ordering
   tests MUST be consistent with the equality test.

   In this specification, the return values of the equality test are
   called "match", "no-match" and "error".  This is not a specification,

Newman, et al.          Expires September 3, 2006               [Page 8]
=0C
Internet-Draft             Collation Registry                 March 2006

   merely a choice of phrasing.

4.2.2.  Substring

   The substring matching operation determines if the first string is a
   substring of the second string, ie. if the second string contains any
   string which is equal to the first, as defined by the collation's
   equality operator.

   A collation which supports substring matching will automatically
   support two special cases of substring matching: prefix and suffix
   matching if those special cases are supported by the application
   protocol.  It returns "match" or "no-match" when supplied valid input
   and returns "error" when supplied invalid input.

   Application protocols MAY return position information for substring
   matches.  If this is done, the position information SHOULD include
   both the starting offset and the ending offset for each match.  All
   matching substrings should be reported, even overlapping matches.

   A string is a substring of itself.  The empty string is a substring
   of all strings.  "Contain" is not defined by this specification.

   Note that the substring operation of some collations can match
   strings of unequal length.  For example, a pre-composed accented
   character can match a decomposed accented character.  Unicode
   Collation Algorithm [8] discusses this in more detail.

   In this specification, the return values of the substring operator
   are called "match", "no-match" and "error".  This is not a
   specification, merely a choice of phrasing.

4.2.3.  Ordering

   The ordering operator determines how two character strings are
   ordered.  It MUST be transitive and trichotomous.

   Ordering returns "less" if the first string is listed before the
   second string according to the collation, "greater" if the second
   string is listed before the first string, and "equal" if the two
   strings are equal as defined by the collation's equality operator.
   If the order of the two strings is reversed, the result of the
   ordering operator of the collation MUST be reversed, i.e. results
   which would be "greater" are instead "less" and results which would
   be "less" are instead "greater", while results which would be "equal"
   stay "equal".

   Since ordering is normally used to sort a list of items, "error" is

Newman, et al.          Expires September 3, 2006               [Page 9]
=0C
Internet-Draft             Collation Registry                 March 2006

   not a useful return value from the ordering operator.  Strings with
   errors that prevent the sorting algorithm from functioning correctly
   should sort to the end of the list.  Thus if the first string is
   invalid while the second string is valid, the result will be
   "greater".  If the second string is invalid while the first string is
   valid, the result will be "less".  If both strings are invalid, the
   result SHOULD match the result from the "i;octet" collation.

   When the collation is used with a "+" prefix, the behavior is the
   same as when used with no prefix.  When the collation is used with a
   "-" prefix, the result of the ordering operator of the collation MUST
   be reversed.

   In this specification, the return values of the ordering operator are
   called "less", "equal", "greater" and "error".  This is not a
   specification, merely a choice of phrasing.

4.3.  Internal Canonicalization Algorithm

   A collation specification MUST describe the internal canonicalization
   algorithm.  This algorithm can be applied to individual strings and
   the result can be stored to potentially optimize future comparison
   operations.  A collation MAY specify that the canonicalization
   algorithm is the identity function.  The output of the
   canonicalization algorithm MAY have no meaning to a human.

4.4.  Use of Lookup Tables

   Collations which use more than one customizable lookup table in a
   documented format MUST assign numbers to the tables they use.  This
   permits an application protocol command to access the tables used by
   a server collation.

4.5.  Multi-Value Attributes

   Some application protocols will permit the use of multi-value
   attributes with a collation.  This paragraph describes the rules that
   apply unless otherwise specified by the collation or application
   protocol.  In the case of the equality and substring operation, the
   operations are applied over each pair of single values from the two
   inputs.  If any combination produces an error, the result is an
   error.  Otherwise, if any combination produces a "match", the result
   is a match.  Otherwise the result is "no-match".  For the ordering
   operator, the smallest ordinal character string from the first set of
   values is compared to the smallest ordinal character string from the
   second set of values.

Newman, et al.          Expires September 3, 2006              [Page 10]
=0C
Internet-Draft             Collation Registry                 March 2006

5.  Application Protocol Requirements

   This section describes the requirements and issues that an
   application protocol needs to consider if it offers searching,
   substring matching and/or sorting, and permits the use of characters
   outside the US-ASCII charset.

5.1.  Character Encoding

   The protocol specification has to make sure that it is clear on which
   characters (rather than just octets) the collations are used.  This
   can be done by specifying the protocol itself in terms of characters
   (e.g. in the case of a query language), by specifying a single
   character encoding for the protocol (e.g.  UTF-8 [3]), or by
   carefully describing the relevant issues of character encoding
   labeling and conversion.  In the later case, details to consider
   include how to handle unknown charsets, any charsets which are
   mandatory-to-implement, any issues with byte-order that might apply,
   and any transfer encodings which need to be supported.

5.2.  Operations

   The protocol must specify which of the operations defined in this
   specification (equality matching, substring matching and ordering)
   can be invoked in the protocol, and how they are invoked.  There may
   be more than one way to invoke an operation.

   The protocol MUST provide a mechanism for the client to select the
   collation to use with equality matching, substring matching and
   ordering.

   If the protocol provides positional information for the results of a
   substring match, that positional information SHOULD fully specify the
   substring in the result that matches independent of the length of the
   search string.  For example, returning both the starting and ending
   offset of the match would suffice, as would the starting offset and a
   length.  Returning just the starting offset is not acceptable.  This
   rule is necessary because advanced collations can treat strings of
   different lengths as equal (for example, pre-composed and decomposed
   accented characters).

5.3.  Wildcards

   The protocol MUST specify whether it allows the use of wildcards in
   collation identifiers or not.  If the protocol allows wildcards,
   then:

Newman, et al.          Expires September 3, 2006              [Page 11]
=0C
Internet-Draft             Collation Registry                 March 2006

      The protocol MUST specify how comparisons behave in the absence of
      explicit collation negotiation or when a collation of "*" is
      requested.  The protocol MAY specify that the default collation
      used in such circumstances is sensitive to server configuration.
      The protocol SHOULD provide a way to list available collations
      matching a given wildcard pattern or patterns.

5.4.  Canonicalization Function

   If the protocol uses a canonicalization function for strings, then
   use of collations MAY be appropriate for that function.  As an
   example, many protocols use case independent strings.  In most cases,
   a simple ASCII mapping to upper/lower case works well.  However, in
   some cases a collation may be better, e.g. to handle Turkish dotted/
   dotless i.

5.5.  Disconnected Clients

   If the protocol supports disconnected clients, then a mechanism for
   the client to precisely replicate the server's collation algorithm is
   likely desirable.  Thus the protocol MAY wish to provide a command to
   fetch lookup tables used by charset conversions and collations.

5.6.  Error Codes

   The protocol specification should consider assigning protocol error
   codes for the following circumstances:
   o  The client requests the use of a collation by name or pattern, but
      no implemented collation matches that pattern.
   o  The client attempts to use a collation for an operation that is
      not supported by that collation.  For example, attempting to use
      the "i;ascii-numeric" collation for substring matching.
   o  The client uses an equality or substring matching collation and
      the result is an error.  It may be appropriate to distinguish
      between the two input strings, particularly when one is supplied
      by the client and one is stored by the server.  It might also be
      appropriate to distinguish the specific case of an invalid UTF-8
      string.

5.7.  Octet Collation

   The i;octet (Section 9.5) collation is only usable with protocols
   based on octet-strings.  Clients and servers MUST NOT use i;octet
   with other protocols.

   If the protocol permits the use of collations with data structures
   other than strings, the protocol MUST describe the default behavior
   for a collation with that data structure.

Newman, et al.          Expires September 3, 2006              [Page 12]
=0C
Internet-Draft             Collation Registry                 March 2006

6.  Use by Existing Protocols

   Both ACAP [12] and Sieve [15] are standards track specifications
   which used collations prior to the creation of this specification and
   registry.  Those standards do not meet all the application protocol
   requirements described in Section 5.  For backwards compatibility,
   those protocols use the "i;ascii-casemap" instead of "en;ascii-
   casemap".  These protocols allow the use of the i;octet (Section 9.5)
   collation working directly on UTF-8 data as used in these protocols.

   IMAP [16] also uses collation, although the use is explicit only when
   the COMPARATOR [18] extension is used.  The built-in IMAP substring
   operation and the ordering provided by the SORT [17] extension may
   not meet the requirements made in this document.

   Other protocols may be in a similar position.

7.  Collation Registration

7.1.  Collation Registration Procedure

   The IETF will create a mailing list, [email-masked], which can be
   used for public discussion of collation proposals prior to
   registration.  Use of the mailing list is encouraged but not
   required.  The actual registration procedure will not begin until the
   completed registration template is sent to [email-masked].  The IESG
   will appoint a designated expert who will monitor the
   [email-masked] mailing list and review registrations forwarded
   from IANA.  The designated expert is expected to tell IANA and the
   submitter of the registration within two weeks whether the
   registration is approved, approved with minor changes, or rejected
   with cause.  When a registration is rejected with cause, it can be
   re-submitted if the concerns listed in the cause are addressed.
   Decisions made by the designated expert can be appealed to the IESG
   and subsequently follow the normal appeals procedure for IESG
   decisions.

   Collation registrations in a standards track, BCP or IESG-approved
   experimental RFC are owned by the IETF, and changes to the
   registration follow normal procedures for updating such documents.
   Collation registrations in other RFCs are owned by the RFC author(s).
   Other collation registrations are owned by the individual(s) listed
   in the contact field of the registration and IANA will preserve this
   information.  Changes to a registration MUST be approved by the
   owner.  In the event the owner cannot be contacted for a period of
   one month and a change is deemed necessary, the IESG MAY re-assign
   ownership to an appropriate party.

Newman, et al.          Expires September 3, 2006              [Page 13]
=0C
Internet-Draft             Collation Registry                 March 2006

7.2.  Collation Registration Format

   Registration of a collation is done by sending a well-formed XML
   document that validates with collationreg.dtd (Section 7.3).

7.2.1.  Registration Template

   Here is a template for the registration:

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"YYYY" scope=3D"i18n" intendedUse=3D"common">
     <name>collation name</name>
     <title>technical title for collation</title>
     <functions>equality order substring</functions>
     <specification>specification reference</specification>
     <owner>email address of owner or IETF</owner>
     <submitter>email address of submitter<submitter>
     <version>1</version>
     <UnicodeVersion>3.2</UnicodeVersion>
     <UCAVersion>3.1.1</UCAVersion>
   </collation>

7.2.2.  The collation Element

   The root of the registration document MUST be a <collation> element.
   The collation element contains the other elements in the
   registration, which are described in the following sub-subsections,
   in the order given here.

   The <collation> element MAY include an "rfc=3D" attribute if the
   specification is in an RFC.  The "rfc=3D" attribute gives only the
   number of the RFC, without any prefix, such as "RFC", or suffix, such
   as ".txt".

   The <collation> element MUST include a "scope=3D" attribute, which MUST
   have one of the values "i18n", "local" or "other".

   The <collation> element MUST include an "intendedUse=3D" attribute,
   which must have one of the values "common", "limited", "vendor", or
   "deprecated".  Collation specifications intended for "common" use are
   expected to reference standards from standards bodies with
   significant experience dealing with the details of international
   character sets.

   Be aware that future revisions of this specification may add
   additional function types, as well as additional XML attributes and
   values.  Any system which automatically parses these XML documents

Newman, et al.          Expires September 3, 2006              [Page 14]
=0C
Internet-Draft             Collation Registry                 March 2006

   MUST take this into account to preserve future compatibility.  A DTD
   for the current definition of the collation registration template is
   given in Section 7.3.

7.2.3.  The name Element

   The <name> element gives the precise name of the collation.  The
   <name> element is mandatory.

7.2.4.  The title Element

   The <title> element gives the title of the collation.  The <title>
   element is mandatory.

7.2.5.  The functions Element

   The <functions> element lists which of the three operators
   ("equality", "order" or "substring") the collation provides.  The
   <functions> element is mandatory.

7.2.6.  The specification Element

   The <specification> element describes where to find the
   specification.  The <specification> element is mandatory.  It MAY
   have a URI attribute.  There may be more than one <specification>
   elements.  (For example, a collation which has previously been
   specified by a vendor may have been published on that vendor's web
   site, and subsequently by a standards organization.)

   In case the different specifications differ, the RFC is the
   definitive specification.

7.2.7.  The submitter Element

   The <submitter> element provides an RFC 2822 [13] email address for
   the person who submitted the registration.  It is optional if the
   <owner> element contains an email address.

   There may be more than one <submitter> element.

7.2.8.  The owner Element

   The <owner> element contains either the four letters "IETF" or an
   email address of the owner of the registration.  The <owner> element
   is mandatory.  There may be more than one <owner> element.  If so,
   all owners are equal.  Each owner can speak for all.

Newman, et al.          Expires September 3, 2006              [Page 15]
=0C
Internet-Draft             Collation Registry                 March 2006

7.2.9.  The version Element

   The <version> element is included when the registration is likely to
   be revised or has been revised in such a way that the results change
   for certain input strings.  The <version> element is optional.

7.2.10.  The UnicodeVersion Element

   The <UnicodeVersion> element indicates the version number of the
   UnicodeData file on which the collation is based.  The
   <UnicodeVersion> element is optional.

7.2.11.  The UCAVersion Element

   The <UCAVersion> element specifics the version of the Unicode
   Collation Algorithm on which the collation is based.  The
   <UCAVersion> element is optional.

7.2.12.  The UCAMatchLevel Element

   The <UCAMatchLevel> element specifies the number of Unicode Collation
   Algorithm sort key levels used for the equality and substring
   operations.  The <UCAMatchLevel> element is optional.

Newman, et al.          Expires September 3, 2006              [Page 16]
=0C
Internet-Draft             Collation Registry                 March 2006

7.3.  DTD for Collation Registration

   <!-
     DTD for Collation Registration Document

     Data types:

     entity      description
     =3D=3D=3D=3D=3D=3D      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     NUMBER      [0-9]+
     URI         As defined in RFC 3986
     CTEXT       printable ASCII text (no line-terminators)
     TEXT        character data
     ->
   <!ENTITY % NUMBER        "CDATA">
   <!ENTITY % URI           "CDATA">
   <!ENTITY % CTEXT         "#PCDATA">
   <!ENTITY % TEXT          "#PCDATA">
   <!ELEMENT collation      (name,title,functions,specification+,owner+,
                             submitter*,version?,UnicodeVersion?,
                             UCAVersion?,UCAMatchLevel?)>
   <!ATTLIST collation
             rfc            %NUMBER;                           "0"
             scope          (i18n|local|other)                 #IMPLIED
             intendedUse    (common|limited|vendor|deprecated) #IMPLIED>
   <!ELEMENT name           (%CTEXT;)>
   <!ELEMENT title          (%CTEXT;)>
   <!ELEMENT functions      (%CTEXT;)>
   <!ELEMENT specification  (%TEXT;)>
   <!ATTLIST specification
             uri            %URI;                              "">
   <!ELEMENT owner          (%CTEXT;)>
   <!ELEMENT submitter      (%CTEXT;)>
   <!ELEMENT version        (%CTEXT;)>
   <!ELEMENT UnicodeVersion (%CTEXT;)>
   <!ELEMENT UCAVersion     (%CTEXT;)>
   <!ELEMENT UCAMatchLevel  (%CTEXT;)>

7.4.  Structure of Collation Registry

   Once the registration is approved, IANA will store each XML
   registration document in a URL of the form
   http://www.iana.org/assignments/collation/collation-name.xml where
   collation-name is the contents of the name element in the
   registration.  Both the submitter and the designated expert is
   responsible for verifying that the XML is well-formed and complies
   with the DTD.

Newman, et al.          Expires September 3, 2006              [Page 17]
=0C
Internet-Draft             Collation Registry                 March 2006

   IANA will also maintain a text summary of the registry under the name
   http://www.iana.org/assignments/collation/summary.txt.  This summary
   is divided into four sections.  The first section is for collations
   intended for common use.  This section is intended for collation
   registrations published in IESG approved RFCs or for locally scoped
   collations from the primary standards body for that locale.  The
   designated expert is encouraged to reject collation registrations
   with an intended use of "common" if the expert believes it should be
   "limited", as it is desirable to keep the number of "common"
   registrations small and high quality.  The second section is reserved
   for limited use collations.  The third section is reserved for
   registered vendor specific collations.  The final section is reserved
   for deprecated collations.

7.5.  Example Initial Registry Summary

   The following is an example of how IANA might structure the initial
   registry summary.txt file:

     Collation                              Functions Scope Reference
     ---------                              --------- ----- ---------
   Common Use Collations:
     i;nameprep;v=3D1;uv=3D3.2                  e, o, s   i18n  [RFC XXXX]
     i;basic;uca=3D3.1.1;uv=3D3.2               e, o, s   i18n  [RFC XXXX]
     i;basic;uca=3D3.1.1;uv=3D3.2;match=3Daccent  e, o, s   i18n  [RFC XXXX]
     i;basic;uca=3D3.1.1;uv=3D3.2;match=3Dcase    e, o, s   i18n  [RFC XXXX]
     en;ascii-casemap                       e, o, s   Local [RFC XXXX]

   Limited Use Collations:
     i;octet                                e, o, s   Other [RFC XXXX]
     i;ascii-numeric                        e, o      Other [RFC XXXX]

   Vendor Collations:

   Deprecated Collations:
     i;ascii-casemap                        e, o, s   Local [RFC XXXX]

   References
   ----------
   [RFC XXXX]  Newman, C., "Internet Application Protocol Collation
               Registry", RFC XXXX, Sun Microsystems, October 2003.

8.  Guidelines for Expert Reviewer

   The expert reviewer appointed by the IESG has fairly broad latitude
   for this registry.  While a number of collations are expected

Newman, et al.          Expires September 3, 2006              [Page 18]
=0C
Internet-Draft             Collation Registry                 March 2006

   (particularly customizations of the basic collation for localized
   use), an explosion of collations (particularly common use collations)
   is not desirable for widespread interoperability.  However, it is
   important for the expert reviewer to provide cause when rejecting a
   registration, and when possible to describe corrective action to
   permit the registration to proceed.  The following table includes
   some example reasons to reject a registration with cause:
   o  The registration is not a well-formed XML document that follows
      the DTD.
   o  The registration has an intended use of "common", but there is no
      evidence the collation will be widely deployed, so it should be
      listed as "limited".
   o  The registration has an intended use of "common", but it is
      redundant with the functionality of a previously registered
      "common" collation.
   o  The registration has an intended use of "common", but the
      specification is not detailed enough to allow interoperable
      implementations by others.
   o  The collation name fails to precisely identify the version numbers
      of relevant tables to use.
   o  The registration fails to meet one of the "MUST" requirements in
      Section 4.
   o  The collation name fails to meet the syntax in Section 3.
   o  The collation specification referenced in the registration is
      vague or has optional features without a clear behavior specified.
   o  The referenced specification does not adequately address security
      considerations specific to that collation.
   o  The regitration's operations are needlessly different from those
      of traditional operations.

9.  Initial Collations

   This section describes an initial set of collations for the collation
   registry.

9.1.  ASCII Numeric Collation

9.1.1.  ASCII Numeric Collation Description

   The "i;ascii-numeric" collation is a simple collation intended for
   use with arbitrary sized unsigned decimal integer numbers stored as
   octet strings of US-ASCII digits (0x30 to 0x39).  It supports
   equality and ordering, but does not support the substring operator.

   The equality operator returns "match" if the two strings represent
   the same number (ie. leading zeroes are disregarded), "no-match" if
   the two strings represent different numbers, and "error" if either

Newman, et al.          Expires September 3, 2006              [Page 19]
=0C
Internet-Draft             Collation Registry                 March 2006

   string is empty or contains nondigits.

   The ordering operator returns "less" if the first string represents a
   smaller number than the second, "equal" if they represent the same
   number, and "greater" if the first string represents a larger number
   than the second.  If either string is empty or contains nondigits,
   the ordering operator returns the result of the i;octet ordering
   function.

   The associated canonicalization algorithm is to truncate the input
   string at the first non-digit character.

9.1.2.  ASCII Numeric Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"other" intendedUse=3D"limited">
     <name>i;ascii-numeric</name>
     <title>ASCII Numeric</title>
     <functions>equality order</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
   </collation>

9.2.  ASCII Casemap Collation

9.2.1.  ASCII Casemap Collation Description

   The "en;ascii-casemap" collation is a simple collation intended for
   use with English language text in pure US-ASCII.  It provides
   equality, substring and ordering operators.  The algorithm first
   applies a canonicalization algorithm to both input strings which
   subtracts 32 (0x20) from all octet values between 97 (0x61) and 122
   (0x7A) inclusive.  The result of the collation is then the same as
   the result of the "i;octet" collation for the canonicalized strings.
   Care should be taken when using OS-supplied functions to implement
   this collation as this is not locale sensitive, but functions such as
   strcasecmp and toupper are sometimes locale sensitive.

   For historical reasons, in the context of ACAP and Sieve, the name
   "i;ascii-casemap" is a synonym for this collation.

Newman, et al.          Expires September 3, 2006              [Page 20]
=0C
Internet-Draft             Collation Registry                 March 2006

9.2.2.  Legacy English Casemap Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"local" intendedUse=3D"deprecated">
     <name>i;ascii-casemap</name>
     <title>Legacy English Casemap</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
   </collation>

9.2.3.  English Casemap Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"local" intendedUse=3D"common">
     <name>en;ascii-casemap</name>
     <title>English Casemap</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
   </collation>

9.3.  Nameprep Collation

9.3.1.  Nameprep Collation Description

   The "i;nameprep;v=3D1;uv=3D3.2" collation is an implementation of the
   nameprep [7] specification based on normalization tables from Unicode
   version 3.2.  This collation applies the nameprep canoncialization
   function to both input strings and then returns the result of the
   i;octet collation on the canonicalized strings.  While this collation
   offers all three operators, the ordering operator it provides is
   inadequate for use by the majority of the world.

   Version number 1 is applied to nameprep as specified in RFC 3491.  If
   the nameprep specification is revised without any changes that would
   produce different results when given the same pair of input octet
   strings, then the version number will remain unchanged.

Newman, et al.          Expires September 3, 2006              [Page 21]
=0C
Internet-Draft             Collation Registry                 March 2006

       The table numbers for tables used by nameprep are as follows:

                 +--------------+-----------------------+
                 | Table Number | Table Name            |
                 +--------------+-----------------------+
                 |            1 | UnicodeData-3.2.0.txt |
                 |            2 | Table B.1             |
                 |            3 | Table B.2             |
                 |            4 | Table C.1.2           |
                 |            5 | Table C.2.2           |
                 |            6 | Table C.3             |
                 |            7 | Table C.4             |
                 |            8 | Table C.5             |
                 |            9 | Table C.6             |
                 |           10 | Table C.7             |
                 |           11 | Table C.8             |
                 |           12 | Table C.9             |
                 +--------------+-----------------------+

9.3.2.  Nameprep Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"common">
     <name>i;nameprep;v=3D1;uv=3D3.2</name>
     <title>Nameprep</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
     <version>1</version>
     <UnicodeVersion>3.2</UnicodeVersion>
   </collation>

9.4.  Basic Collation

9.4.1.  Basic Collation Description

   The basic collation is intended to provide tolerable results for a
   number of languages for all three operators (equality, substring and
   ordering) so it is suitable as a mandatory-to-implement collation for
   protocols which include ordering support.  The ordering operator of
   the basic collation is the Unicode Collation Algorithm [8] version 9
   (UCAv9).

   The equality and substring operators are created as described in
   UCAv9 section 8.  While that section is informative to UCAv9, it is
   normative to this collation specification.

Newman, et al.          Expires September 3, 2006              [Page 22]
=0C
Internet-Draft             Collation Registry                 March 2006

   This collation is based on Unicode version 3.2, with the following
   tables relevant:
   1.  For the normalization step,
       <http://www.unicode.org/Public/3.2-Update/UnicodeData-3.2.0.txt>
       is used.  Column 5 is used to determine the canonical
       decomposition, while column 3 contains the canonical combining
       classes necessary to attain canonical order.
   2.  The table of characters which require a logical order exception
       is a subset of the table in
       <http://www.unicode.org/Public/3.2-Update/PropList-3.2.0.txt> and
       is included here:

   0E40..0E44    ; Logical_Order_Exception
   # Lo   [5] THAI CHARACTER SARA E..THAI CHARACTER SARA AI MAIMALAI
   0EC0..0EC4    ; Logical_Order_Exception
   # Lo   [5] LAO VOWEL SIGN E..LAO VOWEL SIGN AI

   # Total code points: 10

   3.  The table used to translate normalized code points to a sort key
       is <http://www.unicode.org/reports/tr10/allkeys-3.1.1.txt>.

   UCAv9 includes a number of configurable parameters and steps labelled
   as potentially optional.  The following list summarizes the defaults
   used by this collation:
   o  The logical order exception step is mandatory by default to
      support the largest number of languages.
   o  Steps 2.1.1 to 2.1.3 are mandatory as the repertoire of the basic
      collation is intended to be large.
   o  The second level in the sort key is evaluated forwards by default.
   o  The variable weighting uses the "non-ignorable" option by default.
   o  The semi-stable option is not used by default.
   o  Support for exactly three levels of collation is the default
      behavior.
   o  No preprocessing step is used by the basic collation prior to
      applying the UCAv9 algorithm.  Note that an application protocol
      specification MAY require pre-processing prior to the use of any
      collations.
   o  The equality and substring algorithms exclude differences at level
      2 and 3 by default (thus it is case-insensitive and ignores
      accentual distinctions.
   o  The equality and substring algorithms use the "Whole Characters
      Only" feature described in UCAv9 section 8 by default.

   The exact collation name with these defaults is
   "i;basic;uca=3D3.1.1;uv=3D3.2".  When a specification states that the
   basic collation is mandatory-to-implement, only this specific name is
   mandatory-to-implement.

Newman, et al.          Expires September 3, 2006              [Page 23]
=0C
Internet-Draft             Collation Registry                 March 2006

   In order to allow modification of the optional behaviors, the
   following ABNF is used for variations of the basic collation:

     basic-collation  =3D  ("i" / Language-Tag) ";basic;uca=3D3.1.1;uv=3D3.=
2"
                         [";match=3Daccent" / ";match=3Dcase"]
                         [";tailor=3D" 1*collation-char ]

   If multiple modifiers appear, they MUST appear in the order described
   above.  The modifiers have the following meanings:
   match=3Daccent   Both the first and second levels of the sort keys are
                  considered relevant to the equality and substring
                  operations (rather than the default of first level
                  only).  This makes the matching functions sensitive to
                  accentual distinctions.
   match=3Dcase     The first three levels of sort keys are considered
                  relevant to the equality and substring operations.
                  This makes the matching functions sensitive to both
                  case and accentual distinctions.

   The default weighting option is "non-ignorable".  The "semi-stable"
   sort key option is not used by default.

   The canonicalization algorithm associated with this collation is the
   output of step 3 of the UCAv9 algorithm (described in section 4.3 of
   the UCA specification).  This canonicalization is not suitable for
   human consumption.

   Finally, the UCAv9 algorithm permits the "allkeys" table to be
   tailored to a language.  People who make quality tailorings are
   encouraged to register those tailorings using the collation registry.
   Tailoring names beginning with "x" are reserved for experimental use,
   are treated as "Limited use" and MUST NOT match wildcards if any
   registered collation is available that does match.

9.4.2.  Basic Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"common">
     <name>i;basic;uca=3D3.1.1;uv=3D3.2</name>
     <title>Basic</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
     <UnicodeVersion>3.2</UnicodeVersion>
     <UCAVersion>3.1.1</UCAVersion>
     <UCAMatchLevel>1</UCAMatchLevel>

Newman, et al.          Expires September 3, 2006              [Page 24]
=0C
Internet-Draft             Collation Registry                 March 2006

   </collation>

9.4.3.  Basic Accent Sensitive Match Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"common">
     <name>i;basic;uca=3D3.1.1;uv=3D3.2;match=3Daccent</name>
     <title>Basic Accent Sensitive Match</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
     <UnicodeVersion>3.2</UnicodeVersion>
     <UCAVersion>3.1.1</UCAVersion>
     <UCAMatchLevel>2</UCAMatchLevel>
   </collation>

9.4.4.  Basic Case Sensitive Match Collation Registration

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"common">
     <name>i;basic;uca=3D3.1.1;uv=3D3.2;match=3Dcase</name>
     <title>Basic Case Sensitive Match</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
     <UnicodeVersion>3.2</UnicodeVersion>
     <UCAVersion>3.1.1</UCAVersion>
     <UCAMatchLevel>3</UCAMatchLevel>
   </collation>

9.5.  Octet Collation

9.5.1.  Octet Collation Description

   The "i;octet" collation is a simple and fast collation intended for
   use on binary octet strings rather than on character data.  It is the
   only such collation; it is not possible to register additional
   collations with this property.  Protocols that want to make this
   collation available have to do so by explicitly allowing it.  If not
   explicitly allowed, it MUST NOT be used.  It never returns an "error"
   result.  It provides equality, substring and ordering operators.

   The ordering algorithm is as follows:

Newman, et al.          Expires September 3, 2006              [Page 25]
=0C
Internet-Draft             Collation Registry                 March 2006

   1.  If both strings are the empty string, return the result "equal".
   2.  If the first string is empty and the second is not, return the
       result "less".
   3.  If the second string is empty and the first is not, return the
       result "greater".
   4.  If both strings begin with the same octet value, remove the first
       octet from both strings and repeat this algorithm from step 1.
   5.  If the unsigned value (0 to 255) of the first octet of the first
       string is less than the unsigned value of the first octet of the
       second string, then return "less".
   6.  If this step is reached, return "greater".

   This algorithm is roughly equivalent to the C library function memcmp
   with appropriate length checks added.

   The matching operator returns "match" if the sorting algorithm would
   return "equal".  Otherwise the matching operator returns "no-match".

   The substring operator returns "match" if the first string is the
   empty string, or if there exists a substring of the second string of
   length equal to the length of the first string which would result in
   a "match" result from the equality function.  Otherwise the substring
   operator returns "no-match".

   The associated canonicalization algorithm is the identity operator.

9.5.2.  Octet Collation Registration

   This collation is defined with intendedUse=3D"limited" because it can
   only be used by protocols that explicitly allow it.

   <?xml version=3D'1.0'?>
   <!DOCTYPE rfc SYSTEM 'collationreg.dtd'>
   <collation rfc=3D"XXXX" scope=3D"i18n" intendedUse=3D"limited">
     <name>i;octet</name>
     <title>Octet</title>
     <functions>equality order substring</functions>
     <specification>RFC XXXX</specification>
     <owner>IETF</owner>
     <submitter>[email-masked]<submitter>
   </collation>

10.  IANA Considerations

   Section 7 defines how to register collations with IANA.  Section 9
   defines a list of predefined collations, which should be registered
   when this document is approved and published as an RFC.

Newman, et al.          Expires September 3, 2006              [Page 26]
=0C
Internet-Draft             Collation Registry                 March 2006

11.  Security Considerations

   Collations will normally be used with UTF-8 strings.  Thus the
   security considerations for UTF-8 [3], stringprep [6] and Unicode
   TR-36 [9] also apply and are normative to this specification.

12.  Open Issues

   Mark Davis writes:

   The sample registry would suffer a combinatorial explosion if
   parameters are not handled differently.  For example, with CLDR
   collations, there can be hundreds of locales, six different strength
   settings; four different case-first settings; three different
   alternate settings, backwards settings, normalization settings, case
   level settings, hiragana settings, and numeric settings; plus a
   variable-top setting which has a string as an operand.  Registering
   the combinations that people are allowed to use would be untenable.

   Use UCAv9 or UCAvLatest (14)?  Instead of using UCAv9, it sounds
   sensible to use "UCA", "UCA version x" or "UCA version x or greater"

   The change to en;ascii-casemap indicates that its use is local.  It's
   not.  The collation is not suitable to English since it doesn't
   handle common typography, signs like the pound sign, and even some
   words.  And it's not local, since many protocols (like SMTP) use
   ASCII casemapping even when used in non-English locales.

   Can the text on lookup tables be simplified greatly, to remove all
   the MUSTs related to e.g. downloading tables?  The client could get
   its tables from the collation spec rather than indirectly via the
   server.

   Should there be some text which references RFC 2434?  If not, the
   reference should die.

   The section on multi-value attributes seems to be a solution looking
   for a problem.  Frank Ellermann had questions about what it means.

13.  Change Log

13.1.  Changes From -06
   1.  Clarified equality and identity: equality is as defined by a
       collation, identity is stronger.

Newman, et al.          Expires September 3, 2006              [Page 27]
=0C
Internet-Draft             Collation Registry                 March 2006

   2.  Added reference to
       http://www.unicode.org/reports/tr10/#Searching.
   3.  Don't describe sort keys as a canonical representation of the
       string.
   4.  Permit disconnected clients to use wildcards.  (A disconnected
       client has to resolve the wildcard itself, in the same way that a
       server would.)
   5.  Change collation-wild to have the same length limit as collation.
   6.  Change to use "less" instead of "-1", etc., and specify that it's
       just phrasing, not specification.
   7.  Don't describe the equality, substring and ordering operations as
       functions.  The definition of collation uses the word function
       about the collation itself.  A function that has three functions?
       Something has to give.
   8.  Strike a requirement that selecting '*' is the same as not
       selecting any collation.  It restricted the protocol's default
       too much.  Existing code wasn't listening.
   9.  Left out the canonicalization/sort keys.

13.2.  Changes From -05
   1.  Added definitions of client, server and protocol, and prose to
       specify that while the IANA registrations of collations are
       written in terms octet strings, implementations may do it
       differently.
   2.  Changed the wording for ascii-numeric to treat the numbers as
       numbers, etc.
   3.  Added explicit property requirements for the three functions,
       e.g. that equality be symmetric.  Added requirements that the
       three functions be consistent, and that if any operations are
       present, equality must be (needed for consistency).
   4.  Random editing, e.g. changing 'numbers' for ascii-numeric to
       'integer numbers'.
   5.  Gave IMAP/SORT/COMPARATOR the same grandfather treatment as ACAP
       and SIEVE.

13.3.  Changes From -04

   Grammar and clarity changes only.  One (weak) example added.  No
   substantive changes.

13.4.  Changes From -03

   (This does not include all changes made.)
   1.  Checked and resolved most issues marked 'check whether this is
       true' or similar.
   2.  Resolved nameprep issue: No.

Newman, et al.          Expires September 3, 2006              [Page 28]
=0C
Internet-Draft             Collation Registry                 March 2006

   3.  Removed NULL for compatibility with existing collations (IMAP
       SORT, Sieve).
   4.  There can be multiple owners and submitters.  Say how.
   5.  Added a requirement that common collations must now be
       interoperable.  Insufficiently detailed specs cannot be "common".
   6.  Added a guideline that the operations provided by new collations
       should be reminiscent of similar operations on existing
       collations.

13.5.  Changes From -02

   1.  Changed from data being octet sequences (in UTF-8) to data being
       character sequences (with octet collation as an exception).
   2.  Made XML format description much more structured.
   3.  Changed <submittor> to <submitter>, because this spelling is much
       more common.
   4.  Defined 'protocol' to include query languages.
   5.  Reorganized document, in particular IANA considerations section
       (which newly is just a list of pointers).
   6.  Added subsections, and a 'Structure of this Document' section.
   7.  Updated references.
   8.  Created a 'Change Log' chapter, with sections for each draft.
   9.  Reduced 'Open issues' section, open issues are now maintained at
       http://www.w3.org/2004/08/ietf-collation.

13.6.  Changes From -01

   Add IANA comment to open issues.  Otherwise this is just a re-publish
   to keep the document alive.

13.7.  Changes From -00

   1.  Replaced the term comparator with collation.  While comparator is
       somewhat more precise because these abstract functions are used
       for matching as well as ordering, collation is the term used by
       other parts of the industry.  Thus I have changed the name to
       collation for consistency.
   2.  Remove all modifiers to the basic collation except for the
       customization and the match rules.  The other behavior
       modifications can be specified in a customization of the
       collation.
   3.  Use ";" instead of "-" as delimiter between parameters to make
       names more URL-ish.
   4.  Add URL form for comparator reference.
   5.  Switched registration template to use XML document.
   6.  Added a number of useful registration template elements related
       to the Unicode Collation Algorithm.

Newman, et al.          Expires September 3, 2006              [Page 29]
=0C
Internet-Draft             Collation Registry                 March 2006

   7.  Switched language from "custom" to "tailor" to match UCA language
       for tailoring of the collation algorithm.

14.  References

14.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [3]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        STD 63, RFC 3629, November 2003.

   [4]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", RFC 3986,
        January 2005.

   [5]  Alvestrand, H., "Tags for the Identification of Languages",
        BCP 47, RFC 3066, January 2001.

   [6]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
        Strings ("stringprep")", RFC 3454, December 2002.

   [7]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for
        Internationalized Domain Names (IDN)", RFC 3491, March 2003.

   [8]  Davis, M. and K. Whistler, "Unicode Collation Algorithm version
        9", July 2002,
        <http://www.unicode.org/reports/tr10/tr10-9.html>.

   [9]  Davis, M. and M. Suignard, "Unicode Security Considerations",
        February 2006, <http://www.unicode.org/reports/tr36/>.

14.2.  Informative References

   [10]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [11]  Myers, J., "Simple Authentication and Security Layer (SASL)",
         RFC 2222, October 1997.

   [12]  Newman, C. and J. Myers, "ACAP -- Application Configuration
         Access Protocol", RFC 2244, November 1997.

Newman, et al.          Expires September 3, 2006              [Page 30]
=0C
Internet-Draft             Collation Registry                 March 2006

   [13]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [14]  Freed, N. and J. Postel, "IANA Charset Registration
         Procedures", BCP 19, RFC 2978, October 2000.

   [15]  Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
         January 2001.

   [16]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
         4rev1", RFC 3501, March 2003.

   [17]  Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL
         - SORT AND THREAD EXTENSIONS", draft-ietf-imapext-sort-17.txt
         (work in progress), May 2004.

   [18]  Newman, C. and A. Gulbrandsen, "Internet Message Access
         Protocol Internationalization", draft-ietf-imapext-i18n-06.txt
         (work in progress), January 2006.

Newman, et al.          Expires September 3, 2006              [Page 31]
=0C
Internet-Draft             Collation Registry                 March 2006

Authors' Addresses

   Chris Newman
   Sun Microsystems
   1050 Lakes Drive
   West Covina, CA  91790
   US

   Email: [email-masked]

   Martin Duerst
   Aoyama Gakuin University
   5-10-1 Fuchinobe
   Sagamihara, Kanagawa  229-8558
   Japan

   Phone: +81 466 49 1170
   Fax:   +81 466 49 1171
   Email: [email-masked]
   URI:   http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/

  Note:   Please write "Duerst" with u-umlaut wherever possible, for
          example as "D&#252;rst" in XML and HTML.)

   Arnt Gulbrandsen
   Oryx Mail Systems GmbH
   Schweppermannstr. 8
   Munich  81671
   Germany

   Phone: +49 89 4502 9757
   Fax:   +49 89 4502 9758
   Email: [email-masked]
   URI:   http://www.oryx.com/arnt/

Newman, et al.          Expires September 3, 2006              [Page 32]
=0C
Internet-Draft             Collation Registry                 March 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Newman, et al.          Expires September 3, 2006              [Page 33]
=0C

-----

Date: Thu, 02 Mar 2006 10:26:41 -0800
From: Mark Davis <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Chris Newman <[email-masked]>, =?UTF-8?B?TWFydGluIETDvHJzdA==?= <[email-masked]>, [email-masked]
Subject: Re: draft-newman-i18n-comparator-07.txt just submitted
Sender: [email-masked]

Can you send out or post a copy, so we can see it before monday?

Arnt Gulbrandsen wrote:
> Arnt Gulbrandsen writes:
>   
>> Early next week, I hope.
>>     
>
> No. Just before the cutoff, early Monday afternoon by my time.
>
> Wait for that to comment, or get a copy from  me by email.
>
> Arnt
>
>
>
>   

Date: Thu, 2 Mar 2006 08:59:41 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Sender: [email-masked]

On Thu, 2 Mar 2006, Arnt Gulbrandsen wrote:
>> 3. A comparator thingy which can go between any two search-keys and which 
>> changes the comparator used from that point onwards.
> Speaking only for myself, 3 leaves a bad taste in my mouth. Feels like bad 
> design.

I agree.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Thu, 02 Mar 2006 15:37:09 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>> Related to this. The second paragraph says:
>>
>>    When AUTHENTICATE is used, some servers may support userids and
>>    passwords in Unicode [13]. However, such userids cannot be used as
>>    email addresses, and at present also seem to be incompatible with
>>    the current latest ACL drafts. Unless the ACL drafts resolve this,
>>    server authors are cautioned against supporting ACL and unicode
>>    userids simultaneously.
>>
>> The updated ACL got published as RFC 4314. So the end of this 
>> paragraph is wrong.
>
> Simplify my life. Give me text ;)

Delete everything till the end of paragraph, starting from ",and at 
present also seem to be incompatible".

Date: Thu, 2 Mar 2006 16:41:50 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-newman-i18n-comparator-07.txt just submitted
Cc: Chris Newman <[email-masked]>, Martin =?iso-8859-1?q?D=FCrst?= <[email-masked]>, [email-masked]
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Early next week, I hope.

No. Just before the cutoff, early Monday afternoon by my time.

Wait for that to comment, or get a copy from  me by email.

Arnt

Date: Thu, 2 Mar 2006 16:32:56 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Chris Newman <[email-masked]>, Martin =?iso-8859-1?q?D=FCrst?= <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>, [email-masked]
Subject: draft-newman-i18n-comparator-07.txt just submitted
Sender: [email-masked]

The internet-drafts edit seems to have a 2-3 day lag right now.

It's not complete. I'm not happy. I know I have comments from Martin 
Dürst that I haven't worked in yet (very sorry, Martin), and some other 
people's comments are also incompletely processed.

But I wanted to get this submitted. There were so many comments in the 
past week, and the diff is big. The only way to get a new revision out 
was to send it out incomplete.

$ diff -u /tmp/draft-newman-i18n-comparator-0[67].txt | wc -l
1380

There will be another draft fairly soon where I resolve the sort-key 
situation, work in Martin's comments and hopefully use a better DTD. 
The DTD change will also necessitate some textual changes. Early next 
week, I hope.

Now I have to do some of my own work.

Arnt

Date: Thu, 2 Mar 2006 14:17:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Cc: Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Dave Cridland wrote:
>> A simpler solution might be to promote SASL PLAIN as the i18n 
>> plaintext login, since that either will be, or has been, fixed, and 
>> deprecate LOGIN for even that.
>
> I would rather the document just state that both LOGIN usernames and 
> passwords are UTF-8 now.

Much as I'm in favour of that, I feel that this document is the wrong 
place for it. This document specifies two extensions. Making an 
unconditional change to 3501 in the same document feels bad. A bit like 
the way RFC 2231 modifies RFC 2060: Two lines changing 2060 buried in 
the middle of a ten-page document.

I suppose section 5 could be beefed up, so it's not such a tiny change. 
It could allow UTF-8 logins, passwords and mailbox names?

> Related to this. The second paragraph says:
>
>    When AUTHENTICATE is used, some servers may support userids and
>    passwords in Unicode [13]. However, such userids cannot be used as
>    email addresses, and at present also seem to be incompatible with
>    the current latest ACL drafts. Unless the ACL drafts resolve this,
>    server authors are cautioned against supporting ACL and unicode
>    userids simultaneously.
>
> The updated ACL got published as RFC 4314. So the end of this 
> paragraph is wrong.

Simplify my life. Give me text ;)

Arnt

Date: Thu, 02 Mar 2006 12:43:13 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Sender: [email-masked]

Dave Cridland wrote:

> Okay, a handful of comments and notes:
>
> 1) Section 3.2, the LANGUAGE command allows only a single language tag.
>
> This is problematic, because it means the client has to discover the 
> list of supported languages, and select a suitable one. Is there 
> anything against allowing a client to list languages the user can 
> handle, in order? This would eliminate a round-trip, whilst still 
> allowing clients to discover supported languages.
>
> For example, given the examples, one might add:
>
> < Server does not speak French, but does speak English. User speaks 
> Canadian French and Canadian English. >
>
> C: A008 LANGUAGE FR-CA EN-CA
> S: * LANGUAGE (EN)
> S: A008 OK Now speaking English

I like that.

[...]

> 5) Section 5.1:
>
> Isn't this out of date WRT saslprep?

> A simpler solution might be to promote SASL PLAIN as the i18n 
> plaintext login, since that either will be, or has been, fixed, and 
> deprecate LOGIN for even that.

I would rather the document just state that both LOGIN usernames and 
passwords are UTF-8 now.

Related to this. The second paragraph says:

    When AUTHENTICATE is used, some servers may support userids and
    passwords in Unicode [13]. However, such userids cannot be used as
    email addresses, and at present also seem to be incompatible with
    the current latest ACL drafts. Unless the ACL drafts resolve this,
    server authors are cautioned against supporting ACL and unicode
    userids simultaneously.

The updated ACL got published as RFC 4314. So the end of this paragraph 
is wrong.

Date: Thu, 2 Mar 2006 13:41:31 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Cc: Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

> 3. A comparator thingy which can go between any two search-keys and 
> which changes the comparator used from that point onwards.
>
> ...
>
> Discussion, please.

Speaking only for myself, 3 leaves a bad taste in my mouth. Feels like 
bad design.

I don't care much about 1/2/4.

Arnt

Date: Thu, 2 Mar 2006 13:36:38 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt
Cc: Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> 4) Section 4.4:
>
> I suspect that COMPARATOR is weak, but good enough for some 
> circumstances, albeit I'd prefer a more complex SEARCH. One problem 
> is that as specified, the example sequence B123 to B125 cannot be 
> pipelined.
>
> Could we add a COMPARATOR SEARCH option, which would override the 
> comparator used for that command only? Something like:
>
> B123 SEARCH COMPARATOR (i;octet) OR BODY GIF87A BODY GIF89A
>
> I think Alexey's IMAP ABNF has the template syntax present for a 
> search option.

We had this and dropped it. 18 months ago? There weren't any good 
examples, which always makes me feel bad. If one can't dream up at 
least one good example for an extension, maybe that extension isn't so 
useful in practice... so I asked whether any clients would use this and 
whether anything would be lost by omitting the COMPARATOR search-key. 
As I recall, noone stepped forward to speak in favour of the extra 
search-key, and Mark spoke in favour of simplicity.

There are four options:

1. No way to change comparator within the search command. Simple to 
implement for servers. Clients must change comparator before/after the 
search command.

2. Comparator can be set at the start, much like CHARSET. A bit tricky 
to do in the syntax, if I remember correctly, and saves a roundtrip or 
two. Otherwise identical to the previous option.

3. A comparator thingy which can go between any two search-keys and 
which changes the comparator used from that point onwards. (This is 
what we had, if I remember correctly.)

4. A new search-key which takes a comparator name and a search-key, and 
executes that search-key with that collation.

3 and 4 are subtly different. 3 is more like a preprocessor directive in 
C, 4 is more like a wrapper function. To show the difference between 
them, take this command:

     a search or or body arnt or from arnt to arnt cc arnt

I'm using a MUA with proportional spacing, so no ASCII art, sorry. 
You'll have to draw your own tree diagrams of this search.

Here are three variants with COMPARATOR:

     b search comparator i;octet or or body arnt or from arnt to arnt cc arnt
     c search or comparator i;octet or body arnt or from arnt to arnt cc arnt
     d search or or comparator i;octet body arnt or from arnt to arnt cc arnt

Using 3, all these are the same. The 'comparator' is before the first 
leaf node, so all four conditions are handled using i;octet. Using 4, 
they're different. For b, all four conditions are handled using 
i;octet. For c, i;octet is used only for body, from and to, while cc is 
handled by the active comparator. For d, only the body condition is 
subject to i;octet.

Which approach is the better one, 2, 3 or 4?

Is it good enough to be worth the bother? Will any client actually use 
it? (Will it deter any server from offering the extension?)

Discussion, please.

Arnt

Date: Wed, 1 Mar 2006 15:17:10 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Chris Newman <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt 
Sender: [email-masked]

On Wed, 1 Mar 2006, Dave Cridland wrote:
> 1) Section 3.2, the LANGUAGE command allows only a single language tag.
> This is problematic, because it means the client has to discover the list of 
> supported languages, and select a suitable one. Is there anything against 
> allowing a client to list languages the user can handle, in order?

I agree.  I also believe that the use of language-range adds unnecessary 
complexity, and that adding an untagged response is unnecessary.

I also note that the language-data rule is dangling, and RFC 3066 is being 
replaced.

Suggest the following:

 	command-any =/ language-cmd
 	resp-text-code =/ resp-lang / resp-langs

 	language = "LANGUAGE" *[SP lang-tag]

 	resp-langs = "LANGUAGES" [SP "(" lang-tag *(SP lang-tag) ")" ]
 	resp-lang = "LANGUAGE" SP lang-tag

 	lang-tag = astring
 		;; contains language-tag as described in [5]

Command semantics as follows:

LANGUAGE command with no argument: Return tagged OK with resp-langs 
containing the list of languages.

LANGUAGE command with arguments: Return BAD if violates syntax in any 
way.  Otherwise, selects language according to rules of section 2.5 of 
[5]; if success returns resp-lang with the selected language in a tagged 
OK response, otherwise returns resp-lang in a tagged NO with the server's 
preferred language (not necessarily "i-default").

i-default is mandatory to implement.  All other languages are optional.

> 2) Section 3.4:
> What's paragraph 1 for?

Agreed.  This dependency is not good.

IMHO, the LANGUAGE command should NOT localize namespaces.  Instead, if 
such as desired, the NAMESPACE command itself should be extended to take 
an argument.  I can see cases in which a user may want error messages in 
his preferred language but retain mailbox paths in i-default.

This doesn't add an additional RTT since the client has to do a NAMESPACE 
command anyway if it purposes to use namespaces.

> 3) Section 4.2:
> I think this *should* end up reiterating stuff that's currently an open issue 
> in the Comparator draft. Interestingly, this is almost exactly what I think 
> the comparator draft should be reading.

Should we split this off into the COMPARATOR document, and make this 
document focus entirely on localization of error messages and namespaces?

An "IMAP i18n document" should be a broader overview, pointing to all the 
other documents, but not getting into the nuts and bolts the way this one 
does.

> Could we add a COMPARATOR SEARCH option, which would override the comparator 
> used for that command only? Something like:
> B123 SEARCH COMPARATOR (i;octet) OR BODY GIF87A BODY GIF89A

This sounds like a good idea.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 01 Mar 2006 21:52:22 +0000
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt 
From: Dave Cridland <[email-masked]>
To: Chris Newman <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I did a quick review of this, really to compare it against the 
comparator draft, and partly to see how "ready" it's looking. The 
summary is pretty ready, but not quite there yet.

On Wed Mar  1 20:50:01 2006, [email-masked] wrote:
> 	Title		: Internet Message Access Protocol Internationalization
> 	Author(s)	: C. Newman, et al.
> 	Filename	: draft-ietf-imapext-i18n-06.txt
> 	Pages		: 16
> 	Date		: 2006-3-1
> 	
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-06.txt

Okay, a handful of comments and notes:

1) Section 3.2, the LANGUAGE command allows only a single language 
tag.

This is problematic, because it means the client has to discover the 
list of supported languages, and select a suitable one. Is there 
anything against allowing a client to list languages the user can 
handle, in order? This would eliminate a round-trip, whilst still 
allowing clients to discover supported languages.

For example, given the examples, one might add:

< Server does not speak French, but does speak English. User speaks 
Canadian French and Canadian English. >

C: A008 LANGUAGE FR-CA EN-CA
S: * LANGUAGE (EN)
S: A008 OK Now speaking English

2) Section 3.4:

What's paragraph 1 for? Surely most clients will use LANG early in 
the connection in order to switch troublesome authentication errors 
into the user's native language if possible. If LANG is used later, 
then the client can always use NAMESPACE pipelined itself. This adds 
a requirement to both client and server to support both, and I think 
it's making things more complex than they need to be.

Otherwise a note that this can also provide human readable names, 
rather than translations, per se - for instance "user." might be 
translated as "Other Users." or something.

3) Section 4.2:

I think this *should* end up reiterating stuff that's currently an 
open issue in the Comparator draft. Interestingly, this is almost 
exactly what I think the comparator draft should be reading.

4) Section 4.4:

I suspect that COMPARATOR is weak, but good enough for some 
circumstances, albeit I'd prefer a more complex SEARCH. One problem 
is that as specified, the example sequence B123 to B125 cannot be 
pipelined.

Could we add a COMPARATOR SEARCH option, which would override the 
comparator used for that command only? Something like:

B123 SEARCH COMPARATOR (i;octet) OR BODY GIF87A BODY GIF89A

I think Alexey's IMAP ABNF has the template syntax present for a 
search option.

5) Section 5.1:

Isn't this out of date WRT saslprep? A simpler solution might be to 
promote SASL PLAIN as the i18n plaintext login, since that either 
will be, or has been, fixed, and deprecate LOGIN for even that.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-06.txt 
Date: Wed, 01 Mar 2006 15:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, et al.
	Filename	: draft-ietf-imapext-i18n-06.txt
	Pages		: 16
	Date		: 2006-3-1
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search
substrings.  It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions
(MIME).  This specification defines a collection of IMAP extensions
which improve international support including comparator negotiation
for search, sort and thread, language negotiation for international
error text, and translations for namespace prefixes.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-i18n-06.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-i18n-06.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-i18n-06.txt

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

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

--OtherAccess--

--NextPart--