Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-08.txt
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: Wed, 20 Dec 2006 16:18:46 -0800 (Pacific Standard Time)
List-Id: <ietf-imapext.imc.org>

Currently, the document says:
     A server that advertises this extension MUST implement the i;ascii-
     casemap and i;octet comparators, as defined in [RFCxxxx].  A server
     intended to be deployed globally MUST implement the i;basic
     comparator, as defined in [BASIC].

     A server that advertises this extension SHOULD use i;ascii-casemap
     as the default comparator. [...]

Perhaps i;unicode-casemap should also be mentioned, e.g.:

     A server that implements i;unicode-casemap MAY treat i;ascii-casemap
     as equivalent to i;unicode-casemap.  That is, it MAY use
     i;unicode-casemap as its default comparator, and it MAY treat a
     client request for i;ascii-casemap as being for i;unicode-casemap.

The intent here is that all modern servers will do i;unicode-casemap, and 
i;ascii-casemap is only for legacy servers.  I don't really want to 
implement i;ascii-casemap separately, and see no point to doing so.  But 
I'm not going to fight too vigorously for that.  Thus, here's my fallback:

     A server that advertises this extension MUST implement the i;octet
     and i;ascii-casemap comparators, as defined in [RFCxxxx]; and SHOULD
     implement the i;unicode-casemap comparator, as defined in [RFCyyyy].
     A server intended to be deployed globally MUST implement the i;basic
     comparator, as defined in [BASIC].

     A server that advertises this extension SHOULD use i;unicode-casemap
     as the default comparator.  If the server does not support
     i;unicode-casemap, it SHOULD use i;ascii-casemap as the default
     comparator.  [...]

Or, perhaps we can just require i;unicode-casemap now, since it's tied to 
the COMPARATOR extension which is still just an I-D?

Speaking of i;unicode-casemap, is there anything further needed in its 
specification:
 	draft-crispin-collation-unicasemap-00.txt

-- Mark --

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-08.txt 
Date: Wed, 20 Dec 2006 18: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)	: A. Gulbrandsen, C. Newman
	Filename	: draft-ietf-imapext-i18n-08.txt
	Pages		: 16
	Date		: 2006-12-20
	
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-08.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-08.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-08.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-08.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 8 Dec 2006 14:55:37 -0600
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Minutes - comments?
Sender: [email-masked]

Anyone care to comment on these?

IMAPEXT - Minutes of IETF 67 Meeting (San Diego, CA, US)
Thursday, November 9, 2006
1510-1610
Chair: Pete Resnick
Note taker: Eric Burger
Jabber log: <http://www.ietf.org/meetings/ietf-logs/imapext/2006-11-09.html>

The IMAPEXT group is basically in FINWAIT for its documents. There 
have been discussions on the list about how to finish up and some 
non-working-group issues which we used this time to address.

Discussion:

ANNOTATE Draft. In IETF last call. Some discussion about switching 
back from Experimental to Proposed Standard. No strong arguments for 
doing so, so we're sticking with Experimental and will advanced to 
Proposed in the future.

Internationalization Drafts: The SORT draft needs to be re-reviewed 
in light of the new drafts. Phillip, Tony, Cyrus, Barry, and Ken sign 
up to do said review by 22 November. Discussion was had about whether 
an i;basic comparator document is needed. Arnt will submit his draft.

METADATA (ANNOTATEMORE) Draft. Cyrus asks for more reviews. Ken 
volunteers to get comments by 22 November. Alexey wants an exact 
match operator and multi-value attributes. Exact match discussion 
will be brought to the list. No support (especially from the author) 
for multi-values.

EXPUNGED Draft. Discussion of interaction with (lack of) CONDSTORE 
leads to agreement to move this work into the LEMONADE Quick Resync 
work. Discussion about what to do in the face of old MODSEQUENCEs 
(i.e., return all expunged messages, say NO, or some sort of 
optimization). No clear answer in the discussion. Some discussion 
about what the name of the mechanism will be seemed to settle on 
"VANISHED".

QUOTA. Alexey is asking for reviews for this individual effort.

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

From: [email-masked]
To: [email-masked]
Subject: Hi
Date: Thu, 7 Dec 2006 12:47:35 +0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Try this game ;-)

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: application/octet-stream;
	name="patch3425.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="patch3425.zip"

------=_NextPart_000_0016----=_NextPart_000_0016--

Date: Wed, 6 Dec 2006 10:23:45 -0800
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Protocol Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: [Imap-protocol] ESEARCH extension (RFC 4731)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 6 Dec 2006, Alexey Melnikov wrote:
> Mark Crispin wrote:
> > How many client implementations of RFC 4731 are there currently?
> Mark, I am not going to answer this question, but in the last month I 
> know that 3 more servers have added support for this RFC.

The reason why I asked is that I am considering adding support for it in 
UW imapd.  It seems easy enough to do in a server, but if it won't be 
widely used then it will become a potential source of inexplicable bugs.

-- Mark --

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

Date: Wed, 06 Dec 2006 17:23:26 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Protocol Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: [Imap-protocol] ESEARCH extension (RFC 4731)
Sender: [email-masked]

Mark Crispin wrote:

> How many client implementations of RFC 4731 are there currently?

Mark, I am not going to answer this question, but in the last month I 
know that 3 more servers have added support for this RFC.

Date: Sat, 02 Dec 2006 19:00:29 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Mark Crispin <[email-masked]>
Subject: Re: LANGUAGE/COMPARATOR review
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> I too thought about sending all the translations, but didn't see much 
> point in it. What client will ever send LANGAGE more than once? 

I can't think of any.
Besides, if the translation prefixes are provided by an OS library, it 
might not be possible to list them all.

> Defining what happens when LANGAGE is sent more than once is necessary 
> for completeness, but not useful, IMNSHO.

Date: Fri, 1 Dec 2006 20:29:33 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LANGUAGE/COMPARATOR review
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> It wouldn't hurt to make LANGUAGE require NAMESPACE.

I did so now. The obvious best choice. Can't imagine why I didn't think 
of that long ago.

Arnt

Date: Fri, 1 Dec 2006 20:23:20 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LANGUAGE/COMPARATOR review
Cc: Alexey Melnikov <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Arnt, can you remind me why you removed "server MUST sends NAMEPSPACE 
> response on LANGUAGE command, if the user is in authenticated state"?

I sort of reinstated it now. There now is a honest requirement that 
server and client bot support NAMESPACE.

Arnt

Date: Fri, 1 Dec 2006 23:18:39 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LANGUAGE/COMPARATOR review
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

I don't have access to the version history here, but from memory, the 
draft has always said that the translated namespace prefixes are just 
that, translated namespace prefixes.

The client can use them to present something on-screen, or it can throw 
them away, that's all. The translations NEVER are used as arguments to 
SELECT.

I too thought about sending all the translations, but didn't see much 
point in it. What client will ever send LANGAGE more than once? 
Defining what happens when ANGAGE is sent more than once is necessary 
for completeness, but not useful, IMNSHO.

Arnt

Date: Wed, 20 Dec 2006 16:18:46 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-08.txt 
Organization: Networks & Distributed Computing
Sender: [email-masked]

Currently, the document says:
     A server that advertises this extension MUST implement the i;ascii-
     casemap and i;octet comparators, as defined in [RFCxxxx].  A server
     intended to be deployed globally MUST implement the i;basic
     comparator, as defined in [BASIC].

     A server that advertises this extension SHOULD use i;ascii-casemap
     as the default comparator. [...]

Perhaps i;unicode-casemap should also be mentioned, e.g.:

     A server that implements i;unicode-casemap MAY treat i;ascii-casemap
     as equivalent to i;unicode-casemap.  That is, it MAY use
     i;unicode-casemap as its default comparator, and it MAY treat a
     client request for i;ascii-casemap as being for i;unicode-casemap.

The intent here is that all modern servers will do i;unicode-casemap, and 
i;ascii-casemap is only for legacy servers.  I don't really want to 
implement i;ascii-casemap separately, and see no point to doing so.  But 
I'm not going to fight too vigorously for that.  Thus, here's my fallback:

     A server that advertises this extension MUST implement the i;octet
     and i;ascii-casemap comparators, as defined in [RFCxxxx]; and SHOULD
     implement the i;unicode-casemap comparator, as defined in [RFCyyyy].
     A server intended to be deployed globally MUST implement the i;basic
     comparator, as defined in [BASIC].

     A server that advertises this extension SHOULD use i;unicode-casemap
     as the default comparator.  If the server does not support
     i;unicode-casemap, it SHOULD use i;ascii-casemap as the default
     comparator.  [...]

Or, perhaps we can just require i;unicode-casemap now, since it's tied to 
the COMPARATOR extension which is still just an I-D?

Speaking of i;unicode-casemap, is there anything further needed in its 
specification:
 	draft-crispin-collation-unicasemap-00.txt

-- Mark --

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-08.txt 
Date: Wed, 20 Dec 2006 18: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)	: A. Gulbrandsen, C. Newman
	Filename	: draft-ietf-imapext-i18n-08.txt
	Pages		: 16
	Date		: 2006-12-20
	
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-08.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-08.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-08.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-08.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 8 Dec 2006 14:55:37 -0600
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Minutes - comments?
Sender: [email-masked]

Anyone care to comment on these?

IMAPEXT - Minutes of IETF 67 Meeting (San Diego, CA, US)
Thursday, November 9, 2006
1510-1610
Chair: Pete Resnick
Note taker: Eric Burger
Jabber log: <http://www.ietf.org/meetings/ietf-logs/imapext/2006-11-09.html>

The IMAPEXT group is basically in FINWAIT for its documents. There 
have been discussions on the list about how to finish up and some 
non-working-group issues which we used this time to address.

Discussion:

ANNOTATE Draft. In IETF last call. Some discussion about switching 
back from Experimental to Proposed Standard. No strong arguments for 
doing so, so we're sticking with Experimental and will advanced to 
Proposed in the future.

Internationalization Drafts: The SORT draft needs to be re-reviewed 
in light of the new drafts. Phillip, Tony, Cyrus, Barry, and Ken sign 
up to do said review by 22 November. Discussion was had about whether 
an i;basic comparator document is needed. Arnt will submit his draft.

METADATA (ANNOTATEMORE) Draft. Cyrus asks for more reviews. Ken 
volunteers to get comments by 22 November. Alexey wants an exact 
match operator and multi-value attributes. Exact match discussion 
will be brought to the list. No support (especially from the author) 
for multi-values.

EXPUNGED Draft. Discussion of interaction with (lack of) CONDSTORE 
leads to agreement to move this work into the LEMONADE Quick Resync 
work. Discussion about what to do in the face of old MODSEQUENCEs 
(i.e., return all expunged messages, say NO, or some sort of 
optimization). No clear answer in the discussion. Some discussion 
about what the name of the mechanism will be seemed to settle on 
"VANISHED".

QUOTA. Alexey is asking for reviews for this individual effort.

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

From: [email-masked]
To: [email-masked]
Subject: Hi
Date: Thu, 7 Dec 2006 12:47:35 +0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Try this game ;-)

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: application/octet-stream;
	name="patch3425.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="patch3425.zip"

------=_NextPart_000_0016----=_NextPart_000_0016--

Date: Wed, 6 Dec 2006 10:23:45 -0800
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Protocol Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: [Imap-protocol] ESEARCH extension (RFC 4731)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 6 Dec 2006, Alexey Melnikov wrote:
> Mark Crispin wrote:
> > How many client implementations of RFC 4731 are there currently?
> Mark, I am not going to answer this question, but in the last month I 
> know that 3 more servers have added support for this RFC.

The reason why I asked is that I am considering adding support for it in 
UW imapd.  It seems easy enough to do in a server, but if it won't be 
widely used then it will become a potential source of inexplicable bugs.

-- Mark --

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

Date: Wed, 06 Dec 2006 17:23:26 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Protocol Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: [Imap-protocol] ESEARCH extension (RFC 4731)
Sender: [email-masked]

Mark Crispin wrote:

> How many client implementations of RFC 4731 are there currently?

Mark, I am not going to answer this question, but in the last month I 
know that 3 more servers have added support for this RFC.

Date: Sat, 02 Dec 2006 19:00:29 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Mark Crispin <[email-masked]>
Subject: Re: LANGUAGE/COMPARATOR review
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> I too thought about sending all the translations, but didn't see much 
> point in it. What client will ever send LANGAGE more than once? 

I can't think of any.
Besides, if the translation prefixes are provided by an OS library, it 
might not be possible to list them all.

> Defining what happens when LANGAGE is sent more than once is necessary 
> for completeness, but not useful, IMNSHO.

Date: Fri, 1 Dec 2006 20:29:33 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LANGUAGE/COMPARATOR review
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> It wouldn't hurt to make LANGUAGE require NAMESPACE.

I did so now. The obvious best choice. Can't imagine why I didn't think 
of that long ago.

Arnt

Date: Fri, 1 Dec 2006 20:23:20 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LANGUAGE/COMPARATOR review
Cc: Alexey Melnikov <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Arnt, can you remind me why you removed "server MUST sends NAMEPSPACE 
> response on LANGUAGE command, if the user is in authenticated state"?

I sort of reinstated it now. There now is a honest requirement that 
server and client bot support NAMESPACE.

Arnt

Date: Fri, 1 Dec 2006 23:18:39 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LANGUAGE/COMPARATOR review
Cc: Mark Crispin <[email-masked]>
Sender: [email-masked]

I don't have access to the version history here, but from memory, the 
draft has always said that the translated namespace prefixes are just 
that, translated namespace prefixes.

The client can use them to present something on-screen, or it can throw 
them away, that's all. The translations NEVER are used as arguments to 
SELECT.

I too thought about sending all the translations, but didn't see much 
point in it. What client will ever send LANGAGE more than once? 
Defining what happens when ANGAGE is sent more than once is necessary 
for completeness, but not useful, IMNSHO.

Arnt