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-03-01 17:42:02 +00:00
parent 1adb182c1a
commit a653c8b3a9
11 changed files with 3566 additions and 3557 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
doc/draft/draft-ietf-dnsext-ad-is-secure-00.txt → doc/draft/draft-ietf-dnsext-ad-is-secure-01.txt
View File

@@ -4,10 +4,9 @@
DNSEXT Working Group Brian Wellington (Nominum)
INTERNET-DRAFT Olafur Gudmundsson (NAI Labs)
<draft-ietf-dnsext-ad-is-secure-00.txt> November 2000
<draft-ietf-dnsext-ad-is-secure-01.txt> January 2001
Updates: RFC 2535
@@ -38,33 +37,33 @@ Status of this Memo
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on May 17, 2001.
This draft expires on July 19, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All rights reserved.
Copyright (C) The Internet Society (2001). All rights reserved.
Abstract
Based on implementation experience, the current definition of the AD
bit in the DNS header is not useful. This draft changes the
bit in the DNS header is not useful. This draft changes the
specification so that the AD bit is only set on answers where
signatures have been cryptographically verified.
Expires May 2001 [Page 1]
Expires July 2001 [Page 1]
INTERNET-DRAFT AD bit set on secure answers November 2000
INTERNET-DRAFT AD bit set on secure answers January 2001
1 - Introduction
Familiarity with the DNS system [RFC1034, RFC1035] and DNS security
extensions [RFC2535] is helpful but not necessary.
Familiarity with the DNS system [RFC1035] and DNS security extensions
[RFC2535] is helpful but not necessary.
As specified in RFC 2535 (section 6.1), the AD bit indicates in a
response that all the data included in the answer and authority
@@ -112,9 +111,9 @@ INTERNET-DRAFT AD bit set on secure answers November 2000
Expires May 2001 [Page 2]
Expires July 2001 [Page 2]
INTERNET-DRAFT AD bit set on secure answers November 2000
INTERNET-DRAFT AD bit set on secure answers January 2001
If the answer section contains any data, the server MUST NOT include
@@ -129,11 +128,11 @@ INTERNET-DRAFT AD bit set on secure answers November 2000
resolver policy is that it can trust the server.
A DNS server following this modified specification will only set the
AD bit when it has verified the data in the answer. In the case of a
primary server for a secure zone, the data MAY be considered
Authenticated, depending on local policy. Secondary servers SHOULD
NOT consider data Authenticated unless the zone was transfered
securely or the data was verified.
AD bit when it has cryptographically verified the data in the answer.
In the case of a primary server for a secure zone, the data MAY be
considered Authenticated, depending on local policy. Secondary
servers SHOULD NOT consider data Authenticated unless the zone was
transfered securely or the data was verified.
3 - Interpretation of the AD bit
@@ -155,7 +154,7 @@ INTERNET-DRAFT AD bit set on secure answers November 2000
6 - Acknowledgments:
The following people have provided input on this document: Andreas
Gustafsson, Bob Halley, Steven Jacob,
Gustafsson, Bob Halley, Steven Jacob.
References:
@@ -168,9 +167,9 @@ References:
Expires May 2001 [Page 3]
Expires July 2001 [Page 3]
INTERNET-DRAFT AD bit set on secure answers November 2000
INTERNET-DRAFT AD bit set on secure answers January 2001
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
@@ -194,7 +193,7 @@ Authors Addresses
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
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
@@ -224,4 +223,4 @@ Full Copyright Statement
Expires May 2001 [Page 4]
Expires July 2001 [Page 4]

224
doc/draft/draft-ietf-dnsext-dnssec-roadmap-01.txt → doc/draft/draft-ietf-dnsext-dnssec-roadmap-02.txt
View File

@@ -6,7 +6,7 @@
DNEXT Working Group S. Rose
Internet Draft NIST
Expires: June 2001 January 2001
Expires: August 2001 February 2001
Category: Informational
@@ -14,7 +14,7 @@ Category: Informational
DNS Security Document Roadmap
------------------------------
<draft-ietf-dnsext-dnssec-roadmap-01.txt>
<draft-ietf-dnsext-dnssec-roadmap-02.txt>
Status of this Document
@@ -48,10 +48,10 @@ Abstract
data integrity and authentication to security aware
resolvers and applications through the use of
cryptographic digital signatures. Several documents
exist to describe these extensions and the implementation
specific details regarding specific digital signing
schemes. The interrelationship between these different
documents is discussed here. A brief overview of what to
exist to describe these extensions and the
implementation-specific details regarding specific
digital signing schemes. The interrelationship between
these different documents is discussed here. A brief
@@ -61,13 +61,13 @@ Rose [Page 1]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
find in which document and author guidelines for what to
include in new DNS Security documents, or revisions to
existing documents, is described.
overview of what to find in which document and author
guidelines for what to include in new DNS Security
documents, or revisions to existing documents, is
described.
@@ -120,7 +120,7 @@ Rose [Page 2]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
1. Introduction
@@ -147,13 +147,13 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
protocol extension, and what should be considered an operational
issue. Currently, there are at least two documents that fall under
operational security considerations that deal specifically with the
DNS security extensions: The first is RFC 2541 which deals with the
operational side of implementing the security extensions. The other
DNS security extensions: the first is RFC 2541 which deals with the
operational side of implementing the security extensions; the other
is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These documents
should be considered part of the operational side of DNS, but will be
addressed as a supplemental part of the DNS Security roadmap. That
is not to say that these two documents are not important to securing
a DNS zone, but it does not directly address the proposed DNS secu-
a DNS zone, but they do not directly address the proposed DNS secu-
rity extensions. Authors of documents that seek to address the
operational concerns of DNS security should be aware of the structure
of DNS Security documentation if they wish to include their documents
@@ -180,7 +180,7 @@ Rose [Page 3]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
possible that some documents fall into more than one of these
@@ -204,8 +204,8 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
| New | | DNSSEC | | New |
| Security | <------->| protocol |<-------->| Security |
| RRs | | | | Uses |
| [RFC2538, | | [RFC2535, | | |
| RFC2931, | | RFC3007, | +-------------+
| [RFC2538, | | [RFC2535, | | [SSH-DNS] |
| RFC2931, | | RFC3007, | +-------------+
| NO] | | RFC3008, |
+------------+ | CLARIFY, |
| SIZE ] |
@@ -240,17 +240,17 @@ Rose [Page 4]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
The "DNSSEC protocol" document set refers to the document that makes
up the groundwork for adding security to the DNS protocol [RFC2535]
and updates to this document. RFC 2535 laid out the goals and expec-
tations of DNS Security and the new security related Resource Records
tations of DNS Security and the new security-related Resource Records
KEY, SIG, and NXT. Expanding from this document, related document
groups include the implementation documents of various digital signa-
ture algorithms with DNSSEC, and documents further refining the tran-
saction of messages. It is expected that RFC 2535 will be obseleted
saction of messages. It is expected that RFC 2535 will be obsoleted
by one or more documents that refine the set of security extensions
and DNS security transactions. Documents that seek to modify or
clarify the base protocol documents should state so clearly in the
@@ -262,7 +262,7 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
[SIZE], [OKBIT], [ADBIT] and their derivative documents.
The "New Security RRs" set refers to the group of documents that seek
to add additional Resource Record to the set of base DNS Record
to add additional Resource Records to the set of base DNS Record
types. These new records can be related to securing the DNS protocol
[RFC2535], [RFC2931], [NO] or using DNS security for other purposes
such as storing certificates [RFC2538].
@@ -275,7 +275,7 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
and [GSS-TSIG].
The "Transactions" document set refers to the group of documents that
deal with the message transaction sequence of security related DNS
deal with the message transaction sequence of security-related DNS
operations. The contents and sequence for operations such as dynamic
update [RFC2137] [UPDATE] and transaction signatures [RFC2845] are
described in this document category. Additional message transaction
@@ -285,12 +285,12 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
related purposes. Documents that fall in this category include the
use of DNS in the distribution of certificates and individual user
public keys (PGP, email, etc.).
Lastly, there is a set of documents that should be classified as
"Implementation Notes". Because the DNS security extensions are
still in the developmental stage, there is an audience for documents
use of DNS in the storage and distribution of certificates and indi-
vidual user public keys (PGP, e-mail, etc.) Some documents in this
group may fall beyond the DNSEXT WG scope, but they are included
because of their use of the security extensions. The documents in
this group should not propose any changes to the DNS protocol to sup-
port other protocols; only how existing DNS security records and
@@ -300,33 +300,40 @@ Rose [Page 5]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
transactions can be used to support other protocols. One such docu-
ment is [SSH-DNS] which deals with storing SSH keys in the DNS using
the security records.
Lastly, there is a set of documents that should be classified as
"Implementation Notes". Because the DNS security extensions are
still in the developmental stage, there is an audience for documents
that detail the transition and implementation of the security exten-
sions. These have more to do with the practical side of DNS opera-
tions, but can also point to places in the protocol specifications
that need improvement. Documents in this set may be offspring of
both the DNSEXT and/or DNSOP working groups. Currently, there are
two Internet Drafts that falls under this category: The report on
the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
[ROLLOVER]. These documents were submitted through the DNSOP working
group, however the main concern of these documents is the implementa-
tion and limitations of the DNS security extensions, hence their
both the DNSEXT and/or DNSOP Working Groups. Currently, there are
two Internet Drafts that fall under this category: the report on the
CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
[ROLLOVER]. These documents were submitted through the DNSOP Working
Group, however the main concern of thesee documents is the implemen-
tation and limitations of the DNS security extensions, hence their
interest to the DNS security community. The CAIRN draft deals with
the implementation of a secure DNS, and the draft on key rollover
deals with updating DNS keys in a secure fashion. Authors of docu-
ments that deal with the implementation and operational side of the
DNSSEC specifications would be advised/encouraged to submit their
documents to the DNSEXT working group as well.
documents to the DNSEXT Working Group as well.
3. Relationship of DNS Security Documents to other DNS Documents
The DNS security related extensions should be considered a subset of
the DNS protocol. The DNS Security working group of the IETF
(DNSSEC) has been absorbed into the larger DNS Extensions working
group (DNSEXT). Therefore, all DNS security related documents should
The DNS security-related extensions should be considered a subset of
the DNS protocol. The DNS Security Working Group of the IETF
(DNSSEC) has been absorbed into the larger DNS Extensions Working
Group (DNSEXT). Therefore, all DNS security-related documents should
be seen as a subset of the main DNS architecture documents. It is a
good idea for authors of future DNS security documents to be familiar
with the contents of these base protocol documents.
@@ -344,13 +351,6 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
extension should also be included in the document. These criteria
are not officially part of the IETF guidelines regarding RFC/Internet
Drafts, but should be considered as guidance to promote uniformity to
working group documents.
Since the addition of security to the DNS protocol is now considered
A general extension to the DNS protocol, any guideline for the con-
tents of a DNS Security document could be taken as a suggestion for
the contents of any DNS extension document.
@@ -360,7 +360,15 @@ Rose [Page 6]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
Working Group documents.
Since the addition of security to the DNS protocol is now considered
a general extension to the DNS protocol, any guideline for the con-
tents of a DNS Security document could be taken as a suggestion for
the contents of any DNS extension document.
4.1 Security Related Resource Records
@@ -369,19 +377,19 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
should contain information describing the structure and use of the
new RR type. It is a good idea to only discuss one new type in a
document, unless the set of new resource records are closely related
or a protocol extensions requires the use of more than one new record
type. Specifically: each document detailing a new Security related
or a protocol extension requires the use of more than one new record
type. Specifically, each document detailing a new security-related
RR type should include the following information:
* The format of the new RR type, both "on the wire" (bit format) and
ASCII representation (for text zone files), if appropriate.
ASCII representation (for text zone files), if appropriate;
* When and in what section of a DNS query/response this new RR type
is to be included.
* when and in what section of a DNS query/response this new RR type
is to be included;
* At which level of the DNS hierarchy this new RR type is to be
* at which level of the DNS hierarchy this new RR type is to be
considered authoritative (i.e. in a zone, in a zone's superzone) and
who is authoritative to sign the new RR.
who is authoritative to sign the new RR;
4.2 Digital Signature Algorithm Implementations
@@ -391,11 +399,11 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
Security should include the following information:
* The format/encoding of the algorithm's public key for use in a
KEY Resource Record.
KEY Resource Record;
* The acceptable key size for use with the algorithm.
* the acceptable key size for use with the algorithm;
* The current known status of the algorithm (as one of REQUIRED,
* the current known status of the algorithm (as one of REQUIRED,
RECOMMENDED, or OPTIONAL).
In addition, authors are encouraged to include any necessary descrip-
@@ -405,14 +413,6 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
sions to the DNS protocol, not cryptographic research.
4.3 Refinement of Security Procedures
This set of documents includes DNS protocol operations that relate to
DNS Security specifically such as DNS secret key establishment [TKEY]
and security extensions to pre-existing or proposed DNS operations
such as dynamic update [RFC2137]. Documents that describe a new set
Rose [Page 7]
@@ -420,22 +420,28 @@ Rose [Page 7]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
of DNS message transactions, or seek to refine a current series of
transaction that make up a DNS operation SHOULD include the following
information:
4.3 Refinement of Security Procedures
This set of documents includes DNS protocol operations that specifi-
cally relate to DNS Security, such as DNS secret key establishment
[TKEY] and security extensions to pre-existing or proposed DNS opera-
tions such as dynamic update [RFC2137]. Documents that describe a
new set of DNS message transactions, or seek to refine a current
series of transactions that make up a DNS operation SHOULD include
the following information:
* The order in which the DNS messages are sent by the operation ini-
tiator and target.
tiator and target;
* The format of these DNS messages.
* the format of these DNS messages;
* Any required authentication mechanisms for each stage of the
* any required authentication mechanisms for each stage of the
operation and the required authority for that mechanism (i.e. zone,
host, or some other trusted authority such as a DNS administrator or
certificate authority).
certificate authority);
4.4 The Use of DNS Security Extensions with Other Protocols
@@ -445,10 +451,10 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
extend, the DNS security protocols. Examples of this type of docu-
ment include the use of DNS to support the Public Key Infrastructure
(PKI). It is beyond the scope of this roadmap to describe the con-
tents of this class of documents. However, if uses or extensions
tents of this class of documents. However, if uses or extensions
require the addition or modification of a DNS Resource Record type or
DNS query/response transactions, then the guidelines laid out in the
previous sections of this document SHOULD be adhered too.
previous sections of this document SHOULD be adhered to.
5. Security Considerations
@@ -465,12 +471,6 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
numerous Internet drafts that fall in one or more of the categories
of DNS Security documents mentioned above. Depending on where (and
if) these documents are on the IETF standards track, the reader may
not be able to access these documents through the RFC repositories.
For that reason, the version of the Internet drafts that were refer-
enced in this document are given below:
* SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". <draft-ietf-
dnsind-sigalgopt-00.txt>
@@ -480,11 +480,17 @@ Rose [Page 8]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
not be able to access these documents through the RFC repositories.
For that reason, the version of the Internet drafts that were refer-
enced in this document are given below:
* SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". <draft-ietf-
dnsind-sigalgopt-00.txt>
* CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone
Status" <draft-ietf-dnsext-zone-status-03.txt>
Status" <draft-ietf-dnsext-zone-status-05.txt>
* AUTH: B. Wellington. "Domain Name System Security (DNSSEC)
Signing Authority" <draft-ietf-dnsext-signing-auth-01.txt>
* CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa-
@@ -492,11 +498,11 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
* UPDATE: B. Wellington. "Secure Domain Name System (DNS) Dynamic
Update". <draft-ietf-simple-secure-update-02.txt>
* SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver
message size requirements". <draft-ietf-dnsext-message-size-01.txt>
message size requirements". <draft-ietf-dnsext-message-size-03.txt>
* GSS-TSIG: S. Kwan, P. Garg, J. Gilroy, and L. Esibov. "GSS
Algorithm for TSIG (GSS-TSIG)". <draft-ietf-dnsext-gss-tsig-01.txt>
* NO: S. A. Josefsson. "Authenticating Denial of Existence in DNS
with Minimum Disclosure". <draft-jas-dnsext-no-01.txt>
with Minimum Disclosure". <draft-ietf-dnsext-not-existing-rr-01.txt>
* OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC".
<draft-ietf-dnsext-dnssec-okbit-01.txt>
* RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the
@@ -504,9 +510,11 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
* ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS)
Security Key Rollover" <draft-ietf-dnsopt-rollover-00.txt>.
* ADBIT: B. Wellington. "Redefinition of DNS AD bit" <draft-
ietf-dnsext-ad-is-secure-00.txt>
ietf-dnsext-ad-is-secure-01.txt>
* OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" <draft-
kosters-dnsext-dnssec-opt-in-00.txt>
* SSH-DNS: W. Griffin. "Storing SSH Host Keys in DNS" <draft-
griffin-ssh-host-keys-in-dns-00.txt>
7. References
@@ -523,14 +531,6 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
RFC 2137, April 1997.
[RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", RFC 2539, March 1999.
[RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2930] D. Eastlake, "Secret Key Establishment for DNS" RFC 2930,
September 2000.
@@ -540,9 +540,17 @@ Rose [Page 9]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
Name System (DNS)", RFC 2539, March 1999.
[RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2930] D. Eastlake, "Secret Key Establishment for DNS" RFC 2930,
September 2000.
[RFC2931] D. Eastlake "DNS Request and Transaction Signatures
(SIG(0))" RFC 2931, September 2000.
@@ -582,15 +590,7 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001
Expiration and File Name:
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-01.txt> expires June 2001
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-02.txt> expires June 2001
@@ -600,9 +600,14 @@ Rose [Page 10]
INTERNET-DRAFT DNS Security Document Roadmap January 2001
INTERNET-DRAFT DNS Security Document Roadmap February 2001
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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
@@ -643,11 +648,6 @@ INTERNET-DRAFT DNS Security Document Roadmap January 2001

3378
doc/draft/draft-ietf-enum-e164-gstn-np-00.txt → doc/draft/draft-ietf-enum-e164-gstn-np-01.txt
View File

File diff suppressed because it is too large Load Diff

882
doc/draft/draft-ietf-enum-operation-01.txt
View File

@@ -1,882 +0,0 @@
Telephone Number Mapping A. Brown
Internet Draft Nortel Networks
Document: <draft-ietf-enum-operation-01.txt> Greg Vaudreuil
Lucent Technologies
October 27, 2000
ENUM Service Specific Provisioning:
Principles of Operation
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.
Vaudreuil Expires March 2001 1
ENUM Operations Auguest 18, 2000
Table of Contents
1. Abstract........................................................1
2. Introduction....................................................2
3. Scope...........................................................2
4. Overview........................................................3
4.1 Relationship with Dynamic Services.............................3
4.2 Number Portability.............................................4
5. The ENUM Service................................................4
5.1 First Level: Determining the Delegated Authority...............4
5.2 Second Level: Determining the Service Registrar................5
5.3 Third Level: Retrieving Resource records.......................6
5.4 Service-Specific Queries.......................................6
6. Interesting Numbering Topologies...............................7
6.1 Subaddressing..................................................7
6.2 Default and Range-based Service Records........................8
7 Illustrative System Examples.....................................9
7.1 Example: Hypothetical Reachme Service..........................9
7.2 Example: SIP Call Setup Service Request.......................10
8. Security Considerations........................................11
9. References.....................................................12
10. Acknowledgments...............................................12
11. Author's Addresses............................................12
12. Full Copyright Statement......................................13
Appendix: changes from draft-ietf-enum-operations-00.txt..........14
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 architecture and mechanics 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.
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.
Vaudreuil Expires January 2001 2
ENUM Operations Auguest 18, 2000
4. Overview
This telephone number-based directory system implements a four-level
information model, the first two constituting the ENUM service
itself. This model is based on analysis of pre-existing
administrative structures, generalized service requirements, and the
capabilities of candidate protocols.
The mechanics of the ENUM service are specified in [ENUM]
The first level is the mapping of the telephone number delegation
tree to the authority to which the number has been delegated.
Conceptually, this delegated authority knows nothing about service-
specific information associated with the telephone number but can
provide a reference to the appropriate entity that does know the
specific information.
The second is the delegation from the authority to which the
telephone number has been delegated to the service registrar. The
registrar is conceptually responsible for maintaining the set of
service records for a given telephone number. 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. 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.
The third level 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.
If necessary, an additional service-specific level of information
can be provided by the service provider itself. This level 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
ED Note: Text requested discussing FAST UPDATE VS SLOW UPDATE. WG
decided only slow update is in scope for ENUM. Discuss timing
considerations for propagation of changed records at various levels.
Illustrate how time-of-day services should be provided at the
service-specific level.
The telephone number delegation information changes infrequently.
However, when a change to this data is made, the information must be
Vaudreuil Expires January 2001 3
ENUM Operations Auguest 18, 2000
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
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 [portability]. In support of
number portability, the ENUM service provides mechanism at the three
conceptual levels of the ENUM service.
1. If the number has been redelegated to another authority, the
telephone number can be redelegated in the ENUM service to that
authority by changing the name server "NS" records to point to the
new authority. This may be the case where numbers are redelegated
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. Assuming the delegated
authority and service registrar are separate entities, the DNAME
or CNAME redirection records pointing to the previous service
registrar would be changed to point to the new service registrar.
The appropriate service specific NAPTR records would be recreated
by the new service registrar 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 Level: Determining the Delegated Authority
The first level 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. From the client's perspective, this level is transparent,
bundled within the query for the service-specific resource records
stored at the second level.
Vaudreuil Expires January 2001 4
ENUM Operations Auguest 18, 2000
The delegation of telephone numbers from the root authority (the
ITU) down to individuals is a well-established system that can be
utilized. These telephone number registrars have a trusted
relationship with their delegated carriers or subsidiary registrars;
a valuable asset to ensure protection against various attacks. Note
that in this model, the delegation of telephone number blocks or
individual numbers to a corporation or to an individual can be
administratively and technically modeled as a subdelegation to
another carrier. With that additional information publicly
registered, the mapping between telephone numbers and these domain
names can be provided by any neutral entity. The delegated
authority, subdelegated authority, or individual may arrange to have
a third-party (e.g., a service provider) list their 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-level 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 subaddress. 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 subaddress 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 Level: Determining the Service Registrar
In the event that the designated authority is not the same as the
service registrar, the DNAME and CNAME records provide the
redirection from the designated authority to the service registrar.
The DNAME provides a means for reforming and re-issuing a query for
a "non-terminal" domain name. As is standard for compliant DNS
Vaudreuil Expires January 2001 5
ENUM Operations Auguest 18, 2000
resolver libraries, clients must support the CNAME record type.
Servers that provide for substitution MAY support the DNAME record
to provide redirection for an entire telephone number range as a DNS
subtree. These servers MUST provide synthesized CNAME records for
the proper operation of older resolver libraries that have not been
extended to understand DNAME. Servers that redirect queries on a
per-telephone number basis MUST support CNAMES.
From the client's perspective, this level may be transparent based
on the capabilities of the resolver library in use. The client
(with the help of a suitable DNS library) must be able interpret
returned CNAME and should be able to resolve DNAME records into a
new domain name. The new domain name MUST be used to continue the
query for the requested service records.
It is important to ensure that DNS configurations provide only one
path from the e164.arpa tree to a single DNS leaf-node entry. If
multiple paths point to the same node, the substitution string
provided in the NAPTR may provide unintended results. In
particular, substitution expressions which use the original
telephone number string may result in different URI's depending upon
which number was used to initiate the ENUM query.
5.3 Third Level: Retrieving Resource records.
The third level 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 telcoservice 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.4 Service-Specific Queries
An additional level of query may be used to a service-specific
directory for service-specific information. As indicated in the
URI, such a query may include a SIP query to a designated gatekeeper
or an LDAP query to a designated directory server. This level 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.
Vaudreuil Expires January 2001 6
ENUM Operations Auguest 18, 2000
6. Interesting Numbering Topologies
The following numbering uses require special consideration in the
provision and use of ENUM services.
6.1 Subaddressing
The E.164 standard provides for subaddressing 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 subaddress 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
subaddressing by a given endpoint. Within ENUM, subaddressing may be
supported in two ways. The service registrar may explicitly
provision NAPTR records for each subaddress, or the service
registrar may provision default records for a range of subaddresses.
Using common DNS server implementations, the registrar may provision
default records for a block of subaddresses. 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 subaddress, 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 subaddresses
may be queried without the subaddress 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 which can prompt for the appropriate internal extension.
However, when placing a SIP call using IP telephony, the address
plus the subaddress 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 subaddress, and whether the subaddress is explicitly
provisioned or not. Calling using SIP to the explicitly provisioned
subaddress 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!" .
Vaudreuil Expires January 2001 7
ENUM Operations Auguest 18, 2000
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 subaddressing, 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.SvcReg.company.com
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.SvcReg.company.com
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.SvcReg.company.com
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 a number within the 100's block that
does not have an explicit entry will be sent to tel#@company.com.
Mail is not accepted at the automated attendant number as indicted
by the lack of a mailto service record. Because extension 22 has an
explicit record, it must also have an explicit mailto: URL in a
NAPTR record.
Vaudreuil Expires January 2001 8
ENUM Operations Auguest 18, 2000
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.6.1.3.1.e164.arpa
Sample configuration file for the top level 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.ServiceProviderA.net.
;for +1 613 555 XXXX
In this example, ServiceProviderA.net is the authority to which the
telephone number has been delegated. ServiceProviderA.net provides
a non-terminal redirection pointer to Zcorporation, the designated
service registrar for the block of 100 numbers +1 613 555 12XX. The
configuration for this block of numbers is:
2.1.5.5.5.3.1.6.1.e164.arpa.
DNAME 2.1.5.5.3.1.6.1.Zcorporation.com.
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.Zcorporation.com.
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 CNAME 2.1.2.1.5.5.5.3.1.6.1.Zcorporation.com
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.
Vaudreuil Expires January 2001 9
ENUM Operations Auguest 18, 2000
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 level 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 and hosts the service records directly without
using a DNAME record. 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.
Vaudreuil Expires January 2001 10
ENUM Operations Auguest 18, 2000
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.
Vaudreuil Expires January 2001 11
ENUM Operations Auguest 18, 2000
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.
[DNAME]
[NAPTR] M. Mealling, R. Daniel _The Naming Authority Pointer (NAPTR)
DNS Resource Record_, RFC 2915, September 2000.
[Portability]
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
Vaudreuil Expires January 2001 12
ENUM Operations Auguest 18, 2000
12. 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
Vaudreuil Expires January 2001 13
ENUM Operations Auguest 18, 2000
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.
Vaudreuil Expires January 2001 14

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

@@ -0,0 +1,945 @@
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

65
doc/draft/draft-ietf-idn-dnsii-mdnp-01.txt → doc/draft/draft-ietf-idn-dnsii-mdnp-02.txt
View File

@@ -1,10 +1,10 @@
IDN Working Group Edmon Chung & David Leung
Internet Draft Neteka Inc.
<draft-ietf-idn-dnsii-mdnp-01.txt> August 2000
<draft-ietf-idn-dnsii-mdnp-02.txt> February 2001
DNSII Multilingual Domain Name Protocol
The DNSII Multilingual Domain Name Protocol
STATUS OF THIS MEMO
@@ -29,9 +29,21 @@ STATUS OF THIS MEMO
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
@@ -41,30 +53,25 @@ Abstract
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
transparent to the end-user. Which means initially the server, or
more specifically, the resolver, SHOULD take the primary
responsibility for the technical implementation of the changes
required for a multilingual Internet.
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. Besides the original specifications therefore, four
alternatives are included for discussion purposes in this document.
Chung & Leung [Page 1]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
This draft forms the introduction of a series of draft including
intended resolution processes and other DNSII documents.
names.
Table Of Contents
1. Introduction....................................................2
1.1 Terminology....................................................2
1.2 DNSII..........................................................2
1.2 DNSII..........................................................3
2. DNSII Protocol..................................................3
2.1 InPacket DNSII Identifier......................................3
2.2 InPacket Label Encoding Type (ILET)............................4
@@ -102,19 +109,12 @@ Table Of Contents
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.
1.2 DNSII
Many of the current proposals for a multilingual domain name system
involve working around the current ANSI based DNS. So doing either
affects the integrity of the original spirit of the DNS or does not
well address the encoding conflict issues apparent in different
character encoding schemes.
Chung & Leung [Page 2]
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
@@ -165,10 +165,7 @@ Chung & Leung [Page 2]
scheme.
Chung & Leung [Page 3]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
2.2 InPacket Label Encoding Type (ILET)
@@ -398,7 +395,7 @@ Chung & Leung [Page 6]
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
@@ -512,7 +509,7 @@ Chung & Leung [Page 8]
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
@@ -682,7 +679,7 @@ Chung & Leung [Page 11]
Chung & Leung [Page 12]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
: :
/ /
+---------------------------------------------------------------+
@@ -712,7 +709,7 @@ Chung & Leung [Page 12]
http://www.dnsii.org.
8. References
[DNSII-MDNR] E. Chung, D. Leung, _DNSII Multilingual Domain Name
Resolution_, August 2000
@@ -739,10 +736,10 @@ Chung & Leung [Page 12]
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.
@@ -795,5 +792,3 @@ Chung & Leung [Page 13]
Chung & Leung [Page 14]

90
doc/draft/draft-ietf-idn-dnsii-mdnr-00.txt → doc/draft/draft-ietf-idn-dnsii-mdnr-01.txt
View File

@@ -1,7 +1,7 @@
IDN Working Group Edmon Chung & David Leung
Internet Draft Neteka Inc.
<draft-ietf-idn-dnsii-mdnr-00.txt> August 2000
<draft-ietf-idn-dnsii-mdnr-01.txt> February 2001
@@ -30,33 +30,37 @@ STATUS OF THIS MEMO
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.
The DNSII-MDNR outlines a resolution process that forms a framework
for the resolution of multilingual domain names. 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 enabled DNS system. It also
outlines the conformance levels required for basic or complete
implementations for applications, resolvers and name servers.
This document also introduces a tunneling mechanism for the short-run
to transition the system through to a truly multilingual capable name
space.
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
Chung & Leung [Page 1]
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
@@ -103,6 +107,11 @@ Table of Contents
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.
@@ -110,10 +119,6 @@ Table of Contents
Chung & Leung [Page 2]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
1.2 Multilingual Domain Name Resolution
The original specifications for the DNS were designed to be open
@@ -160,15 +165,7 @@ Chung & Leung [Page 2]
Chung & Leung [Page 3]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
+---------------+
@@ -225,7 +222,6 @@ Chung & Leung [Page 3]
Chung & Leung [Page 4]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Case folding for multilingual domain names should follow the existing
@@ -282,7 +278,6 @@ Chung & Leung [Page 4]
Eventually, an ISO 10646 UCS without transformation is desired as the
common format. The benefits of having a uniform byte length encoding
Chung & Leung [Page 5]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
far exceeds the seemingly easier transformation solution. Especially
@@ -320,7 +315,7 @@ Chung & Leung [Page 5]
| | (3) Upon the detection | |
| | of the DNSII Flag | |
| | resolver will reply | |
| | with "Format Error" | |
| | with _Format Error_ | |
| | | |
| |----------------------->| | (5) Current resolu-
| | (4) Send QNAME using | | tion process begins
@@ -339,7 +334,6 @@ Chung & Leung [Page 5]
Chung & Leung [Page 6]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
It is not feasible to have a new RR type just for DNSII because the
@@ -358,7 +352,7 @@ Chung & Leung [Page 6]
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
_-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.
@@ -396,7 +390,6 @@ Chung & Leung [Page 6]
Chung & Leung [Page 7]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
(The Additional DNSII RR Tunneled in TXT RR form)
@@ -414,7 +407,7 @@ Chung & Leung [Page 7]
+---------------------------------------------------------------+
96| t |1 0|0 0| UCS-2=1000 | 4 |
+---------------------------------------------------------------+
100|1 1| 13 |1 0|z| ILET=2 | 4 |
100|1 1| 13 |1 0|z| ILET=2 | 4 |
+---------------------------------------------------------------+
104| —Œ (U+57DF) | ªW (U+540D) |
+---------------------------------------------------------------+
@@ -453,7 +446,6 @@ Chung & Leung [Page 7]
Chung & Leung [Page 8]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Following the example given in 3.2.1, the QNAME would be in UTF-8
@@ -491,7 +483,7 @@ Chung & Leung [Page 8]
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
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.
@@ -508,9 +500,8 @@ Chung & Leung [Page 8]
Continuing on the example given in Section 3.2, suppose an A record
is requested and the IP address returned for the domain host.—ŒªW¿t™ð
Chung & Leung [Page 9]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
.tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the
@@ -567,9 +558,10 @@ Chung & Leung [Page 9]
necessary for all servers and applications to be switched to
multilingual capable before starting the deployment.
Chung & Leung [Page 10]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
4.1 Application Conformance Levels
The BASIC compliancy for applications would be to remove validity
@@ -622,8 +614,6 @@ Chung & Leung [Page 10]
should however prepare for the transition towards a multilingual name
space even if they do not intend to deploy it right away.
Chung & Leung [Page 11]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
@@ -680,7 +670,6 @@ Chung & Leung [Page 11]
resolution.
Chung & Leung [Page 12]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
6.1 Client/Application Resolution Strategy
@@ -689,7 +678,7 @@ Chung & Leung [Page 12]
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
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
@@ -703,7 +692,7 @@ Chung & Leung [Page 12]
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-"
THEN send query in ASCII with _-for-tunneling-only-_
label
AND append DNSII RR
AND check for DNSII ANS RR in response
@@ -737,7 +726,6 @@ Chung & Leung [Page 12]
ELSE use InZone DNSII mechanisms AND use 8-bit clean approach
Chung & Leung [Page 13]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
7. Security Considerations
@@ -794,8 +782,7 @@ Chung & Leung [Page 13]
Chung & Leung [Page 14]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Authors:
@@ -848,8 +835,7 @@ DNSII-MDNR Multilingual Domain Name Resolution August 2000
Chung & Leung [Page 15]

220
doc/draft/draft-ietf-idn-idna-00.txt → doc/draft/draft-ietf-idn-idna-01.txt
View File

@@ -1,9 +1,9 @@
Internet Draft Paul Hoffman
draft-ietf-idn-idna-00.txt IMC & VPNC
September 12, 2000 Patrik Faltstrom
Expires in six months Cisco
Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-01.txt Cisco
Paul Hoffman
Expires in six months IMC & VPNC
Internationalizing Host Names In Applications (IDNA)
Internationalizing Host Names In Applications (IDNA)
Status of this Memo
@@ -20,11 +20,11 @@ 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 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 list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
@@ -51,6 +51,11 @@ 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
To date, the proposals for IDN protocols have required that DNS servers
@@ -67,10 +72,10 @@ as well.
Updating all (or even a significant percentage) of the DNS servers in
the world will be difficult, to say the least. Because of this, we have
designed a protocol that requires no updating of any name servers. IDNA
still requires the updating of applications, but once a
user has updated these, she or he could immediately start using
internationalized host names. The cost of implementing IDN would thus be
much lower, and the speed of implementation will be much higher.
still requires the updating of applications, but once a user has updated
these, she or he could immediately start using internationalized host
names. The cost of implementing IDN would thus be much lower, and the
speed of implementation will be much higher.
1.2 Terminology
@@ -78,15 +83,6 @@ 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 IDN summary
Using the terminology in [IDNCOMP], this protocol specifies an IDN
architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE),
and the method for distinguishing ACE name parts from current name parts
is ace-2.1.1 (add hopefully-unique legal tag). Because there is no
changes needed to the DNS, the transition strategy is trans-1 (always do
current plus new architecture).
2. Structural Overview
@@ -99,30 +95,36 @@ and process the inputs and outputs from the DNS.
The interfaces in IDNA can be represented pictorially as:
+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+--------------- v -------------------------------+
| +-------------+ |
| | Application | | End system
| +-------------+
| ^
| | API call and return: nameprepped RACE
| v
| +----------+
| | Resolver |
| +----------+ |
+----------------^--------------------------------+
| DNS query and response: nameprepped RACE
v
+-------------+
| DNS servers |
+-------------+
+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+--------------- v -------------------------------+
| +-------------+ |
| | Application | | End system
| +-------------+
| ^
| | API call and return: nameprepped ACE
| v
| +----------+
| | Resolver |
| +----------+ |
+----------------^--------------------------------+
| DNS query and response: nameprepped ACE
v
+-------------+
| DNS 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 Users and applications
Applications can accept host names using any character set or sets
@@ -132,56 +134,53 @@ 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 RACE [RACE] ASCII-compatible encoding.
Applications MAY allow RACE input and output, but are not encouraged to
do so except as an interface for advanced users, possibly for debugging.
RACE 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 RACE encodings in the user interface is described
in section 3. Since RACE can be rendered either as the encoded ASCII
glyphs or the proper decoded character glyphs, the rendering engine for
an application SHOULD have an option for the user to select the
preferred display; if it does, rendering the RACE SHOULD NOT be the
default.
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
advanced users, 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. Since ACE can be rendered
either as the encoded ASCII glyphs or the proper decoded character
glyphs, the rendering engine for an application SHOULD have an option
for the user to select the preferred display; if it does, rendering the
ACE SHOULD NOT be the default.
2.1.2 Applications and resolvers
Applications communicate with resolver libraries through a programming
interface (API). Typically, the IETF does not standardize APIs, although
it has 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.
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 RACE, the application MUST prepare
each name part as specified in [NAMEPREP]. The application MUST use RACE
ASCII-compatible encoding for the name parts that are sent to the
resolver, and will always get name parts encoded in RACE from the
resolver.
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 RFC 1035
[STD13]) and internationalized host name parts. An IDNA-aware
application that is resolving a non-internationalized host name parts
MUST NOT do any preparation or conversion to RACE on any
non-internationalized name part.
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 parts 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 RACE. 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 [STD
13]), or the nameprepped, RACE-encoded name part. Such a library would
help keep applications smaller.
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 RACE format for internationalized host name
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 RACE to
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.
@@ -198,10 +197,10 @@ of resolution to users.
3. Name Server Considerations
It is imperative that there be only one encoding for a particular host
name. RACE is an encoding for host name parts that use characters
outside those allowed for host names [STD 13]. Thus, a primary master
name server MUST NOT contain an RACE-encoded name that decodes to a host
name that is allowed in [STD 13].
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
@@ -212,7 +211,7 @@ application will ever ask for a name that is not legal in [NAMEPREP]
because requests always go through [NAMEPREP] before getting to the DNS.
The host name data in zone files (as specified by section 5 of RFC 1035)
MUST be both nameprepped and RACE encoded.
MUST be both nameprepped and ACE encoded.
4. Root Server Considerations
@@ -238,26 +237,54 @@ security considerations from that document as well.
6. References
[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare.
[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep.
[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
draft-ietf-idn-race.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
10646", January 1998, RFC 2279.
[STD13] Paul Mockapetris, "Domain names - implementation and
specification", November 1987, STD 13 (RFC 1035).
[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.
A. Authors' Addresses
B. Changes from the -00 draft
Throughout: Changed "RACE" to "ACE" and removed RACE-specific wording.
1: Added pointer to the mailing list.
1.3: Removed the [IDNCOMP] comparison section.
2.1: Added the last paragraph discussing ACEs.
2.1.2: Changed the discussion of IPv6 APIs to say they are not
standards. Added reference to [STD3].
2.1.3: Added reference to [STD3]. Removed the sentence about making
things smaller.
3: Added reference to [STD3].
6: Added [STD3], and updated the reference info for [STD13].
Removed [IDNCOMP].
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
@@ -265,8 +292,9 @@ Internet Mail Consortium and VPN Consortium
Santa Cruz, CA 95060 USA
phoffman@imc.org
Patrik Faltstrom
Cisco Systems
170 West Tasman Drive SJ-13/2
San Jose, CA 95134 USA
paf@cisco.com
--
Patrik F„ltstr÷m <paf@cisco.com> Cisco Systems
Consulting Engineer Office of the CSO
Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-8509
PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC

509
doc/draft/draft-ietf-idn-lace-00.txt → doc/draft/draft-ietf-idn-lace-01.txt
View File

@@ -1,7 +1,7 @@
Internet Draft Mark Davis
draft-ietf-idn-lace-00.txt IBM
November 6, 2000 Paul Hoffman
Expires May 6, 2001 IMC & VPNC
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
@@ -26,7 +26,6 @@ material or to cite them other than as "work in progress."
http://www.ietf.org/shadow.html.
Abstract
This document describes a transformation method for representing
@@ -52,7 +51,7 @@ 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
Row-based ACE or LACE, that can be used with protocols that match arch-2
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
@@ -62,7 +61,9 @@ 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].
"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:
@@ -96,9 +97,10 @@ Hexadecimal values are shown preceded with an "0x". For example,
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".
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
@@ -112,8 +114,7 @@ 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. In this list, "row" means
a row from ISO 10646.
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.
@@ -139,22 +140,22 @@ 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
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 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
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 "bq--" at the
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 "bq--" unless those names are post-converted
names. Creating host part names that begin with "bq--" but that are not
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
@@ -179,33 +180,38 @@ 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.
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.
2.2.1 Check the input string for disallowed names
2.2.1 Compress the pre-converted string
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.2 Check the length of 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.3 Encode the compressed string with Base32
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.4 Prepend "bq--" to the encoded string and finish
2.2.5 Prepend "lq--" to the encoded string and finish
Prepend the characters "bq--" to the encoded string. This is the host
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
@@ -223,11 +229,11 @@ 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--"
2.3.1 Strip the "lq--"
The input string MUST begin with the characters "bq--". If it does not,
The input string MUST begin with the characters "lq--". 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
"lq--" from the input string. The result of this step is the stripped
string.
2.3.2 Decode the stripped string with Base32
@@ -246,6 +252,12 @@ 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
@@ -255,9 +267,9 @@ 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 almost all names in
almost scripts. Also, this limit is close to the limits set by other
encoding proposals.
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
@@ -268,53 +280,54 @@ section.
2.4.1 Compressing a string
The input string is in big-endian UTF-16 encoding with no byte order
mark.
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 of the input is not even, or is less than 2, stop with
an error.
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 pairs at or after IP that have HIGH as the
first octet; call this COUNT.
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+1)).
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), output the
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.
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, go to step 10.
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. Set IP to IP+1. If IP is now at
the end of the input string, stop with an error.
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. 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. Get the octet at IP, call it LOW. 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.
@@ -322,17 +335,11 @@ the end of the input string, stop with an error.
8. If IP is not at the end of the input buffer, go to step 3.
9. Compare the length of the input string with the length of the output
buffer. If the length of the output buffer is longer than the length of
the input buffer, stop with an error because the wrong compression form
was used. Otherwise, send out the output buffer and stop.
10. Set IP to IP+1. Copy the rest of the input buffer to the output
buffer. Compress the output buffer into a separate comparison buffer
following the steps for compression above. If the length of the
comparison buffer is less than or equal to the length of the output
buffer, stop with an error because the wrong compression form was used.
Otherwise, send out the output buffer and stop.
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
@@ -342,16 +349,16 @@ 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+012E U+0110 U+014A U+00C5> are represented
in big-endian UTF-16 as the eight octets <01 2E 01 10 01 4A 00 C5>. The
output buffer has eight octets <03 01 2E 10 4A 01 00 C5>, which is the
same length as the input string. Thus, the output is <03 01 2E 10 4A 01
00 C5>.
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+012E U+00D0 U+014A> are represented in
big-endian UTF-16 as the six octets <01 2E 00 D0 01 4A>. The output
buffer is nine octets <01 01 2E 01 00 D0 01 01 4A>, which is longer than
the input buffer. Thus, the output is <FF 01 2E 00 D0 01 4A>.
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
@@ -418,15 +425,23 @@ is in the hex column).
The input is octets in network byte order. The input octets MUST be
values from the second column in Table 1.
1) Set the read pointer to the beginning of the input octet stream.
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) Look up the character value of the octet in the char column (or hex
value in hex column) of Table 1, and output the five bits from the bits
column.
2) Set the read pointer to the beginning of the input octet stream.
3) Move the read pointer one octet forward. If the read pointer is at
the end of the input octet stream (that is, there are no more octets in
the input), stop. Otherwise, go to step 2.
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
@@ -488,6 +503,9 @@ 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).
@@ -498,16 +516,335 @@ specification", November 1987, STD 13 (RFC 1035).
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. IANA Considerations
B. Sample code
There are no IANA considerations in this document.
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) ×{
parseResult.set("Lace: count out of range", iCount);
return;
}
if ((iCount % 2) == 1) ×{
parseResult.set("Lace: odd length, can't be UTF-16", iCount);
return;
}
var op = 0; ×// input index
var ip = 0; ×// output index
var lastHigh = -1;
var lenp = 0;
while (ip < iCount) {
var high = iArray[ip++];
if (high != lastHigh) {
if (lastHigh != -1) { ×// store last length
var len = op - lenp - 2;
oArray[lenp] = len;
} ×
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) ×{
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) { ×// special case FF
copyTo(iArray, 1, iCount-1, oArray, 0);
result = iCount-1;
} else {
while (ip < iCount) { ×// 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) ×{
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;
} ×
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); ×// 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;
}
C. Author Contact Information
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

239
doc/draft/draft-ietf-idn-requirements-03.txt → doc/draft/draft-ietf-idn-requirements-04.txt
View File

@@ -1,6 +1,6 @@
IETF IDN Working Group Editors Zita Wenzel, James Seng
Internet Draft draft-ietf-idn-requirements-03.txt
28 June 2000 Expires 28 November 2000
Internet Draft draft-ietf-idn-requirements-04.txt
04 October 2000 Expires 04 March 2001
Requirements of Internationalized Domain Names
@@ -49,48 +49,109 @@ list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
1.1 Definitions and Conventions
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].
A language is a way that humans interact. In computerised form, a text
in a written language can be expressed as a string of characters.
The same set of characters can often be used for many written languages,
and many written languages can be expressed using different scripts.
The same characters are often shown with somewhat different glyphs
(shapes)
for display of a text depending on the font used, the automatic shaping
applied, or the automatic formation of ligatures. In addition, the same
characters can be shown with somewhat different glyphs (shapes) for
display
of a text depending on the language being used, even within the same
font
or trough automatic font change.
A character is a member of a set of elements used for organization,
control, or representation of textual data.
A graphic character is a character, other than a control function,
that has a visual representation normally handwritten, printed, or
displayed.
Characters mentioned in this document are identified by their position
in the Unicode [UNICODE] character set. The notation U+12AB, for
example, indicates the character at position 12AB (hexadecimal) in the
Unicode character set. Note that the use of this notation is not an
indication of a requirement to use Unicode.
in the Unicode [UNICODE] character set. This character set is also
known as the UCS [ISO10646]. The notation U+12AB, for example, indicates
the character at position 12AB (hexadecimal) in the Unicode character
set. Note that the use of this notation is not an indication of a
requirement to use Unicode.
Examples quoted in this document should be considered as a method to
further explain the meanings and principles adopted by the document. It
is not a requirement for the protocol to satisfy the examples.
A character is a member of a set of elements used for organization,
control, or representation of data.
Unicode Technical Report 17 [UTR17] defines a character encoding
model in several levels (much of the text below is quoted from
Unicode Technical Report 17 [UTR17]):
A coded character is a character with its coded representation.
1. A abstract character repertoire (ACR) is defined as the set of
abstract characters to be encoded, normally a familiar alphabet
or symbol set. The word abstract just means that these objects
are defined by convention (such as the 26 letters of the English
alphabet, uppercase and lowercase forms). Examples: the ASCII
repertoire, the Latin-15 repertoire, the JIS X 0208 repertoire,
the UCS repertiore (of a particular version).
A coded character set ("CCS") is a set of unambiguous rules that
establishes a character set and the relationship between the characters
of the set and their coded representation.
2. A coded character set (CCS) is defined to be a mapping from a
set of abstract characters to the set of non-negative integers.
This range of integers need not be contiguous. An abstract
character is defined to be in a coded character set if the coded
character set maps from it to an integer. That integer is said
to be the code point for the abstract character. That abstract
character is then an encoded character. Examples: ASCII, Latin-15,
JIS X 0208, the UCS.
A graphic character or glyph is a character, other than a control
function, that has a visual representation normally handwritten,
printed, or displayed.
3. A character encoding form (CEF) is a mapping from the set of integers
used in a CCS to the set of sequences of code units. A code unit
is an integer occupying a specified binary width in a computer
architecture, such as a septet, an octet, or a 16-bit unit. The
encoding form enables character representation as actual data in
a computer. The sequences of code units do not necessarily have the
same length. Examples: ASCII, Latin-15, Shift-JIS, UTF-16, UTF-8.
A character encoding scheme or "CES" is a mapping from one or more
coded character sets to a set of octets. Some CESs are associated with
a single CCS; for example, UTF-8 [RFC2279] applies only to ISO 10646.
Other CESs, such as ISO 2022, are associated with many CCSs.
4. A character encoding scheme (CES) is a mapping of code units into
serialized octet sequences. Character encoding schemes are relevant
to the issue of cross-platform persistent data involving code units
wider than a byte, where byte-swapping may be required to put data
into the byte polarity canonical for a particular platform.
A charset is a method of mapping a sequence of octets to a sequence of
abstract characters. A charset is, in effect, a combination of one or
more CCS with a CES. Charset names are registered by the IANA according
to procedures documented in [RFC2278].
The CES may involve two or more CCS's, and may include code units
(e.g. single shifts, SI/SO, or escape sequences) that are not part
of the CCS per se, but which are defined by the character encoding
architecture and which may require an external registry of particular
values (as for the ISO 2022 escape sequences). In such a case, the
CES is called a compound CES. (A CES that only involves a single
CCS is called a simple CES.)
A language is a way that humans interact. In written form, a language
is expressed in characters. The same set of characters can often be
used in many languages, and many languages can be expressed using
different scripts. A particular charset MAY have different glyphs
(shapes) depending on the language being used.
Examples: ASCII, Latin-15, Shift-JIS, UTF-16BE, UTF-16LE, UTF-8.
5. The mapping from an abstract character repertoire (ACR) to a
serialised
sequence of octets is called a Character Map (CM). A simple character
map thus implicitly includes a CCS, a CEF, and a CES, mapping from
abstract characters to code units to octets. A compound character
map includes a compound CES, and thus includes more than one CCS
and CEF. In that case, the abstract character repertoire for the
character map is the union of the repertoires covered by the coded
character sets involved.
Character Maps are the things that in the IAB architecture get IANA
charset identifiers. A sequence of encoded characters must be
unambiguously mapped onto a sequence of octets by the charset. The
charset must be specified in all instances, as in Internet
protocols, where textual content is treated as a ordered sequence
of octets, and where the textual content must be reconstructible
from that sequence of octets. Charset names are registered by the
IANA according to procedures documented in [RFC2278]. In many cases,
the same name is used for both a character map and for a character
encoding scheme, such as UTF-16BE. Typically this is done for simple
character maps when such usage is clear from context.
6. A transfer encoding syntax (TES) is a reversible transform of encoded
data which may (or may not) include textual data represented in
one or more character encoding schemes. Examples: 8bit,
Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE).
1.2 Description of the Domain Name System
@@ -100,7 +161,7 @@ clarifications, extensions and modifications given in [RFC1123],
security extensions described in [RFC2535] and companions.
Over the years, many different words have been used to describe the
components of resource naming on the Internet (e.g., [URI], [URN]); to make
components of resource naming on the Internet (e.g., URI, URN); to make
certain that the set of terms used in this document are well-defined and
non-ambiguous, the definitions are given here.
@@ -138,9 +199,10 @@ The form specified for most protocols using the DNS is a limited form of
the master file format domain name. This limited form is defined in
[RFC1034] Section 3.5 and [RFC1123]. In most implementations of
applications today, domain names in the Internet have been limited to
the much more restricted forms used, e.g., in email. Those names are
limited to the ASCII upper and lower-case characters (interpreted in a
case-independent fashion), the digits, and the hyphen.
the much more restricted forms used, e.g., in email. Those names are
limited to the upper- and lower-case letters a-z (interpreted in a
case-independent fashion), the digits, and the hyphen-minus, all in
ASCII.
1.3 Definition of "hostname" and "Internationalized Domain Name"
@@ -170,7 +232,8 @@ The DNS can be seen as a multilayer function:
- Above that is the "DNS service", created by an infrastructure of DNS
servers, NS records that point to those DNS servers, that is
pointed to by the root servers (listed in the "root cache file" on each DNS
pointed to by the root servers (listed in the "root cache file" on
each DNS
server, often called "named.cache". It is at this level that the
statement "the DNS has a single root" [RFC2826] makes sense, but
still, what are being transferred are octets, not characters.
@@ -276,22 +339,26 @@ internationalized domain name.
names as described in [RFC1034]. It MUST maintain a single, global,
universal, and consistent hierarchical namespace.
[2.5] The DNS service layer (the packet formats that go on the wire)
MUST NOT limit the codepoints that can be used. This interface SHOULD
NOT assign meaning to name strings; the application service layer,
where "gethostbyname" et al reside, MAY constrain the name strings to
be used in certain services. (conflict)
[2.5] The DNS protocol (the packet formats that go on the wire) MUST
NOT limit the codepoints that can be used. A service defined on top of
the DNS, for instance the IDN-to-address function, MAY limit the
codepoints that can be used. The service descriptions MUST describe
what limitations are imposed.
[2.6] The protocol MUST work for all features of DNS, IPv4, and
IPv6. The protocol MUST NOT allow an IDN to be returned to a requestor
that requests the IP-to-(old)-domain-name mapping service.
[3] The same name resolution request MUST generate the same response,
regardless of the location or localization settings in the resolver, in
the master server, and in any slave servers involved in the resolution
process.
[4] The protocol SHOULD allow creation of caching servers that do
not understand the charset in which a request or response is encoded.
The caching server SHOULD perform correctly for IDN as well as for
current domain names (without the authoritative bit) as the master
server would have if presented with the same request.
[4] The protocol MUST NOT require that the current DNS cache
servers be modified to support IDN. If a cache server can have
additional functionality to support IDN better, this additional
functionality MUST NOT cause problems for resolving correctly
functioning current domain names.
[5] A caching server MUST NOT return data in response to a query that
would not have been returned if the same query had been presented to an
@@ -321,27 +388,23 @@ used in DNS names and records. The protocol MUST specify what charset is
used when resolving domain names and how characters are encoded in DNS
records.
[12] This document RECOMMENDS Unicode only. If multiple charsets are
allowed, each charset MUST be tagged and conform to [RFC2277].
[12] Codepoints SHOULD be from the Universal Set as defined in
ISO-10646 or Unicode. The specifics of versions MUST be defined in the
proposed solution. If multiple charsets are allowed, each charset MUST
be tagged and conform to [RFC2277].
[12.5] IDN MUST NOT return illegal code points in responses, SHOULD
reject queries with illegal codepoints. (one request to add; one request
to remove)
[13] CES(s) chosen SHOULD NOT encode ASCII characters differently
depending on the other characters in the string. In other words, unless
IDN names are identified and coded differently from ASCII-only ones,
characters in the ASCII set SHOULD remain as specified in [US-ASCII]
(one request to remove).
[12.5] The protocol MUST NOT reject any non-IDN characters (to be
defined) in any queries or responses.
[14] The protocol SHOULD NOT invent a new CCS for the purpose of IDN
only and SHOULD use existing CES. The charset(s) chosen SHOULD also be
non-ambiguous.
[15] The protocol SHOULD NOT make any assumptions about the location in
a domain name where internationalization might appear. In other words,
it SHOULD NOT differentiate between any part of a domain name because
this MAY impose restrictions on future internationalization efforts.
[15] The protocol SHOULD NOT make any assumptions about the location
in a domain name where internationalization might appear. In other
words, it SHOULD NOT differentiate between any part of a domain name
because this MAY impose restrictions on future internationalization
efforts. For example, the TLDs can be internationalized.
[16] The protocol also SHOULD NOT make any localized restrictions in the
protocol. For example, an IDN implementation which only allows domain
@@ -354,10 +417,6 @@ domain name input and display, IDN is only concerned with the
protocol. Therefore, there MUST be a single way of encoding an
internationalized domain name within the DNS.
[18] The protocol SHOULD NOT place any restrictions on the
application service layer. It SHOULD only specify changes in the DNS
service layer and within the DNS itself.
2.4 Canonicalization
Matching rules are a complicated process for IDN. Canonicalization
@@ -431,9 +490,7 @@ local-rule-ignorant) caches.
[36] The protocol MUST work with DNSSEC.
[37] The protocol MUST work for all features of DNS, IPv4, and IPv6.
4. Security Considerations
3. Security Considerations
Any solution that meets the requirements in this document MUST NOT be
less secure than the current DNS. Specifically, the mapping of
@@ -449,7 +506,7 @@ MUST be compatible with DNSSEC and, if multiple charsets or
representation forms are permitted, the implications of this name-spoof
MUST be throughly understood.
5. References
4. References
[CHARREQ] "Requirements for string identity matching and String
Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
@@ -501,29 +558,42 @@ MUST be throughly understood.
[IDNCOMP] "Comparison of Internationalized Domain Name Proposals",
draft-ietf-idn-compare-00.txt, June 2000, P. Hoffman.
[UNICODE] 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
[ISO10646] ISO/IEC 10646-1:2000 (note that an amendment 1 is in
preparation), ISO/IEC 10646-2 (in preparation), plus
corrigenda and amendments to these standards.
[UNICODE] The Unicode Consortium, "The Unicode Standard". Described at
http://www.unicode.org/unicode/standard/versions/.
[UNICODE30] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Same repertoire as ISO/IEC
10646-1:2000. Described at
http://www.unicode.org/unicode/standard/versions/Unicode3.0.html.
[US-ASCII] Coded Character Set -- 7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
Information Interchange, ANSI X3.4-1986; also: ISO/IEC
646 (IRV).
[UTR15] "Unicode Normalization Forms", Unicode Technical Report
#15, http://www.unicode.org/unicode/reports/tr15/,
Nov 1999, M. Davis & M. Duerst, Unicode Consortium.
[UAX15] "Unicode Normalization Forms", Unicode Standard Annex #15,
http://www.unicode.org/unicode/reports/tr15/, 2000-08-31,
M. Davis and M. Duerst, Unicode Consortium.
[UTR17] "Character Encoding Model", Unicode Technical Report #17,
http://www.unicode.org/unicode/reports/tr17/, 2000-08-31,
K. Whistler and M. Davis, Unicode Consortium.
[UTR21] "Case Mappings", Unicode Technical Report #21,
http://www.unicode.org/unicode/reports/tr21/, Dec 1999,
M. Davis, Unicode Consortium. Approved status.
http://www.unicode.org/unicode/reports/tr21/, 2000-09-12,
M. Davis, Unicode Consortium.
6. Editors' Contact
5. Editors' Contact
Zita Wenzel, Ph.D.
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, CA
Marina del Rey, CA
90292 USA
Tel: +1 310 448 8462
Fax: +1 310 823 6714
@@ -537,7 +607,7 @@ Tel: +65 248 6208
Fax: +65 248 6198
Email: jseng@pobox.org.sg
7. Acknowledgements
6. Acknowledgements
The editors gratefully acknowledge the contributions of:
@@ -553,7 +623,7 @@ Ned Freed <ned.freed@innosoft.com>
Olafur Gudmundsson <ogud@tislabs.com>
Paul Hoffman <phoffman@imc.org>
Simon Josefsson <jas+idn@pdc.kth.se>
Karlsson Kent <keka@im.se>
Kent Karlsson <keka@im.se>
John Klensin <klensin+idn@jck.com>
Tan Juay Kwang <tanjk@i-dns.net>
Dongman Lee <dlee@icu.ac.kr>
@@ -562,3 +632,6 @@ Dan Oscarsson <Dan.Oscarsson@trab.se>
J. William Semich <bill@mail.nic.nu>
James Seng <jseng@pobox.org.sg>

530
doc/draft/draft-ietf-idn-udns-01.txt → doc/draft/draft-ietf-idn-udns-02.txt
View File

@@ -1,7 +1,7 @@
Internet Draft Dan Oscarsson
draft-ietf-idn-udns-01.txt Telia ProSoft
Updates: RFC 2181, 1035, 1034, 2535 27 August 2000
Expires: 27 February 2001
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
Using the Universal Character Set in the Domain Name System (UDNS)
@@ -34,9 +34,11 @@ Abstract
started to experiment with non-ASCII names.
This document defines how the Universal Character Set (UCS)
[ISO10646] can be used in DNS without extending the current [RFC1035]
protocol and how DNS is extended to overcome length limits in the
future.
[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
@@ -44,16 +46,16 @@ 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
using UTF-8 in use, and others using other methods.
Dan Oscarsson Expires: 27 Februray 2001 [Page 1]
Dan Oscarsson Expires: 24 August 2001 [Page 1]
Internet Draft Universal DNS 27 August 2000
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
that do not work together, and to avoid breaking the current ASCII
only DNS, there is an immediate need to standardise how DNS shall
@@ -65,10 +67,6 @@ Internet Draft Universal DNS 27 August 2000
all octets are to be used in character data allowing a standardised
way to use non-ASCII in DNS.
To support the software where only ASCII host and domain names are
allowed, this document defines how resource records are to be
returned in a response to avoid breaking that software.
The specification here conforms to the IDN requirements [IDNREQ].
1.1 Terminology
@@ -85,6 +83,10 @@ Internet Draft Universal DNS 27 August 2000
1.2 Previous versions of this document
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.
The second version of this document was available as draft-ietf-idn-
udns-00.txt. It included a lot of possibilities as well as a flag bit
that is now removed.
@@ -100,147 +102,107 @@ Internet Draft Universal DNS 27 August 2000
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
is fully compatible with the DNS of today.
For a long time there will be software understanding UCS in DNS and
software only understanding ASCII in DNS. It is therefore necessary
to support a mixing of both types. For the following text software
understanding UCS in DNS will be called UDNS aware.
This specification supports the following scenarios:
- UDNS unaware client, UDNS aware DNS server
- UDNS aware client, UDNS unaware DNS server
- UDNS aware client, UDNS unaware DNS server
Dan Oscarsson Expires: 27 Februray 2001 [Page 2]
Internet Draft Universal DNS 27 August 2000
2.1 Fundamentals
2.1 Character data
2.1.1 Standard Character Encoding (SCE)
Character data need to be able to represent as much as possible of
the characters in the world as well as being compatible with ASCII.
It must also be well defined so that it can easily be handled and
should be compact as only 63 octets is available without an extension
of the protocol. Character data is used in labels and in text fields
in the RDATA part of a RR.
Character data is used in labels and in text fields in the RDATA part
of a RR.
Character data used in the DNS protocol MUST:
The Standard Character Encoding of character data used in the DNS
protocol MUST:
- Use ISO 10646 (UCS) [ISO10646] as coded character set.
- Be normalised using form C as defined in Unicode technical report
#15 [UTR15]. See also [CHNORM].
- Encoded using the UTF-8 [RFC2279] character encoding scheme.
2.2 Name matching
2.1.2 Binary Comparison Format (BCF)
RFC 1035 states that the labels of a name are matched case-
insensitively. When using UCS this is no longer enough as there are
other forms than case that need to match as equivalent.
other forms than case that need to match as equivalent. Form-
insensitive matching of UCS includes:
- Letters of different case are compared as the same character.
- Code points of primary typographical variations of the same
character are compared as the same character. An example is double
width/normal width characters or presentation forms of a
character.
- Some characters are represented with multiple code points in UCS.
All code points of one character must compare as the same. For
example the degree Kelvin sign is the same as the letter K.
The original definition is now extended to be: labels must be
compared using form-insensitivity.
For the UCS character code range 0-255 (ASCII and ISO 8859-1) the
case folding MUST be done by case-insensitive matching following the
one to one mapping as defined in the Unicode 3.0 Character Database
[UDATA].
How to do form-insensitive matching for the rest of UCS will be
defined in a separate document.
2.2.1 Rules for matching of domain names in DNS servers
To be able to handle correct domain name matching in lookups, the
following MUST be followed by DNS servers:
- Do matching on authorative data using form-insensitive matching
for the characters used in the data (for example a zone using only
ASCII need only handle matching of ASCII characters).
- On non-authorative data, either do binary matching or case-
insensitive matching on ASCII letters and binary matching on all
others.
The effect of the above is:
- 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
their authorative zones.
Dan Oscarsson Expires: 27 Februray 2001 [Page 3]
Dan Oscarsson Expires: 24 August 2001 [Page 3]
Internet Draft Universal DNS 27 August 2000
Internet Draft Universal DNS 24 February 2001
- it normally gives fast lookup because data is usually sent like:
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
binary matching. So the impact of complex matching rules should
not slow down DNS very much.
To handle form-insensitivity it is here defined the Binary Comparison
Format (BCF) to which strings can be mapped. After strings is mapped
to BCF they can be compared using binary string comparison.
Implementors may implement the form-insensitive comparison without
using BCF, as long as the results are the same.
2.3 Supporting older software and allowing for ASCII aliases.
Mapping of a label to BCF is typically done by steps like: changing
all upper case letters to lower case, mapping different forms to one
form and changing different code points of one character into a
single code point.
As there is a lot of software expecting host and domain names to only
use a subset of ASCII, they may work incorrectly if receiving a
response with non-ASCII characters. And when communicating between
nations it is sometimes good to also have a version of a name that
can be used by most people.
For the UCS character code range 0-255 (ASCII and ISO 8859-1) the BCF
MUST be done by mapping all upper case characters to lower case
following the one to one mapping as defined in the Unicode 3.0
Character Database [UDATA].
To support this the following MUST be followed:
- Queries for PTR records must return two records if the name
pointed to includes non-ASCII. They may also return two records if
an alternative name exist for the object pointed to.
The two records MUST be ordered with the ASCII version of the name
first and the non-ASCII or true name second. The second record
defines the true name of the object, the first record an ASCII
version of the name.
The definition of the Binary Comparison Format (BCF) for the rest of
UCS will be defined in a separate document. The nearest today is
[NAMEPREP].
Note: older software will normally stop analysing a response when
finding the first PTR record so they will get the ASCII name.
Newer software can select the name best suited for its needs.
- Queries for other records with non-ASCII in the RDATA section MUST
return an ASCII version also, unless the client is known to handle
non-ASCII.
2.1.3 Backward Compatibility Encoding (BCE)
At a future date IETF can decide that it is no longer necessary to
support the software only handling ASCII names, and the servers can
stop including ASCII versions in the responses.
To support older software expecting only ASCII and to support
downgrading from 8-bit to 7-bit ASCII in other protocols (like SMTP)
a Backward Compatibility Encoding (BCE) is available. It is a
transition mechanism and will no longer be supported at some future
time when it is so decided.
NOTE: a cache server shall return data in the same way as an
authorative server. If some do not and change the order of the PTR
records, some old software will not get the ASCII version of the
name.
2.3.1 ASCII versions of a name
When returning an ASCII version of a name, there are two
possibilities: returning a user defined ASCII alias or an ASCII
compatible encoding (ACE) of the name.
The ASCII Compatible Encoding (ACE) is used to support older software
expecting only ASCII and to support downgrading from 8-bit to 7-bit
Dan Oscarsson Expires: 27 Februray 2001 [Page 4]
Internet Draft Universal DNS 27 August 2000
ASCII in other protocols (like SMTP). It is a transition mechanism
and will no longer be supported at some future time when it is so
decided.
All software following this specification MUST recognise ACE and
decode them into their true name when doing matching and handling. A
DNS server must recognise ACE in a query.
The Backward Compatibility Encoding (BCE) of a label is defined as
the BCF of the label encoded using an ASCII Compatible Encoding
(ACE).
The definition of the ACE to be used, is defined in a separate
document. Typical definitions that are suitable are [SACE] and
[RACE].
NOTE: To support the transition to UTF-8 in resolver code, it is
recommended that a server recognise local encodings for the zones it
is authorative for. This will allow clients using the local character
set in many cases even before the resolver code is upgraded.
2.4 Handling long names
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
@@ -252,6 +214,14 @@ Internet Draft Universal DNS 27 August 2000
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).
@@ -270,87 +240,132 @@ Internet Draft Universal DNS 27 August 2000
The limits for labels are updated since RFC 1025 as follows:
A label is limited to a maximum of 63 character code points in UCS
Dan Oscarsson Expires: 27 Februray 2001 [Page 5]
Internet Draft Universal DNS 27 August 2000
normalised using Unicode form C. The full name is limited to a
maximum of 255 character code points normalised as for a label.
A long label MUST always use the Standard Character Encoding (SCE).
As long labels are not understood by older software, a response MUST
not include a long label unless the query did. At a later date, IETF
may change this.
2.5 Handling to large responses and identifying non-ASCII clients
If a client sends the QNAME in the query using the long label type,
the client shows that it implements this specification and do not
need ASCII compatibility.
2.2 Rules for matching of domain names in UDNS aware DNS servers
If the client is not identified to follow this specification, the UDP
packet size is limited to 512 bytes. If then a response will not fit,
the response MUST set the TC bit (truncated) to indicate that. A
client may then resend the query using a long label in the query to
show that it can handle larger responses.
To be able to handle correct domain name matching in lookups, the
following MUST be followed by DNS servers:
- Do matching on authorative data using form-insensitive matching
for the characters used in the data (for example a zone using only
ASCII need only handle matching of ASCII characters).
- On non-authorative data, either do binary matching or case-
insensitive matching on ASCII letters and binary matching on all
others.
2.6 DNSSEC
The effect of the above is:
- 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
their authorative zones.
- it normally gives fast lookup because data is usually sent like:
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.
2.3 Mixing of UDNS aware and non-UDNS aware clients and servers
To handle the mixing of UDNS aware and non-UDNS aware clients and
servers the following MUST be followed for clients and servers.
2.3.1 Native UDNS aware client
A native UDNS aware client is a client supporting all in this
document.
When doing a query it MUST:
- Use the long label in the QNAME.
- If server rejected query due to long label, retry the query using
the normal short label. If the QNAME contains non-ASCII it must be
encoded using BCE.
- Handle answers containg BCE.
The client may skip trying a query using the long label if it knows
the server does not understand it.
2.3.2 Application based UDNS aware client
An application based UDNS aware client is a client supporting UDNS
through BCE handling in the application.
It only understands BCE and need only a non-UDNS aware resolver to
work. All encoding and decoding of BCE is handled in the
application.
Due to BCE being an ACE of BCF the names returned in an answer need
not contain the real form of the name. Instead it may contains the
simplified form used in name matching. As this is a transition
mechanism to support non-ASCII in names before the DNS servers have
been upgraded, it is acceptable and will give people a reason to
upgrade.
2.3.3 non-UDNS aware client
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.
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
contains non-ASCII, the non-ASCII labels must be encoded using
BCE.
- If a short label is used in a query and the QNAME contains non-
ASCII, an authorative server must handle the query if the
character encoding can be recognised. If must recognise SCE and
should recognise common encodings used for the labels in the
domain it is authorative for. Answers will use BCE for all labels
except the one matching QNAME. This will allow clients using the
local character set to work in many cases before the resolver code
is upgraded.
2.3.5 non-UDNS aware server
A non-UDNS server can only handle ASCII matching when comparing
names. It can support the transition mechanism with BCE. The
authorative zones will then have to be loaded with manually BCE
encoded names.
2.4 DNSSEC
As labels now can have non-ASCII in them, DNSSEC [RFC2535] need to be
revised so that it also can handle that.
3. User interface issues
Locally on a system or in a user interface a different character set
than the one defined to be used in the DNS protocol may be used.
Therefore software must map between the local character set and the
character set of the protocol, so that human beings can understand
it.
This means that a zone file that is edited in a text editor by a
person before being loaded into a DNS server must be allowed to be in
the local character set. Software may not assume that the user can
edit text encoded in UTF-8. A zone file transmitted between DNS
software that is not handled by a human, can be transmitted using any
format.
When character data is presented to a human or entered by a human,
software must, as good as possible, present it using local character
set and allow it to be entered using the local character set. It is
the responsibility of the software to convert between the local
character set and the one used in the protocol, not the human.
The down coding defined above allows all names to be entered and
displayed for all users, as long as at least the ASCII characters are
supported.
Dan Oscarsson Expires: 27 Februray 2001 [Page 6]
Internet Draft Universal DNS 27 August 2000
4.1 Applications using DNS software
If an application does a call to DNS, it must present the data to the
users in the local character set used by the user, down coding if
necessary. Software used to access DNS should give the application
programmer both the possibility of doing queries and getting
responses using local character set, and using UTF-8.
APIs like getipnodebyname should be updated with a IDN flag that
results in the name being returned using the current locale, instead
of native UTF-8 or ASCII format.
5. Effect on other protocols
3. Effect on other protocols
As now a domain name may include non-ASCII many other protocols that
include domain names need to be updated. For example SMTP, HTTP and
URIs. The ACE format can be used when interfacing with ASCII only
URIs. The BCE format can be used when interfacing with ASCII only
software or protocols. Protocols like SMTP could be extended using
ESMTP and a UTF8 option that defines that all headers are in UTF-8.
@@ -367,34 +382,22 @@ Internet Draft Universal DNS 27 August 2000
recommendations given above, so that a human will see the characters
in their local character set, if possible.
5.1 An example: SMTP
When using SMTP it may be extended to allow UTF-8 in headers and
addresses. It will then have to, when transferring an e-mail to a
SMTP system that have not been extended, encoded e-mail addresses and
IDNs into an ACE.
In this case an e-mail address could look like:
ra--XXXXX.surname@ra--YYYYY.com
where ra--XXXXX is the ACE of the given name and ra--YYYYY is the ACE
of one part of the domain name.
6. Security Considerations
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
Dan Oscarsson Expires: 27 Februray 2001 [Page 7]
Internet Draft Universal DNS 27 August 2000
a problem, security may be affected. As more characters than ASCII is
allowed, software only expecting ASCII and with no checks may now get
security problems.
7. References
5. References
[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
@@ -435,17 +438,18 @@ Internet Draft Universal DNS 27 August 2000
[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.
Dan Oscarsson Expires: 27 Februray 2001 [Page 8]
Internet Draft Universal DNS 27 August 2000
[IDNREQ] James Seng, "Requirements of Internationalized Domain
Names", draft-ietf-idn-requirement.
@@ -470,7 +474,7 @@ Internet Draft Universal DNS 27 August 2000
[RACE] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
for IDN", draft-ietf-idn-race.
8. Acknowledgements
6. Acknowledgements
Paul Hoffman giving many comments in our e-mail discussions.
@@ -490,6 +494,14 @@ Author's Address
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
@@ -497,61 +509,49 @@ Author's Address
Dan Oscarsson Expires: 27 Februray 2001 [Page 9]
Internet Draft Universal DNS 27 August 2000
Dan Oscarsson Expires: 27 Februray 2001 [Page 10]
Dan Oscarsson Expires: 24 August 2001 [Page 10]