rfc3490.txt

bind 9.3结合mysql数据库

   zone-specific restrictions or conventions.

   In IDNA, equivalence of labels is defined in terms of the ToASCII
   operation, which constructs an ASCII form for a given label, whether
   or not the label was already an ASCII label.  Labels are defined to
   be equivalent if and only if their ASCII forms produced by ToASCII
   match using a case-insensitive ASCII comparison.  ASCII labels
   already have a notion of equivalence: upper case and lower case are
   considered equivalent.  The IDNA notion of equivalence is an
   extension of that older notion.  Equivalent labels in IDNA are
   treated as alternate forms of the same label, just as "foo" and "Foo"
   are treated as alternate forms of the same label.

   To allow internationalized labels to be handled by existing
   applications, IDNA uses an "ACE label" (ACE stands for ASCII
   Compatible Encoding).  An ACE label is an internationalized label
   that can be rendered in ASCII and is equivalent to an
   internationalized label that cannot be rendered in ASCII.  Given any
   internationalized label that cannot be rendered in ASCII, the ToASCII
   operation will convert it to an equivalent ACE label (whereas an
   ASCII label will be left unaltered by ToASCII).  ACE labels are
   unsuitable for display to users.  The ToUnicode operation will
   convert any label to an equivalent non-ACE label.  In fact, an ACE
   label is formally defined to be any label that the ToUnicode
   operation would alter (whereas non-ACE labels are left unaltered by



Faltstrom, et al.           Standards Track                     [Page 6]

RFC 3490                          IDNA                        March 2003


   ToUnicode).  Every ACE label begins with the ACE prefix specified in
   section 5.  The ToASCII and ToUnicode operations are specified in
   section 4.

   The "ACE prefix" is defined in this document to be a string of ASCII
   characters that appears at the beginning of every ACE label.  It is
   specified in section 5.

   A "domain name slot" is defined in this document to be a protocol
   element or a function argument or a return value (and so on)
   explicitly designated for carrying a domain name.  Examples of domain
   name slots include: the QNAME field of a DNS query; the name argument
   of the gethostbyname() library function; the part of an email address
   following the at-sign (@) in the From: field of an email message
   header; and the host portion of the URI in the src attribute of an
   HTML <IMG> tag.  General text that just happens to contain a domain
   name is not a domain name slot; for example, a domain name appearing
   in the plain text body of an email message is not occupying a domain
   name slot.

   An "IDN-aware domain name slot" is defined in this document to be a
   domain name slot explicitly designated for carrying an
   internationalized domain name as defined in this document.  The
   designation may be static (for example, in the specification of the
   protocol or interface) or dynamic (for example, as a result of
   negotiation in an interactive session).

   An "IDN-unaware domain name slot" is defined in this document to be
   any domain name slot that is not an IDN-aware domain name slot.
   Obviously, this includes any domain name slot whose specification
   predates IDNA.

3. Requirements and applicability

3.1 Requirements

   IDNA conformance means adherence to the following four requirements:

   1) Whenever dots are used as label separators, the following
      characters MUST be recognized as dots: U+002E (full stop), U+3002
      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
      (halfwidth ideographic full stop).

   2) Whenever a domain name is put into an IDN-unaware domain name slot
      (see section 2), it MUST contain only ASCII characters.  Given an
      internationalized domain name (IDN), an equivalent domain name
      satisfying this requirement can be obtained by applying the




Faltstrom, et al.           Standards Track                     [Page 7]

RFC 3490                          IDNA                        March 2003


      ToASCII operation (see section 4) to each label and, if dots are
      used as label separators, changing all the label separators to
      U+002E.

   3) ACE labels obtained from domain name slots SHOULD be hidden from
      users when it is known that the environment can handle the non-ACE
      form, except when the ACE form is explicitly requested.  When it
      is not known whether or not the environment can handle the non-ACE
      form, the application MAY use the non-ACE form (which might fail,
      such as by not being displayed properly), or it MAY use the ACE
      form (which will look unintelligle to the user).  Given an
      internationalized domain name, an equivalent domain name
      containing no ACE labels can be obtained by applying the ToUnicode
      operation (see section 4) to each label.  When requirements 2 and
      3 both apply, requirement 2 takes precedence.

   4) Whenever two labels are compared, they MUST be considered to match
      if and only if they are equivalent, that is, their ASCII forms
      (obtained by applying ToASCII) match using a case-insensitive
      ASCII comparison.  Whenever two names are compared, they MUST be
      considered to match if and only if their corresponding labels
      match, regardless of whether the names use the same forms of label
      separators.

3.2 Applicability

   IDNA is applicable to all domain names in all domain name slots
   except where it is explicitly excluded.

   This implies that IDNA is applicable to many protocols that predate
   IDNA.  Note that IDNs occupying domain name slots in those protocols
   MUST be in ASCII form (see section 3.1, requirement 2).

3.2.1. DNS resource records

   IDNA does not apply to domain names in the NAME and RDATA fields of
   DNS resource records whose CLASS is not IN.  This exclusion applies
   to every non-IN class, present and future, except where future
   standards override this exclusion by explicitly inviting the use of
   IDNA.

   There are currently no other exclusions on the applicability of IDNA
   to DNS resource records; it depends entirely on the CLASS, and not on
   the TYPE.  This will remain true, even as new types are defined,
   unless there is a compelling reason for a new type to complicate
   matters by imposing type-specific rules.





Faltstrom, et al.           Standards Track                     [Page 8]

RFC 3490                          IDNA                        March 2003


3.2.2. Non-domain-name data types stored in domain names

   Although IDNA enables the representation of non-ASCII characters in
   domain names, that does not imply that IDNA enables the
   representation of non-ASCII characters in other data types that are
   stored in domain names.  For example, an email address local part is
   sometimes stored in a domain label ([e-mail] would be
   represented as hostmaster.example.com in the RDATA field of an SOA
   record).  IDNA does not update the existing email standards, which
   allow only ASCII characters in local parts.  Therefore, unless the
   email standards are revised to invite the use of IDNA for local
   parts, a domain label that holds the local part of an email address
   SHOULD NOT begin with the ACE prefix, and even if it does, it is to
   be interpreted literally as a local part that happens to begin with
   the ACE prefix.

4. Conversion operations

   An application converts a domain name put into an IDN-unaware slot or
   displayed to a user.  This section specifies the steps to perform in
   the conversion, and the ToASCII and ToUnicode operations.

   The input to ToASCII or ToUnicode is a single label that is a
   sequence of Unicode code points (remember that all ASCII code points
   are also Unicode code points).  If a domain name is represented using
   a character set other than Unicode or US-ASCII, it will first need to
   be transcoded to Unicode.

   Starting from a whole domain name, the steps that an application
   takes to do the conversions are:

   1) Decide whether the domain name is a "stored string" or a "query
      string" as described in [STRINGPREP].  If this conversion follows
      the "queries" rule from [STRINGPREP], set the flag called
      "AllowUnassigned".

   2) Split the domain name into individual labels as described in
      section 3.1.  The labels do not include the separator.

   3) For each label, decide whether or not to enforce the restrictions
      on ASCII characters in host names [STD3].  (Applications already
      faced this choice before the introduction of IDNA, and can
      continue to make the decision the same way they always have; IDNA
      makes no new recommendations regarding this choice.)  If the
      restrictions are to be enforced, set the flag called
      "UseSTD3ASCIIRules" for that label.





Faltstrom, et al.           Standards Track                     [Page 9]

RFC 3490                          IDNA                        March 2003


   4) Process each label with either the ToASCII or the ToUnicode
      operation as appropriate.  Typically, you use the ToASCII
      operation if you are about to put the name into an IDN-unaware
      slot, and you use the ToUnicode operation if you are displaying
      the name to a user; section 3.1 gives greater detail on the
      applicable requirements.

   5) If ToASCII was applied in step 4 and dots are used as label
      separators, change all the label separators to U+002E (full stop).

   The following two subsections define the ToASCII and ToUnicode
   operations that are used in step 4.

   This description of the protocol uses specific procedure names, names
   of flags, and so on, in order to facilitate the specification of the
   protocol.  These names, as well as the actual steps of the
   procedures, are not required of an implementation.  In fact, any
   implementation which has the same external behavior as specified in
   this document conforms to this specification.

4.1 ToASCII

   The ToASCII operation takes a sequence of Unicode code points that
   make up one label and transforms it into a sequence of code points in
   the ASCII range (0..7F).  If ToASCII succeeds, the original sequence
   and the resulting sequence are equivalent labels.

   It is important to note that the ToASCII operation can fail.  ToASCII
   fails if any step of it fails.  If any step of the ToASCII operation
   fails on any label in a domain name, that domain name MUST NOT be
   used as an internationalized domain name.  The method for dealing
   with this failure is application-specific.

   The inputs to ToASCII are a sequence of code points, the
   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
   ToASCII is either a sequence of ASCII code points or a failure
   condition.

   ToASCII never alters a sequence of code points that are all in the
   ASCII range to begin with (although it could fail).  Applying the
   ToASCII operation multiple times has exactly the same effect as
   applying it just once.

   ToASCII consists of the following steps:

   1. If the sequence contains any code points outside the ASCII range
      (0..7F) then proceed to step 2, otherwise skip to step 3.




Faltstrom, et al.           Standards Track                    [Page 10]

RFC 3490                          IDNA                        March 2003


   2. Perform the steps specified in [NAMEPREP] and fail if there is an
      error.  The AllowUnassigned flag is used in [NAMEPREP].

   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:

     (a) Verify the absence of non-LDH ASCII code points; that is, the
         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.

     (b) Verify the absence of leading and trailing hyphen-minus; that
         is, the absence of U+002D at the beginning and end of the
         sequence.

   4. If the sequence contains any code points outside the ASCII range
      (0..7F) then proceed to step 5, otherwise skip to step 8.

   5. Verify that the sequence does NOT begin with the ACE prefix.

   6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
      fail if there is an error.

   7. Prepend the ACE prefix.

   8. Verify that the number of code points is in the range 1 to 63
      inclusive.

4.2 ToUnicode

   The ToUnicode operation takes a sequence of Unicode code points that
   make up one label and returns a sequence of Unicode code points.  If
   the input sequence is a label in ACE form, then the result is an
   equivalent internationalized label that is not in ACE form, otherwise
   the original sequence is returned unaltered.

   ToUnicode never fails.  If any step fails, then the original input
   sequence is returned immediately in that step.

   The ToUnicode output never contains more code points than its input.
   Note that the number of octets needed to represent a sequence of code
   points depends on the particular character encoding used.

   The inputs to ToUnicode are a sequence of code points, the
   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
   ToUnicode is always a sequence of Unicode code points.

   1. If all code points in the sequence are in the ASCII range (0..7F)
      then skip to step 3.





Faltstrom, et al.           Standards Track                    [Page 11]