rfc4790.txt

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


RFC 4790                   Collation Registry                 March 2007


   In Sieve, all matches are either true or false.  Accordingly, Sieve
   servers must treat "undefined" and "no-match" results of the equality
   and substring operations as false, and only "match" as true.

   In ACAP and Sieve, there are no invalid strings.  In this document's
   terms, invalid strings sort after valid strings.

   IMAP [15] also collates, although that is explicit only when the
   COMPARATOR [17] extension is used.  The built-in IMAP substring
   operation and the ordering provided by the SORT [16] extension may
   not meet the requirements made in this document.

   Other protocols may be in a similar position.

   In IMAP, the default collation is i;ascii-casemap, because its
   operations are understood to match IMAP's built-in operations.

7.  Collation Registration

7.1.  Collation Registration Procedure

   The IETF will create a mailing list, [e-mail], which can be
   used for public discussion of collation proposals prior to
   registration.  Use of the mailing list is strongly encouraged.  The
   IESG will appoint a designated expert who will monitor the
   [e-mail] mailing list and review registrations.

   The registration procedure begins when a completed registration
   template is sent to [e-mail] and [e-mail].  The
   designated expert is expected to tell IANA and the submitter of the
   registration within two weeks whether the registration is approved,
   approved with minor changes, or rejected with cause.  When a
   registration is rejected with cause, it can be re-submitted if the
   concerns listed in the cause are addressed.  Decisions made by the
   designated expert can be appealed to the IESG Applications Area
   Director, then to the IESG.  They follow the normal appeals procedure
   for IESG decisions.

   Collation registrations in a standards track, BCP, or IESG-approved
   experimental RFC are owned by the IETF, and changes to the
   registration follow normal procedures for updating such documents.
   Collation registrations in other RFCs are owned by the RFC author(s).
   Other collation registrations are owned by the individual(s) listed
   in the contact field of the registration, and IANA will preserve this
   information.

   If the registration is a change of an existing collation, it MUST be
   approved by the owner.  In the event the owner cannot be contacted



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


   for a period of one month, and the designated expert deems the change
   necessary, the IESG MAY re-assign ownership to an appropriate party.

7.2.  Collation Registration Format

   Registration of a collation is done by sending a well-formed XML
   document to [e-mail] and [e-mail].

7.2.1.  Registration Template

   Here is a template for the registration:

   <?xml version='1.0'?>
   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
   <collation rfc="YYYY" scope="global" intendedUse="common">
     <identifier>collation identifier</identifier>
     <title>technical title for collation</title>
     <operations>equality order substring</operations>
     <specification>specification reference</specification>
     <owner>email address of owner or IETF</owner>
     <submitter>email address of submitter</submitter>
     <version>1</version>
   </collation>

7.2.2.  The Collation Element

   The root of the registration document MUST be a <collation> element.
   The collation element contains the other elements in the
   registration, which are described in the following sub-subsections,
   in the order given here.

   The <collation> element MAY include an "rfc=" attribute if the
   specification is in an RFC.  The "rfc=" attribute gives only the
   number of the RFC, without any prefix, such as "RFC", or suffix, such
   as ".txt".

   The <collation> element MUST include a "scope=" attribute, which MUST
   have one of the values "global", "local", or "other".

   The <collation> element MUST include an "intendedUse=" attribute,
   which must have one of the values "common", "limited", "vendor", or
   "deprecated".  Collation specifications intended for "common" use are
   expected to reference standards from standards bodies with
   significant experience dealing with the details of international
   character sets.

   Be aware that future revisions of this specification may add
   additional function types, as well as additional XML attributes,



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


   values, and elements.  Any system that automatically parses these XML
   documents MUST take this into account to preserve future
   compatibility.

7.2.3.  The Identifier Element

   The <identifier> element gives the precise identifier of the
   collation, e.g., i;ascii-casemap.  The <identifier> element is
   mandatory.

7.2.4.  The Title Element

   The <title> element gives the title of the collation.  The <title>
   element is mandatory.

7.2.5.  The Operations Element

   The <operations> element lists which of the three operations
   ("equality", "order" or "substring") the collation provides,
   separated by single spaces.  The <operations> element is mandatory.

7.2.6.  The Specification Element

   The <specification> element describes where to find the
   specification.  The <specification> element is mandatory.  It MAY
   have a URI attribute.  There may be more than one <specification>
   element, in which case, they together form the specification.

   If it is discovered that parts of a collation specification conflict,
   a new revision of the collation is necessary, and the
   [e-mail] mailing list should be notified.

7.2.7.  The Submitter Element

   The <submitter> element provides an RFC 2822 [12] email address for
   the person who submitted the registration.  It is optional if the
   <owner> element contains an email address.

   There may be more than one <submitter> element.

7.2.8.  The Owner Element

   The <owner> element contains either the four letters "IETF" or an
   email address of the owner of the registration.  The <owner> element
   is mandatory.  There may be more than one <owner> element.  If so,
   all owners are equal.  Each owner can speak for all.





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


7.2.9.  The Version Element

   The <version> element MUST be included when the registration is
   likely to be revised, or has been revised in such a way that the
   results change for one or more input strings.  The <version> element
   is optional.

7.2.10.  The Variable Element

   The <variable> element specifies an optional variable to control the
   collation's behaviour, for example whether it is case sensitive.  The
   <variable> element is optional.  When <variable> is used, it must
   contain <name> and <default> elements, and it may contain one or more
   <value> elements.

7.2.10.1.  The Name Element

   The <name> element specifies the name value of a variable.  The
   <name> element is mandatory.

7.2.10.2.  The Default Element

   The <default> element specifies the default value of a variable.  The
   <default> element is mandatory.

7.2.10.3.  The Value Element

   The <value> element specifies a legal value of a variable.  The
   <value> element is optional.  If one or more <value> elements are
   present, only those values are legal.  If none are, then the
   variable's legal values do not form an enumerated set, and the rules
   MUST be specified in an RFC accompanying the registration.

7.3.  Structure of Collation Registry

   Once the registration is approved, IANA will store each XML
   registration document in a URL of the form
   http://www.iana.org/assignments/collation/collation-id.xml, where
   collation-id is the content of the identifier element in the
   registration.  Both the submitter and the designated expert are
   responsible for verifying that the XML is well-formed.  The
   registration document should avoid using new elements.  If any are
   necessary, it is important to be consistent with other registrations.

   IANA will also maintain a text summary of the registry under the name
   http://www.iana.org/assignments/collation/collation-index.html.  This
   summary is divided into four sections.  The first section is for
   collations intended for common use.  This section is intended for



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


   collation registrations published in IESG-approved RFCs, or for
   locally scoped collations from the primary standards body for that
   locale.  The designated expert is encouraged to reject collation
   registrations with an intended use of "common" if the expert believes
   it should be "limited", as it is desirable to keep the number of
   "common" registrations small and of high quality.  The second section
   is reserved for limited-use collations.  The third section is
   reserved for registered vendor-specific collations.  The final
   section is reserved for deprecated collations.

7.4.  Example Initial Registry Summary

   The following is an example of how IANA might structure the initial
   registry summary.html file:

     Collation                              Functions Scope Reference
     ---------                              --------- ----- ---------
   Common Use Collations:
     i;ascii-casemap                        e, o, s   Local [RFC 4790]

   Limited Use Collations:
     i;octet                                e, o, s   Other [RFC 4790]
     i;ascii-numeric                        e, o      Other [RFC 4790]

   Vendor Collations:

   Deprecated Collations:


   References
   ----------
   [RFC 4790]  Newman, C., Duerst, M., Gulbrandsen, A., "Internet
               Application Protocol Collation Registry", RFC 4790,
               Sun Microsystems, March 2007.

8.  Guidelines for Expert Reviewer

   The expert reviewer appointed by the IESG has fairly broad latitude
   for this registry.  While a number of collations are expected
   (particularly customizations of the UCA for localized use), an
   explosion of collations (particularly common-use collations) is not
   desirable for widespread interoperability.  However, it is important
   for the expert reviewer to provide cause when rejecting a
   registration, and, when possible, to describe corrective action to







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


   permit the registration to proceed.  The following table includes
   some example reasons to reject a registration with cause:

   o  The registration is not a well-formed XML document.

   o  The registration has an intended use of "common", but there is no
      evidence the collation will be widely deployed, so it should be
      listed as "limited".

   o  The registration has an intended use of "common", but it is
      redundant with the functionality of a previously registered
      "common" collation.

   o  The registration has an intended use of "common", but the
      specification is not detailed enough to allow interoperable
      implementations by others.

   o  The collation identifier fails to precisely identify the version
      numbers of relevant tables to use.

   o  The registration fails to meet one of the "MUST" requirements in
      Section 4.

   o  The collation identifier fails to meet the syntax in Section 3.

   o  The collation specification referenced in the registration is
      vague or has optional features without a clear behavior specified.

   o  The referenced specification does not adequately address security
      considerations specific to that collation.

   o  The registration's operations are needlessly different from those
      of traditional operations.

   o  The registration's XML is needlessly different from that of
      already registered collations.

9.  Initial Collations

   This section registers the three collations that were originally
   defined in [11], and are implemented in most [14] engines.  Some of
   the behavior of these collations is perhaps not ideal, such as
   i;ascii-casemap accepting non-ASCII input.  Compatibility with widely
   deployed code was judged more important than fixing the collations.
   Some of the aspects of these collations are necessary to maintain
   compatibility with widely deployed code.





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


9.1.  ASCII Numeric Collation

9.1.1.  ASCII Numeric Collation Description

   The "i;ascii-numeric" collation is a simple collation intended for
   use with arbitrarily-sized, unsigned decimal integer numbers stored
   as octet strings.  US-ASCII digits (0x30 to 0x39) represent digits of
   the numbers.  Before converting from string to integer, the input
   string is truncated at the first non-digit character.  All input is
   valid; strings that do not start with a digit represent positive
   infinity.

   The collation supports equality and ordering, but does not support
   the substring operation.

   The equality operation returns "match" if the two strings represent
   the same number (i.e., leading zeroes and trailing non-digits are
   disregarded), and "no-match" if the two strings represent different
   numbers.

   The ordering operation returns "less" if the first string represents
   a smaller number than the second, "equal" if they represent the same
   number, and "greater" if the first string represents a larger number
   than the second.