mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2001-11-19 20:52:23 +00:00
parent e61793f086
commit b0a1fa9b20
49 changed files with 1590 additions and 18887 deletions
Download Patch File Download Diff File Expand all files Collapse all files

219
doc/draft/draft-esibov-dnsext-dynupdtld-00.txt
View File

@@ -1,219 +0,0 @@
DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Stuart Kwan
Category: Best Current Practice Microsoft
<draft-esibov-dnsext-dynupdtld-00.txt>
February 22, 2001
Dynamic DNS Update of the Top Level Domain and Root Zones
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
With an increasing number of implementations where the DNS client is
capable of performing dynamic DNS updates, an increase in the number of
the dynamic DNS updates sent to the servers hosting top level domain
zones has been observed. The purpose of this document is to recommend
DNS client configuration that prevents sending dynamic DNS updates for
the top level domain zones and root zones.
Esibov & Kwan BCP [Page 1]
INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001
1. Introduction
RFC 2136 [1] specifies Dynamic Updates in DNS, but does not
consider updates of the top level domain zones (e.g. "com", "edu", "ca",
"uk", etc...) and the root zone as a special case. Usually requests to
perform dynamic updates of the top level domain zones and the root zone
are expected to fail because these zones (on the Internet) are
configured to prohibit any dynamic updates. The same is true for most
organizations' private internal DNS infrastructures. The unnecessary
load of the dynamic updates sent by DNS clients attempting dynamic
updates of these zones consumes the resources of the DNS servers
authoritative for these zones and consumes network bandwidth.
With an increasing number of implementations where the DNS client is
capable of performing dynamic DNS updates, an increase in the number of
the dynamic DNS updates sent to the servers hosting top level domain
zones has been observed. The purpose of this document is to recommend
DNS client configuration that prevents sending dynamic DNS updates for
the top level domain zones and root zones.
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [2].
2. Dynamic updates of the top level domain zones and root zones.
To prevent dynamic DNS update requests to the top level domain zones and
root zone, it is recommended that DNS clients are configured by default
to suppress dynamic DNS updates of the top level domain zones and the
root zone.
To address the needs of the organizations using top level domain zones
and/or the root zone in their private internal DNS infrastructures, and
to allow dynamic updates of such zones, DNS clients MAY be configured to
allow dynamic DNS updates to be sent to the top level domain zones.
3. IANA Considerations
IANA's consideration is not required.
4. Security Considerations
This draft does not introduce any additional security concerns.
Esibov & Kwan BCP [Page 2]
INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001
5. Acknowledgements
Authors would like to thank Aristotle Balogh and Mark Kosters for
bringing to our attention the raising volume of the dynamic update
requests sent to the top level domain zones. We would also like to thank
Michael Cretzman for review of this document.
6. Authors' Addresses
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: levone@microsoft.com
Stuart Kwan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: skwan@microsoft.com
7. References
[1] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates
in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.
Esibov & Kwan BCP [Page 3]
INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
9. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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."
10. Expiration Date
This memo is filed as <draft-esibov-dnsext-dynupdtld-00.txt>, and
expires August 22, 2001.
Esibov & Kwan BCP [Page 4]

20
doc/draft/draft-esibov-dnsext-dynupdtld-01.txt Normal file
View File

@@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
S. Kwan: skwan@microsoft.com
L. Esibov: levone@microsoft.com

338
doc/draft/draft-ietf-dnsext-edns0dot5-02.txt
View File

@@ -1,338 +0,0 @@
Network Working Group R. Austein
draft-ietf-dnsext-edns0dot5-02.txt InterNetShare.com, Inc.
H. Alvestrand
Cisco Systems
November 2000
A Proposed Enhancement to the EDNS0 Version Mechanism
Status of this document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>
Distribution of this document is unlimited. Please send comments to
the Namedroppers mailing list <namedroppers@ops.ietf.org>.
Motivation and Scope
EDNS0 [EDNS0] specifies a general framework for extending the packet
format used by the Domain Name System protocols. The framework
includes a simple version numbering scheme to allow the parties in a
DNS protocol exchange to determine which extension features the other
party understands. While having the advantage of simplicity, the
version numbering scheme as specified has drawbacks:
- It provides no way to deprecate a protocol feature;
- It provides no way to deploy experimental protocol features.
Austein & Alvestrand Expires 22 May 2001 [Page 1]
draft-ietf-dnsext-edns0dot5-02.txt November 2000
This note proposes to augument the monolithic version numbering
mechanism with a mechanism for listing an explicit set of protocol
features that a particular implementation supports. We retain
version numbering as a way of abbreviating the feature sets that we
expect to see in common use.
Model
Our revised extension model for the DNS is designed with three goals
in mind:
- We want the protocol to be as simple as possible for the common
case of a client or server that implements "mainstream standard
DNS";
- We want to provide a safe way to experiment with new protocol
features, both inside and outside the deployed DNS;
- We want to provide a safe way to deprecate protocol features.
Our revised extension model has two parts, both of which are carried
in the OPT pseudo-RR: the VERSION, which stored in the second octet
of the TTL field of the OPT RR, and a variable-length list of
FEATURES, stored in the variable part of the OPT RR.
All FEATUREs are extensions of the DNS. We reserve the range of
FEATURE numbers from 1 to 100 for describing features of the original
RFC 1034/1035 DNS specification that we might eventually choose to
deprecate.
Any query/response pair can be described as using a set of DNS
FEATUREs. Such features might for instance be:
- Domain binary labels according to [BINARY-LABELS];
- Extended RCODEs (the general principle, not specific values);
- Multi-packet UDP response;
- Increased maximum UDP payload size;
- Character set identification in DNS labels;
- SIG record parsing and checking;
FEATURE numbers are handed out by IANA on a first-come-first-served
basis within their appropriate ranges. Any revised specification of
a format or function should have its own FEATURE number; in the IETF
Austein & Alvestrand Expires 22 May 2001 [Page 2]
draft-ietf-dnsext-edns0dot5-02.txt November 2000
process, any significantly changed Internet-Draft should have a new
FEATURE number assigned for experimentation.
An assigned VERSION number names a set of FEATUREs. VERSION numbers
are assigned by the IETF through a standards action.
Normally, any VERSION number encompasses every FEATURE of all lower
VERSION numbers, but the possibility of removing FEATUREs exists for
two reasons:
- To remove the need for supporting FEATUREs that turned out to be a
Really Bad Idea;
- To allow replacing a badly specified FEATURE with a better
specified FEATURE performing the same function that has a new
FEATURE number.
Mechanism
We transport explicit feature sets as lists of integers carried in
the variable RDATA portion of the EDNS0 OPT pseudo-RR.
The OPTION-CODE for FEATURES is [TBD].
The OPTION-DATA for FEATURES is an ordered list of "feature numbers";
a feature number is represented as a big-endian 16-bit unsigned
integer, and the list is sorted into numerically increasing order.
Each feature number names a particular protocol feature that is
supported by the implementation that generated this OPT pseudo-RR.
Usage
In most respects, the FEATURE mechanism is used symmetrically by
clients and servers; exceptions to this rule are stated after the
general explanation.
When composing a DNS message, a client or server includes an OPT
record indicating a set of FEATUREs that:
- MUST include all FEATUREs that the client or server believes are
relevant to this message;
- MAY include all FEATURES that the client or server is prepared to
receive.
This set is expressed as a VERSION and any additional FEATURES
required.
Austein & Alvestrand Expires 22 May 2001 [Page 3]
draft-ietf-dnsext-edns0dot5-02.txt November 2000
In general, we expect that a client or server will include an OPT
pseudo-RR that indicates:
- The highest VERSION number that the entity generating the message
supports; and
- A small (possibly empty) set of additional FEATUREs not encompassed
by the VERSION that the entity deems necessary or desirable.
The above symmetry notwithstanding, we impose one important
constraint on the server: while a server is allowed to indicate
whatever FEATUREs it believes are relevant or useful, a server MUST
NOT make use of any FEATURE in a response that is not within the set
of FEATUREs indicated by the client that generated the corresponding
request. That is, a response may say "I support FEATURE FOO"
regardless of what the client supports, but the rest of the response
must not use FEATURE FOO unless the client also supports it.
As a special case, if a client explicitly queries for the OPT RR of
the root zone, the server returns an OPT record including all
FEATUREs that the server supports. This functionality is provided
strictly for diagnostic purposes.
Life Cycle
We expect the life cycle of new features to proceed as follows:
- VERSION X is defined and deployed.
- A new FEATURE is defined and experimentally implemented. All
clients and servers taking part in the experiment use FEATURE to
indicate support.
- Community consensus is reached that this FEATURE is genuinely
useful.
- VERSION X+1 is defined, encompassing all FEATUREs from VERSION X,
plus the new FEATURE (and perhaps others).
- The next generation of DNS software supports VERSION X+1, and never
use FEATURE.
Risks
While we have tried to provide the ability to deprecate old bad
protocol features, such an ability should be used only rarely, if at
all, since by any realistic estimate it takes years (decades?) to
upgrade all the DNS implementations already in the field.
Austein & Alvestrand Expires 22 May 2001 [Page 4]
draft-ietf-dnsext-edns0dot5-02.txt November 2000
A flexible extension mechanism of this type increases the risk that
some implementors might chose to deploy features designed to hinder
interoperability (so-called "labeled noninteroperability").
Security Considerations
We do not believe that this protocol enhancement adds any major new
security risks, but we do believe that it would be helpful in getting
complicated DNS extensions such as [DNSSEC] deployed more quickly.
As with any enhancement to or complication of the DNS protocol, this
enhancement offers attackers yet another way to increase the load on
a name server. Root, TLD and other "major" name servers should view
excessively complicated FEATURE sets with suspicion, and should not
allow themselves to be tricked into performing more work than is
really necessary.
IANA Considerations
IANA will need to allocate an EDNS0 option code for FEATURES.
IANA will need to create a new registry of feature numbers.
Acknowledgments
The authors would like to thank the following people for their help
in improving this document: Randy Bush, Patrik Faltstrom, Olafur
Gudmundsson, Bob Halley, and XXX.
References
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
facilities", RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
and specification", RFC 1035, November 1987.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
[BINARY-LABELS] Crawford, M., "Binary Labels in the Domain Name
System", RFC 2673 August 1999.
Austein & Alvestrand Expires 22 May 2001 [Page 5]
draft-ietf-dnsext-edns0dot5-02.txt November 2000
Author's addresses:
Rob Austein
InterNetShare.com, Inc.
505 West Olive Ave., Suite 321
Sunnyvale, CA 94086
USA
sra@hactrn.net
Harald Tveit Alvestrand
Cisco Systems
Weidemanns vei 27
N-7043 Trondheim
NORWAY
+47 73 50 33 52
Harald@Alvestrand.no
Austein & Alvestrand Expires 22 May 2001 [Page 6]

20
doc/draft/draft-ietf-dnsext-edns0dot5-03.txt Normal file
View File

@@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
H. Alvestrand: harald@alvestrand.no
R. Austein: sra@hactrn.net

953
doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt
View File

@@ -1,953 +0,0 @@
Network Working Group S. Josefsson
Internet-Draft RSA Security
Expires: May 25, 2001 November 24, 2000
Authenticating denial of existence in DNS with minimum disclosure
(or; An alternative to DNSSEC NXT records)
draft-ietf-dnsext-not-existing-rr-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 25, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This draft present an alternative to NXT records, used to achieve
authenticated denial of existence of a domain name, class and type.
Problems with NXT records, as specified in RFC 2535, are identified.
One solution, the NO record, is presented.
The NO record differ from the NXT record by using a cryptographic
hash value instead of the domain name. This prevent an adversery
from collecting information by "chaining" through a zone. It also
remove delegation point concerns that was a side effect of NXT
records. The document also describe hash truncation and record
merging that reduces storage/network load.
Josefsson Expires May 25, 2001 [Page 1]
Internet-Draft The NO Record November 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The NO Resource Record . . . . . . . . . . . . . . . . . . 4
3.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 NO RDATA Format . . . . . . . . . . . . . . . . . . . . . 4
3.3 NO RDATA on-the-wire format example . . . . . . . . . . . 6
3.4 Owner Names . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Additional Complexity Due To Wildcards . . . . . . . . . . 7
3.6 No Considerations at Delegation Points . . . . . . . . . . 7
3.7 Hash Truncation and Dynamic Updates . . . . . . . . . . . 8
3.8 Reducing Number of Records . . . . . . . . . . . . . . . . 9
3.9 Hash Collisions . . . . . . . . . . . . . . . . . . . . . 9
3.10 Authenticating Denial of NO Records . . . . . . . . . . . 9
3.11 Case Considerations . . . . . . . . . . . . . . . . . . . 10
3.12 Presentation Format . . . . . . . . . . . . . . . . . . . 10
3.13 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.13.1 Adding NO Records to a Zone . . . . . . . . . . . . . . . 10
3.13.2 Simple NO creating entity . . . . . . . . . . . . . . . . 11
3.13.3 Advanced NO creating entity . . . . . . . . . . . . . . . 11
3.13.4 Resolver Query for Non-existing Domain . . . . . . . . . . 11
3.13.5 Resolver Query for Non-existing Type At Existing Domain . 12
4. Comparing NO and NXT . . . . . . . . . . . . . . . . . . . 13
4.1 Denial Of Existence Of Non-Existing Names . . . . . . . . 13
4.2 Denial Of Types Of Existing Names . . . . . . . . . . . . 13
4.3 Information disclosure (chain problem) . . . . . . . . . . 13
4.4 Delegation problem . . . . . . . . . . . . . . . . . . . . 13
4.5 Zone size (Bytes) . . . . . . . . . . . . . . . . . . . . 13
4.6 Zone size (Number Of Records) . . . . . . . . . . . . . . 13
4.7 Zone size (Number Of Owner names) . . . . . . . . . . . . 14
4.8 SIG Labels field and Wildcard records . . . . . . . . . . 14
4.9 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . 17
Josefsson Expires May 25, 2001 [Page 2]
Internet-Draft The NO Record November 2000
1. Introduction
"Domain Name Security Extensions", RFC 2535 [1], specifies several
extensions to DNS that provides data integrity and authentication.
Among them is the NXT record, used to achieve authenticated denial
of existence of domains, and authenticated denial of existence on
certain class/types on existing domains.
As a consequence of NXT records it is possible to "chain" through a
zone secured by DNS security extensions, collecting all names and/or
records in the zone. NXT records also introduce a complication at
delegation points. These are the main problems that motivated this
draft.
2. Context
There have been arguments that the "chain" problem of NXT records is
a non-issue. Often used is the argument that information in DNS is
public, and if you wish to keep information private, you shouldn't
publish it in DNS. This might be true, but nonetheless major
service providers and companies are restricting access to zone
transfers. Also, people have debated whether NXT records should be
part of DNSSEC at all because of this problem [5].
Another aspect exist. When DNS is used to store certificates, as
described in RFC 2538 [2], certificates can identify individuals
and/or carry authentication information for special purposes. This
context has been the motivation for developing this draft.
The "chain" problem is not the only concern with NXT records. The
delegation considerations for NXT records (different RRsets in the
parent and child for the same domain) has also been regarded as a
flaw of the NXT records.
Josefsson Expires May 25, 2001 [Page 3]
Internet-Draft The NO Record November 2000
3. The NO Resource Record
This section describe the NO Resource Record.
3.1 Idea
A straight-forward extension to the NXT record that minimize
disclosure of information is to store a one-way function value
instead of the actual domain name. This is similar to NXT records;
where NXT records secure a interval where no existing domain names
are to be found, NO records secure a interval where no one-way value
of existing domain names are to be found.
The benefit, of course, is that an adversary does not yield any
useful information from the record. Specifically, "chaining"
through a zone to collect all records is no longer possible.
This idea has been extended in this document into allowing (but not
requiring) one record to deny existence of several records, and
truncating the hash value to the shortest unique prefix to preserve
space.
3.2 NO RDATA Format
The RDATA for a NO RR consists of one or more fields with the
following structure. The structure have the following elements: a
zero-terminated list of RR types, a hash length specifier, and a
hash value, as shown below. Both the "RR type" list and the "next
hash value" fields are of variable width.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ owner RR type list /
/ |
+---------------+-----------------------------------------------+
| # hash octets | SHA-1 hash value /
+---------------+ /
/ /
+---------------------------------------------------------------+
Replacing the NXT RR "type bit map" field is a variable length list
of RR types. Each RR type is 16 bits. As the list is of variable
length, a end-of-list indicator is require. End of the list is
signalled by a all-zero RR type. Each element is a 2 byte RR type.
The list MUST be sorted in RR type order. The change from NXT's
bitmap field removes the limit of authenticating only the first 127
RR types.
Josefsson Expires May 25, 2001 [Page 4]
Internet-Draft The NO Record November 2000
The RR type list indicates what types exist at the previous hash
value -- i.e. the first RR type list in the RRdata of a NO record
indicate what RR types exist at the domain name that hashes to the
owner name of that NO record. The second RR type list, if any, in
the RRdata of a NO record indicate what RR types exist at the domain
name that hashes the first SHA-1 value in the RRdata. And so on.
See below for a complete example of the on-the-wire-format of a NO
record with hash truncation and record merging and its
interpretation.
Length of the hash value field is denoted by the # hash octets
fields, it is a unsigned integer ranging from 0 to 255. The meaning
of a zero length integer is reserved.
The SHA-1 hash value field is a variable length field containing the
actual hash value.
The NO RRs for a zone SHOULD be automatically calculated and added
to the zone when SIGs are added. The NO RR's TTL SHOULD NOT exceed
the zone minimum TTL.
The type number for the NO RR is TBD.
NO RR's MUST only be signed by zone level keys [7].
Josefsson Expires May 25, 2001 [Page 5]
Internet-Draft The NO Record November 2000
3.3 NO RDATA on-the-wire format example
The following is a example of the on-the-wire-format of a complete
NO resource record were hash truncation and record merging is used.
It is the on-the-wire format of the NO record in section 3.13.1.2.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR type 1 (A) | RR type 0 (end-of-list) |
+---------------+-----------------------------------------------+
| 1 hash octet | Hash 0x22 | RR type 2 (NS) |
+---------------+---------------+-------------------------------+
| RR type 6 (SOA) | RR type 15 (MX) |
+-------------------------------+---------------+---------------+
| RR type 0 (end-of-list) | 1 hash octet | Hash 0x83 |
+-------------------------------+---------------+---------------+
| RR type 1 (A) | RR type 0 (end-of-list) |
+---------------+-----------------------------------------------+
| 1 hash octet | Hash 0x90 | RR type 1 (A) |
+---------------+---------------+-------------------------------+
| RR type 16 (TXT) | RR type 0 (end-of-list) |
+---------------+---------------+-------------------------------+
| 1 hash octet | Hash 0x1b |
+-------------------------------+
The intepretation here is that the domain that corresponds with the
NO owner name ("1b._no.example.org.", not shown above) have a A
record, that the domain that hash to 0x22 (truncated to one octet)
have a NS, SOA and MX record, that the domain that hash to 0x83
(truncated to 1 octet) have a A record etc. Note that the last hash
value of NO RRdata does not have a RR type list in the same record.
3.4 Owner Names
As the previous NO RR format describe, the "next domain name" of NXT
records is replaced by its hash value. This removes the possibility
of chaining both backwards and forwards through a zone.
But without also modifying the owner names of NO records it is still
not difficult to chain through a zone. Consider querying a server
for (say) "m._no.example.org", the reply could contain a NO record
for "g._no.example.org", now an adversary can lookup records for
"g._no.example.org", and then issue a query for a domain that would
sort (in "the canonical order" described in RFC 2535) just before
"g._no.example.org". Applying the technique over and over again, all
records in the zone can still be collected.
To prevent this, the owner names of NO records is replaced by its
Josefsson Expires May 25, 2001 [Page 6]
Internet-Draft The NO Record November 2000
hash value. As DNS places limits on what characters can be used in
owner names, the owner name uses a base 16 "hex" encoding [6].
In order to remove the (very small) chance of generated NO record
names colliding with existing, "real", domains, all NO records MUST
be stored directly in the "_no" domain of the zone. I.e., a zone
"example.org." store its NO records as, say,
"35a4d1._no.example.org.".
This change in owner names also make sure that the delegation point
concerns of NXT records does not occur in NO records.
3.5 Additional Complexity Due To Wildcards
Proving that a non-existent name response is correct, or that a
wildcard expansion response is correct, makes things a little more
complex.
In particular, when a non-existent name response is returned, an NO
must be returned showing that the exact name did not exist and, in
general, one or more additional NO need to be returned to also prove
that there wasn't a wildcard whose expansion should have been
returned. (There is no need to return multiple copies of the same
NO.) These NOs, if any, are returned in the authority section of the
response.
Furthermore, if a wildcard expansion is returned in a response, in
general one or more NOs needs to also be returned in the authority
section to prove that no more specific name (including possibly more
specific wildcards in the zone) existed on which the response should
have been based.
3.6 No Considerations at Delegation Points
When NXT records are used to deny existance, there exists a special
case at delegation points. Namely, that two distinct RRsets exist
for the same owner name, one in the parent zone and one in the child
zone.
$ORIGIN parent.example.org.
@ SOA
NS
NXT child SOA NS SIG NXT
child NS foo
NXT next NS SIG NXT
next A 127.0.0.2
Josefsson Expires May 25, 2001 [Page 7]
Internet-Draft The NO Record November 2000
$ORIGIN child.parent.example.org.
@ SOA
NS
NXT name SOA NS SIG NXT
name A 127.0.2.1
NXT child.parent.example.org.
With NO records, the parent would deny existance of domains in
"_no.parent.example" and the child in
"_no.child.parent.example.org". Thus no NO RRset collision occur.
3.7 Hash Truncation and Dynamic Updates
Entities that create NO records MAY truncate the hash field. It
MUST NOT truncate hash fields so they are no longer unique
throughout a zone. Hash truncations MUST only be done to octet
offsets. Truncation MUST be such that less significant bits are
truncated, i.e. higher-order bits are preserved (see the examples).
Zones that are dynamically updated will have to calculate and add NO
records on-the-fly. If hash truncation is used, adding a new name
to the zone will require updating (and signing) NO records for the
conflicting name(s).
Since truncation (and also "compression" described in the next
section) make it impossible to predict the corresponding NO record
given a domain name, resolvers should not ask for a hashed NO record
(aaaa._no.example.org. IN NO) for a known domain name if they want
to find out what types exist at the domain. Instead, a resolver
might ask for NO records on the original name (www.example.org. IN
NO). Such records will never exist, and the correct NO record will
be returned by the server.
To summarize, the behaviour of hash truncation should be
configurable in the entity that creates NO records, to accomodate
different usage-patterns. If the zone is intended to be dynamicly
updated, hash truncation may be considered not worth the extra
on-the-fly processing required.
Josefsson Expires May 25, 2001 [Page 8]
Internet-Draft The NO Record November 2000
3.8 Reducing Number of Records
Entitities that create NO records MAY deny existence for several
records per NO record. Entities that create NO records should take
care so that each resulting NO record is not "too large". [Comments
on this? Should there be a specific limit? It might be left as a
DNS Operational consideration]
Merging several NO records into one record also place more work on
the resolver. Instead of parsing two hash values for each NO record
to determine if it's applicaple, a resolver will have to parse
several hash values and compare each.
The NO RR record consist of one or more RR type list / hash values,
described above, and a resolver need to parse the entire record to
collect each individual field. I.e., a NO parse algorithm could
looke like: read RRs, stop when you read a zero RR type, read hash
length indicator, read hash size, if the entire record is read stop,
otherwise read RRs, stop when you read a zero RR type, etc..
3.9 Hash Collisions
Hash value collisions are expected not to occur. For SHA-1, the
probability that this should happen is 1 out of 2^80 on average.
However, collisions are actually only a problem if the domain names
producing the same hash value have different sets of existing types.
Consider the following records
; SHA-1(one.example.org) = SHA-1(two.example.org)
one.example.org. IN A 1.2.3.4
two.example.org. IN A 5.6.7.8
Given that no other RR types exist for neither domain, both
"one.example.org" and "two.example.org" would be authenticated not
to exist by the same NO record.
3.10 Authenticating Denial of NO Records
NO records (together with SIG records) authenticate denial for other
types in a zone. Unlike NXT records that re-use the namespace in
the zone, NO records are not intended to authenticate denial of
other NO records.
Josefsson Expires May 25, 2001 [Page 9]
Internet-Draft The NO Record November 2000
3.11 Case Considerations
Before calculating SHA-1 hash values, domain names MUST be converted
into canonical format as described in RFC 2535. This is to make hash
comparisons possible.
3.12 Presentation Format
NO RRs do not appear in original unsigned zone master files since
they should be derived from the zone as it is being signed.
If a signed file with NO records is printed or NO records are
printed by debugging code, they appear as a list of unsigned
integers or RR mnemonics, and the hash value in base 16 hex
representation [6] with "0x" prepended (to distinguish it from
integer RR codes). The zero RR that terminate the list of RR types,
and the hash value length indicator, does not appear.
See the next section for examples of printed NO RRs.
3.13 Examples
This section contain examples of NO records, using the reserved
domain exmaple.org [3].
3.13.1 Adding NO Records to a Zone
Consider the following zone file.
$ORIGIN example.org.
@ IN SOA ...
@ IN NS ns
@ IN MX 0 server
ns IN A ...
www IN A ...
sERVEr IN A ...
sERVEr IN TXT "text"
; SHA1(example.org.) = 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
; SHA1(ns.example.org.) = 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
; SHA1(www.example.org.) = 0x839ebd4386c0b26d81f147421b5b7036e61438cf
; SHA1(server.example.org.) = 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
Note that hash values are calculcated on the canonical form.
The following two sections describe two valid ways of adding NO
records to a zone.
Josefsson Expires May 25, 2001 [Page 10]
Internet-Draft The NO Record November 2000
3.13.2 Simple NO creating entity
A simple NO creator entity might not implement truncation or provide
the possibility to deny more than one records per NO record. In
this case, the following would be added to the zone file.
$ORIGIN _no.example.org.
1b7838c69a66eb50cc215f66ee4554d0c4c940a5
IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf
839ebd4386c0b26d81f147421b5b7036e61438cf
IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
906a0ad5e604b1905828499dc8672ecb8de73e2f
IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
3.13.3 Advanced NO creating entity
A more advanced NO creator entity might append the following
instead, using both truncation and "compression".
$ORIGIN _no.example.org
1b IN NO A 0x22 NS SOA MX 0x83 A 0x90 A TXT 0x1b A
Note that this contain 5 hash values while the zone only contain 4
records, the last value in the line above is in fact the first hash
value in the zone, closing the circular NO chain.
3.13.4 Resolver Query for Non-existing Domain
Consider a client looking up the non-existant domain name
"baz.example.org.", using the zone file from the previous section.
First, we note the following calculations.
SHA-1(baz.example.org.) = 0xd5d0f98783eec6e9943750f35904304bd1a4090e
SHA-1(*.example.org.) = 0x7ab3776e3b529eb42467cc5d279c88ec951cf021
A server would reply with an RCODE of NXDOMAIN and the authority
section data including the following:
Josefsson Expires May 25, 2001 [Page 11]
Internet-Draft The NO Record November 2000
; backwards compatibility
example.org. IN SOA
; prove no baz.example.org
906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org.
IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. IN SIG NO
; prove no *.example.org:
222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org.
IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf
222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. IN SIG NO
In order for a client to verify the authenticity of this reply, in
addition of verifying the SIG record, it will also need to calculate
the one-way hash of "baz.example.org." and verify it is contained
inside the interval of any NO record in the authority section.
Also, to prove there are no wildcard records for baz.example.org.,
NO records for possible wildcard expansions are returned. A client
should similarily calculate hash values of possible wildcards and
compare them to the authority section.
Of course, if the zone was generated with the more advanced NO
creating entity, only the NO record from the previous section would
have to be returned.
3.13.5 Resolver Query for Non-existing Type At Existing Domain
Consider a client looking up TXT records for the existing domain
"www.example.org.", again, using the same zone file as previous. A
server would reply with an authority section like the following:
839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org.
IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. IN SIG NO
The resolver verifies the signature and make sure
SHA-1("bar.example.org.") hashes correctly.
Josefsson Expires May 25, 2001 [Page 12]
Internet-Draft The NO Record November 2000
4. Comparing NO and NXT
To ease comparison between NXT and NO records, this section
summarize (mis-)features of the NXT and the NO record formats. The
intent here is to address all operational differences between NO and
NXT records.
4.1 Denial Of Existence Of Non-Existing Names
Both NXT and NO provide strong data non-existance for non-existing
names.
NXT records authenticate data non-existance up to the probability of
finding a collision in the signature algorithm (1 in 2^64 for
RSA/MD5). NO records authenticate data non-existance up to the
probability of finding a collision in the signature algorithm (1 in
2^64 for RSA/MD5) and the NO record hash value (varies due to
truncation). If the RSA/MD5 scheme is used, hash values in NO
records may be truncated to 64 bits.
4.2 Denial Of Types Of Existing Names
Both NXT and NO provide strong data non-existance of types for
existing names. The previous discussion also apply here.
4.3 Information disclosure (chain problem)
NXT records make it possible to collect all names (and records) in a
zone. NO records prohibit this.
4.4 Delegation problem
NXT records require a special case where two different RRsets exist
at the same owner name, class and type. NO records does not have
this problem.
4.5 Zone size (Bytes)
The size difference is due to changing complete domain names with
hash values (SHA1 20 bytes). Without truncation, NO records are
probably larger than most NXT records. With truncation, NO records
uses a few byte per hash value instead of the (possibly compressed)
complete owner name.
4.6 Zone size (Number Of Records)
When NO compression is not used, NXT and NO uses the same number of
records.
Josefsson Expires May 25, 2001 [Page 13]
Internet-Draft The NO Record November 2000
However, NO compression can greatly reduce the number of records.
As an example, considering a zone with records of 100.000 different
names. NXT uses 200.000 records (NXT+SIG). Using NO compression
with 10 hash values on each reduce this number to 20.000 records
(NO+SIG).
4.7 Zone size (Number Of Owner names)
NO uses twice the amount of owner names as NXT.
However, NO compression can be used to reduce this to a fraction of
the normal amount. From the previous example with 10 hash values
per NO record, it will uses 10.000 additional owner names in a zone
with 100.000 names
4.8 SIG Labels field and Wildcard records
It is marginally faster to verify signatures for NXT records when
wildcard records are involved -- the SIG "Label fields" hints can be
used to determine the canonical name. With NO records this hint
cannot be used, because it relies on knowing the full name whereas
only the hash is available. One need to try a few SHA1 hashes to
find the correct canonical name. The number of hashes required to
try depend on the number of labels in the name, and scale linearly.
N.B. This penalty only apply to wildcard records.
4.9 Dynamic Updates
Resigning dynamically updated records is required both with NXT and
NO records.
However, when NO truncation and compression is used, the additional
penalty of re-hashing might also be required.
Josefsson Expires May 25, 2001 [Page 14]
Internet-Draft The NO Record November 2000
5. Security Considerations
Chaining through all NO records is still technically possible,
altough it cannot be used to collect names and/or records in the
zone (other than NO records themself).
The security of NO record hash values is dependent on the security
of the SHA-1 hash functions used. Truncation may affect this, but
the birthday-paradox argument does not apply. One must find a hash
collision given an existing hash value -- not simply find any hash
collision. It is thus reasonably to truncate NO records to half the
hash length used in the signature scheme (this would mean 64 bits in
the RSA/MD5 case).
It should be pointed out that given this scheme, it is easy to
estimate the number of records within a zone, considering hash
values are supposed to be equally distributed. This can be foiled
by adding any number of bogus records in the zone.
The authentication of NO records is provided by DNS SIG records, as
specified in RFC 2535. The security considerations of RFC 2535 is
not affected by this document, and should also be considered.
6. IANA Considerations
The NO RR type number should be selected by the IANA from the normal
RR type space.
The meaning of a zero hash length value can only be assigned by a
standards action.
Acknowledgement
The idea of encrypting names, that later evolved into just hashing
them, was originally proposed by Jonas Holmerin in private
discussions about DNS Security. Magnus Nystr<74>m proposed truncating
the hash values.
Thanks to John Linn and Magnus Nystr<74>m for comments on a early
version of this draft.
Olafur Gudmundsson pointed out delegation point issues, suggested
the use of a "_no" subdomain, and suggested replacing the type bit
map field with a sorted list. From the namedroppers mailing list,
I'd like to thank Alan Barrett, Andrew Draper, Andreas Gustafsson,
Peter Koch and Brian Wellington for comments and suggestions. Ed
Lewis noted that truncation to shortest unique prefix would not work.
Josefsson Expires May 25, 2001 [Page 15]
Internet-Draft The NO Record November 2000
References
[1] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[2] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC
2606, June 1999.
[4] NIST, , "Secure Hash Standard", FIPS PUB 180-1, April 1995.
[5] Massey, D., Lehman, T. and E. Lewis, "DNSSEC Implementation in
the CAIRN Testbed.", I.D. draft-ietf-dnsop-dnsseccairn-00.txt,
October 1999.
[6] Josefsson, S.A. (editor), "Base 64, 32 and 16 Encodings", I.D.
draft-josefsson-base-encoding-00.txt, August 2000.
[7] Wellington, B, "Domain Name System Security (DNSSEC) Signing
Authority", I.D. draft-ietf-dnsext-signing-auth-01.txt, May
2000.
Author's Address
Simon Josefsson
RSA Security
Arenav<61>gen 29
Stockholm 121 29
Sweden
Phone: +46 8 7250914
EMail: sjosefsson@rsasecurity.com
Josefsson Expires May 25, 2001 [Page 16]
Internet-Draft The NO Record November 2000
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.
Josefsson Expires May 25, 2001 [Page 17]

19
doc/draft/draft-ietf-dnsext-not-existing-rr-02.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
S. Josefsson: sjosefsson@rsasecurity.com

211
doc/draft/draft-ietf-dnsop-parent-sig-00.txt
View File

@@ -1,211 +0,0 @@
Parent's SIG over child's KEY
draft-ietf-dnsop-parent-sig-00.txt
Miek Gieben, Ted Lindgreen
Status of This Document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
When dealing with large amounts of keys the procedures to update a zone and
to sign a zone need to be clearly defined and practically possible.
The current idea is to have the KEY RR and the parent's SIG to reside in the
child's zone and perhaps also in the parent's zone. We feel that this would
lead to very complicated procedures for large TLD's. We propose a alternative
scheme in which the parent zone stores the parent's signature over the child's
key and also a copy of the child's key itself.
The advantage of this proposal is that all signatures signed by a key are in
the same zone file as the producing key. This allows for a simple key
rollover and resigning mechanism. For large TLD's this is extremely important.
We further discuss the impact on a secure aware resolver/forwarder.
Table of Contents
Status of This Document....................................
Abstract...................................................
Table of Contents..........................................
1 Introduction.............................................
2 Proposal.................................................
3 Impact on a secure aware resolver/forwarder..............
3.1 Impact of key rollovers on resolver/forwarder..........
4 Key rollovers............................................
4.1 Scheduled key rollover.................................
4.2 Unscheduled key rollover...............................
5 Zone resiging............................................
References................................................
Authors' Addresses........................................
References................................................
1. Introduction
Within a CENTR working group NLnet Labs is researching the impact of
DNSSEC on the ccTLDs and gTLDs.
In this document we are considering a secure zone, somewhere under a secure
entry point and on-tree [1] validation between the secure entry point and the
zone in question. The resolver we are considering is security aware and is
preconfigured with the KEY of the secure entry point.
RFC 2535 [2] states that a zone key must be present in the apex of a zone.
This can be in the at the delegation point in the parent's zonefile
(normally the case for null keys), or in the child's zonefile, or in both.
This key is only valid if it is signed by the parent, so there is also the
question where this signature is located.
The original idea was to have the KEY RR and the parent's SIG to reside
in the child's zone and perhaps also in the parent's zone. There is a
draft proposal [3], that describes how a keyrollover can be handled.
At NLnet Labs we found that storing the parent's signature over the
child's key in the child's zone:
- makes resigning a KEY by the parent difficult
- makes a scheduled keyrollover very complicated
- makes an unscheduled keyrollover virtually impossible
We propose an alternative scheme in which the parent's signature over the
child's key is only stored in the parent's zone, i.e. where the signing key
resides. This would solve the above problems.
2. Proposal
The core of the new proposal is that the parent zone stores the parent's
signature over the child's key and also a copy of the child's key itself.
The child zone also contains its zonekey, where it is selfsigned.
The advantage of this proposal is that all signatures signed by a key are in
the same zone file as the producing key. This allows for a simple key
rollover and resigning mechanism. For large TLD's this is extremely important.
A disadvantage would be that not all the information concerning one zone is
stored at that zone, namely the (parent) SIG RR. Note that the same argument
can be applied to a zone's NULL key, which is also stored at the parent.
3. Impact on a secure aware resolver/forwarder
The resolver must be aware of the fact that the parent is more authoritative
than a child when it comes to deciding whether a zone is secured or not.
Without caching and with on-tree validation, a resolver will always start
its search at a secure entry point. In this way it can determine whether it
must expect SIG records or not.
Considering caching in a secure aware resolver or forwarder. If information
of a secure zone is cached, its validated KEY should also be cached.
If the KEY record expires, because the KEY TTL expires or because the SIG is
no longer valid, the KEY should be discarded. The resolver or forwarder
should then also discard other data concerning the zone because it is no
longer validated and possible bad data should not be cached.
3.1. Impact of key rollovers on resolver/forwarder
When a zone is in the process of a key rollover, there could be a discrepancy
between the KEY and the SIG in the apex of the zone and the KEY and SIG that
are stored in the cache of a resolver.
Suppose a resolver has cached the NS, KEY and SIG records of a zone. Next a
request comes for an A record in that zone. Also the zone is in the process
of a keyrollover and already has new keys in its zone. The resolver receives
an answer consisting of the A record and a SIG over the A record. It uses
the tag field in the SIG to determine if it has a KEY which is suitable to
validate the SIG. If it does not has such a KEY the resolver must ask the
parent of the zone for a new KEY and then try it again. Now the resolver
has 2 keys for the zone, according to the tag field in the SIG it can use
either one.
If the new key also does not validate the SIG the zone is marked bad. If the
KEY found at the parent is the NULL key the resolver knows that the child is
considered insecure. This could for instance be in the case the private key
of the zone is stolen.
4. Key rollovers
Private keys can be stolen or a key can become over used. In both
cases a new a new key must be signed and distributed. This event is
called keyrollover. We further distinguish between a scheduled and an
unscheduled key rollover. A scheduled rollover is announced before hand.
An unscheduled key rollover is needed when a private key is compromised.
4.1. Scheduled key rollover
When the signatures, produced by the key to be rolled over, are all
in one zone file, there are two parties involved. Let us look at an
example where a TLD rolls over its zone key. The new key needs to be
signed with the root's key before it can be used to sign the TLD zone
and the zone keys of the TLD's children. The steps that need to be taken
by TLD and root are:
- the TLD adds the new key to its keyset in its zonefile. This
zone and keyset are signed with the old zonekey
- then the TLD signals the parent
- the root copies the new keyset, consisting of the both new
and the old key, in its zonefile, resigns it and signals the TLD
- the TLD removes the old key from its keyset, resigns its zone
with the new key, and signals the the root
- the root copies the new keyset, now consisting of the new key
only, and resigns it
4.2. Unscheduled key rollover
Although nobody hopes that this will ever happen, we must be able to
cope with possible key compromises. When such an event occurs, an
immediate keyrollover is needed and must be completed in the shortest
possible time. With two parties involved, it will still be awkward, but
not impossible to update two zonefiles overnight. "Out-of-band"
communication between the two parties will be necessary, since the
compromised old key can not be trusted. We think that between two
parties this is doable, but this complicated procedure is beyond the
scope of this document. [4]
5. Zone resigning
Resigning a TLD is necessary before the current signatures expire.
When all SIG records, produced by the TLD's zone key are kept in the
TLD's zonefile, and only there, such a resign session is trivial, as
only one party (the TLD) and one zonefile is involved.
Authors' Addresses
R. Gieben
Stichting NLnet Labs
Kruislaan 419
1098 VA Amsterdam
miek@nlnetlabs.nl
T. Lindgreen
Stichting NLnet Labs
Kruislaan 419
1098 VA Amsterdam
ted@nlnetlabs.nl
References
[1] Lewis, E. "DNS Security Extension Clarification on Zone Status",
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt
[2] Eastlake, D. "DNS Security Extensions", RFC 2535
http://www.ietf.org/rfc/rfc2535.txt?number=2535
[3] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover"
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt
[4] Gieben, R. "Chain of trust"
http://secnl.nlnetlabs.nl/thesis/thesis.html

21
doc/draft/draft-ietf-dnsop-parent-sig-01.txt Normal file
View File

@@ -0,0 +1,21 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
M. Gieben: miek@nlnetlabs.nl
T. Lindgreen: ted@nlnetlabs.nl
R. Gieben: miek@nlnetlabs.nl

154
doc/draft/draft-ietf-enum-e164-gstn-np-01.txt → doc/draft/draft-ietf-enum-e164-gstn-np-02.txt
View File

@@ -2,9 +2,9 @@
Mark Foster
Internet Draft Tom McGarry
Document: <draft-ietf-enum-e164-gstn-np-01.txt> James Yu
Document: <draft-ietf-enum-e164-gstn-np-02.txt> James Yu
NeuStar, Inc.
Category: Informational February 9, 2001
Category: Informational October 19, 2001
Number Portability in the GSTN: An Overview
@@ -56,9 +56,9 @@ Status of this Memo
the later to the former. In addition, there are various regulatory
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 [1]
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 1
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
constraints that establish relevant parameters for NP
@@ -115,9 +115,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
NP changes the fundamental nature of a dialed E.164 number from a
hierarchical physical routing address to a virtual address. NP
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 2
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 2
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
implementations attempt to encapsulate the impacts to the GSTN and
@@ -153,7 +153,7 @@ Number Portability in the GSTN: An Overview February 9, 2000
constraints, as well as the need for interoperation with the
existing GSTN NP implementations, are relevant topics for numerous
areas of IP telephony work-in-progress at IETF.
This document describes three types of number portability and the
four schemes that have been standardized to support SPNP for
geographic E.164 numbersspecifically. Following that, specific
@@ -174,9 +174,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 3
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 3
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
3. Abbreviations and Acronyms
@@ -233,9 +233,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
PCS Personal Communication Services
PNTI Ported Number Translation Indicator
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 4
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 4
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
PODP Public Office Dialing Plan
@@ -292,9 +292,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
old telephone service to Integrated Services Digital Network (ISDN)
services) while keeping the same phone number is called service
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 5
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 5
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
portability. Another aspect of service portability is to allow the
@@ -351,9 +351,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
below on number pooling, as this enhancement to NP further
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 6
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 6
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
bifurcates the role of donor network into two (the number range or
@@ -410,9 +410,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
(3) The Originating Network uses the routing number to route the
call to the new serving network.
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 7
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 7
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
@@ -469,9 +469,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
number.
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 8
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 8
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
(5) The Originating Network uses the routing number to route the
@@ -528,9 +528,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
Figure 4 - Onward Routing (OR) Scheme.
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 9
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 9
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
@@ -587,9 +587,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
Similarly, in other national E.164 numbering plans, number ranges
cover a contiguous range of numbers within that range. Once a
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 10
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 10
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
number within that range has ported away from the donor network, all
@@ -646,9 +646,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
of the protocol stack that includes the ANSI MTP Levels 1
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 11
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 11
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
through 3, ANSI SCCP, and ANSI TCAP. This interface can be used
@@ -705,9 +705,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
One of the following three interfaces can be used to query an NPDB:
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 12
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 12
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
@@ -764,9 +764,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it
is the Originating Network that has the routing information and is
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 13
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 13
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
ready to route the call. For the OR scheme, it is the donor network
@@ -823,9 +823,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
been performed. All the switches in the downstream will not perform
the NPDB query if the PNTI bit is set.
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 14
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 14
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
@@ -882,9 +882,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
In addition to the addition of the routing prefix to the CdPN
parameter, some other information may be added/modified as is listed
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 15
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 15
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
in the draft ITU-T Recommendation Q.769.1 [ISUP]. Those
@@ -941,9 +941,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
concatenated with the DN in the CdPN parameter.
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 16
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 16
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
If MNP-SRF is supported, the Gateway Mobile Services Switching
@@ -1000,9 +1000,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
+ + on-switch solution. +
+-------------+----------------------------------------------------+
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 17
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 17
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
+ Austria + Uses onward routing at the donor network. Routing +
@@ -1059,9 +1059,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
+ + where "xxxxx" identifies the recipient switch. +
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 18
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 18
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
+ + Telecom Italia uses IN solution and other operators+
@@ -1118,9 +1118,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 19
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 19
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
9. Number Conservation Methods Enabled by NP
@@ -1177,9 +1177,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
assigns individual telephone numbers to operators. Using the North
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 20
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 20
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
American example, one block of 10,000 TNs can be divided into 10,000
@@ -1236,9 +1236,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 21
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 21
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
IP-based networks can handle the domestic calls between two GSTNs.
@@ -1259,7 +1259,7 @@ Number Portability in the GSTN: An Overview February 9, 2000
dip indicator may not be present because there are cases where
routing number is added for routing the call even if NP is not
involved. One issue is how to transport the NP related information
via SIP. The SIP Universal Resource Locator (URL) is one mechanism.
via SIP. The SIP Uniform Resource Locator (URL) is one mechanism.
Another better choice may be to add an extension to the "tel" URL
[TEL] that is also supported by SIP. If the called directory is +1-
202-533-1234, and its associated routing number is +1-202-544-0000,
@@ -1285,7 +1285,7 @@ Number Portability in the GSTN: An Overview February 9, 2000
present in the "tel" URL in the SIP INVITE message, it instead of
the called directory number should be used for making routing
decisions. If "rn" is not present, then the dialed directory number
can be used as the routing number for making routing decisions.
can be used as the routing number for making routing decisions.
Telephony Routing Information Protocol (TRIP) [TRIP] is a policy
driven inter-administrative domain protocol for advertising the
@@ -1295,9 +1295,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
routing number, if present, not the called directory number that
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 22
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 22
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
should be used to check against the TRIP tables for making the
@@ -1315,7 +1315,7 @@ Number Portability in the GSTN: An Overview February 9, 2000
does not handle the overlap signaling and collect the complete
called directory number.
The IETF enum working group is defining the use of Domain Name
The IETF enum working group has defined the use of Domain Name
System (DNS) for identifying available services associated with a
particular E.164 number [ENUM]. [ENUMPO] outlines the principles
for the operation of a telephone number service that resolves
@@ -1351,19 +1351,19 @@ Number Portability in the GSTN: An Overview February 9, 2000
be to assign a special routing number so that the call to an end
user currently served by an IP entity is routed to the nearest GSTN
gateway. The called directory number then is used to locate the IP-
entity that serves that dialed directory number. Then a mechanism
is developed for the IP-based network to locate the IP entity that
entity that serves that dialed directory number. Then some
mechanisms are needed for the IP-based network to locate the IP
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 23
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 23
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
serves a particular dialed directory number. Many other types of
networks use E.164 numbers to identify the end users or terminals in
those networks. Number portability among GSTN, IP-based network and
those various types of networks may also need to be supported in the
future.
entity that serves a particular dialed directory number. ENUM can
be one of the mechanisms. Many other types of networks use E.164
numbers to identify the end users or terminals in those networks.
Number portability among GSTN, IP-based network and those various
types of networks may also need to be supported in the future.
11. References
@@ -1390,12 +1390,12 @@ Number Portability in the GSTN: An Overview February 9, 2000
[ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916.
[ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific
Provisioning: Principles of Operations," April 27, 2000.
Provisioning: Principles of Operations," draft-ietf-enum-
operation-02.txt, February 23, 2001.
[GSM] GSM 09.02: "Digital cellular telecommunications system (Phase
2+); Mobile Application Part (MAP) specification".
[IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for
Wireless Number Portability Phase II (December 1998)"Number
Portability Network Support," April 1998.
@@ -1413,9 +1413,9 @@ Number Portability in the GSTN: An Overview February 9, 2000
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 24
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 24
Number Portability in the GSTN: An Overview February 9, 2000
Number Portability in the GSTN: An Overview October 19, 2001
[RFC] Scott Bradner, RFC2026, "The Internet Standards Process --
@@ -1424,16 +1424,15 @@ Number Portability in the GSTN: An Overview February 9, 2000
[TEL] A. Vaha-Sipila, RFC2806, "URLs for Telephone Calls," April
2000.
[TELNP] J. Yu, draft-yu-tel-url-02.txt, "Extensions to the "tel" and
[TELNP] J. Yu, draft-yu-tel-url-03.txt, "Extensions to the "tel" and
"fax" URLs to support Number Portability and Freephone
Service," February 9, 2001.
Service," November 1, 2001.
[SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, RFC
2543, "SIP: Session Initiation Protocl," March 1999.
[TRIP] J. Rosenberg, H. Salama and M. Squire, draft-ietf-iptel-trip-
02.txt, "Telephony Routing Information Protocol (TRIP)," May
2000.
[TRIP] J. Rosenberg, H. Salama and M. Squire, RFC XXX, "Telephony
Routing Information Protocol (TRIP)," September 2001.
12. Acknowledgments
@@ -1471,13 +1470,13 @@ Number Portability in the GSTN: An Overview February 9, 2000
NeuStar, Inc.
1120 Vermont Avenue, NW,
Suite 550
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 25
Number Portability in the GSTN: An Overview February 9, 2000
Washington, D.C. 20005
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 25
Number Portability in the GSTN: An Overview October 19, 2001
United States
Phone: +1-202-533-2814
@@ -1530,8 +1529,9 @@ Full Copyright Statement
<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 26
<Foster,McGarry,Yu> Informational - Expiration in April 19, 2002 26

945
doc/draft/draft-ietf-enum-operation-02.txt
View File

@@ -1,945 +0,0 @@
Telephone Number Mapping A. Brown
Internet Draft Nortel Networks
Document: <draft-ietf-enum-operation-02.txt> Greg Vaudreuil
Lucent Technologies
February 23, 2001
ENUM Service Reference Model
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document outlines the principles for the operation of a
telephone number directory service. This service provides for the
resolution of telephone numbers into Internet domain name addresses
and service specific directory discovery.
Brown, Vaudreuil Expires August 2001 1
ENUM Reference Model February 23, 2001
Table of Contents
1. Abstract........................................................1
2. Introduction....................................................2
3. Scope...........................................................2
4. Overview........................................................4
4.1 Relationship with Dynamic Services.............................4
4.2 Number Portability.............................................5
5. The ENUM Service................................................5
5.1 First Tier: Determining the Service Registrar..................5
5.2 Second Tier: Retrieving Resource records.......................6
5.3 Third Tier: Service-Specific Queries...........................6
6. Interesting Numbering Topologies...............................8
6.1 Sub-addressing.................................................8
6.2 Default and Range-based Service Records........................9
6.3 Permissive dialing for dialing plan transitions...............9
7 Illustrative System Examples....................................10
7.1 Example: Hypothetical Reachme Service.........................10
7.2 Example: SIP Call Setup Service Request.......................11
8. Security Considerations........................................12
9. References.....................................................13
10. Acknowledgments...............................................13
11. Author's Addresses............................................13
12. Full Copyright Statement......................................14
Appendix:.........................................................15
Changes from draft-ietf-enum-operations-00.txt....................15
Changes from draft-ietf-enum-operations-01.txt....................15
2. Introduction
This document outlines the principles for the operation of a
telephone number directory service. This service provides for the
resolution of telephone numbers into the address of a service
specific directory or where applicable for a given service, directly
into a service-specific endpoint addresses.
This directory service uses the algorithms and methods described in
RFC 2916.
Please send comments on this document to the ENUM working group.
3. Scope
This document defines the reference architecture behind the ENUM
protocols necessary to implement a telephone number-based Internet
directory system. This solution enables an extensible set of
services to be provided for a given telephone number. Example
services may include IP telephony, store and forward or real-time
Internet Fax, VPIM voice messaging, Internet paging, geographic
phone location, and many others. Each service is to be separately
defined and identified using a unique, registered service
identifier.
Brown, Vaudreuil Expires August 2001 2
ENUM Reference Model February 23, 2001
This document does not specify the particulars of any telephone
number-based service. In particular, it does not describe how phone
calls are placed, routed, or terminated or how voice, fax, pager, or
email messages are routed.
Brown, Vaudreuil Expires August 2001 3
ENUM Reference Model February 23, 2001
4. Overview
This telephone number-based directory system implements a three-tier
information model; the first two constituting the ENUM service.
This abstract model is based on analysis of pre-existing
administrative structures, generalized service requirements, and the
capabilities of candidate protocols. This model does not itself
specify an administrative model, but provides a reference to guide
implementers or conforming clients and servers.
The mechanics of the ENUM service are specified in [ENUM].
The first tier is the mapping of the telephone number delegation
tree to the service registrar. Conceptually, this delegated
authority knows nothing about service-specific information
associated with the telephone number but provides a reference to
the service registrar that does know the specific information. Where
this services registrar is different from the delegated authority, a
query redirection from the delegated authority to the name server of
the service registrar for a given telephone number is necessary.
The second tier is the set of service records themselves. The
service records indicate which of several services may be available
for a given telephone number. Multiple records indicating redundant
or competitive service providers may be provided. The set of records
may be provided or modified by any number of service providers. The
ENUM service defines these records to be NAPTR records yielding a
valid URL for a potentially useful service. It is up to the client
initiating the service request to sort through the set of NAPTR
records to determine which services are appropriate for the intended
action.
The service registrar is conceptually responsible for maintaining
the set of service records for a given telephone number. Because
there may be multiple service providers for a given telephone
number, conceptually this registrar of services assumes a role of
managing service registrations and arbitrating conflicts between
service providers.
If necessary, an additional service-specific tier of information can
be provided by the service provider itself. This tier provides
specific attributes including any necessary attributes to place a
call, route a message, validate capabilities, or other data
necessary for that service that are known only by the provider of
that specific service.
4.1 Relationship with Dynamic Services
The telephone number delegation information changes infrequently.
However, when a change to this data is made, the information must be
rapidly propagated through the directory system. Inconsistencies
between the authoritative data and cached data may result in loss of
service, misrouting of communications, and/or service loops. An
effective ENUM service requires that DNS time-to-live fields be set
to an appropriate value consistent with the telephone number
reassignment policies and service record update intervals.
Use of the ENUM system to implement time-of-day and other highly
dynamic services is discouraged. Where such a service is desired,
Brown, Vaudreuil Expires August 2001 4
ENUM Reference Model February 23, 2001
it is recommended that itself be implemented as part of a service
indicated by the service records.
4.2 Number Portability
The concept of number portability generally refers to the ability of
a subscriber to change service providers, service types, or
locations without changing their telephone number. For a full
discussion of number portability, see [PORT]. In support of number
portability, the ENUM service provides mechanism at the three
conceptual tiers of the ENUM service.
1. If the telephone number has been re-delegated to another
authority, and that authority also provides the Tier-1 ENUM
service, the telephone number can be re-delegated in the ENUM
service by changing the name server "NS" records to point to the
new authority. This may be the case where numbers are re-
delegated from the incumbent service provider to another or to a
portability authority. The immediately higher delegated authority
coordinates the transfer.
2. The service registrar may be reassigned. This may be the case
where an individual or corporation changes telephony service
providers and wishes that telephony service provider to also
provide service registrar functions. The new service registrar
would recreate the appropriate service specific NAPTR records and
the delegated authority would coordinate the transfer from one
registrar to the other.
3. If a specific service for a given telephone number was changed
from one provider to another, such as switching telephone
answering / voice messaging providers, the NATPR record indicating
the specific service would change. The service registrar would
coordinate the deletion of the record for the previous service
provider and the insertion of a record for the new service
provider.
It is anticipated that in the early stages of an ENUM deployment,
the delegated authority and the service registrar may be the same
entity.
5. The ENUM Service
5.1 First Tier: Determining the Service Registrar
The first tier is the mapping of an E.164-formatted international
telecommunication number into the identity of the service registrar
for that number. This may or may not involve more than one referral
in DNS.
The delegation of telephone numbers from the root authority (the
ITU) down to individuals is a well-established system. While there
are differing Tier-1 administrative models, to a client they each
aim to represent in a single tree the trusted relationship between
the delegated carriers and subsidiary registrars; a necessary
precondition to ensure protection against various attacks. The
delegated authority, sub-delegated authority, or individual may
arrange to have a third-party (e.g., a service provider) list their
Brown, Vaudreuil Expires August 2001 5
ENUM Reference Model February 23, 2001
information. In this case the service provider's domain would be
returned in the ENUM query.
The Internet Domain Name System provides an ideal technology for the
first-tier directory due to its hierarchical structure, fast
connectionless queries, and distributed administrative model.
Earlier experimentation with the TPC.INT remote printing experiment
has shown how the hierarchical assignment of telephone numbers can
be mapped directly to the hierarchy of domains within the DNS. The
ENUM directory uses that approach to map any arbitrary telephone
number into a single domain name.
ITU standard E.164 defines the structure of the public telephone
number as follows: country code, followed by nationally significant
part, followed by sub-address. The country code may be from one to
three digits, and the total length may be up to 15 digits. The
nationally significant portion may be arbitrarily divided on any
number boundary. In many countries numbering plans, the divisions
are not uniform, that is, the "area codes" or "city codes" may be of
varying lengths within a single country and the total number of
digits may be variable. Where supported by the relevant service, an
optional sub-address of up to four digits may be utilized to
designate an extension telephone number. Note that while sub-
addressing is not well supported in GSTN calling, it is more widely
supported for voice messaging. It is important to note that the
national long-distance access or international dialing prefix
sequence is not part of the canonical E.164 number.
Within this delegation flexibility, it is always the case that the
delegation of authority is always done left-to-right. With this
assumption, a numbering tree can be built on a digit-by-digit basis
that can represent any arbitrary hierarchical structure. DNS
permits the delegation of authority on arbitrary boundaries such
that a delegation to country code "1", "44", and "972" can all
coexist under a single numbering plan root. The same applies for
"service selectors", "area codes", "city codes", "line number", or
"additional address information " within numbering plans.
5.2 Second Tier: Retrieving Resource records.
The second tier is the request for NAPTR RRs to discover the URL of
the appropriate service-specific directory such as an LDAP directory
server, H.323 gatekeeper, or specific endpoint addresses.
The service registrar is responsible for ensuring that multiple
services may be provided on behalf of a single telephone number,
potentially by different service providers. This function includes
an arbiter function to ensure that there is a deterministic instance
of any given service assigned to a single telephone number. The
service-specific directory locator function is a new service modeled
upon existing telco service provisioning models. Long-distance
carrier selection within the United States is one well-known example
of a service-specific registration requiring an arbiter function
within the current network.
5.3 Third Tier: Service-Specific Queries
An additional tier of query may be used to a service-specific
directory for service-specific information. As indicated in the
Brown, Vaudreuil Expires August 2001 6
ENUM Reference Model February 23, 2001
URI, such a query may include a SIP query to a designated gatekeeper
or an LDAP query to a designated directory server. This tier is
specific to the service and is to be described in service-specific
documents. The service-specific directory is expected to be
dynamic. It is important that as little coordination as possible be
required between the directories of innovative and potentially
competing service-specific providers.
Brown, Vaudreuil Expires August 2001 7
ENUM Reference Model February 23, 2001
6. Interesting Numbering Topologies
The following numbering uses require special consideration in the
provision and use of ENUM services.
6.1 Sub-addressing
The E.164 standard provides for sub-addressing through "additional
information" within the 16 digits of an E.164 number. This
information is passed through many telecommunications networks to be
used by terminal equipment to select between alternate services or
terminal devices. The sub-address digits are not processed by the
switching system and are not used by intermediate processes to
select services or route calls. In many cases, the network-
numbering infrastructure may be unaware of the existence or use of
sub-addressing by a given endpoint. Within ENUM, sub-addressing may
be supported in two ways. The service registrar may explicitly
provision NAPTR records for each sub-address, or the service
registrar may provision default records for a range of sub-
addresses.
Using common DNS server implementations, the registrar may provision
default records for a block of sub-addresses. A combination of
explicit entries and default entries may be provided in common DNS
server implementations using a longest-match algorithm. It is
important to note that if a NAPTR or any other RR is provisioned for
a sub-address, then all NAPTR records that are useful for that sub-
address must also be provisioned.
It is also important to note that numbers with optional sub-
addresses may be queried without the sub-address component. For
example, it may be useful to dial an address when placing a PSTN
telephone call. The telephone number may terminate on an automated
attendant application that can prompt for the appropriate internal
extension. However, when placing a SIP call using IP telephony, the
address plus the sub-address may be queried.
The following set of records for company.com illustrate one
configuration where a PSTN caller will be directed to the automated
attendant application whether they dial the number or the number
plus a sub-address, and whether the sub-address is explicitly
provisioned or not. Calling using SIP to the explicitly provisioned
sub-address will result in a direct call to the intended recipient.
Example:
1.2.3.4.5.6.7.8.9.e164.arpa
IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" .
IN NAPTR 10 10 "u" "sip+E2U" "!+(.*)!sip:AA@company.com!" .
*.1.2.3.4.5.6.7.8.9.e164.arpa
IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" .
IN NAPTR 10 10 "u" "sip+E2U" "!+(.*)!sip:AA@company.com!" .
1.0.1.1.2.3.4.5.6.7.8.9.e164.arpa
IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:joe@company.com!" .
IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" .
Brown, Vaudreuil Expires August 2001 8
ENUM Reference Model February 23, 2001
6.2 Default and Range-based Service Records
It is envisioned that a corporation or service provider not subject
to number portability may wish to maintain a set of default NAPTR
records for all E.164 telephone numbers within a delegation block.
Similar to sub-addressing, a service registrar may provision a set
of NAPTR records for a set of E.164 numbers with similar service
requirements.
Example:
*.3.4.5.6.7.8.9.164.arpa
IN NAPTR 102 10 "u" "tel+E2U" "!+(.*)!Tel:+\1" .
IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:AA@company.com!" .
IN NAPTR 10 10 "U" "mailto+E2U" \
"!+(.*)!mailto:+\1@company.com!" .
1.0.3.4.5.6.7.8.9.164.arpa
IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654310!" .
IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:AA@company.com!" .
2.2.3.4.5.6.7.8.9.164.arpa
IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654322!" .
IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:joe@company.com!" .
IN NAPTR 10 10 "U" "mailto+E2U" \
"!^.*$!tel:+987654322@company.com!" .
In this example, mail sent to the phone number +987654311 using
1.1.3.4.5.6.7.8.9.164.arpa will be sent to +987654311@company.com.
Mail is explicitly not accepted at the automated attendant number as
indicted by the lack of a mailto service record. Because extension
22 has an explicit NAPTR record for inbound calls via the tel
record, it must also have an explicit mailto: URL in a NAPTR record.
6.3 Permissive dialing for dialing plan transitions
In the real-world environment, the telephone number hierarchy is
modified as necessary to prevent number exhaustion and to facilitate
new services. These re-numberings either insert additional digits
at arbitrary parts of the previous telephone number or result in the
re-assignment of a sub-tree of numbers to a new prefix. To avoid
the operational and social disruption involved with a _flash cut_, a
practice of _permissive dialing_ has been created. Permissive
dialing enables and end-user to use either the previous or new
telephone number for a period of time. During this time, there may
be two different telephone numbers pointing to the same set of
service records, or a duplicate set of service records for the new
and previous number.
Brown, Vaudreuil Expires August 2001 9
ENUM Reference Model February 23, 2001
7 Illustrative System Examples
7.1 Example: Hypothetical Reachme Service
The following hypothetical service enables an end-user to discover
the various means by which she can reach a recipient represented by
their corporate telephone number +1 613-555-1212 using the
hypothetical "reachme" service. This service is hosted by directly
by the recipient's corporation.
The telephone number is transformed into a domain name form to be
used in a DNS query.
2.1.2.1.5.5.5.3.1.6.1.e164.arpa
Sample configuration file for the top tier delegations from ITU:
1.e164.arpa. IN NS ns.NANP.phone.net. ;for NANP
3.3.e164.arpa. IN NS ns.FR.phone.net. ; for France
2.7.9.e164.arpa. IN NS ns.il.phone.net. ; for Israel
Sample configuration file for numbers delegated from the NANP node
in the DNS tree:
5.5.5.3.1.6.1.e164.arpa. IN NS ns.Zcorporation.com.
;for +1 613 555 XXXX
Zcorporation is the designated service registrar for the block of
100 numbers +1 613 555 12XX. Zcorporation provides the following
service specific record for all telephone numbers within it's 100
number block:
*.2.1.5.5.5.3.1.6.1.e164.arpa.
IN NAPTR 100 10 "u" "ldap+E2U"\
"$!ldap://ldap1.Zcorporation.com/cn=\1!" .
Assuming the resolver is using non-extended DNS, the query using
telephone number +1 613 555 1212 for the_reachme service is as
follows:
QueryType: NAPTR
QueryName: _ 2.1.2.1.5.5.5.3.1.6.1.e164.arpa.
Response:
IN NAPTR 10 10 "u" "Reachme+E2U" \
"!LDAP:\\ldap1.zcorporation.com\cn=\1!" .
The client can then apply the regular expression to yield an LDAP
URI of LDAP:\\ldap1.zcorporation.com\cn=16135551212 and then use
LDAP with the reachme schema to determine the set of communications
technologies available for +1 613 555 1212.
Brown, Vaudreuil Expires August 2001 10
ENUM Reference Model February 23, 2001
7.2 Example: SIP Call Setup Service Request
This example provides resolution of a telephone number to the
identifier for the SIP gatekeeper designated to support real-time
calling (Sipphonecall) to 972 555 1313. The telephone number is
part of a block of ported telephone numbers that have been ported
out of the donor carriers block to another carrier.
The telephone number is transformed into a domain name form to be
used in a DNS query.
Sample configuration file for the top tier delegations from ITU:
1.e164.arpa. IN NS ns.NANP.phone.net. ;for NANP
3.3.e164.arpa. IN NS ns.FR.phone.net. ; for France
2.7.9.e164.arpa. IN NS ns.il.phone.net. ; for Israel
Sample DNS configuration file for the ported number block serviced
by the 972 555 number portability authority delegated from the NANP
node in the DNS tree:
5.5.5.2.7.9.1.e164.arpa. IN NS ns.972555Port.NANP.phone.net.
;for 972 555
The number portability authority manages the delegation on a per-
telephone number basis. Logically, the ns.972555Port.NANP.phone.net
has the following record for the telephone number.
3.1.3.1.5.5.5.2.7.9.1.e164.arpa. IN NS ns.ServiceProviderB.net.
;for 972 555 1313
ServiceProviderB provides service registrar functions directly for
the telephone number. The following configuration entry is provided
for +1 972 555 1313.
3.1.3.1.5.5.2.7.9.1.ServiceProviderB.net.
IN NAPTR 10 10 "u" "sip+E2U"\
"!^.*$!sip:19725551313@ServiceProviderB.net!" .
The DNS Query and response using telephone number +1 972 555 1313:
QueryType: NAPTR
QueryName: 3.1.3.1.5.5.5.2.7.9.1.e164.arpa
Result:
IN NAPTR 10 10 "u" "sip+E2U" \
"!^.*$!sip:19725551313@ServiceProviderB.net!" .
The client can now use the SIP protocols to contact the SIP gateway
to initiate a phone call.
Brown, Vaudreuil Expires August 2001 11
ENUM Reference Model February 23, 2001
8. Security Considerations
The following are known security issues taken into consideration in
the definition of this directory service.
1. Service provider customer information is very sensitive,
especially in this time of local phone competition. Service
providers require the maximum flexibility to protect this data.
2. Registration of a domain name for the telephone numbers
delegated to another carrier may result in messages being
misdirected to the wrong carrier. As subdelegations are
implemented, the risk that phone numbers delegated to one
enterprise may be incorrectly pointed at another will increase.
3. Service providers operate in a regulated environment where
certain information about subscribers must not be disclosed.
Telephony services and Voice Messaging are subject to caller-ID
blocking restrictions, restrictions normally enforced in the
telephony network. No such protection is available on the
Internet. The protection of this data is essential, but is up
to the individual service providers to not disclose this
information outside of their control.
Brown, Vaudreuil Expires August 2001 12
ENUM Reference Model February 23, 2001
9. References
[DNS1] Mockapetris, P., "Domain names - implementation and
specification", RFC1035, Nov 1987.
[DNS2] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, Nov 1987.
[SRV] Arnt Gulbrandsen, Paul Vixie, Levon Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", Work in Progress
[E164] ITU, "CCITT Recommendation E.164 (1991), Telephone Network
and ISDN Operation, Numbering, Routing and Mobile Service -
Numbering Plan for the ISDN Era."
[TPC1] Malamud, Carl, Rose, Marshall, "Principles of Operation for
the TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC
1530, October 1993.
[VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet
Mail, Version 2", RFC 2421, September 1998.
[SRV] Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[REQ] Brown, Anne, "ENUM Requirements", work-in-progress, November
1999
[ENUM] Faltstrom, Patrick, "E.164 number and DNS", RFC 2916,
September 2000.
[NAPTR] M. Mealling, R. Daniel _The Naming Authority Pointer (NAPTR)
DNS Resource Record_, RFC 2915, September 2000.
[PORT] M. Foster, T. McGarry, j. Yu, _Number Portability in the
GSTN: An Overview_, Work-in-Progress, July 2000.
10. Acknowledgments
11. Author's Addresses
Anne R. Brown
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1-613-765-5274
Fax: +1-613-763-2697
Email: ARBrown@NortelNetworks.com
Gregory M. Vaudreuil
Lucent Technologies,
Communications Application Group
17080 Dallas Parkway
Dallas, TX 75248-1905
United States
Phone/Fax: +1-972-733-2722
Email: GregV@IEEE.org
Brown, Vaudreuil Expires August 2001 13
ENUM Reference Model February 23, 2001
12. Full Copyright Statement
"Copyright (C) The Internet Society (2001). 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
Brown, Vaudreuil Expires August 2001 14
ENUM Reference Model February 23, 2001
Appendix:
Changes from draft-ietf-enum-operations-00.txt
o Discussion of interesting numbering topologies was added
o Retrieval of NAPTR records are now described in a separate step
from the determination of a service registrar.
o A new example was created to illustrate ENUM using sub-addressing.
Changes from draft-ietf-enum-operations-01.txt
O Changed the title to more clearly reflect the intent of the
document.
o Collapsed Level 1 and 2 into a single tier. Aligned the document
to use the _tier_ terminology.
o Added missing text for dynamic updates.
o Reworked the examples to eliminate all references to the
controversial DNAME and CNAME redirection.
o Generalized descriptions of the administrative model to avoid
exclusion of any particular tier-1 approach.
o Corrected various errors in the examples.
Brown, Vaudreuil Expires August 2001 15

20
doc/draft/draft-ietf-enum-operation-03.txt Normal file
View File

@@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
G. Vaudreuil: gregv@lucent.com
A. Brown: arbrown@nortel.ca

1741
doc/draft/draft-ietf-idn-amc-ace-m-00.txt
View File

File diff suppressed because it is too large Load Diff

19
doc/draft/draft-ietf-idn-amc-ace-m-01.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
A. Costello: amc@cs.berkley.edu

1053
doc/draft/draft-ietf-idn-brace-00.txt
View File

File diff suppressed because it is too large Load Diff

19
doc/draft/draft-ietf-idn-brace-01.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
A. Costello: amc@cs.berkley.edu

794
doc/draft/draft-ietf-idn-dnsii-mdnp-02.txt
View File

@@ -1,794 +0,0 @@
IDN Working Group Edmon Chung & David Leung
Internet Draft Neteka Inc.
<draft-ietf-idn-dnsii-mdnp-02.txt> February 2001
The DNSII Multilingual Domain Name Protocol
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The reader is cautioned not to depend on the values that appear in
examples to be current or complete, since their purpose is primarily
educational. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A copy of this particular draft is also archived at
http://www.dnsii.org.
Abstract
The core thinking for DNSII is that multilingual DNS requests SHOULD
be signaled within a DNS label whether by way of a binary tag or an
alphanumeric prefix, and that compatibility to legacy client
applications SHOULD be taken into concern alongside legacy server
implementations.
Besides the original specifications, four alternatives including the
use of EDNS are included for discussion purposes in this document.
Historically, the DNS is capable of handling only names within the
basic English alphanumeric character set (plus the hyphen), yet the
standards were so elegantly and openly designed that the extension of
the DNS into a multilingual and symbols based system proves to be
possible with simple adjustments.
These adjustments will be made on both the client side and the server
side. However, DNSII works on the principal that it is preferable to
make the transition to multilingual domain names seamless and
DNSII-MDNP Multilingual Domain Name Protocol August 2000
transparent to the end-user. Which means initially the server SHOULD
take the primary responsibility for the technical implementation of
the changes required for a multilingual Internet.
The DNSII protocol is designed to allow the preservation of
interoperability, consistency and simplicity of the original DNS,
while being expandable and flexible for the handling of any character
or symbol used for the naming of an Internet domain. DNSII intends
to provide a platform for the implementation of multilingual domain
names.
Table Of Contents
1. Introduction....................................................2
1.1 Terminology....................................................2
1.2 DNSII..........................................................3
2. DNSII Protocol..................................................3
2.1 InPacket DNSII Identifier......................................3
2.2 InPacket Label Encoding Type (ILET)............................4
2.3 The Rationale for using ILET...................................5
2.4 Considerations for Specific Requests...........................6
2.4.1 PTR Records..................................................6
3. Alternate Implementations.......................................7
3.1 Restricted ILET Values.........................................7
3.2 Reduced ILET Bit Allocation....................................8
3.3 DNSII over EDNS................................................9
3.3.1 DNSII Identifier using EDNS..................................9
3.3.2 ILET using EDNS OPT RRs.....................................10
4. Implementation & Deployment Strategies.........................11
5. IDN Requirements Considerations................................12
6. DNSSEC, EDNS and IPv6 Considerations...........................12
7. Intellectual Property Considerations...........................13
8. References.....................................................13
1. Introduction
This Internet-draft describes details of the DNSII Multilingual
Domain Name protocol. The Internet-Draft assumes that the reader is
familiar with the concepts discussed in the widely distributed RFCs
"Domain Names Concepts and Facilities" [RFC 1034] and "Domain Names
Implementation and Specification" [RFC 1035].
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in RFC
2119 [RFC2119].
A number of multilingual characters are used in this document for
examples. Please select your view encoding type to UTF-8 for it to
be displayed properly.
DNSII-MDNP Multilingual Domain Name Protocol August 2000
1.2 DNSII
The DNSII specifications takes a radically different approach: it
successfully identifies the difference between original DNS and DNSII
packets within the labels and at the same time allows the use of
multiple charsets to be easily incorporated in a standardized manner.
It causes no harm to the current DNS because it embraces the original
format for DNS laid out in RFC1035, complemented with the ideas
incorporated in EDNS [RFC2671].
2. DNSII Protocol
The DNSII Protocol consists mainly of two parts: the InPacket DNSII
Identifier and the InPacket Label Encoding Type. In addition, there
are several special considerations for specific record types.
2.1 InPacket DNSII Identifier
In the DNSII specifications, an InPacket DNSII Identifier MUST be
inserted before a label to signify that it contains extended
characters that are not supported by the current DNS.
This DNSII flag, which is the first two bits of a label, effectively
distinguishes a DNSII compliant request from the existing format,
without having to conduct a guess from a name check whether the
incoming packet is multilingual aware. This is a substantial
improvement over character encoding schemes and multilingual
implementations in which it is almost impossible to determine the
language of an incoming request. The DNSII flag makes the process
clear and simple.
Currently:
"00" regular label [RFC1035]
"11" a redirection for DNS compression [RFC1035]
"01" indicates the use of EDNS for multiple UDP packets [RFC2671]
DNSII calls for the use of the bit sequence "10" to identify that the
querying node is DNSII aware. This will mean that all the possible
variations at top two label bits will be used. Therefore, in
consideration, following two bits MUST be reserved for future
flagging use. The 2 bits SHOULD be arbitrarily set to "00". This
effectively opens up 3 more possible implementations for future
enhancements.
The motivation for this approach is the belief there should be no
ambiguity in name resolution. Any name that the client wishes to
resolve, should resolve, regardless of the client side-encoding
scheme.
DNSII-MDNP Multilingual Domain Name Protocol August 2000
2.2 InPacket Label Encoding Type (ILET)
Immediately following the 2 assigned DNSII flag and the 2 reserved
bits are 12 bits assigned to determine the InPacket Label Encoding
Type (ILET).
The ILET is a 12-bit number that is used to determine the encoding
scheme used by the characters of the label. The MIBenum numbers
[RFC1700] SHOULD be used in this field. The allocation of 12 bits
aligns perfectly with the MIBenum specification, of which the value
goes up to over 2200. With 12 bits, the total possible values would
be 4096 (with 11 bits, the largest value that can be represented is
only 2047, slightly short of the specification). The reason for the
adoption of MIBenum is to make use of the existing list of encoding
numbering schemes rather than re-inventing the wheel.
The value in the ILET field SHOULD only be allowed for the valid
encoding schemes defined in the MIBenum list. After identifying the
encoding type, the regular count-label scheme of the DNS resumes.
The resulting label should look like this:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+-------+---------------+
|1 0| z | ILET |
+---------------+---------------+
| COUNT | characters... |
+---------------+---------------+
To minimize the size of a DNS packet, if the entire label is
constituted in characters only from the ANSI table, the DNS label
will appear identical to current implementations. The first two bits
will remain "00".
For example, using the DNSII format the label for "dns" MAY be
represented as:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 0| 0 0| 0 0 0 0 0 0 0 0 0 0 1 1| MIBenum 3 = ANSI
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 3 | 6 4 | "d"=64
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 6 E | 7 3 | "n"=6E "s"=73
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Or, the same domain label "dns" MAY also be represented as:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 3 | d |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| n | s |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Chung & Leung [Page 4]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
With a multilingual domain name ns.<2E><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>.tld as an example:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------------------------------------------------------+
|1 0| z | ANSI=3 | 2 | n |
+---------------------------------------------------------------+
| s |1 0|0 0| UCS-2=1000 | 4 |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+57DF) | <20><><EFBFBD> (U+540D) |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+7CFB) | <20><><EFBFBD> (U+7D71) |
+---------------------------------------------------------------+
|0 0| 3 | t | l | d |
+---------------------------------------------------------------+
| 0 |
+---------------+
From the above example, we can see that the DNSII format is used for
the first label "ns", as well as for the second label, which is in
Chinese (the MIBenum for UCS-2 or ISO 10646 [Unicode] is 1000). The
third label "tld" however uses the current format.
In any case, the count-label-count-label mechanism is largely
preserved. Especially in the case of extended characters where in
other proposals, the "count" no longer represents the character
count. In the above example, the domain is still represented as 2ns4
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>3t ld0, exactly in line with the original specifications.
Note that the first label in any query could be represented in DNSII
format to alert the destination server that it is DNSII aware. This
is not required but is specifically configured for the considerations
with CNAME, A6, DNAME and PTR records.
This approach is used to ensure that there is no confusion about the
encoding format of the label. ILET allows the capability of
employing all existing encoding schemes (UTF-7, UTF-8, ISO 10646
[UCS-2], ISO 10646 [UCS-4]). ILET also allows the flexibility of
employing future encoding schemes.
2.3 The Rationale for using ILET
Besides being able to preserve the count-label-count-label structure,
which in itself is actually a very important part because of the
problematic non-uniform byte encoding schemes, the use of ILET aligns
perfectly with previous IETF specifications as well as beneficial for
tricky case folding and canonicalization issues.
We know that all protocols MUST identify, for all character data,
which charset is in use [RFC2277], therefore it is necessary to
specify whatever encoding scheme, whether it be UTF-8, UTF-7, 16-bit
UCS-2 or ISO 8859 that is being used. In essence, we understand that
Chung & Leung [Page 5]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
it is paramount that a charset be clearly identified, especially in
situation like the DNS where no direct communication is established.
At times and in specific cases, language information may be required
to achieve a particular level of quality for the purpose of
displaying a text stream. For example, UTF-8 encoded Han may require
transmission of a language tag to select the specific glyphs to be
displayed at a particular level of quality.
Note that information other than language may be used to achieve the
required level of quality in a display process. In particular, a
font tag is sufficient to produce identical results. However, the
association of a language with a specific block of text has
usefulness far beyond its use in display. In particular, as the
amount of information available in multiple languages on the World
Wide Web grows, it becomes critical to specify which language is in
use in particular documents, to assist automatic indexing and
retrieval of relevant documents._ [RFC2130]
In effect, this means for different languages, it is beneficial to be
able to identify the language in order to perform specific functions
to the characters, including case folding. With ILET, the local
encoding scheme could be used and with them there are well defined
folding methods. Therefore, the use of ILET enables an optimized
folding mechanism brought about by the preservation of local encoding
schemes, which is otherwise very difficult or virtually impossible to
do if only UTF-8 is used.
For the DNS however, a language tag is less feasible because if a
name is consisted of multiple languages, it would be very difficult
for tagging to be performed. The possibility of having multiple
languages is very sound, and is used frequently as trademarks around
the world. For example the famous Toys"ϯ"Us name, uses a character
from the Cyrillic language set.
2.4 Considerations for Specific Requests
For certain requests, an ANSI only name could result in a
multilingual domain as an answer. These include PTR, CNAME, A6 and
DNAME requests. Special considerations are made within the DNSII
protocol to make sure that non-DNSII aware servers will not be fed
with a DNSII format packet.
2.4.1 PTR Records
For all PTR requests, the first label of the query MUST use DNSII
format to alert the destination server. Upon which, a DNSII packet
will be replied should the name contain extended characters.
If the DNSII format is not used, and the PTR record stumbles upon a
multilingual domain name, one of the following responses SHOULD be
given:
Chung & Leung [Page 6]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
a. The implementer of DNSII MAY chose to reject the request;
or
b. An ACE format domain with a "for.ref.only" suffix MAY be returned;
or
c. A DNSII compliant server MAY return an 8-bit format of the
requested domain.
Since the PTR record is usually used for display purposes only, the
rejection (the IP address will then be used) or ACE format is
acceptable. If the response is however used for further resolution,
an ACE format MUST not be used.
2.4.2 CNAME, A6 & DNAME
For queries concerning the record types CNAME, A6 or DNAME, a DNSII
aware server should first check to see if the incoming request is
DNSII compliant (flagged by the "10" bits in the first label):
If so, and the domain to be returned includes extended characters,
the response SHOULD be in DNSII format.
If not, any multilingual domains returned should be in an 8 bit form.
For the above record types it is strongly RECOMMENDED not to
associate an alphanumeric label to a multilingual label as the
RDATA. However, it is permissible to associate a multilingual label
with an alphanumeric label as the RDATA.
3. Alternate Implementations
The DNSII-MDNP is intended to be a framework for the implementation
of multilingual domain names. While the core concepts and the design
principles remain consistent, it is possible to contemplate
alternative implementations. The four alternatives introduced here
include the arbitrary restriction of ILET values, the reduction of
ILET bit allocation for reflecting ISO 10646 transformations only,
and finally two implementations using DNSII over EDNS.
3.1 Restricted ILET Values
One possible implementation guideline is for the ILET to be
restricted to values only representing ISO 10646 transformations
including UCS-2, UCS-4, UTF-7, UTF-8, UTF-16 and other as they become
available and included as a standard MIBenum.
Chung & Leung [Page 7]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
Although this takes away some of the benefits of keeping the local
encoding scheme which includes the issues of case folding,
canonicalization and other related concerns, it creates a system that
on one hand contains only encoding schemes from ISO 10646, but on the
other hand still provides the flexibility of deploying new encoding
schemes that stem from ISO 10646, such as the 32-bit format that is
due to be used soon.
We understand it is specified that in protocols, which up to now have
used US-ASCII only, UTF-8 forms a simple upgrade path; however, its
use should be negotiated either by negotiating a protocol version or
by negotiating charset usage, and a fallback to UTF-7 MUST be
available. [RFC2130] With DNSII, the required fallback to UTF-7
could easily be done by setting the ILET value to reflect UTF-7.
3.2 Reduced ILET Bit Allocation
Furthering the restriction of the ILET to ISO 10646 transformations
only, the ILET bit allocations could also be reduced from 12 bit to 5
bit. This successfully creates a total of 32 possible values. The
reserved bits are also reduced to one.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+-+---------+---------------+
|1 0|z| ILET | COUNT |
+---------------+---------------+
| characters... |
+---------------+
For example, the label "<22><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>" will now be reflected in DNS packets
in the following form:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------------------------------------------------------+
|1 0|z| ILET=1 | 4 | <20><><EFBFBD> (U+57DF) |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+540D) | <20><><EFBFBD> (U+7CFB) |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+7D71) |
+--------------------------------+
To start off with, the ILET values MAY be determined as follows:
0 = reserved for ANSI 1 = UTF-7
2 = UCS-2 3 = UTF-8
4 = UCS-4 5 = UTF-16
6 = 6 octets per character 7 = 7 octets per character
8 = UCS-8 (8 octets per character) 9 = UTF-31
etc.
Chung & Leung [Page 8]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
The ILET number will be the number of octets that should be read each
time, with exceptions at 0,3,5,9 or any number that is just after a
full UCS. ILET=3 corresponds to UTF8 because ILET=2 = UCS2 and UTF-8
is a compatibility transformation for UCS-2 (in 16bit) in 8bit. A
possible future expansion to UCS-8 is also included to make the
schema truly future prove.
This arrangement opens up opportunity and versatility of the use of
private schemes that make use of odd byte length characters or
symbols such as 6, 7 or even 18octet representations without the need
for the DNS to update or adjust to, while maintaining the integrity
and unique nature of domain names.
3.3 DNSII over EDNS
While DNSII and EDNS could coexist, it is possible to implement the
DNSII concept onto an EDNS based platform. It is however preferable
to use both EDNS and the DNSII scheme together as described in
Section 6, because EDNS(0) compliant servers may have trouble when
the label count exceeds the value of 63 (and smaller than 127)
because then, the EDNS mechanism MAY be reiterated.
Nevertheless, it is possible to utilize EDNS to act as a DNSII
Identifier. The short-comings and pit-falls are however further laid
in another draft DNSII-EDNS.
3.3.1 DNSII Identifier using EDNS
EDNS could simply be used in place of the DNSII Identifier. Assuming
that the reduced ILET values introduced in Section 3.2 is used, the
ILET will fit nicely into one octet immediately following the ELT
portion. The resulting representation for the domain "host.<2E><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
.tld" would be as follows:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------------------------------------------------------+
20|0 0| 4 | h | o | s |
+---------------------------------------------------------------+
| t |0 1|0 0 0 0 1 0| ILET=UCS-2=2 | 4 |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+57DF) | <20><><EFBFBD> (U+540D) |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+7CFB) | <20><><EFBFBD> (U+7D71) |
+---------------------------------------------------------------+
|0 0| 3 | t | l | d |
+---------------------------------------------------------------+
| 0 |
+---------------+
Chung & Leung [Page 9]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
The OPT RR could be used not only for version control but also as a
notification for the destination server on the level of conformance
of the inquirer. This is especially beneficial when considering the
issues raised in Section 2.4 where ANSI only requests my result in a
multilingual response.
Proposed identifications within the OPT RR (used in this document for
discussion purposes):
ELT = 0b000010
EDNS-VERSION = 2 (DNSII)
OPTION-CODE = 1 (IDN)
OPTION-DATA = conformance level (defined in DNSII-MDNR Section 4)
Plus other information if required
The conformance level SHOULD be included in the first octet of the
OPTION-DATA field and reflect the value corresponding to:
BASIC conformance = 1
INTERMEDIATE conformance = 2
FULL conformance = 3
A resulting DNSII OPT RR from a fully compliant inquirer SHOULD be in
the form:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------------------------------------------------------+
| NAME=0 | TYPE = OPT = 41 | Sender's UDP |
+---------------------------------------------------------------+
| Payload Size |EXTENDED-RCODE=0|EDNS-VERSION=2| z |
+---------------------------------------------------------------+
| z | RDLENGTH = 5 | OPTION-CODE = |
+---------------------------------------------------------------+
| IDN = 1 | OPTION-LENGTH = 1 | Conformance=3 |
+---------------------------------------------------------------+
3.3.2 ILET using EDNS OPT RRs
Instead of using the OPT RR only as a notification of DNSII
awareness, it utilized to indicate the type of encoding that is being
used in the labels. In other words, the ILET value could be included
in the OPT RR instead of within the label.
The ILET value will be included right after the conformance level
octet in the OPTION-DATA field within the OPT RR RDATA.
Chung & Leung [Page 10]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
The resulting QNAME labels and OPT RR for the domain "www.<2E><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
.tld" from a fully compliant inquirer sending the name in UCS-2
would become:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------------------------------------------------------+
|0 0| 3 | w | w | w |
+---------------------------------------------------------------+
|0 1|0 0 0 0 1 0| 4 | <20><><EFBFBD> (U+57DF) |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+540D) | <20><><EFBFBD> (U+7CFB) |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+7D71) |0 0| 3 | t |
+---------------------------------------------------------------+
| l | d | 0 |
+-----------------------------------------------+
(OPT RR containing ILET information)
: :
/ /
+---------------------------------------------------------------+
| NAME=0 | TYPE = OPT = 41 | Sender's UDP |
+---------------------------------------------------------------+
| Payload Size |EXTENDED RCODE=0|EDNS-VERSION=2| z |
+---------------------------------------------------------------+
| z | RDLENGTH = 9 | OPTION-CODE = |
+---------------------------------------------------------------+
| IDN = 1 | OPTION-LENGTH = 4 | Conformance=3 |
+---------------------------------------------------------------+
| 1 | 0 | 0 | 0 |
+---------------------------------------------------------------+
Note that instead of allocating only 12 bits for the ILET, the
MIBenum value is expressed over 4 octets with each octet carrying a
numeric value. Since UCS-2 is used and the MIBenum value for UCS-2 =
1000, the 4 octets corresponds to the values 1, 0, 0, 0 respectively.
If the reduced ILET values are used, only 1 octet is required to
reflect the encoding scheme being used.
4. Implementation & Deployment Strategies
The first step in any multilingual domain name implementation should
be to encourage an 8-bit clean approach to DNS. However, even when
the system is 8-bit clean the problem with conflicting characters
still exists. This is where the DNSII protocol becomes most
valuable.
Although the DNSII protocol could be implemented at any level of the
DNS, the following phased rollout is contemplated.
Chung & Leung [Page 11]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
(1) Registry Level - The most meaningful starting point for
deployment would be at the registry level since this creates the
demand from the end users to use multilingual and extended character
domain names for Second Level Domains.
(2) Host Level - At the same time, registrants of the new extended
domain names could start to implement DNSII to host these special
kinds of domain names. All other hosts that do not wish to use
extended characters do not have to migrate to the DNSII.
(3) Client Level - Once the multilingual aspect and the DNSII
specifications become mainstream, the user level resolvers will begin
to migrate. This will include both the client resolver as well as
the ISP's DNS.
(4) Root Level - Eventually, as the DNSII is proven to be stable and
beneficial for the Internet at large, it could be used in the Root
Level so that new multilingual TLDs could be created.
5. IDN Requirements Considerations
The DNSII protocol specification is in line with most if not all of
the requirements identified by the IDN work group.
6. DNSSEC, EDNS and IPv6 Considerations
The use of DNSII should not require any adjustments with the
implementation of DNSSEC, EDNS or IPv6. EDNS as well as compression
in fact will be done exactly the same as the existing system.
For example, the domain host.dns.<2E><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>.tld running with EDNS as
well as compression after host will look as follows:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------------------------------------------------------+
20|0 1| ELT |0 0| 3 | d | n |
+---------------------------------------------------------------+
| s |1 0|0 0| UCS-2=1000 | 4 |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+57DF) | <20><><EFBFBD> (U+540D) |
+---------------------------------------------------------------+
| <20><><EFBFBD> (U+7CFB) | <20><><EFBFBD> (U+7D71) |
+---------------------------------------------------------------+
|0 0| 3 | t | l | d |
+---------------------------------------------------------------+
| 0 |
+---------------+
Chung & Leung [Page 12]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
: :
/ /
+---------------------------------------------------------------+
|0 0| 4 | h | o | s |
+---------------------------------------------------------------+
| t |1 1| 21 |
+-----------------------------------------------+
7. Intellectual Property Considerations
It is the intention of Neteka to submit the DNSII protocol and other
elements of the multilingual domain name server software to IETF for
review, comment or standardization.
Neteka Inc. has applied for one or more patents on the technology
related to multilingual domain name server software and multilingual
email server software suite. If a standard is adopted by IETF and
any patents are issued to Neteka with claims that are necessary for
practicing the standard, any party will be able to obtain the right
to implement, use and distribute the technology or works when
implementing, using or distributing technology based upon the
specific specifications under fair, reasonable and non-discriminatory
terms.
Other DNSII related documents and discussions could be found at
http://www.dnsii.org.
8. References
[DNSII-MDNR] E. Chung, D. Leung, _DNSII Multilingual Domain Name
Resolution_, August 2000
[RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700,
October 1994.
[ISO10646] ISO/IEC 10646-1:2000. International Standard -
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS)
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities," STD 13, RFC 1034, USC/ISI, November 1987
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification," STD 13, RFC 1035, USC/ISI, November 1987
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997
[RFC2130] C. Weider, et al. _The Report of the IAB Character Set
Workshop held 29 February - 1 March, 1996_ RFC 2130,
April 1997
Chung & Leung [Page 13]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
[RFC2277] H. Alvestrand, _IETF Policy on Character Sets and
Languages_ RFC 2277, January 1998
[RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)",
August 1999, RFC 2671.
Authors:
Edmon Chung
Neteka Inc.
2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5
edmon@neteka.com
David Leung
Neteka Inc.
2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5
david@neteka.com
Chung & Leung [Page 14]

20
doc/draft/draft-ietf-idn-dnsii-mdnp-03.txt Normal file
View File

@@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
E. Chung: edmon@neteka.com
D. Leung: david@neteka,com

841
doc/draft/draft-ietf-idn-dnsii-mdnr-01.txt
View File

@@ -1,841 +0,0 @@
IDN Working Group Edmon Chung & David Leung
Internet Draft Neteka Inc.
<draft-ietf-idn-dnsii-mdnr-01.txt> February 2001
DNSII Multilingual Domain Name Resolution
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The reader is cautioned not to depend on the values that appear in
examples to be current or complete, since their purpose is primarily
educational. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A copy of this particular draft is also archived at
http://www.dnsii.org.
Abstract
This document outlines a resolution process that forms a framework
for the resolution of multilingual domain names. Additionally, a
tunneling mechanism utilizing additional RRs is introduced for the
transition to a fully multilingual capable name space.
The Internet-Draft for DNSII-MDNP was focused purely on discussing
the ultimate packet protocol that is being sent around the Internet
for multilingual domain names. This paper complements the previous
paper by outlining the contemplated resolution process with the DNSII
protocol throughout the DNS name resolution process.
Whether the DNSII protocol is implemented exactly as specified in
DNSII-MDNP is less relevant, rather it is the idea of having a
multilingual packet identifier and the fall back process that
matters. The DNSII-MDNR successfully addresses the transitional
issues at each node of the DNS resolution process providing a clear
migration path and strategy for the deployment of a multilingual
DNSII-MDNR Multilingual Domain Name Resolution August 2000
enabled DNS system. It also outlines the conformance levels required
for basic or complete implementations for applications, resolvers and
name servers.
Table of Contents
1. Introduction....................................................2
1.1 Terminology....................................................2
1.2 Multilingual Domain Name Resolution............................3
1.2 DNSII-MDNR.....................................................3
2. DNSII Proposal with respect to the DNS Layers...................3
3. The Resolution Process..........................................5
3.1 Steady State Resolution........................................5
3.2 Client-End or Inquirer Transitional Fall-Back Strategy.........6
3.2.1 Tunneling MDNP through DNSII RR..............................6
3.2.2 Tunneling ILET RRs...........................................8
3.3 Resolvers & Server-End Transitional Fallback Strategy..........9
3.3.1 Tunneling MDNP Responses through DNSII ANS RR................9
3.3.2 Reinsertion of ILET and DNSII Identifier....................10
4. DNSII Conformance Levels.......................................10
4.1 Application Conformance Levels................................11
4.2 Resolver Conformance Levels...................................11
4.3 Authoritative Server Conformance Levels.......................11
5. Transition Schedule & Strategy.................................12
6. Summary of Discussion..........................................12
6.1 Client/Application Resolution Strategy........................13
6.2 Resolver Resolution Strategy..................................13
6.3 Authoritative Name Server Resolution Strategy.................13
7. Security Considerations........................................14
8. Intellectual Property Considerations...........................14
9. References.....................................................14
1. Introduction
This Internet-Draft describes details of the contemplated resolution
process after the deployment of DNSII-MDNP, or other multilingual
domain name efforts containing a bit flag multilingual packet
identifier or otherwise InPacket identifications for that matter.
The reader is assumed to be familiar with the concepts discussed in
the DNSII-MDNP Internet-Draft <draft-ietf-idn-dnsii-mdnp.txt>.
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in RFC
2119 [RFC2119].
DNSII-MDNR Multilingual Domain Name Resolution August 2000
A number of multilingual characters are used in this document for
examples. Please select your view encoding type to Big-5
(Traditional Chinese) for them to be displayed properly.
1.2 Multilingual Domain Name Resolution
The original specifications for the DNS were designed to be open
enough for simple implementation of a multilingual naming system with
slight adjustments as laid out in DNSII-MDNP. The transition and
especially its resolution process during migration is however a
tricky problem. Several things that MUST be kept in mind is that
there is a initial phase, an intermediate phase and an ultimate
steady state phase. DNSII-MDNP only described the ideal protocol at
steady state, with incorporated flexibility for transition from the
present to multilingual as well as again towards future unknown
grounds.
It is important to remember that the ultimate form SHOULD be
determined and then the transition scheme laid out. While an ASCII
translation system might seem favorable in the short-run, it
effectively creates an alternative universe which is counter to the
spirit of the DNS. However an ASCII translation is implemented, it
immediately creates a "human-multilingual" universe and a "machine-
ASCII" universe. This document introduces a tunneling mechanism to
transition the DNS from today's monolingual system, through an 8-bit
or 7-bit migration scheme towards a truly sustainable multilingual
name space, arriving at a DNSII type system.
1.2 DNSII-MDNR
While DNSII-MDNP describes the framework for the ultimate protocol
format of a multilingual DNS, DNSII-MDNR will discuss how the packet
SHOULD be transported and interpreted throughout the DNS. The
document will describe both the intended resolution process as well
as part of the transition strategy from the existing DNS to a DNSII
enabled system.
2. DNSII Proposal with respect to the DNS Layers
The following diagram illustrates the use of DNSII-MDNP at a steady
state. Section 3 will discuss the fallback strategies while Section
4 will talk about issues on conformance levels.
DNSII-MDNR Multilingual Domain Name Resolution August 2000
+---------------+
| | NamePrep:
| Application | Canonicalize in Form C/KC
| | Insert DNSII Identifier +---------------------+
| | Insert appropriate ILET | (Base data) |
+---------------+ +---------------------+
| |
| DNS Packet with DNSII | (no standard)
| Identifier & ILET | RECOMMENDS
| | UCS-2/4
+---------------+ |
| Resolver | Canonicalize, Case Fold +---------------------+
| | (for cache lookup) or | Auth DNS server |
+---------------+ leave as is & Resolve | (Canonicalize, |
| | Case Fold & Lookup) |
| Pass Along without +---------------------+
| Altering Case or Canonicalization |
| |
| <----- DNS service interface -----> |
+------------------------------------------------------------------+
| DNS service |
| +-----------------------+ +--------------------+ |
| | Forwarding DNS server | | Caching DNS server | |
| +-----------------------+ +--------------------+ |
| |
| +-------------------------+ |
| | Parent-zone DNS servers | |
| +-------------------------+ |
| |
| +-------------------------+ |
| | Root DNS servers | |
| +-------------------------+ |
| |
+------------------------------------------------------------------+
Please note that at each level, the domain name is being
canonicalized. This is to ensure that at the end, characters that
can be represented by a single code point will not be otherwise
compared resulting in inconsistent reply to a humanly identical name.
It is RECOMMENDED that applications SHOULD conduct canonicalization
while servers MUST. Duplicating the process is fine because if a
character is already composed, it will not compose again with another
character.
This arrangement is very similar to the ASCII case folding
experienced in the DNS today. In the original specifications, it was
RECOMMENDED that query sent be left as they are and case folding done
only at the server end. Some application implementations however do
perform the case folding at the user end. As the query arrives at
the server, it is still case folded.
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Case folding for multilingual domain names should follow the existing
implementations for ASCII names, where the application SHOULD and the
server MUST.
3. The Resolution Process
It is inevitable that at the end of the day, the entire DNS chain
SHOULD be updated in order for multilingual domain names to be as
efficiently resolved as names under the current DNS. DNSII strives
to provide a schema that ultimately brings the system to a desirable
steady state while carefully giving considerations to all the
transition issues. These include the considerations that at the
application end, there is already a preference and an installed base
of character encoding that may or may not conform to the desires of
the server end operations. The use of ILET is therefore highly
desirable and essential.
3.1 Steady State Resolution
At steady state, the resolution process of multilingual domain names
SHOULD be identical to the existing system. Additional steps of
going through alphanumeric translation are unnecessary and
undesirable.
With DNSII, the contemplated steady state process resembles the well-
known DNS model laid out in RFC1035.
Local Host | Foreign
|
+---------+ +----------+ | +---------+
| | user queries | |queries | | |
| |(DNSII identifier | | | | |
| | ILET=UCS without | | | | |
| User | Transformation) | | | | Foreign |
| Program |------------------>| Resolver |---------|->| Name |
| | | | | | Server |
| |<------------------| |<--------|--| |
| | user responses | |responses| | |
| | | | | | |
+---------+ +----------+ | +---------+
| ^ |
cache additions | | references |
v | |
+----------+ |
| cache | |
+----------+ |
Eventually, an ISO 10646 UCS without transformation is desired as the
common format. The benefits of having a uniform byte length encoding
DNSII-MDNR Multilingual Domain Name Resolution August 2000
far exceeds the seemingly easier transformation solution. Especially
considering that the DNS requires a label count that should reflect
the number of characters in a label. Of course there exists
combination characters in the ISO 10646 specifications as well, but
after canonicalization, only the ones that must use combinations
remain and they are usually meaningful depictions.
The importance of this count value is further demonstrated by
scrambling efforts to extend the size of this field or to compress
character encoding to accommodate multilingual characters. With
DNSII, this no longer constitutes an issue because any language will
be able to share the same number of characters thanks to the use of
ISO 10646. As a matter of fact, the desire to use uniform byte
length characters formed part of the original intent of the ISO 10646
initiative anyway.
3.2 Client-End or Inquirer Transitional Fall-Back Strategy
For a DNSII aware Client, it will be able to create DNSII packets
which provides precise character data of the domain name in question.
However, if it encounters a non-compliant resolver, it MUST be able
to fallback to a format acceptable by current resolvers.
+---------+ +----------+
| | (1) user queries | | (2) if Resolver is
| | (DNSII identifier | | DNSII compliant,
| | ILET=UCS without | | Packet is resolved
| User | Transformation) | | accordingly. If
| Program |----------------------->| Resolver | not fallback to (3)
| | | |
| |<-----------------------| |
| | (3) Upon the detection | |
| | of the DNSII Flag | |
| | resolver will reply | |
| | with _Format Error_ | |
| | | |
| |----------------------->| | (5) Current resolu-
| | (4) Send QNAME using | | tion process begins
| | local encoding or | | with the DNSII RR
| | UTF-8 with or without | | passed along as an
| | Additional DNSII RR | | Additional RR
+---------+ +----------+
3.2.1 Tunneling MDNP through DNSII RR
An additional DNSII RR would be tunneled through using the format of
a TXT RR with the RDATA part containing the multilingual labels in a
DNSII compliant format. The TTL of the RR MUST be set to zero to
avoid caching.
DNSII-MDNR Multilingual Domain Name Resolution August 2000
It is not feasible to have a new RR type just for DNSII because the
resolver might reject RRs with unknown types. For the name used in
the QNAME as well as the NAME field of the DNSII RR UTF-8 MAY be used
as the default fallback encoding. However, an arbitrary ASCII name
MAY also be used just for the purpose of tunneling. The TTL for
responses to tunneled requests MUST be set to zero to avoid caching
at any level in the DNS. More detailed description in Section 3.4.
For older DNS servers, requests with a non-empty additional
information section MAY produce error returns, however since the
deployment of DNSSEC, especially for TSIG considerations, this no-
longer constitutes a problem. Basic security prepared servers such
as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR.
It is possible to use ACE/RACE type translations at this level,
however it is more advisable to use a truly arbitrary label such as
_-for-tunneling-only-_. So doing requires only reserving one
arbitrary name while ACE/RACE creates one more arbitrary name for
each new multilingual name registered, which will eventually
contribute to the fracturing of the DNS.
As an example, a tunneling packet for the domain name: host. <20><><EFBFBD>W<EFBFBD>t<EFBFBD><74>
.tld. (4host4<74><34><EFBFBD>W<EFBFBD>t<EFBFBD><74>3 tld0) will be represented as:
(in the QNAME field)
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------------------------------------------------------+
12|0 0| 4 | h | o | s |
+---------------------------------------------------------------+
16| t | 20 | - | f |
+---------------------------------------------------------------+
20| 0 | r | - | t |
+---------------------------------------------------------------+
24| u | n | n | e |
+---------------------------------------------------------------+
28| l | i | n | g |
+---------------------------------------------------------------+
32| - | o | n | l |
+---------------------------------------------------------------+
36| y | - | 3 | t |
+---------------------------------------------------------------+
40| l | d | 0 |...
+-----------------------------------------------+
DNSII-MDNR Multilingual Domain Name Resolution August 2000
(The Additional DNSII RR Tunneled in TXT RR form)
: :
/ /
+---------------------------------------------------------------+
80|1 1| 12 | TYPE = TXT = 16 |
+---------------------------------------------------------------+
84| CLASS = IN = 1 | TTL |
+---------------------------------------------------------------+
88| = 0 | RDLENGTH = 22 |
+---------------------------------------------------------------+
92|0 0| 4 | h | o | s |
+---------------------------------------------------------------+
96| t |1 0|0 0| UCS-2=1000 | 4 |
+---------------------------------------------------------------+
100|1 1| 13 |1 0|z| ILET=2 | 4 |
+---------------------------------------------------------------+
104| <20><> (U+57DF) | <20>W (U+540D) |
+---------------------------------------------------------------+
108| <20>t (U+7CFB) | <20><> (U+7D71) |
+---------------------------------------------------------------+
112|1 1| 38 |
+-------------------------------+
The reason a DNSII RR is attached is to alert the authoritative DNS
server that the query is DNSII compliant while being able to tunnel
the request through non-compliant resolvers without any loss of
information.
3.2.2 Tunneling ILET RRs
Another fallback strategy is to tunnel just the ILET instead of the
entire DNSII label. If UTF-8 or a local encoding is used as the
QNAME, then the arbitrary ASCII label is no longer necessary. The
tunneled RR therefore need only consist of an ILET indicating the
encoding format used.
Within the RDATA of an ILET RR masked as a TXT RR the first 4 bytes
will be used to indicate that it is an ILET and the following 4 bytes
to reflect the MIBenum of the encoding used.
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Following the example given in 3.2.1, the QNAME would be in UTF-8
(MIBenum = 106), while the additional ILET RR would be in the form:
: :
/ /
+---------------------------------------------------------------+
80|1 1| 12 | TYPE = TXT = 16 |
+---------------------------------------------------------------+
84| CLASS = IN = 1 | TTL |
+---------------------------------------------------------------+
88| = 0 | RDLENGTH = 22 |
+---------------------------------------------------------------+
92| I | L | E | T |
+---------------------------------------------------------------+
96| 0 | 1 | 0 | 6 |
+---------------------------------------------------------------+
3.3 Resolvers & Server-End Transitional Fallback Strategy
The tunneling scheme described in Section 3.2 assumes that the
authoritative server is fully DNSII compliant. This assertion is
laid out in Section 4.3 where it is discussed that only fully
compliant servers SHOULD serve multilingual names directly under
their authoritative zone. In any other case, the arbitrary domain
"-for-tunneling-only-" should result in an NXDomain response.
For security aware servers, an NXT RR of the last name wrapped by its
first name in the zone records will be returned because of the
leading "-" for the tunneling label.
If the application end is not DNSII compliant, the fallback
resolution strategy for resolvers would simply be to pass along the
labels in their 8-bit format and determine the existence of the
requested name as usual. If a tunneled DNSII RR is detected, by way
of a label constituting entirely of _-for-tunneling-only-_ and the
existence of a valid DNSII RR, the resolver should attempt to resolve
the name according to the DNSII specification and tunnel the answer
back to the inquirer.
3.3.1 Tunneling MDNP Responses through DNSII ANS RR
To tunnel a DNSII compliant answer through a non-compliant resolver,
another DNSII ANS RR is tunneled. Also using the TXT RR format as a
mask. TXT RRs are best used because it is a valid RR and its RDATA
is an unrestricted byte stream determined only by the RDLENGTH. The
RDATA for a DNSII ANS RR would be the entire content of a regular
response RR attached to a DNSII format name.
Continuing on the example given in Section 3.2, suppose an A record
is requested and the IP address returned for the domain host.<2E><><EFBFBD>W<EFBFBD>t<EFBFBD><74>
DNSII-MDNR Multilingual Domain Name Resolution August 2000
.tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the
following form will be included:
: :
/ /
+---------------------------------------------------------------+
114|1 1| 12 | TYPE = TXT = 16 |
+---------------------------------------------------------------+
118| CLASS = IN = 1 | TTL |
+---------------------------------------------------------------+
122| = 0 | RDLENGTH = 16 |
+---------------------------------------------------------------+
126|1 1| 92 | TYPE = A = 1 |
+---------------------------------------------------------------+
130| CLASS = IN = 1 | TTL |
+---------------------------------------------------------------+
134| = 3600 | RDLENGTH = 4 |
+---------------------------------------------------------------+
138| 123 | 4 | 5 | 6 |
+---------------------------------------------------------------+
Note that compression is available in the DNSII RRs. While the
tunneling TXT mask uses the ASCII tunneling name and therefore points
back to the QNAME at offset 12, the tunneled A Record response uses
the offset corresponding to the DNSII compliant labels at 92. While
the TTL of the TXT mask MUST be zero, the tunneled A Record RR
contains a regular TTL, in this case 3600.
3.3.2 Reinsertion of ILET and DNSII Identifier
When a resolver receives an incoming query with a tunneled DNSII/ILET
RR, it SHOULD reconfigure the query into a fully compliant format
before engaging in further resolution. If a "00" query is received,
the resolver should convert the label into UTF-8, set the DNSII
identifier "10" on and set the ILET to UTF-8.
In the scenario where the client end is not DNSII compliant, either a
local encoding 8-bit stream or a UTF-8 encoded stream without the
DNSII flag nor ILET will be transported. During the transition
period, should this occur, the above forced UTF-8 conversion and ILET
insertion would take place and it would be up to the authoritative
server to determine the existence of the requested domain. InZone
DNSII handling mechanism will serve to take care of these
transitional exceptions.
4. DNSII Conformance Levels
DNSII is designed for a smooth transition from the existing ASCII
based DNS to a multilingual capable DNS. Therefore, it is not
necessary for all servers and applications to be switched to
multilingual capable before starting the deployment.
DNSII-MDNR Multilingual Domain Name Resolution August 2000
4.1 Application Conformance Levels
The BASIC compliancy for applications would be to remove validity
checks for domain names. The resolution process will determine a
non-existing domain name, so there really is no need to prevent a DNS
packet with multilingual labels to be sent through the wires.
The INTERMEDIATE compliancy for applications involves the insertion
of the DNSII identifier as well as the ILET according to the local
inputting and screen scheme. If a user is using a JIS format scheme,
it should set the ILET to reflect it being used. At the same time,
the tunneling mechanism discussed in Section 3.2 MUST also be in
place.
FULLY compliant applications will send all DNS packets with the DNSII
identifier and the ILET set to UCS-2/4. The fallback scheme discussed
in Section 3.2 MUST also be in place. InZone DNSII mechanisms SHOULD
also be available to deal with local encoding exceptions.
4.2 Resolver Conformance Levels
The BASIC compliancy for resolvers would be to allow an 8-bit clean
approach to name resolution. Also, it should be made sure that the
additional DNSII RR (TXT) will not be truncated during resolution.
The INTERMEDIATE compliant resolvers MUST understand how to process
the DNSII identifier as well as not reject the ILET. Interpretation
of the name is not required so it is NOT necessary for the resolvers
to be able to map all or any of the ILET values (with the alternative
approach in DNSII-MDNP, the ILET value corresponds to the byte length
of the characters contained in the label, which makes the count
workable even if the ILET value is not known by the resolver). In
this scenario caching will be for exact comparison only (label to
label with ILET intact). The important criteria is for the resolver
to be able to pass along the DNS query to the corresponding
authoritative server and obtain a correct response.
FULLY compliant resolvers will be able to process the DNSII identifer
and know all the ILET values for full function name mapping. Cache
name lookup will be fully enabled and inquiry fallback mechanism
discussed in Section 3.2.2 SHOULD be performed in the event of
encountering a non-compliant server.
4.3 Authoritative Server Conformance Levels
Authoritative servers MUST be fully compliant before attempting to
serve multilingual sub-domains under its authoritative zone. They
should however prepare for the transition towards a multilingual name
space even if they do not intend to deploy it right away.
DNSII-MDNR Multilingual Domain Name Resolution August 2000
The BASIC compliancy for authoritative name servers is to allow an 8-
bit clean approach towards sub-domains that are not directly under
its authority (i.e. sub-sub-domains).
The INTERMEDIATE compliant name server will be able to process the
DNSII identifier and ILET without rejecting the query. The
authoritative zone as well as its direct sub-domains however SHOULD
not include the use of the DNSII flags because ILET values are not
understood at this compliancy level.
FULLY compliant name servers will be able to handle DNSII compliant
label formats at its sub-domain levels. That is, fully compliant
root servers will be able to serve multilingual TLDs, fully compliant
TLD servers will be able to serve multilingual SLDs, etc.
5. Transition Schedule & Strategy
DNSII is designed to allow a gradual adoption of multilingual domain
names on the Internet. The transition strategy is therefore geared
to be demand-pull instead of a technology-push incentive. However,
to provide a platform for a demand-pull approach, it is required for
operators to first safeguard their system. The simple approach as
laid out in Section 4 is to propose that servers take a 8-bit clean
approach on name resolution.
As discussed in DNSII-MDNP, it is reasonable for the deployment of
DNSII-MDNP at the registry level first to draw demand for the service
and let the host level DNSs with multilingual names to begin
migration first. DNS operators around the world should however
prepare for the transition and begin the deployment of DNSII
depending on their interest in serving multilingual domain names,
according to the conformance levels laid out in Section 4, beginning
from BASIC compliancy for operators that are least interested to a
FULLY compliant server for operators who wishes to provide
multilingual capabilities for their users.
The root servers could easily be adjusted to be a BASIC compliant
authoritative name server. Once the demand is proven and the
stability of the system tested, they too could transition to fully
compliant authoritative servers so that multilingual TLDs could be
rolled out.
6. Summary of Discussion
This document introduces the contemplated transition and steady state
resolution process for multilingual domain names with a DNSII
compliant format. Two tunneling mechanisms using the TXT RR was
introduced for the preservation of information during transitional
resolution.
DNSII-MDNR Multilingual Domain Name Resolution August 2000
6.1 Client/Application Resolution Strategy
Send Query in DNSII format
IF RCODE = Format Error
THEN send query in UTF-8/Local Encoding AND append DNSII RR
IF RCODE = Format Error
THEN send Query in ASCII with _-for-tunneling-only-_ label
AND append DNSII RR
AND check for DNSII ANS RR in response
ELSE proceed and check for DNSII ANS RR in response
ELSE proceed as usual
6.2 Resolver Resolution Strategy
(*)IF incoming request is in pure DNSII format
THEN resolve according to ILET in cache and by recursive lookup
IF encounter RCODE = Format Error
THEN send query in UTF-8 AND append DNSII RR
IF RCODE = Format Error
THEN send query in ASCII with _-for-tunneling-only-_
label
AND append DNSII RR
AND check for DNSII ANS RR in response
ELSE proceed and check for DNSII ANS RR in response
ELSE proceed as usual with pure DNSII Format (*)
AND respond in pure DNSII format
ELSE IF incoming request has tunneled MDNP information
THEN resolve using the information in the appended DNSII RR
Reset Query using DNSII Format and go through (*)
AND convert back to tunneling format before responding to query
With DNSII ANS RR appended to response
AND set TTL for regular RRs in the Answer field to be = 0
ElSE IF incoming request is in the original "00" label format
AND no tunneled information is included
AND the label contains characters beyond A-z, 0-9 or "-"
THEN force convert all labels to UTF-8
AND query using DNSII Format and go through (*)
ELSE proceed as usual (existing ASCII based names)
6.3 Authoritative Name Server Resolution Strategy
IF incoming request is in pure DNSII format
THEN resolve according to ILET
AND respond in pure DNSII format
ELSE IF incoming request has tunneled MDNP information
THEN resolve using the information in the appended DNSII RR
AND convert back to tunneling format before responding to query
With DNSII ANS RR appended to response
AND set TTL for regular RRs in the Answer field to be = 0
ELSE use InZone DNSII mechanisms AND use 8-bit clean approach
DNSII-MDNR Multilingual Domain Name Resolution August 2000
7. Security Considerations
DNSII RRs will be secured through transaction authentication, while
DNSII ANS RRs could have their own SIG RRs. In general, the DNSII-
MDNR should not constitute any extra burden on DNS security.
8. Intellectual Property Considerations
It is the intention of Neteka to submit the DNSII protocol and other
elements of the multilingual domain name server software to IETF for
review, comment or standardization.
Neteka Inc. has applied for one or more patents on the technology
related to multilingual domain name server software and multilingual
email server software suite. If a standard is adopted by IETF and
any patents are issued to Neteka with claims that are necessary for
practicing the standard, any party will be able to obtain the right
to implement, use and distribute the technology or works when
implementing, using or distributing technology based upon the
specific specifications under fair, reasonable and non-discriminatory
terms.
Other DNSII related documents and discussions could be found at
http://www.dnsii.org.
9. References
[DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name
Protocol", August 2000
[RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC
1700, October 1994.
[ISO10646] ISO/IEC 10646-1:2000. International Standard --
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS)
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities," STD 13, RFC 1034, USC/ISI, November 1987
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification," STD 13, RFC 1035, USC/ISI, November
1987
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Authors:
Edmon Chung
Neteka Inc.
2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5
edmon@neteka.com
David Leung
Neteka Inc.
2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5
david@neteka.com

20
doc/draft/draft-ietf-idn-dnsii-mdnr-02.txt Normal file
View File

@@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
E. Chung: edmon@neteka.com
D. Leung: david@neteka,com

636
doc/draft/draft-ietf-idn-dnsii-trace-00.txt
View File

@@ -1,636 +0,0 @@
Working Group Edmon Chung & David Leung
Internet Draft Neteka Inc.
<draft-ietf-idn-dnsii-trace-00.txt> September 2000
DNSII Transitional Reflexive ASCII Compatible Encoding (TRACE)
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The reader is cautioned not to depend on the values that appear in
examples to be current or complete, since their purpose is primarily
educational. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
ASCII Compatible Encoding (ACE) schemes should only be used as a
transitional strategy with a well-defined way forward to the eventual
enabling of a truly multilingual name space for the DNS.
The previous DNSII documents surrounding multilingual domain names
have focused on the ultimate form with the DNSII-MDNR suggesting
possible tunneling techniques where ACE may be used. This document
furthers the discussion on an ACE system, which not only provides a
pathway towards the ultimate DNSII scheme but also an interim
solution taking care of the immediate needs.
A reflexive CNAME process RENAME is introduced where non-ASCII
incoming queries will be automatically CNAMEd to its ASCII
counterpart without requiring an actual lookup. The resolver will
then be responsible for recursively looking up the corresponding
translated alphanumeric name.
This document does not attempt to create another ACE scheme, instead
it discusses the way an ACE scheme could be used as a transition
towards the ultimate goal of a true multilingual name on the wire.
Chung & Leung [Page 1]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
Table of Contents
1. Introduction....................................................2
1.1 Terminology....................................................2
2. TRACE - Introduced with Due Obsolescence........................3
2.1 Problems & Benefits of ACE.....................................3
2.2 TRACE Format...................................................3
2.3 TRACE Identifier...............................................3
2.4 TRACE Zone Handling............................................4
3. REflexive CNAME (RENAME)........................................4
3.1 Non-Recursive Name Servers with RENAME-ON......................5
3.1 Recursive Name Servers (Resolvers) with RENAME-ON..............6
3.2 Benefits of RENAME.............................................6
3.3 Problems with RENAME...........................................7
4. Use of RENAME with Respect to DNS Hierarchy.....................7
4.1 General Rules for using RENAME.................................8
4.2 Transitioning towards Identification Based DNSII...............8
5. Security Considerations.........................................9
6. Conclusion......................................................9
7. Intellectual Property Considerations...........................10
8. References.....................................................10
1. Introduction
ACE usage should be limited to machine read only and steps should be
taken to avoid the user being able to easily input the names through
an application onto the wire. This is a well-understood concept
because without this requirement, the creation of an ACE system
effectively creates an alternate universe model that is counter to
the spirit of the DNS. In essence, if an ACE scheme could easily be
typed in, people who are typing that sequence of characters may be
unexpectedly be brought to another site which happens to have the
same "code".
TRACE outlines a scheme that uses an ACE scheme but is identified in
a 7-bit format that could not easily be typed in by a user. Thereby
preventing an inconsistent expectation of a domain name. Beyond the
specification of an identifier a RENAME function for an ACE
resolution process is also introduced.
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in RFC
2119 [RFC2119].
A number of characters used in this document are in a Big-5 encoding,
you could select your view encoding type to traditional Chinese or
Big-5 for it to be displayed properly.
Chung & Leung [Page 2]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
2. TRACE - Introduced with Due Obsolescence
TRACE is designed to be a transitional scheme with due obsolescence
once a full-fledged DNSII mode is attained.
2.1 Problems & Benefits of ACE
One of the major problems with ACE is the evident result of creating
an extra layer on top of the DNS. DNS was designed to be the human
friendly machine identifier with its names human readable. With ACE,
it is certain that an added layer is required to decode a domain
name. This also effectively results in a quasi-alternate universe
mode whereby the actual characters represent a translation into the
existing domain name space.
However, ACE has its benefits as well and the most prominent one is
that host servers need not migrate to new name servers. Also it will
ensure that there is a lengthy enough migration period for other
applications to start adapting to the new DNS specifications.
2.2 TRACE Format
TRACE does not intend to introduce a new type of encoding. Rather,
it is concerned with using a 7-bit compatible identifier and a
reflexive mechanism for switching from regular DNS packets to TRACE.
2.3 TRACE Identifier
In other ACE proposals, identifiers are often created from
alphanumeric characters, which end users can easily type in. The
problem with this approach is easy to understand, for each
multilingual name, one alphanumeric name must be reserved simply for
the use of the multilingual conversion and will not be available for
normal usage.
For example from Paul Hoffman's draft [RACE-01], the sample
conversion for a value 0x3a27 would result in a string "bq--hitq".
The name "bq--hitq" which is a perfectly usable name on its own must
now be reserved for a multilingual name. Also, 4 character spaces
will be wasted just for the identifier.
Instead of using an alphanumeric identifier, a single 7-bit compliant
control character is used. The proposed character is the control
character with the value 0x7F. With this character, a multilingual
name part could be effectively identified while it would be very
difficult for the average user to enter the character into an
application, thereby avoiding the issue discussed above.
In any case, an ACE form name is not intended for an end user to type
in. The only reason for ACE is that the current name servers could
Chung & Leung [Page 3]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
easily handle them. TRACE provides a simple and effective way which
is 7-bit compliant and a string that is could not be easily imitated.
2.4 TRACE Zone Handling
A zone administrator could also easily enter the TRACE Identifier
into the zone file. To insert the TRACE Identifier in a BIND server,
the administrator could simply append the string "\127" before the
ACE label. Current BIND servers will understand that "\127" calls
for the character with the value 127 and therefore load it into
memory accordingly. The BIND should also be reconfigured to set the
options for "check-names" to "ignore".
In the following examples, the ACE format used is simply the hex
value of the corresponding character encoding. RACE or other ACE
formats or hex of other encoding schemes may be used.
To set up an NS record to ns1.trace.tld and an A record to 123.4.5.6
for the name "<22><><EFBFBD><EFBFBD>" <U+4e2d><U+6587> in a BIND server, using UTF-8
(E4B8AD E69687) the following lines are included into the zone file:
\127e4b8ade69687 IN NS ns1.trace.tld.
\127e4b8ade69687 IN A 123.4.5.6
Section 4.3 will discuss a method to prepare the zone file for the
transition into a fully DNSII compliant mode.
3. REflexive CNAME (RENAME)
To complement an ACE transition, a reflexive mechanism is introduced.
REflexive CNAME (RENAME) successfully creates a scheme whereby child
DNS nodes could keep using their BIND name servers while be capable
of hosting multilingual domain names.
RENAME is simply a mechanism that attaches an incoming multilingual
name to its ACE counterpart as it enters a RENAME-ON name server.
When to use RENAME is discussed in Section 4.
As an example, if an incoming query contains a the domain name "<22><>
<20><>.tld" <U+4e2d><U+6587>.tld in UTF-8 encoding reaches a RENAME-ON
name server, the following automatic response will be created:
<20><><EFBFBD><EFBFBD>.tld IN CNAME \127e4b8ade69687.tld
If the server is in non-recursive mode, the RENAMEd name will now be
used for a lookup within the zone and the corresponding response
returned to the inquirer, including the CNAME process. If the server
is in recursive mode, the RENAMEd name will be used for lookup within
cache and passed on through the DNS hierarchy when not found.
Chung & Leung [Page 4]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
3.1 Non-Recursive Name Servers with RENAME-ON
The two basic modes for a name server includes a non-recursive mode,
which are usually used by registries, root or authoritative host
servers; and a recursive mode, which are usually resolvers installed
in ISPs.
A non-recursive mode server with RENAME-ON would upon receiving a
multilingual name label, automatically CNAME the name to an ACE
format. If a complete match is found, the response will be passed
back to the inquirer including the CNAME record. If no direct match
is found, it will pass along either an authoritative NXDomain or the
nearest NS Record in ACE format so that the inquirer may continue its
recursive request.
The following diagram and descriptions details the resolution process
for the domain "www.<2E><><EFBFBD><EFBFBD>.<2E><><EFBFBD><EFBFBD>.tld" or <U+4e2d><U+6587>.<U+4e2d>
<U+6587>.tld, with a DNSII TRACE RENAME-ON server installed at the
Parent domain "<22><><EFBFBD><EFBFBD>.tld" and a BIND server installed at the Child DNS
domain "<22><><EFBFBD><EFBFBD>.<2E><><EFBFBD><EFBFBD>.tld":
(3)
+--------+ +------------+ +---------------+
| | (1) | | (2) | |
| Client |-------->| Resolver |-------->| Parent Domain | <20><><EFBFBD><EFBFBD>.tld
| |<--------| |<--------| (RENAME-ON) |
| | (8) | | (4) | |
+--------+ +------------+ +---------------+
^ |
| | (6)
| | (5) +--------------+
| +-------->| |
+-----------| Child Domain | <20><><EFBFBD><EFBFBD>.<2E><><EFBFBD><EFBFBD>.tld
(7) | (using BIND) |
| |
+--------------+
(1) A user enters a query for the A record of "www.<2E><><EFBFBD><EFBFBD>.<2E><><EFBFBD><EFBFBD>.tld" or
<U+4e2d><U+6587>.<U+4e2d><U+6587>.tld using an ISO10646 encoding
input.
(2) The DNS recursive resolver arrives at the parent domain "<22><>
<20><>.tld" <U+4e2d><U+6587>.tld
(3) With RENAME-ON and detection that the incoming query is non-ASCII,
the server reflexively assigns the CNAME to the domain:
www.<2E><><EFBFBD><EFBFBD>.<2E><><EFBFBD><EFBFBD>.tld. IN CNAME www.\127e4b8ade69687.
\127e4b8ade69687.tld.
Chung & Leung [Page 5]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
(4) Since a direct match is not found in the Parent DNS, the closest
NS record is returned to the Resolver, with the CNAME part
included:
www.<2E><><EFBFBD><EFBFBD>.<2E><><EFBFBD><EFBFBD>.tld. IN CNAME www.\127e4b8ade69687.
\127e4b8ade69687.tld.
\127e4b8ade69687.\127e4b8ade69687.tld. IN NS
ns1.\127e4b8ade69687.\127e4b8ade69687.tld.
ns1.\127e4b8ade69687.\127e4b8ade69687.tld. IN A 123.5.6.7
(5) The recursive resolver passes on the request using the CNAME
record to the Child DNS as:
www.\127e4b8ade69687.\127e4b8ade69687.tld.
Asking for an A record for the corresponding domain.
(6) The Child DNS simply does a regular look up for the domain with
the corresponding response.
(7) Assuming that the correct IP address for www.<2E><><EFBFBD><EFBFBD>.<2E><><EFBFBD><EFBFBD>.tld is
123.6.7.8, the response would be:
www.\127e4b8ade69687.\127e4b8ade69687.tld. IN A 123.6.7.8
(8) The resolver will then respond to the client request accordingly,
including the CNAME record.
3.1 Recursive Name Servers (Resolvers) with RENAME-ON
If the recursive resolver is DNSII compatible and have switched the
RENAME-ON, then both the parent and child DNSs could still run BIND
and be able to serve multilingual names. As the request goes through
the resolver, it is automatically CNAMEd to the corresponding ACE
format name and passed along for further resolution.
When the corresponding response is obtained, the definite answer
including the CNAME record will both be passed to the client.
3.2 Benefits of RENAME
The immediate benefit for using RENAME is that once it is deployed at
a particular DNS level, all its child, or sub-level DNSs could
continue to run a BIND-based or current name server while still be
capable of serving multilingual domain names.
Most ACE implementations expect the client application to begin
migration first. This is unfortunately would take a long time
because we understand that client end migration may take years to
Chung & Leung [Page 6]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
complete. With RENAME however, the migration could be dynamic.
Section 4 explains further how and when RENAME should be used to
complement and facilitate the resolution of multilingual names even
when some of the components are not fully multilingual aware.
3.3 Problems with RENAME
RENAME effectively creates an ACE based name space which is
ultimately undesired. Also, wherever the RENAME function is located,
it will intensify the processing requirements for the machine to
handle the conversion of the incoming multilingual label into an ACE
format and package the CNAME record accordingly.
4. Use of RENAME with Respect to DNS Hierarchy
For the discussion within this document, the DNS hierarchy is
summarized into four nodes, beginning with the client end
application, through the resolver, to the root or NIC servers then
finally at the authoritative host for a second-level domain. This
more or less summarizes the DNS process from the initiation of a
request to the authoritative host.
All together, there are 16 combinations with the basic DNS
environments. The following chart outlines the different
combinations with the denotations as:
B = B-DNS = Current Bind-based DNS
D = DNSII = DNSII Compliant Name Servers
RENAME(X-X-X-X) = RENAME(Client/application-Resolver-Root/NIC-Host)
with X = ON = RENAME-ON
FF = RENAME-OFF
OP = Optional ON/OFF
NA = Not Applicable
Scenario | Client |Resolver|Root/NIC| Host | RENAME(ON/OFF)
---------+--------+--------+--------+--------+---------------------
1) BBBB | B-DNS | B-DNS | B-DNS | B-DNS | existing system
+--------+--------+--------+--------+
2) BBBD | B-DNS | B DNS | B-DNS | DNSII | RENAME(NA-NA-NA-FF)
+--------+--------+--------+--------+
3) BBDB | B-DNS | B DNS | DNSII | B-DNS | RENAME(NA-NA-ON-NA)
+--------+--------+--------+--------+
4) BDBB | B-DNS | DNSII | B DNS | B-DNS | RENAME(NA-ON-NA-NA)
+--------+--------+--------+--------+
5) DBBB | DNSII | B-DNS | B-DNS | B-DNS | RENAME(ON-NA-NA-NA)
+--------+--------+--------+--------+
6) BBDD | B-DNS | B-DNS | DNSII | DNSII | RENAME(NA-NA-FF-FF)
+--------+--------+--------+--------+
7) DNND | B-DNS | DNSII | DNSII | B-DNS | RENAME(NA-OP-ON-NA)
+--------+--------+--------+--------+
Chung & Leung [Page 7]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
Scenario | Client |Resolver|Root/NIC| Host | RENAME(ON/OFF)
---------+--------+--------+--------+--------+---------------------
8) DDBB | DNSII | DNSII | B-DNS | B-DNS | RENAME(OP-ON-NA-NA)
+--------+--------+--------+--------+
9) DBBD | DNSII | B-DNS | B-DNS | DNSII | RENAME(ON-NA-NA-FF)
+--------+--------+--------+--------+
10) BDBD | B-DNS | DNSII | B-DNS | DNSII | RENAME(NA-ON-NA-FF)
+--------+--------+--------+--------+
11) DBDB | DNSII | B-DNS | DNSII | B-DNS | RENAME(ON-NA-OP-NA)
+--------+--------+--------+--------+
12) BDDD | B-DNS | DNSII | DNSII | DNSII | RENAME(NA-FF-FF-FF)
+--------+--------+--------+--------+
13) DDDB | DNSII | DNSII | DNSII | B-DNS | RENAME(OP-OP-ON-NA)
+--------+--------+--------+--------+
14) DDBD | DNSII | DNSII | B-DNS | DNSII | RENAME(OP-ON-NA-FF)
+--------+--------+--------+--------+
15) DBDD | DNSII | B-DNS | DNSII | DNSII | RENAME(ON-NA-FF-FF)
+--------+--------+--------+--------+
16) DDDD | DNSII | DNSII | DNSII | DNSII | Full DNSII mode
+--------+--------+--------+--------+
4.1 General Rules for using RENAME
As a general rule, RENAME should be turned on whenever there is an
anticipation that further down the DNS hierarchy or resolution
process, a host has not been migrated and is still using existing
name server software. For example, Scenario(3),(4) or (5) and their
equivalents.
If it is known that the entire set of child hosts is DNSII compliant,
then RENAME is optional even if there exists child sub-sub-domain
host beneath the sub-domain level that uses existing name servers.
For example, Scenario(7) and the sample given in Section 3.
The end host without any more child sub-domains SHOULD never turn on
RENAME. This consideration is given to reduce the amount of
transition traffic created due to the reflexive answer where no
further resolution is required.
4.2 Transitioning towards Identification Based DNSII
Following the DNSII-MDNP recommendations, TRACE could smooth the
transition into a multilingual name space by starting at the registry
level and without requiring the host DNSs to migrate.
As the user-end applications or recursive ISP resolvers began the
migration, new multilingual TLDs could also be introduced even before
the root servers begin any migration.
Eventually, when the root servers migrate, they should be enabled
with both the full DNSII capability with the InPacket Identifier,
Chung & Leung [Page 8]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
ILET as well as TRACE as a fallback should there be any host DNS
still using existing servers.
From the general rules, we understand that if the entire child DNSs
are DNSII enabled, then the RENAME function of the parent DNS could
be turned off. This therefore makes way for a very sensible
migration strategy owing to the hierarchical structure of the DNS.
Since a parent DNS must know a glue record for its immediate
children, it is easy for the zone administrator to determine whether
it could turn off the RENAME function for its zone.
While it is understood that gradually, all name servers should
migrate to be DNSII capable and that multilingual names, TRACE
creates a very effective way of monitoring the migration by
encouraging child DNSs to begin transition first followed by upper
and more important levels, up to the root.
A fully DNSII aware server should also be prepared for DNSII queries.
That is, it should be able to process requests containing the DNSII
Identifier and ILET. As a working example, a Neteka Enhanced BIND
(for a demo copy please mailto:netekare@neteka.com) has been
developed as a demonstration. To enter a full DNSII label, in the
product, simply duplicate the TRACE identifier and insert a
corresponding ILET. As an example, for "<22><><EFBFBD><EFBFBD>.tld" <U+4e2d>
<U+6587>.tld with ILET = 1000 = Unicode, an A record for the IP
address 123.4.5.6 could be added to the zone file as:
\127\12710004e2d6587.tld. IN A 123.4.5.6
In such an environment, DNSII aware queries will be answered
accordingly utilizing the "\127\127" record.
5. Security Considerations
The implementation of TRACE constitutes no further security burden on
the DNS. DNSSEC could be used in parallel with TRACE resolution and
records. RENAME records will be secured through transaction
authentication, while authoritative records will have their own SIG
RRs.
Moreover, the TRACE identifier actually increases the security for
multilingual names over other ACE implementations by using the 0x7F
character, which is difficult for an end user to key in, thereby
reducing the possible confusions.
6. Conclusion
With any implementation, the first step towards universal deployment
of a multilingual aware name space should be an 8-bit clean approach.
For current BIND servers it is a simple configuration matter, which
could be set as an option for checknames to be ignored.
Chung & Leung [Page 9]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
With TRACE, the migration from the current system could be dynamic.
While it is encouraged that the registries begin the migration first
because it is most sensible, client end or recursive resolvers could
also begin the migration.
The use of the control character 0x7F also solves two problems at
once: 1) a 7-bit identifier to avoid disruption of other applications
using DNS; and, 2) an identifier that is not easily input by a client
end user to prevent confusion between a multilingual name and an
English alphanumeric only name.
RENAME successfully creates an environment where host level DNSs
could hold on to their existing BIND based name servers while being
able to host multilingual domains, thereby relieving the migration
stress for hosting facilities and ISPs.
7. Intellectual Property Considerations
It is the intention of Neteka to submit the DNSII protocol and other
elements of the multilingual domain name server software to IETF for
review, comment or standardization.
Neteka Inc. has applied for one or more patents on the technology
related to multilingual domain name server software and multilingual
email server software suite. If a standard is adopted by IETF and
any patents are issued to Neteka with claims that are necessary for
practicing the standard, any party will be able to obtain the right
to implement, use and distribute the technology or works when
implementing, using or distributing technology based upon the
specific specifications under fair, reasonable and non-discriminatory
terms.
8. References
[DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name
Protocol", August 2000
[RACE] P. Hoffman "RACE: Row-based ASCII Compatible Encoding for
IDN", August 31, 2000
[RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC
1700, October 1994.
[ISO10646] ISO/IEC 10646-1:2000. International Standard --
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS)
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997
Chung & Leung [Page 10]
DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
Authors:
Edmon Chung
Neteka Inc.
2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5
edmon@neteka.com
David Leung
Neteka Inc.
2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5
david@neteka.com
Chung & Leung [Page 11]

20
doc/draft/draft-ietf-idn-dnsii-trace-01.txt Normal file
View File

@@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
E. Chung: edmon@neteka.com
D. Leung: david@neteka,com

379
doc/draft/draft-ietf-idn-idna-03.txt
View File

@@ -1,379 +0,0 @@
Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-03.txt Cisco
July 20, 2001 Paul Hoffman
Expires in six months IMC & VPNC
Internationalizing Host Names In Applications (IDNA)
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The current DNS infrastructure does not provide a way to use
internationalized host names (IDN). This document describes a mechanism
that requires no changes to any DNS server or resolver that will allow
internationalized host names to be used by end users with changes only
to applications. It allows flexibility for user input and display, and
assures that host names that have non-ASCII characters are not sent to
DNS servers or resolvers.
1. Introduction
In the discussion of IDN solutions, a great deal of discussion has
focused on transition issues and how IDN will work in a world where not
all of the components have been updated. Earlier proposed solutions
require that user applications, resolvers, and DNS servers to be updated
in order for a user to use an internationalized host name. Instead of
this requirement for widespread updating of all components, the current
proposal is that only user applications be updated; no changes are
needed to the DNS protocol or any DNS servers or the resolvers on user's
computers.
This document is being discussed on the ietf-idna@mail.apps.ietf.org
mailing list. To subscribe, send a message to
ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in
the body of the message.
1.1 Design philosophy
Many proposals for IDN protocols have required that DNS servers be
updated to handle internationalized host names. Because of this, the
person who wanted to use an internationalized host name had to be sure
that their request went to a DNS server that was updated for IDN.
Further, that server could only send queries to other servers that had
been updated for IDN because the queries contain new protocol elements
to differentiate IDN name parts from current host parts. In addition,
these proposals require that resolvers must be updated to use the new
protocols, and in most cases the applications would need to be updated
as well.
These proposals would require that the application protocols that use
host names as protocol elements to change. This is due to the
assumptions and requirements made in those protocols about the
characters that have always been used for host names, and the encoding
of those characters. Other proposals for IDN protocols do not require
changes to DNS servers but still require changes to most application
protocols to handle the new names.
Updating all (or even a significant percentage) of the existing servers
in the world will be difficult, to say the least. Updating applications,
application gateways, and clients to handle changes to the application
protocols is also daunting. Because of this, we have designed a protocol
that requires no updating of any name servers. IDNA still requires the
updating of applications, but only for input and display of names, not
for changes to the protocols. Once a user has updated these, she or he
could immediately start using internationalized host names. The cost of
implementing IDN may thus be much lower, and the speed of implementation
could be much higher.
1.2 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
2. Structural Overview
In IDNA, users' applications are updated to perform the processing
needed to input internationalized host names from users, display
internationalized host names that are returned from the DNS to users,
and process the inputs and outputs from the DNS.
2.1 Interfaces between DNS components in IDNA
The interfaces in IDNA can be represented pictorially as:
+------+
| User |
+------+
^
|Input and display: local interface methods
|(pen, keyboard, glowing phosphorus, ...)
+-----------------|------------------------------+
| v |
| +--------------------------+ |
| | Application | |
| +--------------------------+ |
| ^ ^ |
| Call to resolver:| |Application-specific |
| nameprepped ACE| |protocol: |
| v |predefined by the | End system
| +----------+ |protocol or defaults |
| | Resolver | |to nameprepped ACE |
| +----------+ | |
| ^ | |
+---------------|----------|---------------------+
DNS protocol:| |
nameprepped ACE| |
v v
+-------------+ +---------------------+
| DNS servers | | Application servers |
+-------------+ +---------------------+
This document uses the generic term "ACE" for an ASCII-compatible
encoding. After the IDN Working Group has chosen a specific ACE, this
document will be updated to refer to just that single ACE. Until that
time, an implementor creating experimental software must choose an ACE
to use, such as RACE or LACE or DUDE.
2.1.1 Entry and display in applications
Applications can accept host names using any character set or sets
desired by the application developer, and can display host names in any
charset. That is, this protocol does not affect the interface between
users and applications.
An IDNA-aware application can accept and display internationalized host
names in two formats: the internationalized character set(s) supported
by the application, and in an ACE. Applications MAY allow ACE input and
output, but are not encouraged to do so except as an interface for
special purposes, possibly for debugging. ACE encoding is opaque and
ugly, and should thus only be exposed to users who absolutely need it.
The optional use, especially during a transition period, of ACE
encodings in the user interface is described in section 3. Because name
parts encoded with ACE can be rendered either as the encoded ASCII
characters or the proper decoded characters, the application MAY have an
option for the user to select the preferred method of display; if it
does, rendering the ACE SHOULD NOT be the default.
Host names are often stored and transported in many places. For example,
they are part of documents such as mail messages and web pages. They are
transported in the many parts of many protocols, such as both the
control commands and the RFC 2822 body parts of SMTP, and the headers
and the body content in HTTP.
In protocols and document formats that define how to handle
specification or negotiation of charsets, IDN host name parts can be
encoded in any charset allowed by the protocol or document format. If a
protocol or document format only allows one charset, IDN host name parts
must be given in that charset. In any place where a protocol or document
format allows transmition of the characters in IDN host name parts, IDN
host name parts SHOULD be transmitted using whatever character encoding
and escape mechanism that the protocol or document format uses at that
place.
All protocols that have host names as protocol elements already have the
capacity for handling host names in the ASCII charset. Thus, IDN host
name parts can be specified in those protocols in the ACE charset, which
is a superset of the ASCII charset that uses the same set of octets.
2.1.2 Applications and resolvers
Applications communicate with resolver libraries through a programming
interface (API). Typically, the IETF does not standardize APIs, although
there are non-standard APIs specified for IPv6. This protocol does not
specify a specific API, but instead specifies only the input and output
formats of the host names to the resolver library.
Before converting the name parts into ACE, the application MUST prepare
each name part as specified in [NAMEPREP]. The application MUST use ACE
for the name parts that are sent to the resolver, and will always get
name parts encoded in ACE from the resolver.
IDNA-aware applications MUST be able to work with both
non-internationalized host name parts (those that conform to [STD13] and
[STD3]) and internationalized host name parts. An IDNA-aware application
that is resolving a non-internationalized host name part MUST NOT do
any preparation or conversion to ACE on any non-internationalized name
part.
2.1.3 Resolvers and DNS servers
An operating system might have a set of libraries for converting host
names to nameprepped ACE. The input to such a library might be in one or
more charsets that are used in applications (UTF-8 and UTF-16 are likely
candidates for almost any operating system, and script-specific charsets
are likely for localized operating systems). The output would be either
the unchanged name part (if the input already conforms to [STD13] and
[STD3]), or the nameprepped, ACE-encoded name part.
DNS servers MUST use the ACE format for internationalized host name
parts.
If a signalling system which makes negotiation possible between old and
new DNS clients and servers is standardized in the future, the encoding
of the query in the DNS protocol itself can be changed from ACE to
something else, such as UTF-8. The question whether or not this should
be used is, however, a separate problem and is not discussed in this
memo.
2.1.4 Avoiding exposing users to the raw ACE encoding
All applications that might show the user a host name that was received
from a gethostbyaddr or other such lookup SHOULD update as soon as
possible in order to prevent users from seeing the ACE. However, this is
not considered a big problem because so few applications show this type
of resolution to users.
If an application decodes an ACE name but cannot show all of the
characters in the decoded name, such as if the name contains characters
that the output system cannot display, the application SHOULD show the
name in ACE format instead of displaying the name with the replacement
character (U+FFFD). This is to make it easier for the user to transfer
the name correctly to other programs. Programs that by default show the
ACE form when they cannot show all the characters in a name part SHOULD
also have a mechanism to show the name with as many characters as
possible and replacement characters in the positions where characters
cannot be displayed. In many cases, the application doesn't know exactly
what the underlying rendering engine can or cannot display.
In addition to the condition above, if an application decodes an ACE
name but finds that the decoded name was not properly prepared according
to [NAMEPREP] (for example, if it has illegal characters in it), the
application SHOULD show the name in ACE format and SHOULD NOT display
the name in its decoded form. This is to avoid security issues described
in [NAMEPREP].
2.1.5 Automatic detection of ACE
An application which receives a host name SHOULD verify whether or not
the host name is in ACE. This is possible by verifying the prefix in
each of the labels, and seeing whether or not the label is in ACE. This
MUST be done regardless of whether or not the communication channel used
(such as keyboard input, cut and paste, application protocol,
application payload, and so on) is encoding with ACE.
The reason for this requirement is that many applications are not
ACE-aware. Applications that are not ACE-aware will send host names in
ACE but mark the charset as being US-ASCII or some other charset which
has the characters that are valid in [STD13] as a subset.
2.1.6 Bidirectional text
In IDNA, text storage and display follows the rules in the Unicode standard
[Unicode3.1]. In particular, all Unicode text is stored in logical order;
the Unicode standard has an extensive discussion of how to deal with reorder
glyphs for display when dealing with bidirectional text such as Arabic or
Hebrew. See [UAX9] for more information.
3. Name Server Considerations
It is imperative that there be only one encoding for a particular host
name. ACE is an encoding for host name parts that use characters outside
those allowed for host names [STD13]. Thus, a primary master name server
MUST NOT contain an ACE-encoded name that decodes to a host name that is
allowed in [STD13] and [STD3].
Name servers MUST NOT have any records with host names that contain
internationalized name parts unless those name parts have be prepared
according to [NAMEPREP]. If names that are not legal in [NAMEPREP] are
passed to an application, it will result in an error being passed to the
application with no error being reported to the name server. Further, no
application will ever ask for a name that is not legal in [NAMEPREP]
because requests always go through [NAMEPREP] before getting to the DNS.
Note that [NAMEPREP] describes how to handle versioning of unallocated
codepoints.
The host name data in zone files (as specified by section 5 of RFC 1035)
MUST be both nameprepped and ACE encoded.
4. Root Server Considerations
Because there are no changes to the DNS protocols, adopting this
protocol has no effect on the DNS root servers.
5. Security Considerations
Much of the security of the Internet relies on the DNS. Thus, any change
to the characteristics of the DNS can change the security of much of the
Internet.
This memo describes an algorithm which encodes characters that are not
valid according to STD3 and STD13 into octet values that are valid. No
security issues such as string length increases or new allowed values
are introduced by the encoding process or the use of these encoded
values, apart from those introduced by the ACE encoding itself.
When detecting an ACE-encoded host name, and decoding the ACE, care must
be taken that the resulting value(s) are valid characters which can be
handled by the application. This is described in more detail in section
2.1.4.
Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers
based on different interpretations of the internationalized host name.
Because this document normatively refers to [NAMEPREP], it includes the
security considerations from that document as well.
6. References
[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
and Support" (RFC 1123), STD 3, October 1989.
[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
1034) and "Domain names - implementation and specification" (RFC 1035,
STD 13, November 1987.
[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm.
http://www.unicode.org/unicode/reports/tr9/
[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode
Consortium. The Unicode Standard, Version 3.0. Reading, MA,
Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended
by: Unicode Standard Annex #27: Unicode 3.1
<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.
B. Changes from the -02 draft
Editorial changes throughout
2.1.1: Major changes to the second paragraph. Added major text to fourth
paragraph.
2.1.4: Added to the end of the second paragraph. Added the third
paragraph.
2.1.6: Complete change.
6: Added [Unicode3.1] and [UAX9].
C. Authors' Addresses
Patrik Faltstrom
Cisco Systems
Arstaangsvagen 31 J
S-117 43 Stockholm Sweden
paf@cisco.com
Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
phoffman@imc.org

550
doc/draft/draft-ietf-idn-idna-04.txt Normal file
View File

@@ -0,0 +1,550 @@
Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-04.txt Cisco
November 8, 2001 Paul Hoffman
Expires in six months IMC & VPNC
Adam M. Costello
UC Berkeley
Internationalizing Host Names in Applications (IDNA)
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Until now, there has been no standard way for host names to use
characters outside the ASCII repertoire. This document describes a
mechanism called IDNA that enables internationalized host names,
that is, host names that use characters drawn from a much larger
repertoire. (The "D" in the name originally stood for "domain",
but the work is actually focused on host names, so the word
"host" is used throughout this document.)
1. Introduction
IDNA works by allowing applications to use certain ASCII name labels
(beginning with a special prefix) to represent non-ASCII name labels.
Lower-layer protocols need not be aware of this; therefore IDNA does not
require changes to any infrastructure. In particular, IDNA does not
require any changes to DNS servers, resolvers, or protocol elements,
because the ASCII name service provided by the existing DNS is entirely
sufficient.
This document does not require any applications to conform to IDNA,
but applications can elect to use IDNA in order to support IDN while
maintaining interoperability with existing infrastructure. Adding IDNA
support to an existing application entails changes to the application
only, and leaves room for flexibility in the user interface.
A great deal of the discussion of IDN solutions has focused on
transition issues and how IDN will work in a world where not all of the
components have been updated. Other proposals would require that user
applications, resolvers, and DNS servers be updated in order for a user
to use an internationalized host name. Rather than require widespread
updating of all components, IDNA requires only user applications to be
updated; no changes are needed to the DNS protocol or any DNS servers or
the resolvers on user's computers.
This document is being discussed on the ietf-idna@mail.apps.ietf.org
mailing list. To subscribe, send a message to
ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in
the body of the message.
2 Terminology
[[ Editor's note: the author's are considering changing "host name" to
"domain name" throughout the document after discussing this further
with the DNS experts. ]]
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
A code point is an integral value associated with a character in a coded
character set.
Unicode [UNICODE] is a coded character set containing tens of thousands
of characters. A single Unicode code point is denoted by "U+" followed
by four to six hexadecimal digits, while a range of Unicode code points
is denoted by two hexadecimal numbers separated by "..", with no
prefixes.
ASCII means US-ASCII, a coded character set containing 128 characters
associated with code points in the range 0..7F. Unicode is an extension
of ASCII: it includes all the ASCII characters and associates them with
the same code points.
The term "LDH code points" is defined in this document to mean the code
points associated with ASCII letters, digits, and the hyphen-minus; that
is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an abbreviation for
"letters, digits, hyphen".
A host label is an individual part of a host name. Host labels are
usually shown separated by dots; for example, the host name
"www.example.com" is composed of three host labels: "www", "example",
and "com". In IDNA, not all text strings can be host labels. A string
can be a host label if and only if the ToASCII operation (see section 4)
does not fail when applied to it. (The zero-length root label that is
implied in host names, as described in [STD13], is not considered a
label in this specification.)
An "ACE label" is defined in this document to be a host label that
contains only ASCII characters but represents a label containing
non-ASCII characters (ACE stands for "ASCII-compatible encoding").
Internationalized host labels generally contain non-ASCII characters,
but for every host label that cannot be directly represented in ASCII
there is an equivalent ACE label. The conversion of host labels to and
from the ACE form is specified in section 4.
The "ACE prefix" is defined in this document to be a string of ASCII
characters that appears at the beginning of every ACE label. It is
specified in section 5.
A "host name slot" is defined in this document to be a protocol element
or a function argument or a return value (and so on) explicitly
designated for carrying a host name. Examples of host name slots
include: the QNAME field of a DNS query; the name argument of the
gethostbyname() library function; the part of an email address following
the at-sign (@) in the From: field of an email message header; and the host
portion of the URI in the src attribute of an HTML <IMG> tag.
General text that just happens to contain a host name is not a host name
slot; for example, a host name appearing in the plain text body of an
email message is not occupying a host name slot.
An "internationalized host name slot" is defined in this document to be
a host name slot explicitly designated for carrying an internationalized
host name as described in this document. The designation may be static
(for example, in the specification of the protocol or interface) or
dynamic (for example, as a result of negotiation in an interactive
session).
A "generic host name slot" is defined in this document to be any host
name slot that is not an internationalized host name slot. Obviously,
this includes any host name slot whose specification predates IDNA.
3. Requirements
IDNA conformance means adherence of the following three rules:
1) Whenever a host name is put into a generic host name slot, every
label MUST contain only ASCII characters. Given any host name, an
equivalent host name satisfying this requirement can be obtained by
applying the ToASCII operation (see section 4) to each label.
2) ACE labels SHOULD be hidden from users whenever possible. Therefore,
before a host name is displayed to a user or is output into a context
likely to be viewed by users, the ToUnicode operation (see section 4)
SHOULD be applied to each label. When requirements 1 and 2 both apply,
requirement 1 takes precedence.
3) Whenever two host labels are compared, they MUST be considered to
match if and only if their ASCII forms (obtained by applying ToASCII)
match using a case-insensitive ASCII comparison.
4. Conversion operations
This section specifies the ToASCII and ToUnicode operations. Each one
operates on a sequence of Unicode code points (but remember that all
ASCII code points are also Unicode code points). When host names are
represented using character sets other than Unicode and ASCII, they will
need to first be transcoded to Unicode before these operations can be
applied, and might need to be transcoded back afterwards.
4.1 ToASCII
The ToASCII operation takes a sequence of Unicode code points and
transforms it into a sequence of code points in the ASCII range (0..7F).
The original sequence and the resulting sequence are equivalent host
labels.
ToASCII fails if any step of it fails. Failure means that the original
sequence cannot be used as a host label.
ToASCII never alters a sequence of code points that are all in the ASCII
range to begin with (although it may fail).
ToASCII consists of the following steps:
1. If all code points in the sequence are in the ASCII range (0..7F)
then skip to step 3.
2. Perform the steps specified in [NAMEPREP].
3. Host-specific restrictions:
Host names have additional restrictions:
* Verify the absence of non-LDH ASCII code points; that is, the
absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
* Verify the absence of leading and trailing hyphen-minus; that
is, the absence of U+002D at the beginning and end of the
sequence.
4. If all code points in the sequence are in the ASCII range (0..7F),
then skip to step 8.
5. Verify that the sequence does NOT begin with the ACE prefix.
6. Encode the sequence using the encoding algorithm in [AMC-ACE-Z].
7. Prepend the ACE prefix.
8. Verify that the number of code points is in the range 1 to 63
inclusive.
4.2 ToUnicode
The ToUnicode operation takes a sequence of Unicode code points and
returns a sequence of Unicode code points. If the input sequence is a
host label in ACE form, then the result is an equivalent host label
that is not in ACE form, otherwise the original sequence is returned
unaltered.
ToUnicode never fails. If any step fails, then the original input
sequence is returned immediately in that step.
1. If all code points in the sequence are in the ASCII range (0..7F)
then skip to step 3.
2. Perform the steps specified in [NAMEPREP]. (If step 3
of ToASCII is also performed here, it will not affect the
overall behavior of ToUnicode, but it is not necessary.)
3. Verify that the sequence begins with the ACE prefix, and save a
copy of the sequence.
4. Remove the ACE prefix.
5. Decode the sequence using decoding algorithm in [AMC-ACE-Z]. Save
a copy of the result of this step.
6. Apply ToASCII.
7. Verify that the sequence matches the saved copy from step 3, using
a case-insensitive ASCII comparison.
8. Return the saved copy from step 5.
5. ACE prefix
The ACE prefix, used in the conversion operations (section 4), will
be specified in a future revision of this document. It will be two
alphanumeric ASCII characters followed by two hyphen-minuses. It MUST
be recognized in a case-insensitive manner.
For example, the eventual ACE prefix might be the string "jk--". In this
case, an ACE label might be "jk--r3c2a-qc902xs", where "r3c2a-qc902xs"
is the part of the ACE label that is generated by the encoding steps in
[AMC-ACE-Z].
6. Implications for typical applications using DNS
In IDNA, applications perform the processing needed to input
internationalized host names from users, display internationalized
host names to users, and process the inputs and outputs from DNS and
other protocols that carry host names.
The components and interfaces between them can be represented
pictorially as:
+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+-------------------|-------------------------------+
| v |
| +-----------------------------+ |
| | Application | |
| | (conversion between local | |
| | character set and Unicode | |
| | is done here) | |
| +-----------------------------+ |
| ^ ^ | End system
| | | |
| Call to resolver: | | Application-specific |
| ACE | | protocol: |
| v | predefined by the |
| +----------+ | protocol or defaults |
| | Resolver | | to ACE |
| +----------+ | |
| ^ | |
+-----------------|----------|----------------------+
DNS protocol: | |
ACE | |
v v
+-------------+ +---------------------+
| DNS servers | | Application servers |
+-------------+ +---------------------+
6.1 Entry and display in applications
Applications can accept host names using any character set or sets
desired by the application developer, and can display host names in any
charset. That is, the IDNA protocol does not affect the interface
between users and applications.
An IDNA-aware application can accept and display internationalized host
names in two formats: the internationalized character set(s) supported
by the application, and as an ACE label. Applications MAY allow input
and display of ACE labels, but are not encouraged to do so except as an
interface for special purposes, possibly for debugging. ACE encoding is
opaque and ugly, and should thus only be exposed to users who absolutely
need it. The optional use, especially during a transition period, of ACE
encodings in the user interface is described in section 6.4. Because
name labels encoded as ACE name labels can be rendered either as the
encoded ASCII characters or the proper decoded characters, the
application MAY have an option for the user to select the preferred
method of display; if it does, rendering the ACE SHOULD NOT be the
default.
Host names are often stored and transported in many places. For example,
they are part of documents such as mail messages and web pages. They are
transported in the many parts of many protocols, such as both the
control commands and the RFC 2822 body parts of SMTP, and the headers
and the body content in HTTP. It is important to remember that host
names appear both in host name slots and in the content that is passed
over protocols.
In protocols and document formats that define how to handle
specification or negotiation of charsets, IDN host name labels can be
encoded in any charset allowed by the protocol or document format. If a
protocol or document format only allows one charset, IDN host name
labels MUST be given in that charset. In any place where a protocol or
document format allows transmission of the characters in IDN host name
labels, IDN host name labels SHOULD be transmitted using whatever
character encoding and escape mechanism that the protocol or document
format uses at that place.
All protocols that have generic host name slots already have the
capacity for handling host names in the ASCII charset. Thus, IDN host
name labels that have been processed with the ToASCII operation can
inherently be handled by those protocols.
6.2 Applications and resolvers
Applications communicate with resolver libraries through a programming
interface (API). Typically, the IETF does not standardize APIs, although
there are non-standard APIs specified for IPv6. This protocol does not
specify a specific API, but instead specifies the operations that must
be used for input to and output from the resolver library.
An application MUST prepapre name parts that are sent in the DNS
protocol using the ToASCII operation. Internationalized labels received
from the resolver will always be in ACE form. IDNA-aware applications
MUST be able to work with both non-internationalized host name labels
(those that conform to [STD13] and [STD3]) and internationalized host
name labels.
6.3 Resolvers and DNS servers
An operating system might have a set of libraries for performing the
ToASCII operation. The input to such a library might be in one or more
charsets that are used in applications (UTF-8 and UTF-16 are likely
candidates for almost any operating system, and script-specific charsets
are likely for localized operating systems).
DNS servers MUST use the ACE format for internationalized host labels.
All internationalized names stored in DNS servers must be valid names
that have been processed with the ToASCII operation.
If a signalling system which makes negotiation possible between old and
new DNS clients and servers is standardized in the future, the encoding
of the query in the DNS protocol itself can be changed from ACE to
something else, such as UTF-8. The question whether or not this should
be used is, however, a separate problem and is not discussed in this
memo.
6.4 Avoiding exposing users to the raw ACE encoding
All applications that might show the user a host name that was received
from a gethostbyaddr or other such lookup SHOULD update as soon as
possible in order to prevent users from seeing the ACE. However, this is
not considered a big problem because so few applications show this type
of resolution to users.
If an application decodes an ACE name using ToUnicode but cannot show
all of the characters in the decoded name, such as if the name contains
characters that the output system cannot display, the application SHOULD
show the name in ACE format instead of displaying the name with the
replacement character (U+FFFD). This is to make it easier for the user
to transfer the name correctly to other programs. Programs that by
default show the ACE form when they cannot show all the characters in a
name label SHOULD also have a mechanism to show the name that is
produced by the ToUnicode operation with as many characters as possible
and replacement characters in the positions where characters cannot be
displayed. In many cases, the application doesn't know exactly what the
underlying rendering engine can or cannot display.
In addition to the condition above, if an application receives an ACE
host name after performing the ToUnicode operation, meaning that the
name was not properly prepared with ToASCII (for example, if it has
illegal characters in it), the application MUST show the name in ACE
format because the ToUnicode operation never fails, but returns the
original input if errors are detected at any step.
6.5 Bidirectional text in host names
The display of host names that contain bidirectional text is not covered
in this document. It may be covered in a future version of this
document, or may be covered in a different document.
For developers interested in displaying host names that have
bidirectional text, the Unicode standard has an extensive discussion of
how to deal with reorder glyphs for display when dealing with
bidirectional text such as Arabic or Hebrew. See [UAX9] for more
information. In particular, all Unicode text is stored in logical order.
7. Name Server Considerations
Internationalized host name data in zone files (as specified by section
5 of RFC 1035) MUST be processed with ToASCII before it is entered in
the zone files.
It is imperative that there be only one ASCII encoding for a particular
host name. ACE is an encoding for host name labels that use non-ASCII
characters. Thus, a primary master name server MUST NOT contain an
ACE-encoded label that decodes to an ASCII label. The ToASCII operation
assures that no such names are ever output from the operation.
Name servers MUST NOT have any records with host names that contain
internationalized name labels unless those name labels have be prepared
with the ToASCII operation. If names that are not processed by ToASCII
are passed to an application, it will result in unpredictable behavior.
Note that [NAMEPREP] describes how to handle versioning of unallocated
codepoints.
8. Root Server Considerations
Because there are no changes to the DNS protocols, adopting this
protocol has no effect on the DNS root servers.
9. Security Considerations
Much of the security of the Internet relies on the DNS. Thus, any change
to the characteristics of the DNS can change the security of much of the
Internet.
This memo describes an algorithm which encodes characters that are not
valid according to STD3 and STD13 into octet values that are valid. No
security issues such as string length increases or new allowed values
are introduced by the encoding process or the use of these encoded
values, apart from those introduced by the ACE encoding itself.
Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers
based on different interpretations of the internationalized host name.
Because this document normatively refers to [NAMEPREP], it includes the
security considerations from that document as well.
A. References
[AMC-ACE-Z] Adam Costello, "AMC-ACE-Z version 0.3.1",
draft-ietf-idn-amc-ace-z.
[NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
and Support" (RFC 1123), STD 3, October 1989.
[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
1034) and "Domain names - implementation and specification" (RFC 1035,
STD 13, November 1987.
[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm.
http://www.unicode.org/unicode/reports/tr9/
[UNICODE] The Unicode Standard, Version 3.1.0: The Unicode Consortium.
The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley
Developers Press, 2000. ISBN 0-201-61633-5, as amended by: Unicode
Standard Annex #27: Unicode 3.1
<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.
B. Design philosophy
Many proposals for IDN protocols have required that DNS servers be
updated to handle internationalized host names. Because of this, a
person who wanted to use an internationalized host name would have to be
sure that their request went to a DNS server that had been updated for
IDN. Further, that server could send queries only to other servers that
had been updated for IDN, because the queries contain new protocol
elements to differentiate IDN name labels from current host labels. In
addition, these proposals require that resolvers be updated to use the
new protocols, and in most cases the applications would need to be
updated as well.
These proposals would require changes to the application protocols that
use host names as protocol elements, because of the assumptions and
requirements made in those protocols about the characters that have
always been used for host names, and the encoding of those characters.
Other proposals for IDN protocols do not require changes to DNS servers
but still require changes to most application protocols to handle the
new names.
Updating all (or even a significant percentage) of the existing servers
in the world will be difficult, to say the least. Updating applications,
application gateways, and clients to handle changes to the application
protocols is also daunting. Because of this, we have designed a protocol
that requires no updating of any name servers. IDNA still requires the
updating of applications, but only for input and display of names, not
for changes to the protocols. Once users have updated the applications,
they can immediately start using internationalized host names. The cost
of implementing IDN may thus be much lower, and the speed of
implementation could be much higher.
C. Authors' Addresses
Patrik Faltstrom
Cisco Systems
Arstaangsvagen 31 J
S-117 43 Stockholm Sweden
paf@cisco.com
Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
phoffman@imc.org
Adam M. Costello
University of California, Berkeley
idna-spec.amc @ nicemice.net

859
doc/draft/draft-ietf-idn-lace-01.txt
View File

@@ -1,859 +0,0 @@
Internet Draft Mark Davis
draft-ietf-idn-lace-01.txt IBM
January 5, 2001 Paul Hoffman
Expires July 5, 2001 IMC & VPNC
LACE: Length-based ASCII Compatible Encoding for IDN
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a transformation method for representing
non-ASCII characters in host name parts in a fashion that is completely
compatible with the current DNS. It is a potential candidate for an
ASCII-Compatible Encoding (ACE) for internationalized host names, as
described in the comparison document from the IETF IDN Working Group.
This method is based on the observation that many internationalized host
name parts will have a few substrings from a small number of rows of the
ISO 10646 repertoire. Run-length encoding for these types of
host names will be fairly compact, and is fairly easy to describe.
1. Introduction
There is a strong world-wide desire to use characters other than plain
ASCII in host names. Host names have become the equivalent of business
or product names for many services on the Internet, so there is a need
to make them usable by people whose native scripts are not representable
by ASCII. The requirements for internationalizing host names are
described in the IDN WG's requirements document, [IDNReq].
The IDN WG's comparison document [IDNComp] describes three potential
main architectures for IDN: arch-1 (just send binary), arch-2 (send
binary or ACE), and arch-3 (just send ACE). LACE is an ACE, called
Length-based ACE or LACE, that can be used with protocols that match arch-2
or arch-3. LACE specifies an ACE format as specified in ace-1 in
[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in
[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the
beginning of the name part).
In formal terms, LACE describes a character encoding scheme of the
ISO/IEC 10646 [ISO10646] coded character set (whose assignment of
characters is synchronized with Unicode [Unicode3]) and the rules for
using that scheme in the DNS. As such, it could also be called a
"charset" as defined in [IDNReq]. It can also be viewed as a specialized
UTF (transformation format), designed to work within the restrictions of
the DNS.
The LACE protocol has the following features:
- There is exactly one way to convert internationalized host parts to
and from LACE parts. Host name part uniqueness is preserved.
- Host parts that have no international characters are not changed.
- Names using LACE can include more internationalized characters than
with other ACE protocols that have been suggested to date. LACE-encoded
names are variable length, depending on the number of transitions
between rows in the ISO 10646 repertoire that appear in the name part.
Name parts that cannot be compressed using run-length encoding can have
up to 17 characters, and names that can be compressed can have up to 35
characters. Further, a name that has just a few row transitions
typically can have over 30 characters.
It is important to note that the following sections contain many
normative statements with "MUST" and "MUST NOT". Any implementation that
does not follow these statements exactly is likely to cause damage to
the Internet by creating non-unique representations of host names.
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
Hexadecimal values are shown preceded with an "0x". For example,
"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
shown preceded with an "0b". For example, a nine-bit value might be
shown as "0b101101111".
Examples in this document use the notation for code points and names
from the Unicode Standard [Unicode3] and ISO 10646. For example, the
letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER
A".
LACE converts strings with internationalized characters into
strings of US-ASCII that are acceptable as host name parts in current
DNS host naming usage. The former are called "pre-converted" and the
latter are called "post-converted".
1.2 IDN summary
Using the terminology in [IDNComp], LACE specifies an ACE format as
specified in ace-1. Further, it specifies an identifying mechanism for
ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning
of the name part).
LACE has the following length characteristics.
- LACE-encoded names are variable length, depending on the number of
transitions between rows that appear in the name part.
- Name parts that cannot be compressed using run-length encoding can
have up to 17 characters.
- Names that can be compressed can have up to 35 characters.
-A name that has just a few row transitions typically can have over 30
characters.
2. Host Part Transformation
According to [STD13], host parts must be case-insensitive, start and
end with a letter or digit, and contain only letters, digits, and the
hyphen character ("-"). This, of course, excludes any internationalized
characters, as well as many other characters in the ASCII character
repertoire. Further, domain name parts must be 63 octets or shorter in
length.
2.1 Name tagging
All post-converted name parts that contain internationalized characters
begin with the string "lq--". (Of course, because host name parts are
case-insensitive, this might also be represented as "Lq--" or "lQ--" or
"LQ--".) The string "lq--" was chosen because it is extremely unlikely
to exist in host parts before this specification was produced. As a
historical note, in late October 2000, none of the second-level host
name parts in any of the .com, .edu, .net, and .org top-level domains
began with "lq--"; there are many tens of thousands of other strings of
three characters followed by a hyphen that have this property and could
be used instead. The string "lq--" will change to other strings with the
same properties in future versions of this draft.
Note that a zone administrator might still choose to use "lq--" at the
beginning of a host name part even if that part does not contain
internationalized characters. Zone administrators SHOULD NOT create host
part names that begin with "lq--" unless those names are post-converted
names. Creating host part names that begin with "lq--" but that are not
post-converted names may cause two distinct problems. Some display
systems, after converting the post-converted name part back to an
internationalized name part, might display the name parts in a
possibly-confusing fashion to users. More seriously, some resolvers,
after converting the post-converted name part back to an
internationalized name part, might reject the host name if it contains
illegal characters.
2.2 Converting an internationalized name to an ACE name part
To convert a string of internationalized characters into an ACE name
part, the following steps MUST be preformed in the exact order of the
subsections given here.
If a name part consists exclusively of characters that conform to the
host name requirements in [STD13], the name MUST NOT be converted to
LACE. That is, a name part that can be represented without LACE MUST NOT
be encoded using LACE. This absolute requirement prevents there from
being two different encodings for a single DNS host name.
If any checking for prohibited name parts (such as ones that are
prohibited characters, case-folding, or canonicalization) is to be done,
it MUST be done before doing the conversion to an ACE name part.
Characters outside the first plane of characters (those with codepoints
above U+FFFF) MUST be represented using surrogates, as described in
RFC 2781 [RFC2781].
The input name string consists of characters from the ISO 10646
character set in big-endian UTF-16 encoding. This is the pre-converted
string.
2.2.1 Check the input string for disallowed names
If the input string consists only of characters that conform to the host
name requirements in [STD13], the conversion MUST stop with an error.
2.2.2 Compress the pre-converted string
The entire pre-converted string MUST be compressed using the compression
algorithm specified in section 2.4. The result of this step is the
compressed string.
2.2.3 Check the length of the compressed string
The compressed string MUST be 36 octets or shorter. If the compressed
string is 37 octets or longer, the conversion MUST stop with an error.
2.2.4 Encode the compressed string with Base32
The compressed string MUST be converted using the Base32 encoding
described in section 2.5. The result of this step is the encoded string.
2.2.5 Prepend "lq--" to the encoded string and finish
Prepend the characters "lq--" to the encoded string. This is the host
name part that can be used in DNS resolution.
2.3 Converting a host name part to an internationalized name
The input string for conversion is a valid host name part. Note that if
any checking for prohibited name parts (such as prohibited characters,
case-folding, or canonicalization is to be done, it MUST be done after
doing the conversion from an ACE name part.
If a decoded name part consists exclusively of characters that conform
to the host name requirements in [STD13], the conversion from LACE MUST
fail. Because a name part that can be represented without LACE MUST NOT
be encoded using LACE, the decoding process MUST check for name parts
that consists exclusively of characters that conform to the host name
requirements in [STD13] and, if such a name part is found, MUST
beconsidered an error (and possibly a security violation).
2.3.1 Strip the "lq--"
The input string MUST begin with the characters "lq--". If it does not,
the conversion MUST stop with an error. Otherwise, remove the characters
"lq--" from the input string. The result of this step is the stripped
string.
2.3.2 Decode the stripped string with Base32
The entire stripped string MUST be checked to see if it is valid Base32
output. The entire stripped string MUST be changed to all lower-case
letters and digits. If any resulting characters are not in Table 1, the
conversion MUST stop with an error; the input string is the
post-converted string. Otherwise, the entire resulting string MUST be
converted to a binary format using the Base32 decoding described in
section 2.5. The result of this step is the decoded string.
2.3.3 Decompress the decoded string
The entire decoded string MUST be converted to ISO 10646 characters
using the decompression algorithm described in section 2.4. The result
of this is the internationalized string.
2.3.4 Check the internationalized string for disallowed names
If the internationalized string consists only of characters that conform
to the host name requirements in [STD13], the conversion MUST stop with
an error.
2.4 Compression algorithm
The basic method for compression is to reduce a substring that consists
of characters all from a single row of the ISO 10646 repertoire to a
count octet followed by the row header followed by the lower octets of
the characters. If this ends up being longer than the input, the string
is not compressed, but instead has a unique one-octet header attached.
Although the uncompressed mode limits the number of characters in a LACE
name part to 17, this is still generally enough for all names in almost
scripts. Also, this limit is close to the limits set by other encoding
proposals.
Note that the compression and decompression rules MUST be followed
exactly. This requirement prevents a single host name part from having
two encodings. Thus, for any input to the algorithm, there is only one
possible output. An implementation cannot chose to use one-octet mode or
two-octet mode using anything other than the logic given in this
section.
2.4.1 Compressing a string
The input string is in the UTF-16 encoding (big-endian UTF-16 with no
byte order mark).
Design note: No checking is done on the input to this algorithm. It is
assumed that all checking for valid ISO/IEC 10646 characters has already
been done by a previous step in the conversion process.
1) If the length (measured in octets) of the input is not even, or is
less than 2, stop with an error.
2) Set the input pointer, called IP, to the first octet of the input
string.
3) Set the variable called HIGH to the octet at IP.
4) Determine the number of contiguous pairs at or after IP that have
HIGH as the first octet; call this COUNT.
5) Put into an output buffer the single octet for COUNT followed by the
single octet for HIGH, followed by all those low octets. Move IP to the
end of those pairs; that is, set IP to IP+(2*COUNT).
6) If IP is not at the end of the input string, go to step 3.
7) If the length of the output buffer is less than or equal to the
length of the input buffer (in octets, not in characters), emit the
output buffer. Otherwise, output the octet 0xFF followed by the input
buffer. Note that there can only be one possible representation for a
name part, so that outputting the wrong name part is a serious security
error. Decompression schemes MUST accept only the valid form and MUST
NOT accept invalid forms.
2.4.2 Decompressing a string
1. Set the input pointer, called IP, to the first octet of the input
string. If there is no first octet, stop with an error.
2. If the octet at IP is 0xFF, set IP to IP+1, copy the rest of the
input buffer to the output buffer, and go to step 9.
3. Get the octet at IP, call it COUNT. If COUNT equals zero or is
greater than 36, stop with an error. Set IP to IP+1. If IP is now at the
end of the input string, stop with an error.
4. Get the octet at IP, call it HIGH. Set IP to IP+1.
5. If IP is now at the end of the input string, stop with an error. Get
the octet at IP, call it LOW. Set IP to IP+1.
6. Output HIGH, then LOW, to the output buffer.
7. Decrement COUNT. If COUNT is greater than 0, go to step 5.
8. If IP is not at the end of the input buffer, go to step 3.
9. If the length of the output buffer is odd, stop with an error.
Compress the output buffer into a separate comparison buffer following
the steps for compression above. If the contents of the comparison
buffer does not equal the input to the compression step, stop with an
error. Otherwise, send out the output buffer and stop.
2.4.3 Compression examples
The five input characters <U+30E6 U+30CB U+30B3 U+30FC U+30C9> are
represented in big-endian UTF-16 as the ten octets <30 E6 30 CB 30 B3 30
FC 30 C9>. All the code units are in the same row (03). The output
buffer has seven octets <05 30 E6 CB B3 FC C9>, which is shorter than
the input string. Thus the output is <05 30 E6 CB B3 FC C9>.
The four input characters <U+012F U+0111 U+0149 U+00E5> are represented
in big-endian UTF-16 as the eight octets <01 2F 01 11 01 49 00 E5>. The
output buffer has eight octets <03 01 2F 11 49 01 00 E5>, which is the
same length as the input string. Thus, the output is <03 01 2F 11 49 01
00 E5>.
The three input characters <U+012F U+00E0 U+014B> are represented in
big-endian UTF-16 as the six octets <01 2F 00 E0 01 4B>. The output
buffer is nine octets <01 01 2F 01 00 E0 01 01 4B>, which is longer than
the input buffer. Thus, the output is <FF 01 2F 00 E0 01 4B>.
2.5 Base32
In order to encode non-ASCII characters in DNS-compatible host name parts,
they must be converted into legal characters. This is done with Base32
encoding, described here.
Table 1 shows the mapping between input bits and output characters in
Base32. Design note: the digits used in Base32 are "2" through "7"
instead of "0" through "6" in order to avoid digits "0" and "1". This
helps reduce errors for users who are entering a Base32 stream and may
misinterpret a "0" for an "O" or a "1" for an "l".
Table 1: Base32 conversion
bits char hex bits char hex
00000 a 0x61 10000 q 0x71
00001 b 0x62 10001 r 0x72
00010 c 0x63 10010 s 0x73
00011 d 0x64 10011 t 0x74
00100 e 0x65 10100 u 0x75
00101 f 0x66 10101 v 0x76
00110 g 0x67 10110 w 0x77
00111 h 0x68 10111 x 0x78
01000 i 0x69 11000 y 0x79
01001 j 0x6a 11001 z 0x7a
01010 k 0x6b 11010 2 0x32
01011 l 0x6c 11011 3 0x33
01100 m 0x6d 11100 4 0x34
01101 n 0x6e 11101 5 0x35
01110 o 0x6f 11110 6 0x36
01111 p 0x70 11111 7 0x37
2.5.1 Encoding octets as Base32
The input is a stream of octets. However, the octets are then treated
as a stream of bits.
Design note: The assumption that the input is a stream of octets
(instead of a stream of bits) was made so that no padding was needed.
If you are reusing this algorithm for a stream of bits, you must add a
padding mechanism in order to differentiate different lengths of input.
1) Set the read pointer to the beginning of the input bit stream.
2) Look at the five bits after the read pointer. If there are not five
bits, go to step 5.
3) Look up the value of the set of five bits in the bits column of
Table 1, and output the character from the char column (whose hex value
is in the hex column).
4) Move the read pointer five bits forward. If the read pointer is at
the end of the input bit stream (that is, there are no more bits in the
input), stop. Otherwise, go to step 2.
5) Pad the bits seen until there are five bits.
6) Look up the value of the set of five bits in the bits column of
Table 1, and output the character from the char column (whose hex value
is in the hex column).
2.5.2 Decoding Base32 as octets
The input is octets in network byte order. The input octets MUST be
values from the second column in Table 1.
1) Count the number of octets in the input and divide it by 8; call the
remainder INPUTCHECK. If INPUTCHECK is 1 or 3 or 6, stop with an error.
2) Set the read pointer to the beginning of the input octet stream.
3) Look up the character value of the octet in the char column (or hex
value in hex column) of Table 1, and add the five bits from the bits
column to the output buffer.
4) Move the read pointer one octet forward. If the read pointer is not
at the end of the input octet stream (that is, there are more octets in
the input), go to step 3.
5) Count the number of bits that are in the output buffer and divide it
by 8; call the remainder PADDING. If the PADDING number of bits at the
end of the output buffer are not all zero, stop with an error.
Otherwise, emit the output buffer and stop.
2.5.3 Base32 example
Assume you want to encode the value 0x3a270f93. The bit string is:
3 a 2 7 0 f 9 3
00111010 00100111 00001111 10010011
Broken into chunks of five bits, this is:
00111 01000 10011 10000 11111 00100 11
Padding is added to make the last chunk five bits:
00111 01000 10011 10000 11111 00100 11000
The output of encoding is:
00111 01000 10011 10000 11111 00100 11000
h i t q 7 e y
or "hitq7ey".
3. Security Considerations
Much of the security of the Internet relies on the DNS. Thus, any
change to the characteristics of the DNS can change the security of
much of the Internet. Thus, LACE makes no changes to the DNS
itself.
Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers
based on different interpretations of the internationalized host
name.
LACE is designed so that every internationalized host name part
can be represented as one and only one DNS-compatible string. If there
is any way to follow the steps in this document and get two or more
different results, it is a severe and fatal error in the protocol.
4. References
[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals",
draft-ietf-idn-compare.
[IDNReq] James Seng, "Requirements of Internationalized Domain Names",
draft-ietf-idn-requirement.
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane. Five amendments and
a technical corrigendum have been published up to now. UTF-16 is
described in Annex Q, published as Amendment 1. 17 other amendments are
currently at various stages of standardization. [[[ THIS REFERENCE
NEEDS TO BE UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[RFC2781] Paul Hoffman and Francois Yergeau, "UTF-16, an encoding of ISO
10646", February 2000, RFC 2781.
[STD13] Paul Mockapetris, "Domain names - implementation and
specification", November 1987, STD 13 (RFC 1035).
[Unicode3] 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>.
A. Acknowledgements
Rick Wesson pointed out some error conditions that need to be
tested for. Scott Hollenbeck pointed out some errors in the
compression.
Base32 is quite obviously inspired by the tried-and-true Base64
Content-Transfer-Encoding from MIME.
B. Sample code
The following is sample Javascript code for the LACE algorithm.
This code is believed to be correct, but there may be errors in
it. The code is provided as-is and comes with no warranty of
fitness, correctness, blah blah blah.
/**
* Converts to LACE compression format (without Base32) from
* UTF-16BE array
* @parameter iArray Array of bytes in UTF16-BE
* @parameter iCount Number of elements. Must be 0..63
* @parameter oArray Array for output of LACE bytes.
* Must be at least 100 octets long to provide internal working space
* @return Length of output array used
* @parameter parseResult output error value if any
* @author Mark Davis
*/
function toLACE(iArray, iCount, oArray, parseResult) {
//debugger;
if (iCount < 1 || iCount > 62) <20>{
parseResult.set("Lace: count out of range", iCount);
return;
}
if ((iCount % 2) == 1) <20>{
parseResult.set("Lace: odd length, can't be UTF-16", iCount);
return;
}
var op = 0; <20>// input index
var ip = 0; <20>// output index
var lastHigh = -1;
var lenp = 0;
while (ip < iCount) {
var high = iArray[ip++];
if (high != lastHigh) {
if (lastHigh != -1) { <20>// store last length
var len = op - lenp - 2;
oArray[lenp] = len;
} <20>
lenp = op++; // reserve space
oArray[op++] = high;
lastHigh = high;
}
oArray[op++] = iArray[ip++];
}
// store last len
var len = op - lenp - 2;
oArray[lenp] = len;
// see if the input is short, and we should
// just copy
if (op > iCount) {
if (op > 63) <20>{
parseResult.set("Lace: output too long", op);
return;
}
oArray[0] = 0xFF;
copyTo(iArray, 0, iCount, oArray, 1);
op = iCount + 1;
}
return op;
}
/**
* Converts from LACE compressed format (without Base32) to
* UTF-16BE array
* @parameter iArray Array of bytes in LACE format
* @parameter iCount Number of elements
* @parameter oArray Array for output of bytes, UTF16-BE.
* Must be at least iCount+1 long
* @return Length of output array used
* @parameter parseResult output error value if any
* @author Mark Davis
*/
function fromLACE(iArray, iCount, oArray, parseResult) {
var high;
if (iCount < 1 || iCount > 63) {
parseResult.set("fromLACE: count out of range", iCount);
return;
}
var op = 0;
var ip = 0;
var result = 0;
if (iArray[ip] == 0xFF) { <20>// special case FF
copyTo(iArray, 1, iCount-1, oArray, 0);
result = iCount-1;
} else {
while (ip < iCount) { <20>// loop over runs
var count = iArray[ip++];
if (ip == iCount) {
parseResult.set("fromLACE: truncated before high", ip);
return;
}
high = iArray[ip++];
for (var i = 0; i < count; ++i) {
oArray[op++] = high;
if (ip == iCount) <20>{
parseResult.set("fromLACE: truncated from count", ip);
return;
}
oArray[op++] = iArray[ip++];
}
}
result = op;
}
// check for uniqueness
var checkArray = [];
var checkCount = toLACE(oArray, result, checkArray, parseResult);
if (!equals(iArray, iCount, checkArray, checkCount)) {
parseResult.set("fromLACE: illegal input form");
return;
} <20>
return result;
}
/**
* Utility routine for comparing arrays
* @parameter array1 first array to compare
* @parameter count1 number of elements to compare in first array
* @parameter array2 second array to compare
* @parameter count1 number of elements to compare in second array
* @return true iff counts are same, and elements from 0 to count-1
* are the same
*/
function equals(array1, count1, array2, count2) {
if (count1 != count2) return false;
for (var i = 0; i < count1; ++i) {
if (array1[i] != array2[i]) return false;
}
return true;
}
/**
* Utility routine for getting array of bytes from UTF-16 string
* @parameter str source string
* @parameter oArray output array to fill in
* @return count of bytes put into oArray
*/
function utf16FromString(str, oArray) {
var op = 0;
for (var i = 0; i < str.length; ++i) {
var code = str.charCodeAt(i);
oArray[op++] = (code >>> 8); <20>// top byte
oArray[op++] = (code & 0xFF); // bottom byte
}
return op;
}
/**
* Utility routine to see if string doesn't need LACE
* @parameter str source string
* @return true if ok already
*/
function okAlready(str) {
for (var i = 0; i < str.length; ++i) {
var c = str.charAt(i);
if (c == '-' || 'a' <= c && c <= 'z' || '0' <= c && c <= '9')
continue;
return false;
}
return true
}
/**
* Convert from bytes to base32
* @parameter input Input buffer of bytes with values 00 to FF
* @parameter inputLength Length of input buffer
* @parameter output Output buffer, to be filled with with values from
a-z2-7.
* Must be of at least length input*8/5 + 1
* @return Length of output buffer used
* @author Mark Davis
*/
function toBase32(input, inputLength, output, parseResult) {
//debugger;
var bits = 0;
var bitCount = 0;
var ip = 0;
var op = 0;
var val = 0;
while (true) {
// get bits if we don't have enough
if (bitCount < 5) {
if (ip >= inputLength) break;
// get another input
bits <<= 8;
if (baseDebugTo) alert("byte: " + input[ip].toString(16) + ",
bitCount: " + (bitCount+8));
bits = bits | input[ip++];
bitCount += 8;
}
// emit and remove them
bitCount -= 5;
val = (bits >> bitCount);
if (baseDebugTo) alert("Val: " + val.toString(16) + ", bitCount: "
+ bitCount);
output[op++] = toLetter(val);
//if (baseDebugTo) alert("out: " + output[op-1].toString(16));
bits &= ~(0x1F << bitCount);
}
// add padding and output if necessary
if (bitCount > 0) {
if (baseDebugTo) alert("bits*: " + bits.toString(16) +
", bitCount: " + bitCount);
val = bits << (5 - bitCount);
if (baseDebugTo) alert("out*: " + val.toString(16));
output[op++] = toLetter(val);
}
return op;
}
/**
* Convert from base32 to bytes
* @parameter input Input buffer of bytes with values from a-z2-7
* @parameter inputLength Length of input buffer
* @parameter output Output buffer, to be filled with bytes from
* 00 to FF
* Must be of at least length input*5/8 + 1
* @return Length of output buffer used
* @author Mark Davis
*/
function fromBase32(input, inputLength, output, parseResult) {
//debugger;
var inputCheck = inputLength % 8;
if (inputCheck == 1 || inputCheck == 3 || inputCheck == 6) {
parseResult.set("Base32 excess length", null, inputLength);
return;
}
var bits = 0;
var bitCount = 0;
var ip = 0;
var op = 0;
var val = 0;
while (ip < inputLength) {
// get more bits
var val = input[ip++];
val = fromLetter(val);
if (val < 0 || val > 0x3F) {
parseResult.set("Bad Base32 byte", val, ip-1);
return;
}
if (baseDebugFrom) alert("base32: " + val.toString(16));
bits <<= 5;
bits = bits | val;
bitCount += 5;
if (baseDebugFrom) alert("from: " + val.toString(16) +
", bitCount: " + bitCount);
// emit & remove if we can
if (bitCount >= 8) {
bitCount -= 8;
output[op++] = bits >> bitCount;
if (baseDebugFrom) alert("out2: " + (bits >> bitCount) +
", bitCount: " + bitCount);
bits &= ~(0xFF << bitCount);
}
}
// check that padding is with zero!
if (bits != 0) return -ip;
return op;
}
function toLetter(val) {
if (val > 25) return val - 26 + 0x32;
return val + 0x61;
// return val + (val < 26 ? 0x61 : 0x18);
}
function fromLetter(val) {
if (val < 0x61) return val + 26 - 0x32;
return val - 0x61;
}
C. Difrerences between -00 and -01
1: Minor typos.
2.1: Changed the tag to 'lq--'.
2.2 and 2.3: Added check for all-STD13 names in the steps.
2.4.1: Clarified first sentence. Step 5: fixed the moving of the IP.
2.4.2: Moved the last sentence of step 4 to be the first sentence of
step 5. Added the check for odd-length output. Changed the exit
comparision to doing a full comparison (instead of looking for lengths).
2.5.2: Changed the sense of the test in step 3 and added step 4 to check
for malformed input. Also made the output a buffer. Also added new step
1.
Changed Appendix B from IANA Considerations (of which there are none) to
Javascript code sample.
D. Author Contact Information
Mark Davis
IBM
10275 N. De Anza Blvd
Cupertino, CA 95014
mark.davis@us.ibm.com and mark.davis@macchiato.com
Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
paul.hoffman@imc.org and paul.hoffman@vpnc.org

20
doc/draft/draft-ietf-idn-lace-02.txt Normal file
View File

@@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
P. Hoffman: paul.hoffman@vpnc.org
M. Davis: davismc@us.ibm.com

374
doc/draft/draft-ietf-idn-mua-00.txt
View File

@@ -1,374 +0,0 @@
Internet Draft Maynard Kang
draft-ietf-idn-mua-00.txt i-EMAIL.net
February 5, 2001
Expires on August 5, 2001
Internationalizing Domain Names in Mail User Agents
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a way where domain names used in Internet e-mail
can be internationalized by making changes only to end-user Mail User
Agents and, by doing so, avoid damaging other applications which handle
Internet e-mail, such as Message Transfer Agents and Delivery Agents.
1. Introduction
One of the proposed solutions for internationalized domain names (IDN)
involves only updating the user applications with no changes required
to the DNS protocol, servers and resolvers [IDNA] compared to other
solutions which require changes to be made to protocol, servers,
resolvers and applications.
The underlying principle of [IDNA] may be similarly applied to the
Internet e-mail system today - by effecting changes to only the Mail
User Agent (MUA) component of the e-mail system. Thus, existing
Message Transfer Agents, Delivery Agents and other applications which
handle e-mail do not have to be changed at all.
1.1 Definitions and Conventions
Usage of terms related to the character encoding model are in
reference to Unicode Technical Report 17 [UTR17].
The terms "international character", "non-ASCII character" and
"multilingual character", which are used interchangeably, are taken
to mean any abstract character which is not included in the range
specified by [US-ASCII].
1.2 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in RFC
2119 [RFC2119].
1.3. Design Philosophy
As the Internet e-mail system is a diverse, distributed and
heterogeneous system with many vendors deploying a vast number of
applications, it is of utmost importance that interoperability amongst
these various components is maintained. Thus, the ideal solution would
be one which does not compromise or damage the operation of any of these
existing components once internationalized domain names are encountered.
Also, solutions which call for changes to be made to many or even all
components of the Internet e-mail system would require far too much
time and effort to deploy, given that Internet e-mail has such a huge
installed base.
This solution adheres to both of the above principles, in that
interoperability is preserved and that the cost and speed of
implementation is low. All that the user has to do to use IDNs in e-mail
is update his or her MUA.
1.4. IDN Summary
This solution specifies an IDN architecture of arch-3 (just send ACE)
and a transition strategy of trans-1 (always do current plus new
architecture) as described in [IDNCOMP]. The choice of ACE format is not
defined in this document, but MUST be the same as that specified in
[IDNA] in order to maintain uniqueness and consistency.
1.5. E-mail Internationalization Summary
As many Internet e-mail standards such as the SMTP protocol [RFC821]
and the e-mail message format [RFC822] only specify usage of the 7-bit
ASCII character set [US-ASCII], international characters which use octet-
based character encoding schemes (CES) cannot be used in e-mail
transmission, headers and bodies.
Although this issue has been addressed in [RFC2045] for message bodies
and [RFC2047] for message headers through the use of a Transfer Encoding
Syntax (TES) such as Quoted-Printable or Base64, there is no similar
solution which extends the functionality of [RFC821] to include usage of
international characters, except for [RFC1652] which allows transmission
of 8-bit data passed by the DATA command in an SMTP session.
[RFC1652] however, does not fully address the problem of using IDNs in
an SMTP session - the IDN may be used in areas within the SMTP session
other than the DATA command, such as the MAIL FROM and RCPT TO commands,
where an IDN may be part of the e-mail address(es) specified there.
Hence, this would be a major stumbling block to deploying "just-send-
8bit" IDNs for use in Internet e-mail, as these IDNs would not be able
to be used in SMTP e-mail transmissions due to [RFC821] restrictions.
2. Architectural Overview
The end-user MUA may encounter IDNs in the scenarios below:
(i) When specifying the transmission server (i.e. SMTP server)
(ii) When specifying the retrieval server (i.e. POP3/IMAP4/any other
retrieval mechanism)
(iii) When specifying e-mail addresses during composition of a message
(iv) When reading messages with e-mail addresses in it
As with [IDNA], the MUA is updated in a similar fashion to process IDNs
which are input by users and process IDNs which are displayed to users,
in all of the scenarios above.
For (i) and (ii), the IDN MUST be handled in the same manner as
specified in [IDNA]. The method of handling an IDN For (iii) and (iv) is
described below in 2.1.
2.1 Interfaces between E-mail components when composing/reading a mail
The interfaces between e-mail components can be pictorially represented
as shown below.
The example assumes the setup of a POP3/IMAP4 retrieval client and
server, but the exact nature of end-to-end e-mail transmission may vary
accordingly (e.g. elm or pine would read directly from the mail store).
However, these variations do not impact an accurate description of this
solution to a large extent as no changes are required at these levels.
+------+ +------+
| User | | User |
+------+ +---^--|
| User Input: User Display: Characters/ |
| Keyboard/Pen/etc Glyphs on CRT or other |
+-----v---------------+ Representation (e.g. sound) |
| Input Method Editor | +------------|-----+
+---------------------+ | Rendering Engine |
| Input: Any localized/ +---------^--------+
| internationalized Output: Any localized/ |
| charset internationalized |
+----v-----------------+ charset |
| +------------------+ | +----------|-------------+
| | Mail Composition | | | +--------------+ |
| | Interface | | Sender's | | Mail Reading | |
| +------------------+ | MUA | | Interface | |
| | | | +--------^-----+ |
| | Nameprepped ACE | Receiver's | | Nameprepped |
| v | MUA | | ACE |
| +-------------+ | | +-------------------+ |
| | SMTP Client | | | | POP3/IMAP4 Client | |
| +-------------+ | | +-------------------+ |
+----|-----------------+ +----------^-------------+
| Nameprepped | Nameprepped
v ACE Nameprepped Nameprepped | ACE
+-------------+ ACE +------------+ ACE +-------------------+
| SMTP Server | -----> | Mail Store | -----> | POP3/IMAP4 Server |
+-------------+ +------------+ +-------------------+
2.1.1 Interface between User and Input Method Editor
For ASCII characters, input is straightforward: the user types on the
keyboard and whichever character that is pressed is sent to the
application.
However, for international characters, the end-user has to use a script-
specific Input Method Editor (IME), which may or may not be built-into
the OS, to interpret what the user communicates to the system and
thereafter send the respective international characters to the
application.
For example, for input of Chinese characters, some users use IMEs
which support the "Pinyin" input method. When a user types "zhongguo"
(in ASCII characters) on the keyboard and selects the characters which
represent "China" (in Chinese) from a list, the IME sends the
international characters to the application in a user-determined
charset (e.g. GB2312).
2.1.2 Interface between Input Method Editor and MUA Composition
Interface
The MUA mail composition interface (i.e. the "Compose Message"
function of the MUA) SHOULD be able to accept IDNs using 8-bit character
encoding schemes, including those represented in any localized (e.g.
GB2312) or internationalized (e.g. UTF-8) charsets.
This input typically takes place where e-mail addresses are entered
such as the "From", "To", "Cc", "Bcc" fields, amongst others, as IDNs
may be used at the right-hand-side of the "@" sign in an e-mail address
(domain-parts).
The mail composition interface MAY allow ACE input for the same
reasons as specified in [IDNA], but is not recommended as ACE is opaque
and ugly.
2.1.3 Interface between MUA Composition Interface and SMTP Client
The MUA composition interface communicates with the SMTP client in the
MUA typically through internal function calls within the software itself
or through an API. It is at this level where ACE conversion of any IDN
encountered by the MUA composition interface takes place.
Before converting the name parts of the IDN into ACE, the MUA MUST
prepare each name part as specified in [NAMEPREP]. Thereafter, the MUA
MUST convert the name parts into ACE before passing any data to the SMTP
client.
The SMTP client then prepares the e-mail for transmission using the
SMTP protocol [RFC821], and thereafter establishes an SMTP connection
with the user-specified SMTP server to transmit the e-mail.
It is important to note that an IDN specified in the parameters of any
SMTP command MUST be represented in nameprepped ACE at this point in
time. This includes SMTP commands which require domain parameters (such
as the HELO and EHLO commands) and commands where e-mail addresses are
specified (such as the MAIL FROM, RCPT TO, DATA, VRFY, EXPN, SEND, SOML
and SAML commands).
As for data passed by the DATA command, ACE conversion MUST be
performed when the "domain" portion of an "addr-spec" or when a "domain"
itself, within the context of [RFC822], is encountered. This is
necessary as an updated MUA may originate a message which is read by a
non-updated MUA. If this happens, the non-updated MUA may face
operational problems dealing with IDNs that appear in the "addr-spec"
which are not in ACE.
Any transfer encoding syntax to be applied to the mail headers as
specified in [RFC2047] SHOULD be performed before nameprepped ACE
conversion. This is to reduce confusion between IDNs within "addr-spec"
and "domain" portions, in the context of [RFC822], and IDNs which appear
as arbitrary data in mail headers and bodies.
2.1.4. Interface between POP3/IMAP4 client (or local mail store) and
Mail Reading Interface
The MUA mail reading interface (i.e. "Read mail" function of an MUA)
typically displays e-mail data retrieved from either a POP3/IMAP4
client or from a local mail store through internal function calls within
the MUA software or through an API.
When e-mail containing an ACE-represented IDN is to be displayed, the
MUA SHOULD convert the ACE-represented IDN contained within the
"addr-spec" or "domain" portion specified in [RFC822] back into any
localized or internationalized charset of the user's choice, whenever
possible. In the event that it is impossible to achieve conversion back
into the selected localized charset (for example, conversion of RACE-
represented Hangeul characters into ISO-8859-1 is impossible), the MUA
should prompt the user with an error message.
It may be possible to save and retrieve information about the original
charset of the ACE-converted IDN through the use of additional
[RFC822] mail headers, but that is not (yet) addressed by this memo.
Although it is possible to render ACE into properly decoded glyphs and
display the actual abstract characters without any conversion to other
charsets, the MUA SHOULD NOT do this as it is not the primary function
of an MUA to render characters. This should be left to a rendering
engine which is separate from the MUA and typically embedded into the
OS. It is sufficient for the MUA to pass the appropriate charset to the
rendering engine for proper display.
3. ACE Length Considerations
As [RFC821] in Section 4.5.3 restricts the maximum total length of a
domain name to 64 characters, representation of IDNs using ACE may
pose a potential problem. Most ACEs typically require 3-4 ASCII
characters to represent one international character (especially in the
case of CJK characters, where compression is less effective).
That would leave only about 16-24 characters for the whole IDN,
including all name parts and dots. This is highly undesirable as some
languages such as Arabic are unable to be abbreviated and the domain
names may require a larger length than that which is allowed by
[RFC821].
To further complicate matters, several mailing list software such as
ezmlm embed domain names into the local-parts portion of an e-mail
address during management of subscriptions, together with randomly-
generated subscription information. This would leave an even smaller
maximum ACE length, if interoperability with these mailing list software
were to be maintained, given that there is also a 64 character
restriction on local parts.
4. Security Considerations
As this memo is based on [IDNA], security considerations are similar
to that faced by [IDNA]. This includes security considerations from
[NAMEPREP] as well.
5. Other Considerations
Although this document addresses end-user MUAs (e.g. elm, mutt, pine,
Eudora, Outlook Express, etc) to a large extent, the definition of an
MUA could be extended to include web-based e-mail server software and
automated programs such as mailing list management software.
End-user MUAs may also include additional functionality where IDNs may
be encountered, such as calendaring/scheduling, directory services and
digital certificate storage. This is not (yet) addressed in this memo.
6. Future Extensions
It is possible to achieve internationalization of the entire e-mail
address by representation of international characters in the local-parts
of an "addr-spec" using nameprepped ACE conversion in a similar fashion
as described in this memo.
However, this is a different problem altogether and is currently beyond
the scope of this memo.
7. References
[IDNA] Paul Hoffman & Patrik Faltstrom, "Internationalizing Host Names
in Applications (IDNA)", draft-ietf-idn-idna.
[UTR17] K. Whistler & M. Davis, Unicode Consortium, "Character Encoding
Model", Unicode Technical Report #17,
http://www.unicode.org/unicode/reports/tr17/
[US-ASCII] United States of America Standards Institute, "USA Code for
Information Interchange", X3.4, 1968.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare.
[RFC821] Jonathan B. Postel, "Simple Mail Transfer Protocol", August
1982, RFC 821.
[RFC822] David H. Crocker, "Standard for the Format of ARPA Internet
Text Messages", August 1982, RFC 822.
[RFC2045] N. Freed & N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
November 1996, RFC 2045.
[RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", November
1996, RFC 2047.
[RFC1652] J. Klensin et al., "SMTP Service Extension for 8bit-
MIMEtransport", July 1994, RFC 1652.
[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep.
A. Author's Address
Maynard Kang
i-EMAIL.net Pte Ltd
1 Kim Seng Promenade #12-07
Great World City West Tower
Singapore 237994
E-mail: maynard@i-email.net

19
doc/draft/draft-ietf-idn-mua-01.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
M. Kang: maynard@i-mail.net

588
doc/draft/draft-ietf-idn-race-03.txt
View File

@@ -1,588 +0,0 @@
Internet Draft Paul Hoffman
draft-ietf-idn-race-03.txt IMC & VPNC
November 22, 2000
Expires in six months
RACE: Row-based ASCII Compatible Encoding for IDN
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a transformation method for representing
non-ASCII characters in host name parts in a fashion that is completely
compatible with the current DNS. It is a potential candidate for an
ASCII-Compatible Encoding (ACE) for internationalized host names, as
described in the comparison document from the IETF IDN Working Group.
This method is based on the observation that many internationalized
host name parts will have all their characters in one row of the ISO
10646 repertoire.
1. Introduction
There is a strong world-wide desire to use characters other than plain
ASCII in host names. Host names have become the equivalent of business
or product names for many services on the Internet, so there is a need
to make them usable by people whose native scripts are not representable
by ASCII. The requirements for internationalizing host names are
described in the IDN WG's requirements document, [IDNReq].
The IDN WG's comparison document [IDNComp] describes three potential
main architectures for IDN: arch-1 (just send binary), arch-2 (send
binary or ACE), and arch-3 (just send ACE). RACE is an ACE, called
Row-based ACE or RACE, that can be used with protocols that match arch-2
or arch-3. RACE specifies an ACE format as specified in ace-1 in
[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in
[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the
beginning of the name part).
Author's note: although earlier drafts of this document supported the
ideas in arch-3, I no longer support that idea and instead only support
arch-2. Of course, someone else might right an IDN proposal that matches
arch-3 and use RACE as the protocol.
In formal terms, RACE describes a character encoding scheme of the
ISO/IEC 10646 [ISO10646] coded character set (whose assignment of
characters is synchronized with Unicode [Unicode3]) and the rules for
using that scheme in the DNS. As such, it could also be called a
"charset" as defined in [IDNReq].
The RACE protocol has the following features:
- There is exactly one way to convert internationalized host parts to
and from RACE parts. Host name part uniqueness is preserved.
- Host parts that have no international characters are not changed.
- Names using RACE can include more internationalized characters than
with other ACE protocols that have been suggested to date. Names in the
Han, Yi, Hangul syllables, or Ethiopic scripts can have up to 17
characters, and names in most other scripts can have up to 35
characters. Further, a name that consist of characters from one
non-Latin script but also contains some Latin characters such as digits
or hyphens can have close to 33 characters.
It is important to note that the following sections contain many
normative statements with "MUST" and "MUST NOT". Any implementation that
does not follow these statements exactly is likely to cause damage to
the Internet by creating non-unique representations of host names.
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
Hexadecimal values are shown preceded with an "0x". For example,
"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
shown preceded with an "0b". For example, a nine-bit value might be
shown as "0b101101111".
Examples in this document use the notation from the Unicode Standard
[Unicode3] as well as the ISO 10646 names. For example, the letter "a"
may be represented as either "U+0061" or "LATIN SMALL LETTER A".
RACE converts strings with internationalized characters into
strings of US-ASCII that are acceptable as host name parts in current
DNS host naming usage. The former are called "pre-converted" and the
latter are called "post-converted".
1.2 IDN summary
Using the terminology in [IDNComp], RACE specifies an ACE format as
specified in ace-1. Further, it specifies an identifying mechanism for
ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning
of the name part).
RACE has the following length characteristics. In this list, "row" means
a row from ISO 10646.
- If the characters in the input all come from the same row, up to 35
characters per name part are allowed.
- If the characters in the input come from two or more rows, neither of
which is row 0, up to 17 characters per name part are allowed.
- If the characters in the input come from two rows, one of which is row
0, between 17 and 33 characters per name part are allowed.
2. Host Part Transformation
According to [STD13], host parts must be case-insensitive, start and
end with a letter or digit, and contain only letters, digits, and the
hyphen character ("-"). This, of course, excludes any internationalized
characters, as well as many other characters in the ASCII character
repertoire. Further, domain name parts must be 63 octets or shorter in
length.
2.1 Name tagging
All post-converted name parts that contain internationalized characters
begin with the string "bq--". (Of course, because host name parts are
case-insensitive, this might also be represented as "Bq--" or "bQ--" or
"BQ--".) The string "bq--" was chosen because it is extremely unlikely
to exist in host parts before this specification was produced. As a
historical note, in late August 2000, none of the second-level host name
parts in any of the .com, .edu, .net, and .org top-level domains began
with "bq--"; there are many tens of thousands of other strings of three
characters followed by a hyphen that have this property and could be
used instead. The string "bq--" will change to other strings with the
same properties in future versions of this draft.
Note that a zone administrator might still choose to use "bq--" at the
beginning of a host name part even if that part does not contain
internationalized characters. Zone administrators SHOULD NOT create host
part names that begin with "bq--" unless those names are post-converted
names. Creating host part names that begin with "bq--" but that are not
post-converted names may cause two distinct problems. Some display
systems, after converting the post-converted name part back to an
internationalized name part, might display the name parts in a
possibly-confusing fashion to users. More seriously, some resolvers,
after converting the post-converted name part back to an
internationalized name part, might reject the host name if it contains
illegal characters.
2.2 Converting an internationalized name to an ACE name part
To convert a string of internationalized characters into an ACE name
part, the following steps MUST be preformed in the exact order of the
subsections given here.
If a name part consists exclusively of characters that conform to the
host name requirements in [STD13], the name MUST NOT be converted to
LACE. That is, a name part that can be represented without LACE MUST NOT
be encoded using LACE. This absolute requirement prevents there from
being two different encodings for a single DNS host name.
If any checking for prohibited name parts (such as ones that are
prohibited characters, case-folding, or canonicalization) is to be done,
it MUST be done before doing the conversion to an ACE name part.
Characters outside the first plane of characters (those with codepoints
above U+FFFF) MUST be represented using surrogates, as described in the
UTF-16 description in ISO 10646.
The input name string consists of characters from the ISO 10646
character set in big-endian UTF-16 encoding. This is the pre-converted
string.
2.2.1 Check the input string for disallowed names
If the input string consists only of characters that conform to the host
name requirements in [STD13], the conversion MUST stop with an error.
2.2.2 Compress the pre-converted string
The entire pre-converted string MUST be compressed using the compression
algorithm specified in section 2.4. The result of this step is the
compressed string.
2.2.3 Check the length of the compressed string
The compressed string MUST be 36 octets or shorter. If the compressed
string is 37 octets or longer, the conversion MUST stop with an error.
2.2.4 Encode the compressed string with Base32
The compressed string MUST be converted using the Base32 encoding
described in section 2.5. The result of this step is the encoded string.
2.2.5 Prepend "bq--" to the encoded string and finish
Prepend the characters "bq--" to the encoded string. This is the host
name part that can be used in DNS resolution.
2.3 Converting a host name part to an internationalized name
The input string for conversion is a valid host name part. Note that if
any checking for prohibited name parts (such as prohibited characters,
case-folding, or canonicalization is to be done, it MUST be done after
doing the conversion from an ACE name part.
If a decoded name part consists exclusively of characters that conform
to the host name requirements in [STD13], the conversion from LACE MUST
fail. Because a name part that can be represented without LACE MUST NOT
be encoded using LACE, the decoding process MUST check for name parts
that consists exclusively of characters that conform to the host name
requirements in [STD13] and, if such a name part is found, MUST
beconsidered an error (and possibly a security violation).
2.3.1 Strip the "bq--"
The input string MUST begin with the characters "bq--". If it does not,
the conversion MUST stop with an error. Otherwise, remove the characters
"bq--" from the input string. The result of this step is the stripped
string.
2.3.2 Decode the stripped string with Base32
The entire stripped string MUST be checked to see if it is valid Base32
output. The entire stripped string MUST be changed to all lower-case
letters and digits. If any resulting characters are not in Table 1, the
conversion MUST stop with an error; the input string is the
post-converted string. Otherwise, the entire resulting string MUST be
converted to a binary format using the Base32 decoding described in
section 2.5. The result of this step is the decoded string.
2.3.3 Decompress the decoded string
The entire decoded string MUST be converted to ISO 10646 characters
using the decompression algorithm described in section 2.4. The result
of this is the internationalized string.
2.3.4 Check the internationalized string for disallowed names
If the internationalized string consists only of characters that conform
to the host name requirements in [STD13], the conversion MUST stop with
an error.
2.4 Compression algorithm
The basic method for compression is to reduce a full string that
consists of characters all from a single row of the ISO 10646
repertoire, or all from a single row plus from row 0, to as few octets
as possible. Any full string that has characters that come from two
rows, neither of which are row 0, or three or more rows, has all the
octets of the input string in the output string.
If the string comes from only one row, compression is to one octet per
character in the string. If the string comes from only one row other
than row 0, but also has characters only from row 0, compression is to
one octet for the characters from the non-0 row and two octets for the
characters from row 0. Otherwise, there is no compression and the output
is a string that has two octets per input character.
The compressed string always has a one-octet header. If the string comes
from only one row, the header octet is the upper octet of the
characters. If the string comes from only one row other than row 0, but
also has characters only from row 0, the header octet is the upper octet
of the characters from the non-0 row. Otherwise, the header octet is
0xD8, which is the upper octet of a surrogate pair. Design note: It is
impossible to have a legal stream of UTF-16 characters that has all the
upper octets being 0xD8 because a character whose upper octet is 0xD8
must be followed by one whose upper octet is in the range 0xDC through
0xDF.
Although the two-octet mode limits the number of characters in a RACE
name part to 17, this is still generally enough for almost all names in
almost scripts. Also, this limit is close to the limits set by other
encoding proposals.
Note that the compression and decompression rules MUST be followed
exactly. This requirement prevents a single host name part from having
two encodings. Thus, for any input to the algorithm, there is only one
possible output. An implementation cannot chose to use one-octet mode or
two-octet mode using anything other than the logic given in this
section.
2.4.1 Compressing a string
The input string is in big-endian UTF-16 encoding with no byte order
mark.
Design note: No checking is done on the input to this algorithm. It is
assumed that all checking for valid ISO/IEC 10646 characters has already
been done by a previous step in the conversion process.
Design note: In step 5, 0xFF was chosen as the escape character because
it appears in the fewest number of scripts in ISO 10646, and therefore
the "escaped escape" will be needed the least. 0x99 was chosen as the
second octet for the "escaped escape" because the character U+0099 has
no value, and is not even used as a control character in the C1 controls
or in ISO 6429.
1) Starting at the beginning of the input, read each pair of octets in
the input stream, comparing the upper octet of each. Reset the input
pointer to the beginning of the input again. If all of the upper octets
(called U1) are the same, go to step 4. Note that if the input is only
one character, this test will always be true.
2) Read each pair of octets in the input stream, comparing the upper
octet of each. Reset the input pointer to the beginning of the input
again. If all of the upper octets are either 0x00 or one single other
value (called U1), go to step 4.
3) Output 0xD8, followed by the entire input stream. Finish.
4) If U1 is in the range 0xD8 to 0xDC, stop with an error. Otherwise,
output U1.
5) If you are at the end of the input string, finish. Otherwise, read
the next octet, called U2, and the octet after that, called N1. If U2 is
0x00 and N1 is 0x99, stop with an error.
6) If U2 is equal to U1, and N1 is not equal to 0xFF, output N1, and go
to step 5.
7) If U2 is equal to U1, and N1 is equal to 0xFF, output 0xFF followed
by 0x99, and go to step 5.
8) Output 0xFF followed by N1. Go to step 5.
2.4.2 Decompressing a string
1) Read the first octet of the input string. Call the value of the first
octet U1. If there are no more octets in the input string (that is, if
the input string had only one octet total), stop with an error. If U1 is
0xD8, go to step 8.
2) If you are at the end of the input string, go to step 11. Otherwise,
read the next octet in the input string, called N1. If N1 is 0xFF, go to
step 5.
3) If U1 is 0x00 and N1 is 0x99, stop with an error.
4) Put U1 followed by N1 in the output buffer. Go to step 2.
5) If you are at the end of the input string, stop with an error.
6) Read the next octet of the input string, called N1. If N1 is 0x99,
put U1 followed by 0xFF in the output buffer, and go to step 2.
7) Put 0x00 followed by N1 in the output buffer. Go to step 2.
8) Read the rest of the input stream into a temporary string called
LCHECK. If the length of LCHECK is an odd number, stop with an error.
9) Perform the checks from steps 1 and 2 of the compression algorithm in
section 2.4.1 on LCHECK. If either checks pass (that is, if either would
have created a compressed string), stop with an error because the input
to the decompression is in the wrong format.
10) If the length of LCHECK is odd, stop with and error. Otherwise,
output LCHECK and finish.
11) If the length of the output buffer is odd, stop with and error.
Otherwise, emit the output buffer and finish.
2.4.3 Compression examples
For the input string of <U+012D><U+0111><U+014B>, all characters are in
the same row, 0x01. Thus, the output is 0x012D114B.
For the input string of <U+012D><U+00E0><U+014B>, the characters are all
in row 0x01 or row 0x00. Thus, the output is 0x012DFFE04B.
For the input string of <U+1290><U+12FF><U+120C>, the characters are all
in row 0x12. Thus, the output is 0x1290FF990C.
For the input string of <U+012D><U+00E0><U+24D3>, the characters are
from two rows other than 0x00. Thus, the output is 0xD8012D00E024D3.
2.5 Base32
In order to encode non-ASCII characters in DNS-compatible host name parts,
they must be converted into legal characters. This is done with Base32
encoding, described here.
Table 1 shows the mapping between input bits and output characters in
Base32. Design note: the digits used in Base32 are "2" through "7"
instead of "0" through "6" in order to avoid digits "0" and "1". This
helps reduce errors for users who are entering a Base32 stream and may
misinterpret a "0" for an "O" or a "1" for an "l".
Table 1: Base32 conversion
bits char hex bits char hex
00000 a 0x61 10000 q 0x71
00001 b 0x62 10001 r 0x72
00010 c 0x63 10010 s 0x73
00011 d 0x64 10011 t 0x74
00100 e 0x65 10100 u 0x75
00101 f 0x66 10101 v 0x76
00110 g 0x67 10110 w 0x77
00111 h 0x68 10111 x 0x78
01000 i 0x69 11000 y 0x79
01001 j 0x6a 11001 z 0x7a
01010 k 0x6b 11010 2 0x32
01011 l 0x6c 11011 3 0x33
01100 m 0x6d 11100 4 0x34
01101 n 0x6e 11101 5 0x35
01110 o 0x6f 11110 6 0x36
01111 p 0x70 11111 7 0x37
2.5.1 Encoding octets as Base32
The input is a stream of octets. However, the octets are then treated
as a stream of bits.
Design note: The assumption that the input is a stream of octets
(instead of a stream of bits) was made so that no padding was needed.
If you are reusing this algorithm for a stream of bits, you must add a
padding mechanism in order to differentiate different lengths of input.
1) If the input bit stream is not an even multiple of five bits, pad
the input stream with 0 bits until it is an even multiple of five bits.
Set the read pointer to the beginning of the input bit stream.
2) Look at the five bits after the read pointer.
3) Look up the value of the set of five bits in the bits column of
Table 1, and output the character from the char column (whose hex value
is in the hex column).
4) Move the read pointer five bits forward. If the read pointer is at
the end of the input bit stream (that is, there are no more bits in the
input), stop. Otherwise, go to step 2.
2.5.2 Decoding Base32 as octets
The input is octets in network byte order. The input octets MUST be
values from the second column in Table 1.
1) Count the number of octets in the input and divide it by 8; call the
remainder INPUTCHECK. If INPUTCHECK is 1 or 3 or 6, stop with an error.
2) Set the read pointer to the beginning of the input octet stream.
3) Look up the character value of the octet in the char column (or hex
value in hex column) of Table 1, and add the five bits from the bits
column to the output buffer.
4) Move the read pointer one octet forward. If the read pointer is not
at the end of the input octet stream (that is, there are more octets in
the input), go to step 3.
5) Count the number of bits that are in the output buffer and divide it
by 8; call the remainder PADDING. If the PADDING number of bits at the
end of the output buffer are not all zero, stop with an error.
Otherwise, emit the output buffer and stop.
2.5.3 Base32 example
Assume you want to encode the value 0x3a270f93. The bit string is:
3 a 2 7 0 f 9 3
00111010 00100111 00001111 10010011
Broken into chunks of five bits, this is:
00111 01000 10011 10000 11111 00100 11
Padding is added to make the last chunk five bits:
00111 01000 10011 10000 11111 00100 11000
The output of encoding is:
00111 01000 10011 10000 11111 00100 11000
h i t q 7 e y
or "hitq7ey".
3. Security Considerations
Much of the security of the Internet relies on the DNS. Thus, any
change to the characteristics of the DNS can change the security of
much of the Internet. Thus, RACE makes no changes to the DNS
itself.
Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers
based on different interpretations of the internationalized host
name.
RACE is designed so that every internationalized host name part
can be represented as one and only one DNS-compatible string. If there
is any way to follow the steps in this document and get two or more
different results, it is a severe and fatal error in the protocol.
4. References
[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals",
draft-ietf-idn-compare.
[IDNReq] James Seng, "Requirements of Internationalized Domain Names",
draft-ietf-idn-requirement.
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane. Five amendments and
a technical corrigendum have been published up to now. UTF-16 is
described in Annex Q, published as Amendment 1. 17 other amendments are
currently at various stages of standardization. [[[ THIS REFERENCE
NEEDS TO BE UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[STD13] Paul Mockapetris, "Domain names - implementation and
specification", November 1987, STD 13 (RFC 1035).
[Unicode3] 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>.
A. Acknowledgements
Mark Davis contributed many ideas to the initial draft of this document,
as well as comments in later versions. Graham Klyne and Martin Duerst
offered technical comments on the algorithms used. GIM Gyeongseog and
Pongtorn Jentaweepornkul helped fix technical errors in early drafts.
Rick Wesson and Mark Davis contributed many suggestions on error
conditions in the processing.
Base32 is quite obviously inspired by the tried-and-true Base64
Content-Transfer-Encoding from MIME.
B. Changes from Versions -02 to -03 of this Draft
1: Wording corrections to third paragraph.
2.2 and 2.3: Added need to check for all-STD13.
2.4.1: Wording corrections in the first two paragraphs. Made step 1 and
2 clearer with resetting the input pointer. Also added sentence at the
end of step 1. Also added error conditions in steps 4 and 5.
2.4.2: Added error condition in step 1. Added a new step 3 for an error
check. Expanded step 8 to check for malformed input error. Added error
check for odd-length output.
2.4.3: Changed all the examples to use lowercase characters on input.
2.5.1: Made the list of steps shorter by padding with 0 bits at the
beginning of the steps.
2.5.2: Changed the sense of the test in step 3 and added step 4 to be
checkfor malformed input. Also made the output a buffer. Also added
new step 1.
C. IANA Considerations
There are no IANA considerations in this document.
D. Author Contact Information
Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
paul.hoffman@imc.org and paul.hoffman@vpnc.org

19
doc/draft/draft-ietf-idn-race-04.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
P. Hoffman: paul.hoffman@vpnc.org

172
doc/draft/draft-ietf-idn-udns-02.txt → doc/draft/draft-ietf-idn-udns-03.txt
View File

@@ -1,7 +1,7 @@
Internet Draft Dan Oscarsson
draft-ietf-idn-udns-02.txt Telia ProSoft
Updates: RFC 2181, 1035, 1034, 2535 24 February
2001 Expires: 24 August 2001
Internet Draft Dan Oscarsson
draft-ietf-idn-udns-03.txt Telia ProSoft
Updates: RFC 2181, 1035, 1034, 2535 19 August 2001
Expires: 19 February 2002
Using the Universal Character Set in the Domain Name System (UDNS)
@@ -31,14 +31,11 @@ Abstract
Since the Domain Name System (DNS) [RFC1035] was created there have
been a desire to use other characters than ASCII in domain names.
Lately this desire have grown very strong and several groups have
started to experiment with non-ASCII names.
This document defines how the Universal Character Set (UCS)
[ISO10646] is to be used in DNS.
It includes both a transition scheme for older software supporting
non-ASCII handling in applications only, as well as how to use UCS in
labels and having more than 63 octets in a label.
started to experiment with non-ASCII names. This document defines
how the Universal Character Set (UCS) [ISO10646] is to be used in
DNS. It includes both a transition scheme for older software
supporting non-ASCII handling in applications only, as well as how to
use UCS in labels and having more than 63 octets in a label.
1. Introduction
@@ -46,17 +43,17 @@ Abstract
While the need for non-ASCII domain names have existed since the
creation of the DNS, the need have increased very much during the
last few years. Currently there are at least two implementations
Dan Oscarsson Expires: 24 August 2001 [Page 1]
Internet Draft Universal DNS 24 February 2001
using UTF-8 in use, and others using other methods.
To avoid several different implementations of non-ASCII names in DNS
Dan Oscarsson Expires: 19 February 2002 [Page 1]
Internet Draft Universal DNS 19 August 2001
that do not work together, and to avoid breaking the current ASCII
only DNS, there is an immediate need to standardise how DNS shall
handle non-ASCII names.
@@ -83,6 +80,8 @@ Internet Draft Universal DNS 24 February 2001
1.2 Previous versions of this document
This version contains just minor corrections to the 4:th version.
The third version of this document included a way to return both
ASCII and non-ASCII versions of a name. As this could not be
guaranteed to work it has been removed.
@@ -102,15 +101,15 @@ Internet Draft Universal DNS 24 February 2001
format of zone files or how to enter or display domain names are not
part of the protocol.
Dan Oscarsson Expires: 24 August 2001 [Page 2]
Internet Draft Universal DNS 24 February 2001
The update of the protocol defined here can be used immediately as it
Dan Oscarsson Expires: 19 February 2002 [Page 2]
Internet Draft Universal DNS 19 August 2001
is fully compatible with the DNS of today.
For a long time there will be software understanding UCS in DNS and
@@ -122,7 +121,7 @@ Internet Draft Universal DNS 24 February 2001
- UDNS unaware client, UDNS aware DNS server
- UDNS aware client, UDNS unaware DNS server
- UDNS aware client, UDNS unaware DNS server
- UDNS aware client, UDNS aware DNS server
2.1 Fundamentals
@@ -161,9 +160,10 @@ Internet Draft Universal DNS 24 February 2001
Dan Oscarsson Expires: 24 August 2001 [Page 3]
Dan Oscarsson Expires: 19 February 2002 [Page 3]
Internet Draft Universal DNS 24 February 2001
Internet Draft Universal DNS 19 August 2001
To handle form-insensitivity it is here defined the Binary Comparison
@@ -202,10 +202,26 @@ Internet Draft Universal DNS 24 February 2001
document. Typical definitions that are suitable are [SACE] and
[RACE].
The reason that the BCF form of the label is used is to support
solutions where only applications know about non-ASCII labels. By
using BCF the server need not know about UCS and can just do binary
matching so it can be handled in old servers. Though due to the fact
that BCF destroys information contained in the original form of a
label it is impossible to return the original form to a client using
BCE.
2.1.4 Long names
The current DNS protocol limits a label to 63 octets. As UTF-8 take
more than one octet for some characters, an UTF-8 name cannot have 63
Dan Oscarsson Expires: 19 February 2002 [Page 4]
Internet Draft Universal DNS 19 August 2001
characters in a label like an ASCII name can. For example a name
using Hangul would have a maximum of 21 characters.
@@ -214,14 +230,6 @@ Internet Draft Universal DNS 24 February 2001
simplify implementations.
To support longer names a long label type is defined using [RFC2671]
Dan Oscarsson Expires: 24 August 2001 [Page 4]
Internet Draft Universal DNS 24 February 2001
as extended label 0b000011 (the label type will be assigned by IANA
and may not be the number used here).
@@ -262,6 +270,14 @@ Internet Draft Universal DNS 24 February 2001
others.
The effect of the above is:
Dan Oscarsson Expires: 19 February 2002 [Page 5]
Internet Draft Universal DNS 19 August 2001
- only servers handling authorative data must implement form-
insensitive matching of names. And they need only implement the
subset needed for the subset of characters of UCS they support in
@@ -270,14 +286,6 @@ Internet Draft Universal DNS 24 February 2001
resolver <-> server <-> authorative server.
While form-insensitive matching can be complex and CPU consuming,
the server in the middle will do caching with only simple and fast
Dan Oscarsson Expires: 24 August 2001 [Page 5]
Internet Draft Universal DNS 24 February 2001
binary matching. So the impact of complex matching rules should
not slow down DNS very much.
@@ -319,6 +327,13 @@ Internet Draft Universal DNS 24 February 2001
2.3.3 non-UDNS aware client
Dan Oscarsson Expires: 19 February 2002 [Page 6]
Internet Draft Universal DNS 19 August 2001
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.
@@ -326,14 +341,6 @@ Internet Draft Universal DNS 24 February 2001
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
@@ -375,6 +382,14 @@ Internet Draft Universal DNS 24 February 2001
in ASCII or by tagged character sets should be avoided.
DNS do not only have domain names in them, for example e-mail
Dan Oscarsson Expires: 19 February 2002 [Page 7]
Internet Draft Universal DNS 19 August 2001
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.
@@ -382,14 +397,6 @@ Internet Draft Universal DNS 24 February 2001
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
@@ -431,6 +438,14 @@ Internet Draft Universal DNS 24 February 2001
[UTR15] M. Davis and M. Duerst, "Unicode Normalization Forms",
Unicode Technical Report #15, Nov 1999,
Dan Oscarsson Expires: 19 February 2002 [Page 8]
Internet Draft Universal DNS 19 August 2001
http://www.unicode.org/unicode/reports/tr15/.
[UTR21] M. Davis, "Case Mappings", Unicode Technical Report #21,
@@ -438,14 +453,6 @@ Internet Draft Universal DNS 24 February 2001
[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.
@@ -488,20 +495,19 @@ Internet Draft Universal DNS 24 February 2001
Dan Oscarsson Expires: 19 February 2002 [Page 9]
Internet Draft Universal DNS 19 August 2001
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: Dan.Oscarsson@trab.se
@@ -547,11 +553,5 @@ Internet Draft Universal DNS 24 February 2001
Dan Oscarsson Expires: 24 August 2001 [Page 10]
Dan Oscarsson Expires: 19 February 2002 [Page 10]

269
doc/draft/draft-ietf-idn-uri-00.txt
View File

@@ -1,269 +0,0 @@
INTERNET-DRAFT Martin Duerst
draft-ietf-idn-uri-00 W3C/Keio University
Expires July 2001 January 6, 2001
Internationalized Domain Names in URIs and IRIs
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document is a first draft for the provisions necessary to
upgrade the definitions of URIs [RFC 2396] and IRIs (Internationalized
Resource Identifiers, [IRI]) to work with internationalized domain
names.
1. Introduction
Internet domain names serve to identify hosts and services on the
Internet in a convenient way. The IETF IDN working group is currently
working on extending the character repertoire usable in domain names
beyond a subset of US-ASCII.
One of the most important places where domain names appear are
Uniform Resource Identifiers (URIs, [RFC 2396], as modified by
[RFC2732]). However, in the current definition of the generic URI
syntax, the restrictions on domain names are 'hard-coded'. This
document proposes to relax these restrictions by updating the syntax,
and defines how internationalized domain names are encoded in URIs.
URIs themselves are restricted to a subset of US-ASCII. However,
there is a proposal for relieving these restrictions by creating
a new protocol element called an IRI (Internationalized Resource
Identifier [IRI]). While IRIs in general allow the use of non-ASCII
characters, the syntax of IRIs has the same restriction for domain
names as the syntaxt of URIs. This document proposes to relax these
restrictions, too, in a way that is compatible with the new syntax
for URIs. This means that encoding an internationalized domain name in
an URI and encoding the same name in an IRI will produce an URI and an
IRI that can be converted into each other using the procedures defined
in [IRI] for these conversions.
2. URI syntax changes
The syntax of URIs [RFC2326] currently contains the following rules
relevant to domain names:
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
The later two rules are changed as follows:
domainlabel = escalphanum | escalphanum *( escalphanum | "-" )
escalphanum
toplabel = escalpha | escalpha *( escalphanum | "-" )
escalphanum
and the following rules are added:
escalphanum = escaped8 | alphanum
escalpha = elcaped8 | alpha
escaped8 = "%" hexdig8 HEXDIG
hexdig8 = <<HEXDIG greater than 7>>
The %HH escaping is used to encode characters outside the repertoire
of US-ASCII. This is done by first encoding the characters in UTF-8
[RFC 2279], resulting in a sequence of octets, and then escaping these
octets.
Using UTF-8 assures that this encoding interoperates with IRIs (see
Section 3). It is also alligned with the recommendations in [RFC 2277]
and [RFC 2718], and is consistent with the URN syntax [RFC2141] as
well as recent URL scheme definitions that define encodings of
non-ASCII characters based on (e.g., IMAP URLs [RFC 2192] and POP URLs
[RFC 2384]).
Please note that the use of UTF-8 for encoding internationalized
domain names in URIs is independent of the choice of encoding chosen
for these names in the DNS protocol. In case something else than UTF-8
is chosen for the later, a future version of this document may give
instructions for the conversion if deemed necessary.
The above syntax rules do not extend the possible domain names based
on US-ASCII characters. This may have to be changed in case the IDN
WG should decide to allow such extensions.
The above rules also do not allow escaping of US-ASCII characters,
although this is allowed in the other parts of an URI (except for the
special provisions in case of reserved characters). Allowing such
escaping would make the syntax rules quite a bit more complicated,
would mean that the restrictions on US-ASCII characters can be
circumvented by using escaping, or would lead to much simpler syntax
rules that don't express these restrictions anymore. Even in case
escaping of US-ASCII characters is allowed in order to simplify
processing, it should be noted that it is always better not to escape
US-ASCII characters in domain names because of the possibility that
a resolver cannot unescape them. At least purely US-ASCII domain names
would then always be resolved by such a processor.
While only the restrictions on US-ASCII characters are expressed in the
rules above, all the other restrictions on internationalized
domain names that will be defined by the IDN WG MUST be respected.
The work of the IDN WG currently includes some procedures for name
preparation. Before encoding an internationalized domain name in an
URI, this preparation step SHOULD be applied. However, the resolver
MUST also apply name preparation.
2. IRI syntax changes
The syntax of IRIs [IRI] currently contains the following rules
relevant to domain names:
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
The later two rules are changed as follows:
domainlabel = intalphanum | intalphanum *( intalphanum | "-" )
intalphanum
toplabel = intalpha | intalpha *( intalphanum | "-" )
intalphanum
and the following rules are added:
intalphanum = ichar | alphanum | escaped8
intalpha = ichar | alpha | escaped8
escaped8 = "%" hexdig8 HEXDIG
hexdig8 = <<HEXDIG greater than 7>>
where ichar, as in [IRI], is:
ichar = << any character of UCS [ISO10646] beyond
U+0080, subject to limitations in Section
3.1. of [IRI] >>
With respect to the allowed domain names based on US-ASCII characters,
the same considerations as in Section 2 apply.
As in Section 2, all the other restrictions on internationalized
domain names that will be defined by the IDN WG MUST be respected.
Also, before encoding an internationalized domain name in an IRI,
name preparation SHOULD be applied. However, the IRI resolver MUST
also apply name preparation.
It is expected that the rules in Section 3.1 of [IRI] will be less
restrictive than the rules for internationalized domain names, so that
no escaping is necessary. Nevertheless, escaping is allowed for cases
where not all characters can be directly represented.
4. Security Considerations
Besides the security considerations of [RFC 2396] and [IRI] and those
applying to the various aspects of internationalized domain names in
general, there are currently no known security problems.
Acknowledgements
To be done.
Copyright
Copyright (C) The Internet Society, 1997. 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."
Author's address
Martin J. Duerst
W3C/Keio University
5322 Endo, Fujisawa
252-8520 Japan
duerst@w3.org
http://www.w3.org/People/D%C3%BCrst/
Tel/Fax: +81 466 49 1170
Note: Please write "Duerst" with u-umlaut wherever
possible, e.g. as "D&#252;rst" in XML and HTML.
References
[IRI] L. Masinter, M. Duerst, "Internationalized Resource Identifiers
(IRI)", Internet Draft, January 2001,
<http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-06.txt>,
work in progress.
[ISO10646] ISO/IEC, Information Technology - Universal Multiple-Octet
Coded Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane, Oct. 2000, with amendments.
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2141] R. Moats, "URN Syntax", May 1997.
[RFC 2192] C. Newman, "IMAP URL Scheme", September 1997.
[RFC 2277] H. Alvestrad, "IETF Policy on Character Sets and
Languages".
[RFC 2279] F. Yergeau. "UTF-8, a transformation format of ISO 10646.",
January 1998.
[RFC 2384] R. Gellens, "POP URL Scheme", August 1998.
[RFC 2396] T.Berners-Lee, R.Fielding, L.Masinter. "Uniform Resource
Identifiers (URI): Generic Syntax." August, 1998.
[RFC 2640] B. Curtis, "Internationalization of the File Transfer
Protocol", July 1999.
[RFC 2718] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke,
"Guidelines for new URL Schemes", November 1999.
[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
IPv6 Addresses in URL's", December 1999.

19
doc/draft/draft-ietf-idn-uri-01.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
M. Duerst: mduerst@w3.org

451
doc/draft/draft-ietf-idn-utf6-00.txt
View File

@@ -1,451 +0,0 @@
Internet Engineering Task Force (IETF) Mark Welter
INTERNET-DRAFT Brian W. Spolarich
draft-ietf-idn-utf6-00 WALID, Inc.
November 16, 2000 Expires May 16, 2001
UTF-6 - Yet Another ASCII-Compatible Encoding for IDN
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this document is unlimited.
Copyright (c) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes a tranformation method for representing
Unicode character codepoints in host name parts in a fashion that is
completely compatible with the current Domain Name System. It is
proposed as a potential candidate for an ASCII-Compatible Encoding (ACE)
for supporting the deployment of an internationalized Domain Name System.
The tranformation method, an extension of the UTF-5 encoding proposed by
Duerst, provides both for more efficient representation of typical Unicode
sequences while preserving simplicity and readability. This transformation
method is deployed as part of the current WALID multilingual domain name
system implementation, although that status should not necessarily influence
the evaluation of its merits as a candidate encoding method.
Table of Contents
1. Introduction
1.1 Terminology
2. Hostname Part Transformation
2.1 Post-Converted Name Prefix
2.2 Hostname Prepartion
2.3 Definitions
2.4 UTF-6 Encoding
2.4.1 Variable Length Hex Encoding
2.4.2 UTF-6 Compression Algorithm
2.4.3 Forward Transformation Algorithm
2.5 UTF-6 Decoding
2.5.1 Variable Length Hex Decoding
2.5.2 UTF-6 Decompression Algorithm
2.5.3 Reverse Transformation Algorithm
3. Examples
3.1 'www.walid.com' (in Arabic)
4. Security Considerations
5. References
1. Introduction
UTF-6 describes an encoding scheme of the ISO/IEC 10646 [ISO10646]
character set (whose character code assignments are synchronized
with Unicode [UNICODE3]), and the procedures for using this scheme
to transform host name parts containing Unicode character sequences
into sequences that are compatible with the current DNS protocol
[STD13]. As such, it satisfies the definition of a 'charset' as
defined in [IDNREQ].
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
Hexadecimal values are shown preceded with an "0x". For example,
"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
shown preceded with an "0b". For example, a nine-bit value might be
shown as "0b101101111".
Examples in this document use the notation from the Unicode Standard
[UNICODE3] as well as the ISO 10646 names. For example, the letter "a"
may be represented as either "U+0061" or "LATIN SMALL LETTER A".
UTF-6 converts strings with internationalized characters into
strings of US-ASCII that are acceptable as host name parts in current
DNS host naming usage. The former are called "pre-converted" and the
latter are called "post-converted". This specification defines both
a forward and reverse transformation algorithm.
2. Hostname Part Transformation
According to [STD13], hostname parts must be case-insensitive, start and
end with a letter or digit, and contain only letters, digits, and the
hyphen character ("-"). This, of course, excludes most characters used
by non-English speakers, characters, as well as many other characters in
the ASCII character repertoire. Further, domain name parts must be
63 octets or shorter in length.
2.1 Post-Converted Name Prefix
This document defines the string 'wq--' as a prefix to identify
UTF-6-encoded sequences. For the purposes of comparison in the IDN
Working Group activities, the 'wq--' prefix should be used solely to
identify UTF-6 sequences. However, should this document proceed beyond
draft status the prefix should be changed to whatever prefix, if any,
is the final consensus of the IDN working group.
Note that the prepending of a fixed identifier sequence is only one
mechanism for differentiating ASCII character encoded international
domain names from 'ordinary' domain names. One method, as proposed in
[IDNRACE], is to include a character prefix or suffix that does not
appear in any name in any zone file. A second method is to insert a
domain component which pushes off any international names one or more
levels deeper into the DNS heirarchy. There are trade-offs between
these two methods which are independent of the Unicode to ASCII
transcoding method finally chosen. We do not address the international
vs. 'ordinary' name differention issue in this paper.
2.2 Hostname Prepartion
The hostname part is assumed to have at least one character disallowed
by [STD13], and that is has been processed for logically equivalent
character mapping, filtering of disallowed characters (if any), and
compatibility composition/decomposition before presentation to the UTF-6
conversion algorithm.
While it is possible to invent a transcoding mechanism that relies
on certain Unicode characters being deemed illegal within domain names
and hence available to the transcoding mechanism for improving encoding
efficiency, we feel that such a proposal would complicate matters
excessively. We also believe that Unicode name preprocessing for
both name resolution and name registration should be considered as s
separate, independent issues, which we will attempt to address in a
separate document.
2.3 Definitions
For clarity:
'integer' is an unsigned binary quantity;
'byte' is an 8-bit integer quantity;
'nibble' is a 4-bit integer quantity.
2.4 UTF-6 Encoding
The idea behind this scheme was to improve on the UTF-5 transformation
algorithm described in [IDNDUERST] by providing a straightforward
compression mechanism. UTF-6 defines a compression mechanism by
indentifying identical leading byte or nibble values in the pre-converted
string, and using the length of this leading value to select a mask which
can be applied to the pre-converted string. The resulting post-converted
string is preserves the simplicity and readability of UTF-5 while
enabling longer sequences to be encoded into a single host name part.
2.4.1 Variable Length Hex Encoding
The variable length hex encoding algorithm was introduced by Duerst in
[IDNDUERST]. It encodes an integer value in a slight modification of
traditional hexadecimal notation, the difference being that the most
significant digit is represented with an alternate set of "digits"
- -- 'g through 'v' are used to represent 0 through 15. The result is a
variable length encoding which can efficiently represent integers of
arbitrary length.
The variable length nibble encoding of an integer, C, is defined
as follows:
1. Skip over leading non-significant zero nibbles to find I,
the first significant nibble of c;
2. Emit the Ith character of the set [ghijklmopqrstuv];
3. Continue from most to least significant, encoding each remaining
nibble J by emitting the Jth character of the set [0123456789abcdef].
Examples:
0x1f4c is encoded as "hf4c"
0x0624 is encoded as "m24"
0x0000 is encoded as "g"
'n' a single character in single quotes stands for the
Unicode code point for that character.
2.4.2 UTF-6 Compression Algorithm
UTF-6 improves on the UTF-5 encoding by providing compression, which
enables encoding of a larger number of characters in each hostname
part. The compression algorithm is defined as follows:
1. Set the mask to 0xFFFF;
2. If the number of non '-' characters is less than 2, proceed to
step 5;
3. If the most significant byte of every non '-' character is the
same value:
3a. Set HB to this value;
3b. Emit 'Y';
3c. Emit the variable length hex encoding of HB;
3d. Set the mask to 0x00FF;
3e. Proceed to step 5.
4. If the most significant nibble of every non '-' character is the
same value:
4a. Set HN to this value;
4b. Emit 'Z';
4c. Emit the variable length hex encoding of HN;
4d. Set the mask to 0x0FFF.
5. Foreach input character:
5a. Set HN to the result of the bitwise AND of the input
character and the mask;
5b. Emit the variable length nibble encoding of HN.
2.4.3 Forward Transformation Algorithm
The UTF-6 transformation algorithm accepts a string in UTF-16
[ISO10646] format as input. The encoding algorithm is as follows:
1. Break the hostname string into dot-separated hostname parts.
For each hostname part, perform steps 2 and 3 below;
2. Compress the component using the method described in section
2.4.2 above, and encode using the encoding described in section 2.4.1;
3. Prepend the post-converted name prefix 'wq--' (see section 2.1
above) to the resulting string.
2.5 UTF-6 Decoding
2.5.1 Variable Length Hex Decoding
1. Let N be the lower case of the first input character;
If N is not in set [ghijklmnopqrstuv] return error,
else consume the input character;
2. Let R = N - 'g';
3. If another input character exists,
then let N be the lower case of the next input character,
else goto Step 9;
4. If N is not in the set [0123456789abcdef], go to Step 9;
5. Let N = the lower case of the next input character and consume
the input character;
6. Let R = R * 16;
7. If N is in set [0123456789],
then let R = R + (N - '0'),
else let R = R + (N - 'a') + 10;
8. Go to step 3;
9. Return decoded result R.
2.5.2 UTF-6 Decompression Algorithm
1. Let N be the lower case of the first input character;
2. If N != 'y' and N != 'z',
2a. Let CPART be 0;
2b. Let VMAX be 0xFFFF;
This is the no-compression case;
3. If N == 'y',
3a. Let M be the variable length hex decoding of the next
character;
3b. Let CPART be the result of M * 0x0100;
3c. Let VMAX be 0x00FF;
3d. Continue to Step 5;
4. If N == 'z',
4a. Let M be the variable length hex decoding of the next
character;
4b. Let CPART be the result of M * 0x1000;
4c. Let VMAX be 0x0FFF;
4d. Continue to Step 5;
5. While another input character exists, let N be the lower case of
the next input character, and do the following:
5a. If N == '-' consume the character and
then append '-' to the result string,
else let VPART be the next variable hex decoded value;
5b. If VPART > VMAX, return error,
else append CPART + VPART to the result string;
6. Return the result string.
2.5.3 Reverse Transformation Algorithm
1. Break the string into dot-separated components and apply Steps
2 through 4 to each component:
2. Check for legality (in terms of RFC1035 permitted characters) and
return error status if illegal,
3. Remove the post converted name prefix 'wq--' (see Section 2.1),
4. Decompress the component using the decompression algorithm
described above.
5. Concatenate the decoded segments with dot separators and return.
3. Examples
The examples below illustrate the encoding algorithm and provide
comparisons to alternate encoding schemes. UTF-5 sequences are
prefixed with '----', as no ACE prefix was defined for that encoding.
3.1 'www.walid.com' (in Arabic):
UTF-16: U+0645 U+0648 U+0642 U+0639 . U+0648 U+0644 U+064A U+062F .
U+0634 U+0631 U+0643 U+0629
UTF-6: wq--ymk5k8k2j9.wq--ymk8k4kaif.wq--ymj4j1k3i9
UTF-5: ----m45m48m42m39.----m48m44m4am2f.----m34m31m43m29
RACE: bq--azcuqqrz.bq--azeeisrp.bq--ay2dcqzj
LACE: bq--aqdekscche.bq--aqdeqrckf5.bq--aqddimkdfe
3.2 Mixed Katakana and Hiragana (SOREZORENOBASHO)
UTF-16: U+305D U+308C U+305E U+308C U+306E U+5834 U+6240
UTF-6:
UTF-5:
RACE: bq--4ayf3memgbpdbdbqnzmdiysa
LACE: bq--auyf4dc7rrxacwbuafrea
3.3 Currently Disallowed ASCII Characters ($OneBillionDollars!):
UTF-16: U+0024 U+004F U+006E U+0065 U+0042 U+0069 U+006C U+006C
U+0069 U+006F U+006E U+0044 U+006F U+006C U+006C U+0061
U+0072 U+0073 U+0021
UTF-6:
UTF-5:
RACE: bq--aase74tfijuwy4djn6xei44mnrqxe5zb
LACE: bq--cmacit4omvbgs4dmnfxw5rdpnrwgc5ttee
4. Security Considerations
Much of the security of the Internet relies on the DNS and any
change to the characteristics of the DNS may change the security of
much of the Internet. Therefore UTF-6 makes no changes to the DNS itself.
UTF-6 is designed so that distinct Unicode sequences map to distinct
domain name sequences (modulo the Unicode and DNS equivalence rules).
Therefore use of UTF-6 with DNS will not negatively affect security.
5. References
[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare.
[IDNREQ] James Seng, "Requirements of Internationalized Domain Names",
draft-ietf-idn-requirement.
[IDNNAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep
[IDNDUERST] M. Duerst, "Internationalization of Domain Names",
draft-duerst-dns-i18n.
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane. Five amendments and
a technical corrigendum have been published up to now. UTF-16 is
described in Annex Q, published as Amendment 1. 17 other amendments are
currently at various stages of standardization.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[STD13] Paul Mockapetris, "Domain names - implementation and
specification", November 1987, STD 13 (RFC 1035).
[UNICODE3] 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>.
A. Acknowledgements
The structure (and some of the structural text) of this document is
intentionally borrowed from the LACE IDN draft (draft-ietf-idn-lace)
by Mark Davis and Paul Hoffman.
The 'SOREZORENOBASHO' example was taken from draft-ietf-idn-brace draft
by Adam Costello.
B. IANA Considerations
There are no IANA considerations in this document.
C. Author Contact Information
Mark Welter
Brian W. Spolarich
WALID, Inc.
State Technology Park
2245 S. State St.
Ann Arbor, MI 48104
+1-734-822-2020
mwelter@walid.com
briansp@walid.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6FaCt/DkPcNgtD/0RAtRmAJwISVeJGY6qmll71mL+Axc51o8iIwCgmNt/
86RcQh1JQYWTux+8FS+XvMU=
=bxiv
-----END PGP SIGNATURE-----

20
doc/draft/draft-ietf-idn-utf6-01.txt Normal file
View File

@@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
B. Spolarich: briansp@ans.net
M. Welter: mwelter@walid.com

254
doc/draft/draft-ietf-idn-version-00.txt
View File

@@ -1,254 +0,0 @@
Internet Draft Marc Blanchet
draft-ietf-idn-version-00.txt Viagenie
October 26, 2000
Expires in six
months
Handling versions of internationalized domain names protocols
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes some issues related to handling changes in the
codepoints and other features in the chars space of an internationalized
domain name as well as changes in the protocol that supports it (whatever
that be). It also presents some solutions to these issues.
1. Rationale
The nameprep draft [NAMEPREP] is defining prohibited chars, normalization
algorithms, etc.. The current concensus is to take the safer approach of
not accepting new chars if they are not listed, since the new characters
that can be included in the subsequent releases of the universal character
set can have an impact on the domain name (for example, a new variation of
the dot . will mostly be non-compatible and being excluded).
The Unicode and ISO-10646 versioning is designed not for the same purpose
as the idn work: for example, some chars or properties can be changed or
added to those repertoires that cannot be taken as is by the idn
protocol. In essence, the idn nameprep versions cannot be in sync with
unicode/iso versions. idn need its own versioning of the accepted character
set, which can or cannot be synchronized with the two others. While saying
that, there is no intent at all to define new codepoints inside this work
and any attempt to do that must be rejected.
Since internationalization and specifically internationalization of the
domain names is new, we don't really know if the chosen algorithm, protocol
and codepoitns will not have any problem in the future. We need to handle
versions of the protocol and to have a specific table for idn accepted chars.
2. Versioning of the protocol
Since the idn table of chars will be changed in the future, and possibly
the algorithms and the processing, then there is a need to handle these
situations in a controlled way. A version of the idn protocol should be
defined and included as part of the exchange between the parties so that
they can handle smoothly the new revisions.
2.1 Implementing the version in the protocol
Depending on which way the idn protocol will be, a different versioning
will have to be defined. We will discuss the current proposals and identify
where a versioning system can be handled.
2.1.1 Proposals based on extensions of the DNS protocol
Proposals based on extensions of the DNS protocol should include in the
bits the version number and a way to exchange version numbers between the
parties. [IDNE] already defined a version number as part of the use of
EDNS. Similar versioning should be defined in the other proposed protocols.
2.1.2 Proposals based on ACE and application
Since ACEs (for example [RACE]) in applications [IDNA] do not change the
DNS protocol but only encode the idn in a ascii compatible way, it looks
more difficult to include a version number in the ACE encoding, since it
will change the domain name. The proposal is to use a different
prefix/suffix for each version, by using one of the chars used in the
prefix as a version number, beginning with the lowest possible ascii char
available and increase the ascii codepoint of the char by 1 for each
version. For example, if the prefix is "ra--", then the first version of
idn will be "ra--", the second version will be "rb--", the third "rc--".
While this would be more elegant, one can handle versioning by having
different prefixes for each version, while chosing prefixes randomly (i.e.
1st version: rq--, 2nd version: wz--, ...). IANA should block all possible
prefixes so that no pre-registration is permitted.
2.2 Major and minor version numbers
A <major>.<minor> version number is proposed (i.e. 1.0, 1.1, 2.0). A
minor revision is defined to be as new chars or small changes in the table
to be handled without any modification of algorithm. The idea here is to
enable easy upgrading of idn processors when only new chars will be
handled. In this case, the binary software do not have to be changed and
only the table containing the chars has to be changed to enable a new
version. A major revision means that the software has to be upgraded since
it implies new ways of handling idn which are not identified in the table.
2.3 Processing of the version numbers
Any idn processor MUST verify the version number before processing. When a
major version number is higher than what the processor currently handle is
detected, processing MUST be stopped and rejected. When a minor version
number is higher than what the processor currently handle, then any
intermediate processors MUST forward the idn but the end processor (i.e.
the dns server authoritative for that zone that is handling the request)
MUST stop and reject the request. Specific handling of rejecting the
request should be defined in the protocol document.
2.4 Version numbers
Version numbers of the idn protocol will be handled by IANA. A
IESG-reviewed document should be used as the basis for IANA to define a new
protocol version number.
3. Idn table
Since the unicode consortium and ISO will issue new versions not at the
same time as the idn protocol versioning, the IETF need to have its own
registered table of accepted idn chars. This will also enable specific data
only useful for idn. The intent is not to duplicate the unicode/iso effort,
it is to support the specific needs of the idn group. For example, it is
possible that specific chars will have a different behavior than the normal
Unicode way: the special casing for final or non-final letters in the
Unicode SpecialCasing.txt file can be merged (ie not totally identical to
the unicode processing) to only one casing since final and non-final
letters have less meaning in a domain name. Simpler processing for idn is
also useful: for example, the Lud property is probably not useful in the
idn context and can be considered equivalent to Lu. Combining those
properties together means much simple table and simpler processing and less
errors in implementations. Added chars, codepoint, properties MUST NOT be
done in this file, but must be done within the Unicode/ISO process.
This document proposes a table contained in an ascii file handled by IANA
and available in the IANA public directory. The source of the table will be
the Unicode table, with a similar format, but a simpler, and perhaps
different, content based on the needs of the idn protocol. Proposed
filename is: idntab.txt.
This file format will also help implementors to have the same input
description and exhaustive list of which chars and processing to handle
idn. This is easier for implementors to have a complete list of accepted
chars instead a list of non-accepted chars. The hope is also to help
decrease the different behaviors between the different implementations.
This table can be considered as an implementation of [NAMEPREP].
3.1 File format
The file is divided in two parts. The first part contains variables. The
second part contains all the chars accepted for idn. The two parts are
separated by a empty line.
The format of the first part is:
tag=value<CR><LF>
Currently, only the version tag is defined. The "version" tag defines the
highest idn version number that can be found in this table. The intent is
to have only one file that is kept current but where the beginning of the
file can be used by parsers to identify the latest version of the file.
The first idntab.txt file will define version=1.0:
version=1.0<CR><LF>
The format of the second part is:
one codepoint per line
lines separated by CR/LF
each field in the line separated by ";"
The fields are (in order, from left to right):
1. codepoint in hexadecimal (as in unicode table): HHHH
2. first version of idn table that this char is supported
It is possible that new fields will be added in the future. Parsers should
ignore the fields that they don't understand.
Spaces (ascii 0x20) are ignored. Comments are identified by "#". All text
following the comment char up to the end of line is ignored. Any codepoint
not in the table is considered prohibited. Codepoints that are prohibited
may be included in the table inside commented lines in order to help a
reader to see explicitly which ones are prohibited.
Example of the file idntab10.txt:
version=1.0<CR><LF>
<CR><LF>
0041;1.0;
4. Security Considerations
Changing the way a software react about domain names is clearly something
that have security impacts. While the actual table doesn't present any
security threat by itself, if there is someways by a intruder to reload a
new table into a idn processor software without the knowledge of the user,
then it can completly disables name resolution or have other possible
threats. In conclusion, care must be taken by software developers on how
to manage the insertion of a new idn table in a idn processor software.
5. IANA Considerations
This document describes versions of the idn file called idntab.txt. The
file should be kept in the IANA public directory for references purposes.
New versions of the file should be made available after IESG review of a
document. Old revisions of the file (idntab-xy.txt) should be kept for
documentation purposes.
6. Acknowledgements
The author would like to acknowledge the comments and idea of the
following people: Fran<61>ois Yergeau and Paul Hoffman.
7. Author
Marc Blanchet
Viagenie
2875 boul. Laurier, bur. 300
Ste-Foy, Quebec, Canada
G1V 2M2
Marc.Blanchet@viagenie.qc.ca
tel: 418-656-9254
8. References
[NAMEPREP] Preparation of Internationalized Host Names, Paul Hoffman, Marc
Blanchet. Work in progress.
[RACE] RACE: Row-based ASCII Compatible Encoding for IDN, Paul Hoffman.
Work in progress.
[IDNA] Internationalizing Host Names In Applications (IDNA), Paul Hoffman,
Patrick Falstrom. Work in progress.
Marc Blanchet
Viag<EFBFBD>nie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca
----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

19
doc/draft/draft-ietf-idn-version-01.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
M. Blanchet: Marc.Blanchet@viagenie.qc.ca

544
doc/draft/draft-ietf-ipngwg-default-addr-select-05.txt → doc/draft/draft-ietf-ipngwg-default-addr-select-06.txt
View File

File diff suppressed because it is too large Load Diff

224
doc/draft/draft-ietf-ipngwg-prefix-rr-disc-00.txt
View File

@@ -1,224 +0,0 @@
IPng Working Group Matt Crawford
Internet Draft Fermilab
November 17, 2000
Discovery of Resource Records Designating IPv6 Address prefixes
<draft-ietf-ipngwg-prefix-rr-disc-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The A6 resource record type [A6] was introduced to store IPv6
addresses in a manner which facilitates prefix changes and
assignment of addresses from multiple prefixes. In order to allow
use of dynamic DNS updates while still respecting whatever prefix
hierarchy may be in use in a site's "reverse" DNS zone, a method is
needed for discovering the name(s) of the A6 record(s) which specify
an address prefix.
This memo specifies such a method of prefix name discovery.
1. Introduction
The A6 resource record type [A6] was introduced to store IPv6
addresses in a manner which facilitates prefix changes and
assignment of addresses from multiple prefixes. In order to allow
use of dynamic DNS updates while still respecting whatever prefix
hierarchy may be in use in a site's "reverse" DNS zone, a method is
needed for discovering the name(s) of the A6 record(s) which specify
an address prefix.
Expires May 22, 2001 Crawford et al. [Page 1]
Internet Draft IPv6 DNS November 17, 2000
This memo specifies such a method. No new protocols or DNS record
types are involved -- only a convention for storing the required
information and a procedure for finding it.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD].
2. Prefix Name Storage
Recall from [A6] that address-to-name mapping information may be
stored in a subzone of IP6.ARPA, or in another zone reached by a
chain of one or more DNAME records. Nodenames are stored in PTR
records in such a zone. Extending that custom, we specify that
prefixes are to be named in PTR records in the same way. For a
prefix "P" of length "L" bits there should be a PTR whose RDATA
contains the owner name of an A6 record suitable for designating the
prefix P/L, and this PTR record is to be stored so that it will be
returned by a DNS query for the QNAME \[P/L].IP6.ARPA (possibly
after resolving intervening DNAMEs [DNAME]).
Since the purpose of prefix name discovery is to facilitate dynamic
registration by hosts of their IPv6 addresses in DNS, only the names
of "longest" prefixes need to be discoverable. Accordingly, this
example will show just a prefix which is not subnetted further.
Building on the example from [A6], section 5.2.3, the addition of
the required PTR record is shown below.
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
PTR SUBNET-1.IP6 ; added record
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN IP6
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
Notice that the owner and RDATA are the same. This is a consequence
of a somewhat arbitrary choice. The new record could equally well
have been
\[x0001/16].IP6.X.EXAMPLE. PTR SUBNET-1.IP6.X.EXAMPLE.
It cannot be determined by inspecting an A6 DNS record whether that
Expires May 22, 2001 Crawford et al. [Page 2]
Internet Draft IPv6 DNS November 17, 2000
record is meant to specify all the trailing bits of a 128-bit IPv6
address or merely a prefix. Inclusion of the trailing bits does not
preclude its being pointed to as a prefix by some other A6 record.
Nevertheless, a human or automated zone maintainer will generally
know the intended purpose of each A6 record and which one should be
named in a PTR for prefix name discovery.
3. Prefix Name Discovery
If a process wishing to do prefix name discovery has the prefix
itself available (as opposed to a full address of which an unknown
initial portion is the prefix), the prefix can be looked up
directly. Otherwise, two heuristics are available.
First, it is possible that looking up a PTR record based on the full
IPv6 address, as would be done for ordinary address-to-name mapping,
will yield a PTR record containing a hostname. That hostname will
then be the owner of an A6 record. If its prefix length field is
non-zero, its prefix name field will contain the desired name.
Otherwise, looking up a PTR record will fail, returning an
authoritative name error no no data of the requested type. There
will be a set of DNAME records in the answer section of the reply.
The last of these DNAMEs will indicate where to start looking for
the required PTR record. First its target should be tried, then its
owner. An especially persistent implementation can then prepend one
bit at a time from the portion of the IPv6 address not mapped by the
DNAME records to the target name, looking for a PTR record which was
not at a DNAME cut point of its own. An authoritative name error is
a stopping signal for this search.
4. Security Considerations
No security concerns are raised by this specification beyond those
which apply to all uses of the DNS.
5. References
[A6] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering", RFC 2874, July 2000.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
Expires May 22, 2001 Crawford et al. [Page 3]
Internet Draft IPv6 DNS November 17, 2000
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999.
6. Authors' Addresses
Matt Crawford
Fermilab
MS 368
PO Box 500
Batavia, IL 60510
USA
+1 630 840-3461
crawdad@fnal.gov
Expires May 22, 2001 Crawford et al. [Page 4]

19
doc/draft/draft-ietf-ipngwg-prefix-rr-disc-01.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
M. Crawford: crawdad+ietf@fnal.gov

4141
doc/draft/draft-ietf-ipngwg-rfc2292bis-02.txt
View File

File diff suppressed because it is too large Load Diff

21
doc/draft/draft-ietf-ipngwg-rfc2292bis-03.txt Normal file
View File

@@ -0,0 +1,21 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
E. Nordmark: nordmark@eng.sun.com
M. Thomas: thomas@vayu.net
R. Stevens: rstevens@noao.edu

2044
doc/draft/draft-ietf-ipngwg-rfc2553bis-03.txt
View File

File diff suppressed because it is too large Load Diff

22
doc/draft/draft-ietf-ipngwg-rfc2553bis-04.txt Normal file
View File

@@ -0,0 +1,22 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
R. Gilligan: gilligan@freegate.com
W. Stevens: rstevens@noao.edu
J. Bound: bound@zk3.dec.com
S. Thomson: set@bellcore.com

802
doc/draft/draft-macgowan-dnsext-label-intel-manage-00.txt
View File

@@ -1,802 +0,0 @@
INTERNET-DRAFT DNS Label Intelligence and Management System
UPDATES RFC 1034 February 2001
Expires August 2001
Domain Name System (DNS) DNS Label Intelligence and Management System
draft-macgowan-dnsext-label-intel-manage-00.txt
Michael L. Macgowan Jr.
Status of This Document
This draft is intended to become a Proposed Standard RFC. Distribution
of this document is unlimited. Comments should be sent to the Domain
Name Server Extensions working group mailing
list<namedroppers@ops.ietf.org> or to the author.
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
A multidimensional array of domain label analysis and extensions are
offered to overcome a number of issues with the DNS and its use to
locate resources on the Internet. These goals are accomplished by
proposing a naming convention to add labels to domain strings. The
result will be a rational relationship to the content that will provide
a method for meeting the ever-increasing need to expand the namespace,
while providing an efficient search system to access content in a user-
friendly manner.
A fundamental problem exists in the design of DNS. A user must know the
domain name including the Top Level Domain, TLD, and type the Uniform
Resource Locator, URL, accurately to connect to resources on the
Internet. The current lookup organization of the DNS uses domain labels
separated by periods to provide hierarchical levels for a resolver to
seek in finding a path to an authority. A new masking technique within
labels is proposed to accommodate lookups based on the request.
Multiple processing trees are proposed to redistribute the requests
based on the known pieces of the domain name. Rather than knowing the
fully qualified domain name, FQDN, the user can search for content
based upon known pieces of the string like group (business), country,
area code, phone number, type of organization, street address, zip code
and/or GPS location, etc.. Intelligence is added for determining the
fastest route to resolution based on user weighting, number of
requests, and traffic within the system.
A result of the masking technique is an opportunity to provide a
completely hidden label(s) for maintenance of the system. A TTL (Time
to Live), version, and type of request could be keyed into a label to
provide information, which remains with the client but is normally lost
after a request is processed. This system could be implemented to
create automatically updated records and content. Or hidden labels
could be used to distinguish between version 4 and version 6 requests
in the TCP/IP, Transmission Control Protocol/ Internet Protocol,
rollover.
Implementation of the new name system is facilitated by the addition of
a client interface for building requests. Longer domain names are
enhanced by smart AutoCompletes and group edit boxes.
Table of Contents
Status of This Document 1
Abstract 1
Table of Contents 3
1. Introduction 4
2. Inputting Request for Resolution 4
3. Resolution Processing 7
4. Processing Forest 13
5. Extended Label Uses 14
6. IANA Considerations 16
6. Security Considerations 16
References 16
Authors Address 16
Expiration and File Name 17
1. Introduction
The Domain Name System (DNS) [RFC 1034, 1035] is the global
hierarchical replicated distributed database system for Internet
addressing, mail proxy, and other information. The DNS has been
extended to phone numbers as described in [RFC 2535]. It is designed to
accommodate a user-friendly name as an abstraction level over an IP
address, which provides a path to the physical connection to resources
and/or content on the Internet. This abstraction allows for changing
the physical location of the content without an update by the client.
The design, however, lacks a user-friendly method for assigning TLDs
and determining which TLD a content provider will be registered under.
According to COMPUTERGRAM INTERNATIONAL: January 08, 2001, over 100
million hosts are connected to the Internet with over 350 million
users. ICANN has submitted plans to increase the number of TLDs to
accommodate the lack of namespace, but the problem of organization and
extensibility continues to exist. As the number of TLDs grows, it
becomes harder for a user to input a user friendly domain name. In
essence, the user must know what derivations and which TLDs were
available to a provider at the time the organization chose a domain
name. The method of one response, in an all or nothing request, forces
precision on the part of the user that is a distraction to the original
goal of a user-friendly name. Consider a user that wants to find a new
theoretical health related company called Healthy Foods. Will the
company be called Healthyfoods.com? Or will it have an extension like
healthfoods.net, healthfoods.org, or healthfoods.health? Maybe it will
be forced to be a derivation like healthf.com, healthf.net, etc. There
is no user-friendly method to determine what the associated domain name
might be. This is a central problem of focus and organization. The
number of iterations a user must try increases with each new TLD that
is added. If a user forms multiple guesses for the TLD, excess traffic
is generated and the search is slowed by the inefficient nature of
human typing. Further, if a system were proposed under the current root
structure to allow for a search of all possible TLDs, the number of
requests would grow exponentially with the addition of each new TLD.
2. Inputting Request for Resolution
The key to making a New Name System, NNS, is to provide a user
interface, which will accommodate a friendly method of building name
requests. AutoComplete and multiple-selection drop-down, group list
boxes (some editable, some not) will make more complicated names easier
to input. Consider the previous example of Healthy Foods. Additional
extensions could be added as labels to make the namespace exponentially
larger. The web content might be reached at
www.healthy.food.US2081234567.Fairview101. In this example, www is the
Device label or content desired by the user. Health is the domain or
Subgroup/Group name label. Food is the item under the Type label.
US2081234567 is the item country/area code/number for the Global label.
Sfairview101 is the street/address of the Local label.
Derivations of this example provide a limitless expansion of the
namespace within the physical limits of the protocol. A competitor down
the block might have the same FQDN, except for the street number and
phone number e.g. www.healthy.food.US2088901234.SFairview990. A second
type of business could also be run from the same location by changing
the type e.g. www.healthy.entertainment.US2081234567.SFairview101. A
parody of the site might be offered at
www.healthy.parody.us2086669999.SState103.
A method of using less descriptive labels could also be used to
generalize the content. For example, the site for the regional office
might use only the country and area code designation e.g. .US208. A
corporate address might be located at www.healthy.food.US.corporate.
This way the Global and Local labels are not tied to physical
locations. Or there may be an 800 or 888 number that could be used for
multiple sites that are tied to multiple registrations at different
street addresses in the Local label.
The task of building these longer names with labels can be accomplished
by updating list items from the NNS and by designing a better
interface. Instead of waiting for ICANN to vote on the relative merits
of a proposal for a new TLD, items could be automatically updated and
added to the system by a list of requirements. This would force a
relationship between labels but provide a nonbiased method without
prejudice. For example, a .Bus(iness) item for the Type label would
require a copy of a business license to be granted by the governing
authorities for the area specified in the Global label or the address
specified in the Local label. A <20>TM<54> item could separate the
Intellectual Property of Trademarks and Copyrights from other
registered listings issued from the government specified by the country
code in the Global label. Additionally, the Academy of Motion Pictures
might request an Oscar item, which would restrict membership to
nominees or recipients of the coveted award.
Just as the resolver gets an updated list of root servers upon first
connection, the resolver could also receive an updated list of items in
the Type label and return them to the client. The list could be updated
by a TTL trigger and should not be editable from the user<65>s standpoint.
The user interface should allow for multiple selections, which could be
used to form separate requests for resolution. Finally, the
implementation should begin with at least a list that is equal to a
subject list found in the yellow pages of the phone book. This will
provide a well-known classification that will greatly reduce
competition for names of organizations, which are similar but provide
for very different products/services. Delta.airline is readily
distinguished from Delta.homeimprovement.
The device label would remain largely unaffected. A list of previously
connected items such as www, toasters, lock, refrigerator, etc. would
facilitate input. The list would be editable. As the number of devices
connected to the Internet grows, this method will be invaluable.
Consider mail and faxes being sent directly to
printer.mybusiness.computer.us2081234567.sfairview101. A user that
needs to send a fax to a satellite office might also be able to try
searching for mybusiness at its other street address or telephone
number eg., printer.mybusiness.computer.us714*.sPensylvaiaave2345.
Wildcards and searching are discussed in the next section.
The items under the Groups/Subgroups labels would also be a list of
previously connected to domains (less the TLD) such as sales.business
or kitchen.home. The list would contain a history of previous
connections and be editable.
The Global label would have two characters to represent the country
code followed optionally by all or part of a representative telephone
number or mask for identifying the voice number(s) associated as items
in the domain. An international code would require a rational
relationship with world organizations. The interface would contain the
country codes and/or area codes, but the numbers would have to be
added.
The Local label would require a single character to represent the type
of information presented, followed by the information in a standardized
form. The following codes are proposed for the Local label, <20>P<EFBFBD> for
Postal code, <20>G<EFBFBD> for Global Satellite Positioning and <20>S<EFBFBD> for street
address. For example, P83706 would represent the author<6F>s postal code,
GP0445004N1162498 (since the <20>+<2B> key is not valid, <20>p<EFBFBD> and <20>n<EFBFBD>
represent positive and negative) would represent the GPS position of
the author with padding to standardize degrees/min/sec or SOrchard15541
would represent the Street address (house number at the end). Note each
of these would require a separate name registration. The editable list
box could be a fly out list box with one of the designators specified,
while the remainder would be user input.
+------------------+
|Street |
| Fairview101 |
State101 |
|Postal |
|GPS |
+------------------+
The added labels would exponentially expand the name space. This may
cause an undesired relation to a Global or Local designation. This
could hamper changes to an organization or business in the future.
Hence a business might want to use a CNAME entry to reference users to
a non-distinct item in a label. For instance, a corporation might want
to register mybusiness.bus.In(ternational).corporate so that the
corporate office could be used for email addresses and bookmarking.
Content might be located at each mybusiness.bus.country.location where
the company does business. This way a corporation does not have to be
penalized for moving to a new physical location. The goal of the DNS
was to remove a physical relationship to the network, but the need of
the users is for some content to have a physical relationship to the
content; which is why, in part, the NNS is proposed. The concept of an
update is also discussed in section 5.
The system would need to distinguish between the need for a request for
a connection to single IP address versus multiple requests. In an
application like a browser, traditional requests for IP resolution are
all or none. Either an IP address is connected to or not. If wildcards
are added to the request, multiple entries could be returned as a <20>hit<69>
list. An option on the browser could determine the number of requests
specified by the user. The <20>hits<74> should also be weighted. For
instance, if a user wanted to find all the movie theatres in the local
area he/she might submit a request for www.*.movies.US8370*.*. She/he
would be more inclined to desire additional theatres at different
nearby area codes than derivations of different domain names or Local
label derivations for a single theatre. A simple listing of each label
with an associated numerical value in an advanced option field could
determine how the responses are weighted against one another. The NNS
could also take into account the number of requests on the system and
further limit the number of responses based upon traffic.
For registration, the content provider might want to register a more
global entry to be displayed on a restrictive search e.g. loans.US*.*.
A business content provider might want to register mybusiness.com.US*
so that requests for www.mybusiness.com.US208.* and
www.mybusiness.com.us714.* both resolve to mybusiness. A process would
have to be in place to copy an entry with wildcards to each of the
associated branches of the processing trees as discussed in section 4.
Similarly wildcard registrations should meet the rational requirements
required for the known item with the generalized scope. In the previous
example the provider would have to be licensed as a financial
institution in each of the states of the United States.
3. Resolution Processing
The key to expanding the DNS is to provide for a name space, which can
be accessed quickly and efficiently. Organization is key to this
process. The current DNS has one root organized by TLDs of the Type
label combined with Country TLDs. If a user does not know the extension
for the name, requests must be created for each one until a match is
found. The NNS creates separate roots for each label that can be used
for a search (see graphic on next page, description of TLDs is in
section 5). Instead of one tree, a forest is created, connected by a
common list of authorities for devices in the zones requested. Requests
can be organized by the known piece(s) of information. For instance, if
a user is trying to find Hewlett Packard and does not know that content
is provided at HP, a search of www.H*.*.US*.* should be returned
alphabetically from the Group label, not the Type label. However, if
the type item is known to be <20>computer<65>, a search of the Type tree
would be fastest. If a user wants to find a local voice number for
Microsoft he/she could submit a request generalized request within the
local area code for www.Microsoft.software.US208*.*. The authority
would best be located by the Global processor, which might list
www.Microsoft.software.US5041234567.SState123 and
www.Microsoft.software.US5044567890.SredmondAve123. If the request for
www.Microsoft.software.US504*.* were sent to the Local processor, every
TLD would have to be queried. The result might be one phone number with
separate Local label listings for the street address, GPS, and postal
code. This would create unwanted traffic on the system.
Root <20>.<2E> Group Root <20>.<2E>Type
| |
| |
<20>H<EFBFBD> TLD TLD <20>Computer<65>
| |
| |
--- Authority for..HP.computer.US2081234567.SChinden12----
| |
| |
<20>US208<30> TLD TLD <20>SChi<68>
| |
| |
Root <20>.<2E> Global Root <20>.<2E>Local
In addition to determining which label(s) to process the request, the
system would also have to take into account the weighting by the user
and the traffic on the system as discussed in the previous section.
When the FQDN is specified, the resolver would query the processor with
the fastest expected response time. A FQDN can be resolved from any of
the search processor trees. In the example
oven.macgowan.private.US2081234567.SOrchard15541, it does not matter
whether the request is sent to the Group, Type, Global, or Local
processing tree. Each leads to the authority,
macgowan.private.us2081234567.SOrchard15541.
If wildcards or null characters exist in the request, the system should
take into account the number of requests that might be generated.
Currently the DNS does not account for the <20>?<3F> and reserves the <20><> for
the root. The <20>*<2A> could replace the singe character wildcard <20>?<3F> and
the word <20>null<6C> could be used in lieu of <20><>. The following table could
be used to determine which processing tree should be the most desirable
under such conditions:
any = any combination of characters displayed in request
reject= no preferred processor
*= match any combination of characters for response
?= match any single character for response
null= no character specified
Device Sub Group T G L Result
* * * * * * reject
* any any any any any reject
* * any any any any reject
* * * any any any submit to T, G, or L
* * * * any any submit to G, or L
* * * * * any submit to L
any * * * * * reject
any any * * * * reject
any any any * * * submit to group
any any any any * * submit to group, or T
any any any any any * submit to group, T, or G
any any any any any any submit to any
any * any any any any submit to any
any * * any any any submit to T, G, or L
any * * * any any submit to any G, or L
any * * * * any submit to any L
any any * any any any submit to any T, G, or L
any any * * any any submit to any G, or L
any any * * * any submit to any L
any any any * any any submit to any group, G, or L
any any any * * any submit to any group, or L
any any any any * any submit to any group, T, or L
any any any any * * submit to any group, or T
* * * * * * reject
* any*any any*any any*any any*any any*any reject
* * any*any any*any any*any any*any reject
* * * any*any any*any any*any submit to T, G, or L
* * * * any*any any*any submit to G, or L
* * * * * any*any submit to L
any*any * * * * * reject
any*any any*any * * * * reject
any*any any*any any*any * * * submit to group
any*any any*any any*any any*any * * submit to group, or T
any*any any*any any*any any*any any*any * submit to group, T, or G
any*any any*any any*any any*any any*any any*any reject
any*any * any*any any*any any*any any*any reject
any*any * * any*any any*any any*any submit to T, G, or L
any*any * * * any*any any*any submit to any G, or L
any*any * * * * any*any submit to any L
any*any any*any * any*any any*any any*any reject
any*any any*any * * any*any any*any submit to any G, or L
any*any any*any * * * any*any submit to any L
any*any any*any any*any * any*any any*any reject
any*any any*any any*any * * any*any submit to any group, or L
any*any any*any any*any any*any * any*any submit to any group, T, or L
any*any any*any any*any any*any * * submit to any group, or T
* * * * * * reject
* any* any* any* any* any* reject
* * any* any* any* any* reject
* * * any* any* any* reject
* * * * any* any* submit to G, or L
* * * * * any* submit to L
any* * * * * * reject
any* any* * * * * reject
any* any* any* * * * reject
any* any* any* any* * * reject
any* any* any* any* any* * reject
any* any* any* any* any* any* reject
any* * any* any* any* any* reject
any* * * any* any* any* submit to T, G, or L
any* * * * any* any* submit to any G, or L
any* * * * * any* submit to any L
any* any* * any* any* any* reject
any* any* * * any* any* submit to any G, or L
any* any* * * * any* submit to any L
any* any* any* * any* any* reject
any* any* any* * * any* submit to any group, or L
any* any* any* any* * any* reject
any* any* any* any* * * submit to any group, or T
?any ?any ?any ?any ?any ?any reject
?any any any any any any reject
?any ?any any any any any reject
?any ?any ?any any any any submit to T, G, or L
?any ?any ?any ?any any any submit to G, or L
?any ?any ?any ?any ?any any submit to L
any ?any ?any ?any ?any ?any reject
any any ?any ?any ?any ?any reject
any any any ?any ?any ?any submit to group
any any any any ?any ?any submit to group, or T
any any any any any ?any submit to group, T, or G
any any any any any any submit to any
any ?any any any any any submit to any
any ?any ?any any any any submit to T, G, or L
any ?any ?any ?any any any submit to any G, or L
any ?any ?any ?any ?any any submit to any L
any any ?any any any any submit to any T, G, or L
any any ?any ?any any any submit to any G, or L
any any ?any ?any ?any any submit to any L
any any any ?any any any submit to any group, G, or L
any any any ?any ?any any submit to any group, or L
any any any any ?any any submit to any group, T, or L
any any any any ?any ?any submit to any group, or T
any?any any?any any?any any?any any?any any?any reject
any?any any any any any any submit to any
any?any any?any any any any any submit to any
any?any any?any any?any any any any submit to any
any?any any?any any?any any?any any any submit to G, or L
any?any any?any any?any any?any any?any any submit to L
any any?any any?any any?any any?any any?any reject
any any any?any any?any any?any any?any reject
any any any any?any any?any any?any submit to group
any any any any any?any any?any submit to group, or T
any any any any any any?any submit to any
any any any any any any submit to any
any any?any any any any any submit to any
any any?any any?any any any any submit to any
any any?any any?any any?any any any submit to any G, or L
any any?any any?any any?any any?any any submit to any L
any any any?any any any any submit to any
any any any?any any?any any any submit to any G, or L
any any any?any any?any any?any any submit to any L
any any any any?any any any submit to any
any any any any?any any?any any submit to any group, or L
any any any any any?any any submit to any
any any any any any?any any?any submit to any group, or T
any? any? any? any? any? any? reject
any? any any any any any submit to any
any? any? any any any any submit to any
any? any? any? any any any submit to any
any? any? any? any? any any submit to any
any? any? any? any? any? any submit to any
any any? any? any? any? any? submit to any
any any any? any? any? any? submit to any
any any any any? any? any? submit to any
any any any any any? any? submit to any
any any any any any any? submit to any
any any any any any any submit to any
any any? any any any any submit to any
any any? any? any any any submit to any
any any? any? any? any any submit to any
any any? any? any? any? any submit to any
any any any? any any any submit to any
any any any? any? any any submit to any
any any any? any? any? any submit to any
any any any any? any any submit to any
any any any any? any? any submit to any
any any any any any? any submit to any
any any any any any? any? submit to any
Null any any any any any not valid
any Null any any any any submit to any
any any Null any any any reject
any any any Null any any submit to group, G, L
any any any any Null any submit to group, T, L
any any any any any Null submit to group, T, G
Null Null any any any any not valid
any Null Null any any any reject
any any Null Null any any submit to G, L
any any any Null Null any submit to group, L
any any any any Null Null submit to group, T
Null Null Null any any any not valid
any Null Null Null any any submit to G, L
any any Null Null Null any submit to L
any any any Null Null Null submit to group
Null Null Null Null any any not valid
any Null Null Null Null any submit to L
any any Null Null Null Null not valid
Null Null Null Null Null any not valid
any Null Null Null Null Null not valid
Null Null Null Null Null Null not valid
4. Processing Forest
|--Group Root---|
| |
|---Type Root---|
| |
client->------Resolver ->------| |----Authority->---
return
| |
|--Global Root--|
| |
|--Local Root---|
Once the resolver has determined which root to send the resolution
request to, each tree should be organized according to an exhaustive
replication of each name string on the route to an authority. For
instance, the Group tree would be organized alphabetically with TLDs
<EFBFBD>A<EFBFBD> through <20>Z<EFBFBD> initially. Since there are a lot of organizations with
business name derivations using the word <20>micron<6F>, there might be a
need to reorganize the <20>M<EFBFBD> TLD to accommodate a <20>Mic<69> and a <20>Mid<69> TLD.
Although it would be more efficient to break down each letter according
to the demands of the system, it would be easier to specify one mask
for the entire tree. The number of TLDs becomes a function of the
permutations of the number of masked characters in the available set of
usable characters rather than a select few that are added over time.
The resolver can cache the TLDs and know when to use them based upon
the mask for the tree. If a larger mask is needed to further distribute
the load, the resolvers would have to be updated.
To replicate the current DNS entries under the additional labels
specified in this proposal a number of applications and uses would have
to be accounted for. The ARPA listings would remain unchanged or they
could be replicated under each root by recombining telephone numbers in
a single label under the e164 or padding IP addresses under the inverse
lookup tables without the periods separating the octets.
Since the NNS uses a forest of processing trees and the current system
uses only one tree, a conversion process would have to be developed to
distinguish between DNS requests and NNS requests. This could be
handled using a number of different methods.
A version flag in the request could accomplish this. This way the
resolver would be able to determine which searchable labels were used
and the order of presentation by standardization. The resolver
intelligence would know which labels to use for lookup or in the
preferred embodiment. The resolver could also reorganize the labels to
be presented under the correct processor so that the Global label is
presented at the right of the name string for processing through the
Global tree. Legacy requests without a version would be sent to the
Type tree.
Another method could accomplish the goal by combining the labels the
request for the processing tree. In the previous example, the request
oven.macgowan.private.US2081234567.SOrchard15541 could be recombined by
the submitting processor as
oven.macgowanUS2081234567SOrchard15541.private to be searched under the
Type tree. Similarly it could be recombined as
oven.macgowanprivateUS2081234567.SOrchard15541 to be searched under the
Local tree. If a legacy DNS based system submitted a request for
www.yahoo.com, it might be appended as www.yahoo.com..... The first <20>.<2E>
after com is to end the Type label. The second <20>.<2E> Represents the null
character at the end of the Global label. The third <20>.<2E> is for the
Local label. The fourth <20>.<2E> is for the root. The last <20>.<2E> is for the
end of the sentence. If applications are affected by the reservation of
the <20>.<2E> for the root, the request could be recreated as
www.yahoo.com.null.null..
A final method is to create a hidden label. Hidden labels are discussed
further in extended label uses.
Once the authority for a label is found within the label, the system
must also determine if there are Subgroups. Subgroups can be used for a
number of internal functions and/or divisions within the authority for
an organization. At this point the system would continue to resolve
using subgroup labels as levels as it does under the current system
toward the device at the left of the name string.
The remaining searchable labels would be serviced using a similar
method. The Type tree would be organized as it is in the DNS with TLDs
representing each item in the list. Since the items in the list are
limited by the system, the mask could be set to none. The Global label
should be organized by a mask, which would accommodate at least the
country and area codes. The Local label would mask the PGS items until
enough TLDs are derived to equal processing traffic under the other
trees. Provisions should be made for the non-distinct items like
<EFBFBD>corporate<EFBFBD> that may use characters not reserved for physical
locations. In addition, a null TLD could be used to organize the
remainder of name strings that have omitted labels. The null <20><>
character or the word <20>null<6C> could be used to represent legacy DNS
strings under the new labels until the name strings are updated with
the longer requirements.
The NNS allows a FQDN to be resolved from each searchable label. Please
refer to the previous example,
oven.macgowan.private.US2081234567.SOrchard15541. The authority,
<EFBFBD>Macgowan.private.US2081234567.SOrchard15541<34> is found using the
traditional method of the DNS using a Type item of <20>private<74> (mask of
zero). The authority, <20>Macgowan.private.US2081234567.SOrchard15541<34> is
found through the Group processor under the <20>Mac<61> branch using a mask
of three characters. The <20>Macgowan.private.US2081234567.SOrchard15541<34>
authority is found under <20>US208<30> using a mask of four characters within
the Global processing tree. The
<EFBFBD>Macgowan.private.US2081234567.SOrchard15541<34> authority is also found
under <20>SOr<4F> of the branch masked under the Local tree.
5. Extended Label Uses
The NNS is a simple design which can accommodate the future of Internet
name strings by incorporating additional processing trees and a large
name space organized by labels with a user friendly interface. A search
engine is automatically derived from the organization within labels as
opposed to across labels. In other words, you send the known pieces of
the request to the processing tree that will yield the quickest results
with the least amount of traffic. Once names are bookmarked or selected
from a list of AutoCompletes, requests can be sent to any processing
tree to balance the load on the system.
The present proposal also provides an extensible path for future labels
that may or may not have associated processors. A <20>Contact<63> label
might always be masked during the request for resolution, but provide
additional value to the user with a description about the connection or
a webmaster<65>s email address. This has extreme value in the event a name
can be resolved, but not reached by connection to the IP address. In
addition to adding new labels, a group or association might request a
new item under the Type label or a new area code might be added under
the Group label. Therefore, one result of this system is a combination
of devices and labels which expands exponentially to meet the demand
for namespace with an inherent capability to adjust to future needs.
An additional hidden label (mask of all) adjacent to the root could be
hidden and give information for maintenance of the system and/or the
listing. The most important consideration is keying the order and
number of labels in the string. Or using this method, a hidden security
label could help create a firewall between valid requests from users in
the domain versus outsiders or tie to a public key for the destination.
The hidden label could also be used to pass a request for content
delivered in a specific language. With the addition of the Local and
Global labels it might also be necessary to add a TTL label which could
serve as a timer for the registration or the life of a bookmark or
connection. The client could use this value in a history of valid
connections to make a request for an updated TTL, a new IP address,
and/or a trigger for replacing the name with a new string. This would
allow for a change in address, phone number, new area code, etc. on the
part of the provider. Just as the domain name was an abstraction layer
over the IP address, the current domain string is an abstraction for a
future domain string. A routine could prompt a user to change an entry
in a contact/bookmark list. Services such as WWW could also
automatically update links in the content or reflect changes to related
destinations within the content. In use, the client could compare its
value to the value at the authority. If the authority has a value of
zero, the client would update its name and IP address to the new
pointer returned by the resolver. An electronically updating NNS with
updating links in content is a product of this system.
An example of using this procedure could be applied to finding the best
cell phone plan. A user buys a cell plan. The user emails contact links
to friends and associates. The recipients use their link to dial the
user. The user determines a new provider would be more advantageous and
purchases a new plan with a new number. The user sets their old TTL to
zero in the NNS and creates a new FQDN with the new cell number. Now
when the recipients use the old string, they are pointed to the new
string. The string with the new number is updated in the recipient<6E>s
contact list. The user is not tied to their telephone number and the
recipients do not need to manually adjust their entries.
Hidden labels and masking would also have to be present at the client.
A business might have a lot of phone numbers or locations listed on the
name servers but use a shorter version of the string for making local
connections. This way all the devices under a group could be combined
as a single domain name. The future direction of label intelligence and
the ideas expressed here suggest that there may be numerous ways to
provide abstraction levels within the label string. Even the IP address
might be used as an identifier to search for the rest of the domain
string or an item like the telephone number.
6. IANA Considerations
The focus of the IANA will change considerably. The need to regulate
name hoarders, TM infringement considerations, and the decision to
implement new TLDs will be greatly reduced. The IANA might be used to
determine the relationships between labels as new items are added under
the requirements that provide for fair and equal addition to the Type
label.
7. Security Consideration
Name resolution is an inherent problem for spoofing content, but is
beyond the scope of this proposal. The suggested ability to update name
strings at the client also increases the need to provide secure
communications between the system and the client.
References
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987.
[RFC 2535] <20> <20>E.164 number and DNS<4E> , P.
P. Faltstrom, 9/1/2000.
Authors Address
Michael L. Macgowan Jr.
15541 Orchard Ave.
Caldwell, ID 83607 USA
Telephone: +1 208.454.1177 (h)
FAX: +1 208.455.0439
EMail: mmacgowa@yahoo.com
Expiration and File Name
This draft expires in August 2001
Its file name is labelmanage.txt
Full Copyright Statement
Copyright (C) The Internet Society (February 2001). 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."
Michael L. Macgowan Jr. February 2001 [Page 17]
Internet Draft DNS Label Intelligence and Management System

19
doc/draft/draft-macgowan-dnsext-label-intel-manage-01.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
M. Macgowan: mmacgowa@yahoo.com

283
doc/draft/draft-msawyer-dnsext-edns-attributes-00.txt
View File

@@ -1,283 +0,0 @@
INTERNET-DRAFT M. Sawyer
A. Gustafsson
M. Graff
Nominum
<draft-msawyer-dnsext-edns-attributes-00.txt> 15 November 2000
Handling of unknown EDNS0 attributes
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This draft expires on May 15, 2001.
Abstract
This document provides a clarification of the EDNS0 protocol,
specifying the behavior of servers when they receive unknown EDNS
options.
1.1 - Introduction
Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms
[RFC2671] is helpful.
EDNS0 [RFC2671] specifies a general framework for extending the
packet format used by the Domain Name System protocol. The framework
provides for a series of additional options, identified by a 16 bit
attribute ID and arbitrary sized payload. Any number of these
additional options can be specified in the DNS packet. As specified,
the current scheme has drawbacks:
Expires May 2001 [Page 1]
INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
- It provides no way for implementers to deploy test systems with
experimental features prior to approval of the feature and assignment
of an attribute ID.
- It provides no specification on what an application should do when
receiving unrecognized options.
This draft proposes to clarify the original EDNS0 draft [RFC2671],
addressing these drawbacks.
1.2 - Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2 - Protocol changes:
This document updates [RFC2671]. Conformance to this specification
is claimed by specifying EDNS version 1.
2.1 - Advisory and Required Options:
Some potential uses of EDNS options are advisory in nature, For
example, a hypothetical option indicating that "I understand frobozz
compression in responses" can be safely ignored by the recipient,
which will then simply not use frobozz compression. Others uses of
options, such as a hypothetical "send only cryptographically verified
data in responses" option, cannot be safely ignored, and should cause
the request to fail if not understood by the receiver.
This suggests that we need two types of options, "advisory" options
(that can be ignored) and "required" options (that can not). Because
a server needs to classify options as advisory or required even if
they were not yet defined when the server was implemented, the type
of an option must be evident without knowing its internal structure.
This is achieved by splitting the option type codes into two ranges:
options with type code 0x0000-0x7FFF are considered "advisory", and
options with type code 0x8000-0xFFFF are considered "required".
2.2 - Handling of Unknown and Unsupported EDNS Option Types
When a server receives an unknown or unsupported advisory option in a
request or response message, it MUST ignore the unknown option and
process the message as if the option was not present. In the reply,
it SHOULD include an advisory UNSUPPORTED option (TBD).
Expires May 2001 [Page 2]
INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
When a server receives an unknown or unsupported required option in a
request message, it MUST NOT act on the request, and it MUST return
an error response with the extended result code BADOPT (TBD). In the
reply, it SHOULD include an advisory UNSUPPORTED option.
When a server receives an unknown or unsupported required option in a
response message, it MUST ignore the response. The server SHOULD
continue to parse options after the unknown option, including a list
of all unsupported options in the UNSUPPORTED option in the reply.
Servers MAY include SUPPORTED options in replies to messages, listing
option codes which they understand. This message SHOULD contain all
option codes the server understands. This facility MAY NOT be used
in place of the UNSUPPORTED option to identify unsupported options in
replies.
Clients MAY include SUPPORTED or UNSUPPORTED options in queries.
UNSUPPORTED options SHOULD only list those option codes which the
client has received in previous replies from the server, not an
inclusive list of all unsupported option codes.
2.3 - Use of Reserved Options for Development
Option codes in the range of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF
are considered "reserved" and shall not be assigned to new protocols.
Software vendors SHOULD use these options for testing of protocols
under development, provided the following conditions are met:
- Vendors MUST NOT ship any versions of the software which use option
codes in this range. They MUST delay shipping software with the new
options until IANA has assigned permanent option codes.
- Vendors MUST NOT place development servers on the live internet
which send options in this range to remote servers or which
understand options in this range as having any meaning.
3.1 - SUPPORTED and UNSUPPORTED options
The SUPPORTED and UNSUPPORTED options contain a list of option codes
which the server or client does or doesn't support. The list
contains, in network byte order, the supported or unsupported 16 bit
option codes:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SUPPORTED or UNSUPPORTED (TBD) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Expires May 2001 [Page 3]
INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
| LENGTH (number of options * 2) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OPTION CODE(s) /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Sending a SUPPORTED option with a zero-length payload indicates that
the server or client supports no EDNS options, so none should be
used. UNSUPPORTED options with zero-length payloads SHOULD NOT be
sent, as such a message is meaningless.
4 - IANA considerations
When allocating EDNS Option Codes, the IANA shall henceforth require
the RFC defining the new option to specify whether the option is an
"advisory" or a "required" option. The option code for an advisory
option shall be allocated from the range 0x0000-0x7FEF, and the code
for a required option shall be allocated from the range
0x8000-0xFFEF.
Option codes in the ranges of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF
are considered "reserved."
The IANA is hereby requested to assign EDNS Version Number 1 to this
specification, to assign a new extended RCODE value for BADOPT, and
to assign advisory option codes for UNSUPPORTED and SUPPORTED.
5 - Security considerations
This document provides a mechanism for users to override the default
behavior of the server when accessing data from its internal zone
databases. Software developers and administrators should use some
care when enabling these options, as they may provide outside users
the ability to retrieve information otherwise not available.
6 - Acknowledgments
The authors would like to thank Olafur Gudmundsson for his input on
this draft.
7 - References
[RFC2119] S. Brander, ``Key words for use in RFCs to Indicate
Requirement Levels,'' RFC 2119, ISI, November 1997.
[RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC
2671, ISI, August, 1999
Expires May 2001 [Page 4]
INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
Author's Address
Michael Sawyer
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1-650-779-6021
michael.sawyer@nominum.com
Andreas Gustafsson
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1-650-779-6004
andreas.gustafsson@nominum.com
Michael Graff
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1-650-779-6034
michael.graff@nominum.com
Expires May 2001 [Page 5]

21
doc/draft/draft-msawyer-dnsext-edns-attributes-01.txt Normal file
View File

@@ -0,0 +1,21 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
A. Gustafsson: gson@namesurfer.com
M. Sawyer: michael.sawyer@nominum.com
M. Graff: michael.graff@nominum.com

221
doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt
View File

@@ -1,221 +0,0 @@
INTERNET-DRAFT M. Sawyer
B. Wellington
M. Graff
Nominum
<draft-sawyer-dnsext-edns0-zone-option-00.txt> 9 October 2000
ZONE and VIEW option records in DNS messages
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This draft expires on April 9, 2001.
Abstract
This document defines two new EDNS option codes used to specify what
zone and view should be used in query messages to a remote DNS
server.
1 - Introduction
Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms
[RFC2671] is helpful.
Domain Concepts and Facilities [RFC1034] Section 3.7 shows a typical
reply to a DNS query, containing the answer as well as additional
data related to the answer provided. The server's zone database may
contain out-of-zone data glue which is internally used but is never
returned in a reply to a query. If recursion is requested by the
client and available in the server, or if the data is available in
Expires April 2001 [Page 1]
INTERNET-DRAFT ZONE and VIEW option records October 2000
the server's cache, the additional information will be taken from
these sources on most servers.
There is no method currently available for an administrator to query
a server specifying that only data from a specific zone should be
used in formulating the reply and that all available data from that
zone's database should be used, including out-of-zone glue. As such,
there is no mechanism for an administrator to ensure that out-of-zone
data in the zone's database is correct except through direct
manipulation of the zone database files. In addition, zone transfers
via AXFR or IXFR do not include out-of-zone glue. The ZONE option
code is provided to specify directly which zone database should be
queried.
In addition, DNS server software exists which may present different
"views" of the DNS space to different clients. In some cases, a
query may match the criteria of multiple views, and a user may wish
to specify which of the acceptable views match the query. The VIEW
option code is provided to specify which view should be searched for
the appropriate zone database.
1.2 - Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2 - Protocol changes:
This document updates [RFC2671]. The ZONE and VIEW option records
are intended as optional features. Servers MAY support either or
both of these options. Servers SHOULD provide configuration options
to enable or disable these optional records as needed.
Servers and clients SHOULD NOT use the ZONE or VIEW option codes in
normal use.
Servers SHOULD NOT use the VIEW option record in zone transfers
unless the administrator has specifically configured the server to
use these records. Servers MAY provide a mechanism for such
configuration. Servers SHOULD NOT use the ZONE option record in zone
transfers under any configuration.
3 - ZONE option record
The ZONE OPTION-DATA MUST contain a standard uncompressed wire-format
name in the format specified by [RFC1035] Section 3.3. Wildcards are
not permitted in ZONE option records.
Expires April 2001 [Page 2]
INTERNET-DRAFT ZONE and VIEW option records October 2000
When a server receives a query with a ZONE option record, it MUST
reply with a REFUSED reply if it understands the ZONE record but is
not configured to allow ZONE specific requests, if the specified zone
does not exist on the server, or if the client is not authorized to
use the ZONE option. If the ZONE option is allowed, it MUST return a
normally formatted reply with a ZONE optional record, containing the
same zone as the one queried. When replying to AXFR or IXFR queries
with ZONE options, the entire zone, including out-of-zone glue,
should be returned to the client.
Servers SHOULD treat ZONE options in zone transfer requests as an
unauthorized request and return REFUSED.
3.2 - VIEW option record
The VIEW OPTION-RECORD contains an arbitrary length text field, which
is used to match the name of the view in the server's configuration.
When a server receives a query with a VIEW option record, it MUST
reply with a REFUSED reply if it understands the VIEW record but is
not configured to allow VIEW specific requests, the specified view
does not exist, or the client is not authorized to access the
specified view. If a VIEW option is allowed, it MUST return a
normally formatted reply with a VIEW optional record containing the
same view as the one queried. The information used in generating the
reply should contain only information from the specified view of the
DNS space.
4 - IANA considerations
We request IANA assign option codes for the ZONE and VIEW options.
5 - Security considerations
This document provides a mechanism for users to override the default
behavior of the server when accessing data from its internal zone
databases. Software developers and administrators should use some
care when enabling these options, as they may provide outside users
the ability to retrieve information otherwise not available.
6 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and
Facilities,'' RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
Expires April 2001 [Page 3]
INTERNET-DRAFT ZONE and VIEW option records October 2000
[RFC2119] S. Brander, ``Key words for use in RFCs to Indicate
Requirement Levels,'' RFC 2119, ISI, November 1997.
[RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC
2671, ISI, August, 1999
Author's Address
Michael Sawyer
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1-650-779-6021
michael.sawyer@nominum.com
Brian Wellington
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1-650-779-6022
brian.wellington@nominum.com
Michael Graff
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1-650-779-6034
michael.graff@nominum.com
Expires April 2001 [Page 4]

21
doc/draft/draft-sawyer-dnsext-edns0-zone-option-01.txt Normal file
View File

@@ -0,0 +1,21 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
B. Wellington: brian.wellington@nominum.com
M. Sawyer: michael.sawyer@nominum.com
M. Graff: michael.graff@nominum.com