rfc4790.txt

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

   Some examples: "0" is less than "1", and "1" is less than
   "4294967298". "4294967298", "04294967298", and "4294967298b" are all
   equal. "04294967298" is less than "". "", "x", and "y" are equal.

9.1.2.  ASCII Numeric Collation Registration

   <?xml version='1.0'?>
   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
   <collation rfc="4790" scope="other" intendedUse="limited">
     <identifier>i;ascii-numeric</identifier>
     <title>ASCII Numeric</title>
     <operations>equality order</operations>
     <specification>RFC 4790</specification>
     <owner>IETF</owner>
     <submitter>[e-mail]</submitter>
   </collation>










Newman, et al.              Standards Track                    [Page 20]

RFC 4790                   Collation Registry                 March 2007


9.2.  ASCII Casemap Collation

9.2.1.  ASCII Casemap Collation Description

   The "i;ascii-casemap" collation is a simple collation that operates
   on octet strings and treats US-ASCII letters case-insensitively.  It
   provides equality, substring, and ordering operations.  All input is
   valid.  Note that letters outside ASCII are not treated case-
   insensitively.

   Its equality, ordering, and substring operations are as for i;octet,
   except that at first, the lower-case letters (octet values 97-122) in
   each input string are changed to upper case (octet values 65-90).

   Care should be taken when using OS-supplied functions to implement
   this collation, as it is not locale sensitive.  Functions, such as
   strcasecmp and toupper, are sometimes locale sensitive, and may
   inappropriately map lower-case letters other than a-z to upper case.

   The i;ascii-casemap collation is well-suited for use with many
   Internet protocols and computer languages.  Use with natural language
   is often inappropriate; even though the collation apparently supports
   languages such as Swahili and English, in real-world use, it tends to
   mis-sort a number of types of string:

   o  people and place names containing non-ASCII,

   o  words such as "naive" (if spelled with an accent, the accented
      character could push the word to the wrong spot in a sorted list),

   o  names such as "Lloyd" (which, in Welsh, sorts after "Lyon", unlike
      in English),

   o  strings containing euro and pound sterling symbols, quotation
      marks other than '"', dashes/hyphens, etc.
















Newman, et al.              Standards Track                    [Page 21]

RFC 4790                   Collation Registry                 March 2007


9.2.2.  ASCII Casemap Collation Registration

   <?xml version='1.0'?>
   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
   <collation rfc="4790" scope="local" intendedUse="common">
     <identifier>i;ascii-casemap</identifier>
     <title>ASCII Casemap</title>
     <operations>equality order substring</operations>
     <specification>RFC 4790</specification>
     <owner>IETF</owner>
     <submitter>[e-mail]</submitter>
   </collation>

9.3.  Octet Collation

9.3.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.  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 "undefined" result.  It provides equality,
   substring, and ordering operations.

   The ordering algorithm is as follows:

   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.






Newman, et al.              Standards Track                    [Page 22]

RFC 4790                   Collation Registry                 March 2007


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

   The substring operation 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 operation returns "no-match".

9.3.2.  Octet Collation Registration

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

   <?xml version='1.0'?>
   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
   <collation rfc="4790" scope="global" intendedUse="limited">
     <identifier>i;octet</identifier>
     <title>Octet</title>
     <operations>equality order substring</operations>
     <specification>RFC 4790</specification>
     <owner>IETF</owner>
     <submitter>[e-mail]</submitter>
   </collation>

10.  IANA Considerations

   Section 7 defines how to register collations with IANA.  Section 9
   defines a list of predefined collations that have been registered
   with IANA.

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 [8] also apply, and are normative to this specification.

12.  Acknowledgements

   The authors want to thank all who have contributed to this document,
   including Brian Carpenter, John Cowan, Dave Cridland, Mark Davis,
   Spencer Dawkins, Lisa Dusseault, Lars Eggert, Frank Ellermann, Philip
   Guenther, Tony Hansen, Ted Hardie, Sam Hartman, Kjetil Torgrim Homme,
   Michael Kay, John Klensin, Alexey Melnikov, Jim Melton, and Abhijit
   Menon-Sen.





Newman, et al.              Standards Track                    [Page 23]

RFC 4790                   Collation Registry                 March 2007


13.  References

13.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]   Phillips, A. and M. Davis, "Tags for Identifying Languages",
         BCP 47, RFC 4646, September 2006.

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

   [7]   Davis, M. and K. Whistler, "Unicode Collation Algorithm version
         14", May 2005,
         <http://www.unicode.org/reports/tr10/tr10-14.html>.

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

13.2.  Informative References

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

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

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

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

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





Newman, et al.              Standards Track                    [Page 24]

RFC 4790                   Collation Registry                 March 2007


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

   [15]  Crispin, M., "Internet Message Access Protocol - Version
         4rev1", RFC 3501, March 2003.

   [16]  Crispin, M. and K. Murchison, "Internet Message Access Protocol
         - Sort and Thread Extensions", Work in Progress, May 2004.

   [17]  Newman, C. and A. Gulbrandsen, "Internet Message Access
         Protocol Internationalization", Work in Progress, January 2006.

Authors' Addresses

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

   EMail: [e-mail]


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

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   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
   81671 Munich
   Germany

   Fax:   [phone]
   EMail: [e-mail]
   URI:   http://www.oryx.com/arnt/




Newman, et al.              Standards Track                    [Page 25]

RFC 4790                   Collation Registry                 March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

Intellectual Property

   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].

Acknowledgement

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







Newman, et al.              Standards Track                    [Page 26]