rfc2825.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                  Internet Architecture Board (IAB)
Request for Comments: 2825                             L. Daigle, Editor
Category: Informational                                         May 2000


         A Tangled Web: Issues of I18N, Domain Names, and the
                        Other Internet protocols

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   The goals of the work to "internationalize" Internet protocols
   include providing all users of the Internet with the capability of
   using their own language and its standard character set to express
   themselves, write names, and to navigate the network. This impacts
   the domain names visible in e-mail addresses and so many of today's
   URLs used to locate information on the World Wide Web, etc.  However,
   domain names are used by Internet protocols that are used across
   national boundaries. These services must interoperate worldwide, or
   we risk isolating components of the network from each other along
   locale boundaries.  This type of isolation could impede not only
   communications among people, but opportunities of the areas involved
   to participate effectively in e-commerce, distance learning, and
   other activities at an international scale, thereby retarding
   economic development.

   There are several proposals for internationalizing domain names,
   however it it is still to be determined whether any of them will
   ensure this interoperability and global reach while addressing
   visible-name representation.  Some of them obviously do not. This
   document does not attempt to review any specific proposals, as that
   is the work of the Internationalized Domain Name (IDN) Working Group
   of the IETF, which is tasked with evaluating them in consideration of
   the continued global network interoperation that is the deserved
   expectation of all Internet users.







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


   This document is a statement by the Internet Architecture Board. It
   is not a protocol specification, but an attempt to clarify the range
   of architectural issues that the internationalization of domain names
   faces.

1. A Definition of Success

   The Internationalized Domain Names (IDN) Working Group is one
   component of the IETF's continuing comprehensive effort to
   internationalize language representation facilities in the protocols
   that support the global functioning of the Internet.

   In keeping with the principles of rough consensus, running code,
   architectural integrity, and in the interest of ensuring the global
   stability of the Internet, the IAB emphasizes that all solutions
   proposed to the (IDN) Working Group will have to be evaluated not
   only on their individual technical features, but also in terms of
   impact on existing standards and operations of the Internet and the
   total effect for end-users: solutions must not cause users to become
   more isolated from their global neighbors even if they appear to
   solve a local problem.  In some cases, existing protocols have
   limitations on allowable characters, and in other cases
   implementations of protocols used in the core of the Internet (beyond
   individual organizations) have in practice not implemented all the
   requisite options of the standards.

2. Technical Challenges within the Domain Name System (DNS)

   In many technical respects, the IDN work is not different from any
   other effort to enable multiple character set representations in
   textual elements that were traditionally restricted to English
   language characters.

   One aspect of the challenge is to decide how to represent the names
   users want in the DNS in a way that is clear, technically feasible,
   and ensures that a name always means the same thing.  Several
   proposals have been suggested to address these issues.

   These issues are being outlined in more detail in the IDN WG's
   evolving draft requirements document; further discussion is deferred
   to the WG and its documents.

3. Integrating with Current Realities

   Nevertheless, issues faced by the IDN working group are complex and
   intricately intertwined with other operational components of the
   Internet.  A key challenge in evaluating any proposed solution is the
   analysis of the impact on existing critical operational standards



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


   which use fully-qualified domain names [RFC1034], or simply host
   names [RFC1123].  Standards-changes can be effected, but the best
   path forward is one that takes into account current realities and
   (re)deployment latencies. In the Internet's global context, it is not
   enough to update a few isolated systems, or even most of the systems
   in a country or region.  Deployment must be nearly universal in order
   to avoid the creation of "islands" of interoperation that provide
   users with less access to and connection from the rest of the world.

   These are not esoteric or ephemeral concerns.  Some specific issues
   have already been identified as part of the IDN WG's efforts.  These
   include (but are not limited to) the following examples.

3.1 Domain Names and E-mail

   As indicated in the IDN WG's draft requirements document, the issue
   goes beyond standardization of DNS usage.  Electronic mail has long
   been one of the most-used and most important applications of the
   Internet.  Internet e-mail is also used as the bridge that permits
   the users of a variety of local and proprietary mail systems to
   communicate. The standard protocols that define its use (e.g., SMTP
   [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of
   characters allowed in the DNS specification. Certain characters are
   not allowed in e-mail address domain portions of these
   specifications.  Some mailers, built to adhere to these
   specifications, are known to fail when on mail having non-ASCII
   domain names in its address -- by discarding, misrouting or damaging
   the mail.  Thus, it's not possible to simply switch to
   internationalized domain names and expect global e-mail to continue
   to work until most of the servers in the world are upgraded.

3.2 Domain Names and Routing

   At a lower level, the Routing Policy Specification Language (RPLS)
   [RFC2622] makes use of "named objects" -- and inherits object naming
   restrictions from older standards ([RFC822] for the same e-mail
   address restrictions, [RFC1034] for hostnames).  This means that
   until routing registries and their protocols are updated, it is not
   possible to enter or retrieve network descriptions utilizing
   internationalized domain names.

3.3 Domain Names and Network Management

   Also, the Simple Network Management Protocol (SNMP) uses the textual
   representation defined in [RFC2579].  While that specification does
   allow for UTF-8-based domain names, an informal survey of deployed
   implementations of software libraries being used to build SNMP-
   compliant software uncovered the fact that few (if any) implement it.



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


   This may cause inability to enter or display correct data in network
   management tools, if such names are internationalized domain names.

3.4 Domain Names and Security

   Critical components of Internet public key technologies (PKIX,
   [RFC2459], IKE [RFC2409]) rely heavily on identification of servers
   (hostnames, or fully qualified domain names) and users (e-mail
   addresses).  Failure to respect the character restrictions in these
   protocols will impact security tools built to use them -- Transport
   Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name
   two.

   Failure may not be obvious.  For example, in TLS, it is common usage
   for a server to display a certificate containing a domain name
   purporting to be the domain name of the server, which the client can
   then match with the server name he thought he used to reach the
   service.

   Unless comparison of domain names is properly defined, the client may
   either fail to match the domain name of a legitimate server, or match
   incorrectly the domain name of a server performing a man-in-the-
   middle attack.  Either failure could enable attacks on systems that
   are now impossible or at least far more difficult.