i18n.txt

广泛使用的邮件服务器！同时

    Comparator Registry [RFC4790].

        command-auth      =/ comparator-cmd

        resp-text-code    =/ "BADCOMPARATOR"

        comparator-cmd    = "COMPARATOR" *(SP comp-order-quoted)

      response-payload  =/ comparator-data

        comparator-data   = "COMPARATOR" SP comp-sel-quoted [SP "("
                        comp-id-quoted *(SP comp-id-quoted) ")"]



Newman & Co                Expires August 2008               FF[Page 13]





Internet-draft                                             February 2008


        comp-id-quoted  = astring
            ; Once any literal wrapper or quoting is removed, this
            ; follows the collation-id rule from [RFC4790]

        comp-order-quoted = astring
            ; Once any literal wrapper or quoting is removed, this
            ; follows the collation-order rule from [RFC4790]

        comp-sel-quoted   = astring
            ; Once any literal wrapper or quoting is removed, this
            ; follows the collation-selected rule from [RFC4790]


5.  Other IMAP Internationalization Issues

    The following sections provide an overview of various other IMAP
    internationalization issues.  These issues are not resolved by this
    specification, but could be resolved by other standards work, such
    as that being done by the EAI group (see [IMAP-EAI]).


5.1 Unicode Userids and Passwords

    IMAP4rev1 currently restricts the userid and password fields of the
    LOGIN command to US-ASCII. The "userid" and "password" fields of the
    IMAP LOGIN command are restricted to US-ASCII only until a future
    standards track RFC states otherwise.  Servers are encouraged to
    validate both fields to make sure they conform to the formal syntax
    of UTF-8 and to reject the LOGIN command if that syntax is violated.
    Servers MAY reject the use of any 8-bit in the "userid" or
    "password" field.

    When AUTHENTICATE is used, some servers may support userids and
    passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows
    that. However, such userids cannot be used as part of email
    addresses.


5.2 UTF-8 Mailbox Names

    The modified UTF-7 mailbox naming convention described in section
    5.1.3 of RFC 3501 is best viewed as an transition from the status
    quo in 1996 when modified UTF-7 was first specified.  At that time,
    there was widespread unofficial use of local character sets such as
    ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant
    non-interoperability.

    The requirements in section 5.1 of RFC 3501 are very important if



Newman & Co                Expires August 2008               FF[Page 14]





Internet-draft                                             February 2008


    we're ever going to be able to deploy UTF-8 mailbox names. Servers
    are encouraged to enforce them.


5.3 UTF-8 Domains, Addresses and Mail Headers

    There is now an IETF standard for Internationalizing Domain Names in
    Applications [RFC3490].  While IMAP clients are free to support this
    standard, an argument can be made that it would be helpful to simple
    clients if the IMAP server could perform this conversion (the same
    argument would apply to MIME header encoding [RFC2047]).  However,
    it would be unwise to move forward with such work until the work in
    progress to define the format of international email addresses is
    complete.


6.  IANA Considerations

    The IANA is requested to add LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2
    to the IMAP4 Capabilities Registry.  [Note to IANA:
    http://www.iana.org/assignments/imap4-capabilities]


7.  Security Considerations

    The LANGUAGE extension makes a new command available in "Not
    Authenticated" state in IMAP.  Some IMAP implementations run with
    root privilege when the server is in "Not Authenticated" state and
    do not revoke that privilege until after authentication is complete.
    Such implementations are particularly vulnerable to buffer overflow
    security errors at this stage and need to implement parsing of this
    command with extra care.

    A LANGUAGE command issued prior to activation of a security layer is
    subject to an active attack which suppresses or modifies the
    negotiation and thus makes STARTTLS or authentication error messages
    more difficult to interpret.  This is not a new attack as the error
    messages themselves are subject to active attack.  Clients MUST re-
    issue the LANGUAGE command once a security layer is active, so this
    does not impact subsequent protocol operations.

    LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2 extensions use the UTF-8
    charset, thus the security considerations for UTF-8 [RFC3629] are
    relevent.  However, neither uses UTF-8 for identifiers so the most
    serious concerns do not apply.


8.  Acknowledgements



Newman & Co                Expires August 2008               FF[Page 15]





Internet-draft                                             February 2008


    The LANGUAGE extension is based on a previous Internet draft by Mike
    Gahrns, a substantial portion of the text in that section was
    written by him.  Many people have participated in discussions about
    an IMAP Language extension in the various fora of the IETF and
    Internet working groups, so any list of contributors is bound to be
    incomplete.  However, the authors would like to thank Andrew McCown
    for early work on the original proposal, John Myers for suggestions
    regarding the namespace issue, along with Jutta Degener, Mark
    Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst,
    Timo Sirainen, Ben Campbell and Magnus Nystrom for their many
    suggestions that have been incorporated into this document.

    Initial discussion of the I18NLEVEL=2 extension involved input from
    Mark Crispin and other participants of the IMAP Extensions WG.


9.  Relevant Standards for i18n IMAP Implementations

    This is a non-normative list of standards to consider when
    implementing i18n aware IMAP software.

      o The LANGUAGE and I18NLEVEL=2 extensions to IMAP (this
        specification).
      o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501.
      o The Mailbox International Naming Convention in section 5.1.3 of
        RFC 3501.
      o MIME [RFC2045] for message bodies.
      o MIME header encoding [RFC2047] for message headers.
      o The IETF EAI working group.
      o MIME Parameter Value and Encoded Word Extensions [RFC2231] for
        filenames.  Quality IMAP server implementations will
        automatically combine multipart parameters when generating the
        BODYSTRUCTURE. There is also some deployed non-standard use of
        MIME header encoding inside double-quotes for filenames.
      o IDNA [RFC3490] and punycode [RFC3492] for domain names
        (currently only relevant to IMAP clients).
      o The UTF-8 charset [RFC3629].
      o The IETF policy on Character Sets and Languages [RFC2277].


Normative References

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

    [RFC2277]  Alvestrand, "IETF Policy on Character Sets and
               Languages", BCP 18, RFC 2277, January 1998.




Newman & Co                Expires August 2008               FF[Page 16]





Internet-draft                                             February 2008


    [RFC2342]  Gahrns, Newman, "IMAP4 Namespace", RFC 2342, May 1998.

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

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

    [RFC4234]  Crocker, Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 4234, Brandenburg
               Internetworking, Demon Internet Ltd, October 2005.

    [RFC4422]  Melnikov, Zeilenga, "Simple Authentication and Security
               Layer (SASL)", RFC 4422, June 2006.

    [RFC4466]  Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF",
               RFC 4466, Isode Ltd., April 2006.

    [RFC4646]  Philips, Davis, "Tags for Identifying Languages", BCP 47,
               RFC 4646, September 2006.

    [RFC4647]  Philips, Davis, "Matching of Language Tags", BCP 47, RFC
               4647, September 2006.

    [RFC4790]  Newman, Duerst, Gulbrandsen, "Internet Application
               Protocol Comparator Registry", RFC 4790, February 2007.

    [SORT]     Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS
               PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf-
               imapext-sort-19 (work in progress), November 2006.

    [UCM]      Crispin, "i;unicode-casemap - Simple Unicode Collation
               Algorithm", RFC 5051, October 2007.

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

    [RFC2047]  Moore, "MIME (Multipurpose Internet Mail Extensions) Part
               Three: Message Header Extensions for Non-ASCII Text", RFC
               2047, November 1996.


Informative References


    [RFC2231]  Freed, Moore, "MIME Parameter Value and Encoded Word
               Extensions: Character Sets, Languages, and



Newman & Co                Expires August 2008               FF[Page 17]





Internet-draft                                             February 2008


               Continuations", RFC 2231, November 1997.

    [RFC3490]  Faltstrom, Hoffman, Costello, "Internationalizing Domain
               Names in Applications (IDNA)", RFC 3490, March 2003.

    [RFC3492]  Costello, "Punycode: A Bootstring encoding of Unicode for
               Internationalized Domain Names in Applications (IDNA)",
               RFC 3492, March 2003.

    [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap-
               annotatemore-12 (work in progress), December 2007.

    [IMAP-EAI] Resnick, Newman, "IMAP Support for UTF-8", draft-ietf-
               eai-imap-utf8 (work in progress), May 2006.



Authors' Addresses

    Chris Newman
    Sun Microsystems
    3401 Centrelake Dr., Suite 410
    Ontario, CA 91761
    US

    Email: [e-mail]


    Arnt Gulbrandsen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen
    Germany

    Email: [e-mail]

    Fax: [phone]


    Alexey Melnikov
    Isode Limited
    5 Castle Business Village, 36 Station Road,
    Hampton, Middlesex, TW12 2BX, UK

    Email: [e-mail]






Newman & Co                Expires August 2008               FF[Page 18]





Internet-draft                                             February 2008


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
    [e-mail].


Full Copyright Statement

    Copyright (C) The IETF Trust (2008).  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.

    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, THE
    IETF TRUST 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.


Acknowledgment

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






Newman & Co                Expires August 2008               FF[Page 19]