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@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
