As per Relevance of the word national, we have this rfc below:
Network Working Group Internet Architecture Board (IAB
Request for Comments: 2825 L. Daigle,
Category: Informational May 2000
A Tangled Web: Issues of I18N, Domain Names, and
Other Internet
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
The goals of the work to "internationalize" Internet
include providing all users of the Internet with the capability
using their own language and its standard character set to
themselves, write names, and to navigate the network. This
the domain names visible in e-mail addresses and so many of today'
URLs used to locate information on the World Wide Web, etc. However
domain names are used by Internet protocols that are used
national boundaries. These services must interoperate worldwide,
we risk isolating components of the network from each other
locale boundaries. This type of isolation could impede not
communications among people, but opportunities of the areas
to participate effectively in e-commerce, distance learning,
other activities at an international scale, thereby
economic development
There are several proposals for internationalizing domain names
however it it is still to be determined whether any of them
ensure this interoperability and global reach while
visible-name representation. Some of them obviously do not.
document does not attempt to review any specific proposals, as
is the work of the Internationalized Domain Name (IDN) Working
of the IETF, which is tasked with evaluating them in consideration
the continued global network interoperation that is the
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.
is not a protocol specification, but an attempt to clarify the
of architectural issues that the internationalization of domain
faces
1. A Definition of
The Internationalized Domain Names (IDN) Working Group is
component of the IETF's continuing comprehensive effort
internationalize language representation facilities in the
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
stability of the Internet, the IAB emphasizes that all
proposed to the (IDN) Working Group will have to be evaluated
only on their individual technical features, but also in terms
impact on existing standards and operations of the Internet and
total effect for end-users: solutions must not cause users to
more isolated from their global neighbors even if they appear
solve a local problem. In some cases, existing protocols
limitations on allowable characters, and in other
implementations of protocols used in the core of the Internet (
individual organizations) have in practice not implemented all
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
other effort to enable multiple character set representations
textual elements that were traditionally restricted to
language characters
One aspect of the challenge is to decide how to represent the
users want in the DNS in a way that is clear, technically feasible
and ensures that a name always means the same thing.
proposals have been suggested to address these issues
These issues are being outlined in more detail in the IDN WG'
evolving draft requirements document; further discussion is
to the WG and its documents
3. Integrating with Current
Nevertheless, issues faced by the IDN working group are complex
intricately intertwined with other operational components of
Internet. A key challenge in evaluating any proposed solution is
analysis of the impact on existing critical operational
IAB Informational [Page 2]
RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
which use fully-qualified domain names [RFC1034], or simply
names [RFC1123]. Standards-changes can be effected, but the
path forward is one that takes into account current realities
(re)deployment latencies. In the Internet's global context, it is
enough to update a few isolated systems, or even most of the
in a country or region. Deployment must be nearly universal in
to avoid the creation of "islands" of interoperation that
users with less access to and connection from the rest of the world
These are not esoteric or ephemeral concerns. Some specific
have already been identified as part of the IDN WG's efforts.
include (but are not limited to) the following examples
3.1 Domain Names and E-
As indicated in the IDN WG's draft requirements document, the
goes beyond standardization of DNS usage. Electronic mail has
been one of the most-used and most important applications of
Internet. Internet e-mail is also used as the bridge that
the users of a variety of local and proprietary mail systems
communicate. The standard protocols that define its use (e.g.,
[RFC821, RFC822] and MIME [RFC2045]) do not permit the full range
characters allowed in the DNS specification. Certain characters
not allowed in e-mail address domain portions of
specifications. Some mailers, built to adhere to
specifications, are known to fail when on mail having non-
domain names in its address -- by discarding, misrouting or
the mail. Thus, it's not possible to simply switch
internationalized domain names and expect global e-mail to
to work until most of the servers in the world are upgraded
3.2 Domain Names and
At a lower level, the Routing Policy Specification Language (RPLS
[RFC2622] makes use of "named objects" -- and inherits object
restrictions from older standards ([RFC822] for the same e-
address restrictions, [RFC1034] for hostnames). This means
until routing registries and their protocols are updated, it is
possible to enter or retrieve network descriptions
internationalized domain names
3.3 Domain Names and Network
Also, the Simple Network Management Protocol (SNMP) uses the
representation defined in [RFC2579]. While that specification
allow for UTF-8-based domain names, an informal survey of
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
management tools, if such names are internationalized domain names
3.4 Domain Names and
Critical components of Internet public key technologies (PKIX
[RFC2459], IKE [RFC2409]) rely heavily on identification of
(hostnames, or fully qualified domain names) and users (e-
addresses). Failure to respect the character restrictions in
protocols will impact security tools built to use them --
Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to
two
Failure may not be obvious. For example, in TLS, it is common
for a server to display a certificate containing a domain
purporting to be the domain name of the server, which the client
then match with the server name he thought he used to reach
service
Unless comparison of domain names is properly defined, the client
either fail to match the domain name of a legitimate server, or
incorrectly the domain name of a server performing a man-in-the
middle attack. Either failure could enable attacks on systems
are now impossible or at least far more difficult
4.
It is therefore clear that, although there are many possible ways
assign internationalized names that are compatible with today's
(or a version that is easily-deployable in the near future), not
of them are compatible with the full range of necessary
tools. When designing a solution for internationalization of
names, the effects on the current Internet must be
evaluated. Some types of solutions proposed would, if put into
immediately, cause Internet communications to fail in ways that
be hard to detect by and pose problems for those who deploy the
services, but also for those who do not; this would have the
of cutting those who deploy them off from effective use of
Internet
The IDN WG has been identified as the appropriate forum
identifying and discussing solutions for such
interoperability issues
Experience with deployment of other protocols has indicated that
will take years before a new protocol or enhancement is used all
the Internet. So far, the IDN WG has benefited from
solutions from all quarters, including organizations hoping
IAB Informational [Page 4]
RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
provide services that address visible-name representation
registration -- continuing this process with the aim of getting
single, scalable and deployable solution to this problem is the
way to ensure the continued global interoperation that is
deserved expectation of all Internet users
5. Security
In general, assignment and use of names does not raise any
security problems. However, as noted above, some existing
mechanisms are reliant on the current specification of domain
and may not be expected to work, as is, with Internationalized
names. Additionally, deployment of non-standard systems (e.g.,
response to current pressures to address national or
characterset representation) might result in name strings that
not globally unique, thereby opening up the possibility of "spoofing
hosts from one domain in another, as described in [RFC2826].
6.
This document is the outcome of the joint effort of the members
the IAB. Additionally, valuable remarks were provided by Randy Bush
Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters
7.
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
821, August 1982.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
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 --
and Support", STD 3, RFC 1123, November 1989.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D and D. Carrel, "The Internet Key
(IKE)", RFC 2409, November 1998.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet
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, "
X.509 Public Key Infrastructure Certificate and
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",
2826, May 2000.
8. Author's
Internet Architecture
EMail: iab@iab.
Membership at time this document was completed
Harald
Ran
Rob
Brian
Steve
Jon
Leslie
Steve
Tony
Geoff
John
Henning
IAB Informational [Page 6]
RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
9. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
IAB Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
