Subject: Protocol Action: 'Internet Message Access Protocol Internationalization' to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 17 Mar 2008 15:35:51 -0700 (PDT)

The IESG has approved the following document:

- 'Internet Message Access Protocol Internationalization '
   <draft-ietf-imapext-i18n-15.txt> as a Proposed Standard

This document is the product of the Internet Message Access Protocol 
Extension Working Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

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

Technical Summary
 
This document provides the internationalization building blocks for
several IMAP extensions. It specifies (1) how to return non-English,
non-US-ASCII human-readable text in replies to IMAP commands; (2) how to
provide translations for NAMESPACE prefixes; and  (3) how to use
internationalized comparators in the IMAP SEARCH, SORT, and THREAD
commands.

Working Group Summary

This document is a product of the IMAP Extensions (IMAPEXT) Working Group
and has been extensively reviewed. In addition to agreement on the
technical aspects of the document, the result of discussion was consensus
to separate the LANGUAGE extension (for human-readable text replies and
NAMESPACE prefixes) from the use of comparators and the separation of two
levels of comparator support.

Protocol Quality

The protocol is the final piece in the puzzle for the IMAP SEARCH, SORT,
and THREAD commands. Implementation for those has been ongoing, and the
result of this work has satisified implementors of those extensions.

 Lisa Dusseault reviewed this for the IESG.

Note to RFC Editor

In Section 2, add to the end of the last paragraph:

The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use
i;unicode-casemap comparator, as defined in [UCM]. I18NLEVEL=1 is
a simpler version of I18NLEVEL=2 with no ability to select a different
collation.

In Section 3.1, add the following sentence to the end of 2nd paragraph:

IMAP servers SHOULD NOT advertise the LANGUAGE extension
if they discover that they only support "i-default".

In Section 3.1, last paragraph, second sentence:

OLD:
 Clients are urged to issue LANGUAGE before authentication, since some
servers send
         ^^^^^^^^^^^^
 valuable user information as part of authentication (e.g. "password
 is correct, but expired").

NEW:
 Clients SHOULD issue LANGUAGE before authentication, since some servers
send
         ^^^^^^
 valuable user information as part of authentication (e.g. "password
 is correct, but expired").

In Section 3.2, add a new sentence to the end of paragraph 9:

OLD:
 If there aren't any arguments, the server SHOULD send an untagged
 LANGUAGE response listing the languages it supports.  If the server
 is unable to enumerate the list of languages it supports it MAY
 return a tagged NO response to the enumeration request.

NEW:
 If there aren't any arguments, the server SHOULD send an untagged
 LANGUAGE response listing the languages it supports.  If the server
 is unable to enumerate the list of languages it supports it MAY
 return a tagged NO response to the enumeration request.
 If, after receiving a LANGUAGE request, the server discovers
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 that it doesn't support any language other than i-default,
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 it MUST return a tagged NO response to the enumeration request.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce