draft-ietf-idn-requirements-06.txt   draft-ietf-idn-requirements-07.txt 
IETF IDN Working Group Editors Zita Wenzel, James Seng IETF IDN Working Group Editors Zita Wenzel, James Seng
Internet Draft draft-ietf-idn-requirements-06.txt Internet Draft draft-ietf-idn-requirements-07.txt
8 May 2001 Expires 8 November 2001 23 May 2001 Expires 23 November 2001
Requirements of Internationalized Domain Names Requirements of Internationalized Domain Names
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 53 skipping to change at line 53
developing protocols for internationalized domain names. developing protocols for internationalized domain names.
1. Introduction 1. Introduction
At present, the encoding of Internet domain names is restricted to a At present, the encoding of Internet domain names is restricted to a
subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many
other text based items on the Internet have already been at least other text based items on the Internet have already been at least
partially internationalized. It is important for domain names to be partially internationalized. It is important for domain names to be
similarly internationalized or for an equivalent solution to be found. similarly internationalized or for an equivalent solution to be found.
This document assumes that the most effective solution involves putting This document assumes that the most effective solution involves putting
non-ASCII names inside some parts of the overall DNS system altho such non-ASCII names inside some parts of the overall DNS system although
assumption may not be the consensus of the IETF community. such assumption may not be the consensus of the IETF community.
This document is being discussed on the "idn" mailing list. To join the This document is being discussed on the "idn" mailing list. To join the
list, send a message to <majordomo@ops.ietf.org> with the words list, send a message to <majordomo@ops.ietf.org> with the words
"subscribe idn" in the body of the message. Archives of the mailing "subscribe idn" in the body of the message. Archives of the mailing
list can also be found at ftp://ops.ietf.org/pub/lists/idn*. list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
1.1 Definitions and Conventions 1.1 Definitions and Conventions
A language is a way that humans interact. In computerised form, a text A language is a way that humans interact. In computerised form, a text
in a written language can be expressed as a string of characters. in a written language can be expressed as a string of characters.
skipping to change at line 496 skipping to change at line 496
[28] An IDN-capable resolver or server SHALL NOT generate more traffic [28] An IDN-capable resolver or server SHALL NOT generate more traffic
than a non-IDN-capable resolver or server would when resolving an than a non-IDN-capable resolver or server would when resolving an
ASCII-only domain name. The amount of traffic generated when resolving ASCII-only domain name. The amount of traffic generated when resolving
an IDN SHALL be similar to that generated when resolving an ASCII-only an IDN SHALL be similar to that generated when resolving an ASCII-only
name. name.
[29] The service SHOULD NOT add new centralized administration for the [29] The service SHOULD NOT add new centralized administration for the
DNS. A domain administrator SHOULD be able to create internationalized DNS. A domain administrator SHOULD be able to create internationalized
names as easily as adding current domain names. names as easily as adding current domain names.
[30] Within a single zone, the zone manager MAY be able to define [30] The protocol MUST work with DNSSEC. The protocol MAY break
equivalence rules that suit the purpose of the zone, such as, but not
limited to, and not necessarily, non-ASCII case folding, Unicode
normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or
traditional/simplified Chinese equivalence. Such defined equivalences
MUST NOT remove equivalences that are assumed by (old or
local-rule-ignorant) caches.
[31] The protocol MUST work with DNSSEC. The protocol MAY break
language sort order. language sort order.
3. Security Considerations 3. Security Considerations
Any solution that meets the requirements in this document MUST NOT be Any solution that meets the requirements in this document MUST NOT be
less secure than the current DNS. Specifically, the mapping of less secure than the current DNS. Specifically, the mapping of
internationalized host names to and from IP addresses MUST have the internationalized host names to and from IP addresses MUST have the
same characteristics as the mapping of today's host names. same characteristics as the mapping of today's host names.
Specifying requirements for internationalized domain names does not Specifying requirements for internationalized domain names does not
skipping to change at line 651 skipping to change at line 643
Olafur Gudmundsson <ogud@tislabs.com> Olafur Gudmundsson <ogud@tislabs.com>
Paul Hoffman <phoffman@imc.org> Paul Hoffman <phoffman@imc.org>
Simon Josefsson <jas+idn@pdc.kth.se> Simon Josefsson <jas+idn@pdc.kth.se>
Kent Karlsson <keka@im.se> Kent Karlsson <keka@im.se>
John Klensin <klensin+idn@jck.com> John Klensin <klensin+idn@jck.com>
Tan Juay Kwang <tanjk@i-dns.net> Tan Juay Kwang <tanjk@i-dns.net>
Dongman Lee <dlee@icu.ac.kr> Dongman Lee <dlee@icu.ac.kr>
Bill Manning <bmanning@ISI.EDU> Bill Manning <bmanning@ISI.EDU>
Dan Oscarsson <Dan.Oscarsson@trab.se> Dan Oscarsson <Dan.Oscarsson@trab.se>
J. William Semich <bill@mail.nic.nu> J. William Semich <bill@mail.nic.nu>
Yoshiro Yoneda <<yone@nic.ad.jp> Yoshiro Yoneda <yone@nic.ad.jp>
 End of changes. 4 change blocks. 
13 lines changed or deleted 5 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/