draft-ietf-idn-udns-02.txt

bind-3.2.

      binary matching. So the impact of complex matching rules should
      not slow down DNS very much.

2.3 Mixing of UDNS aware and non-UDNS aware clients and servers

   To handle the mixing of UDNS aware and non-UDNS aware clients and
   servers the following MUST be followed for clients and servers.

2.3.1 Native UDNS aware client

   A native UDNS aware client is a client supporting all in this
   document.

   When doing a query it MUST:
    - Use the long label in the QNAME.
    - If server rejected query due to long label, retry the query using
      the normal short label. If the QNAME contains non-ASCII it must be
      encoded using BCE.
    - Handle answers containg BCE.

   The client may skip trying a query using the long label if it knows
   the server does not understand it.

2.3.2 Application based UDNS aware client

   An application based UDNS aware client is a client supporting UDNS
   through BCE handling in the application.

   It only understands BCE and need only a non-UDNS aware resolver to
   work.  All encoding and decoding of BCE is handled in the
   application.

   Due to BCE being an ACE of BCF the names returned in an answer need
   not contain the real form of the name. Instead it may contains the
   simplified form used in name matching. As this is a transition
   mechanism to support non-ASCII in names before the DNS servers have
   been upgraded, it is acceptable and will give people a reason to
   upgrade.

2.3.3 non-UDNS aware client

   A non-UDNS aware client will send ASCII or whatever is sent from an
   application. It can be BCE which will for the client just be ASCII
   text.

2.3.4 UDNS aware server

   An UDNS aware server MUST handle all in this document and follow:



Dan Oscarsson           Expires: 24 August 2001                 [Page 6]

Internet Draft               Universal DNS              24 February 2001


    - If an incoming query contains a long label the answer may contain
      a long label and the client is identified as being UDNS aware.
    - If the query comes from a non-UDNS aware client and the answer
      contains non-ASCII, the non-ASCII labels must be encoded using
      BCE.
    - If a short label is used in a query and the QNAME contains non-
      ASCII, an authorative server must handle the query if the
      character encoding can be recognised. If must recognise SCE and
      should recognise common encodings used for the labels in the
      domain it is authorative for. Answers will use BCE for all labels
      except the one matching QNAME.  This will allow clients using the
      local character set to work in many cases before the resolver code
      is upgraded.

2.3.5 non-UDNS aware server

   A non-UDNS server can only handle ASCII matching when comparing
   names.  It can support the transition mechanism with BCE. The
   authorative zones will then have to be loaded with manually BCE
   encoded names.

2.4 DNSSEC

   As labels now can have non-ASCII in them, DNSSEC [RFC2535] need to be
   revised so that it also can handle that.


3. Effect on other protocols

   As now a domain name may include non-ASCII many other protocols that
   include domain names need to be updated. For example SMTP, HTTP and
   URIs. The BCE format can be used when interfacing with ASCII only
   software or protocols.  Protocols like SMTP could be extended using
   ESMTP and a UTF8 option that defines that all headers are in UTF-8.

   It is recommended that protocols updated to handle i18n do this by
   encoding character data in the same standard format as defined for
   DNS in this document (UCS normalised form C). The use of encoding it
   in ASCII or by tagged character sets should be avoided.

   DNS do not only have domain names in them, for example e-mail
   addresses are also included. So an e-mail address would be expected
   to be changed to include non-ASCII both before and after the @-sign.

   Software need to be updated to follow the user interface
   recommendations given above, so that a human will see the characters
   in their local character set, if possible.




Dan Oscarsson           Expires: 24 August 2001                 [Page 7]

Internet Draft               Universal DNS              24 February 2001


4. Security Considerations

   As always with data, if software does not check for data that can be
   a problem, security may be affected. As more characters than ASCII is
   allowed, software only expecting ASCII and with no checks may now get
   security problems.

5. References

   [RFC1034]  P. Mockapetris, "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  P. Mockapetris, "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, November 1987.

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

   [RFC2181]  R. Elz and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2279]  F. Yergeau, "UTF-8, a transformation format of ISO 10646",
              RFC 2279, January 1998.

   [RFC2535]  D. Eastlake, "Domain Name System Security Extensions".
              RFC 2535, March 1999.

   [RFC2671]  P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, August 1999.

   [ISO10646] ISO/IEC 10646-1:2000. International Standard --
              Information technology -- Universal Multiple-Octet Coded
              Character Set (UCS)

   [Unicode]  The Unicode Consortium, "The Unicode Standard -- Version
              3.0", ISBN 0-201-61633-5. Described at
              http://www.unicode.org/unicode/standard/versions/
              Unicode3.0.html

   [UTR15]    M. Davis and M. Duerst, "Unicode Normalization Forms",
              Unicode Technical Report #15, Nov 1999,
              http://www.unicode.org/unicode/reports/tr15/.

   [UTR21]    M. Davis, "Case Mappings", Unicode Technical Report #21,
              Dec 1999, http://www.unicode.org/unicode/reports/tr21/.

   [UDATA]    The Unicode Character Database,
              ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt.



Dan Oscarsson           Expires: 24 August 2001                 [Page 8]

Internet Draft               Universal DNS              24 February 2001


              The database is described in
              ftp://ftp.unicode.org/Public/UNIDATA/
              UnicodeCharacterDatabase.html.

   [IDNREQ]   James Seng, "Requirements of Internationalized Domain
   Names", draft-ietf-idn-requirement.

   [IANADNS]  Donald Eastlake, Eric Brunner, Bill Manning, "Domain Name
   System (DNS) IANA Considerations",draft-ietf-dnsext-iana-dns.

   [IDNE]     Marc Blanchet,Paul  Hoffman, "Internationalized domain
   names using EDNS (IDNE)", draft-ietf-idn-idne.

   [CHNORM]   M. Duerst, M. Davis, "Character Normalization in IETF
   Protocols", draft-duerst-i18n-norm.

   [IDNCOMP]  Paul Hoffman, "Comparison of Internationalized Domain Name
   Proposals", draft-ietf-idn-compare.

   [NAMEPREP] Paul Hoffman, "Comparison of Internationalized Domain Name
   Proposals", draft-ietf-idn-compare.

   [SACE]     Dan Oscarsson, "Simple ASCII Compatible Encoding", draft-
   ietf-idn-sace.

   [RACE]     Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
   for IDN", draft-ietf-idn-race.

6. Acknowledgements

   Paul Hoffman giving many comments in our e-mail discussions.

   Ideas from drafts by Paul Hoffman, Stuart Kwan, James Gilroy and Kent
   Karlsson.

   Magnus Gustavsson, Mark Davis, Kent Karlsson and Andrew Draper for
   comments on my draft.

   Discussions and comments by the members of the IDN working group.



Author's Address

   Dan Oscarsson
   Telia ProSoft AB
   Box 85
   201 20 Malmo



Dan Oscarsson           Expires: 24 August 2001                 [Page 9]

Internet Draft               Universal DNS              24 February 2001


   Sweden

   E-mail: [e-mail]
















































Dan Oscarsson           Expires: 24 August 2001                [Page 10]