rfc2825.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

4. Conclusion

   It is therefore clear that, although there are many possible ways to
   assign internationalized names that are compatible with today's DNS
   (or a version that is easily-deployable in the near future), not all
   of them are compatible with the full range of necessary networking
   tools.  When designing a solution for internationalization of domain
   names, the effects on the current Internet must be carefully
   evaluated. Some types of solutions proposed would, if put into effect
   immediately, cause Internet communications to fail in ways that would
   be hard to detect by and pose problems for those who deploy the new
   services, but also for those who do not; this would have the effect
   of cutting those who deploy them off from effective use of the
   Internet.

   The IDN WG has been identified as the appropriate forum for
   identifying and discussing solutions for such potential
   interoperability issues.

   Experience with deployment of other protocols has indicated that it
   will take years before a new protocol or enhancement is used all over
   the Internet.  So far, the IDN WG has benefited from proposed
   solutions from all quarters, including organizations hoping to



IAB                          Informational                      [Page 4]

RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000


   provide services that address visible-name representation and
   registration -- continuing this process with the aim of getting a
   single, scalable and deployable solution to this problem is the only
   way to ensure the continued global interoperation that is the
   deserved expectation of all Internet users.

5. Security Considerations

   In general, assignment and use of names does not raise any special
   security problems.  However, as noted above, some existing security
   mechanisms are reliant on the current specification of domain names
   and may not be expected to work, as is, with Internationalized domain
   names.  Additionally, deployment of non-standard systems (e.g., in
   response to current pressures to address national or regional
   characterset representation) might result in name strings that are
   not globally unique, thereby opening up the possibility of "spoofing"
   hosts from one domain in another, as described in [RFC2826].

6. Acknowledgements

   This document is the outcome of the joint effort of the members of
   the IAB.  Additionally, valuable remarks were provided by Randy Bush,
   Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.

7. References

   [RFC821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
             821, August 1982.

   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text
             Messages", STD 11, RFC 822, August 1982.

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

   [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application
             and Support", STD 3, RFC 1123, November 1989.

   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

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




IAB                          Informational                      [Page 5]

RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000


   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
             RFC 2246, January 1999.

   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
             X.509 Public Key Infrastructure Certificate and CRL
             Profile", RFC 2459, January 1999.

   [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.
             and M. Rose, "Textual Conventions for SMIv2", RFC 2579,
             April 1999.

   [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
             Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,
             "Routing Policy Specification Language (RPSL)", RFC 2622,
             June 1999.

   [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC
             2826, May 2000.

8. Author's Address

   Internet Architecture Board

   EMail:  [e-mail]


   Membership at time this document was completed:

      Harald Alvestrand
      Ran Atkinson
      Rob Austein
      Brian Carpenter
      Steve Bellovin
      Jon Crowcroft
      Leslie Daigle
      Steve Deering
      Tony Hain
      Geoff Huston
      John Klensin
      Henning Schulzrinne











IAB                          Informational                      [Page 6]

RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000


9. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















IAB                          Informational                      [Page 7]