+++ /dev/null
-
-
- INTERNET-DRAFT Eric A. Hall, Editor
- Document: draft-hall-dm-idns-00.txt Consultant
- Expires: May 2002 November 2001
-
-
- The Internationalized Domain Name System
-
-
- Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
- 1. Abstract
-
- The principle intention of this specification is to facilitate the
- deployment of a completely internationalized domain name syntax
- and service which new protocols, applications and host systems can
- use, but without disrupting the existing infrastructure. Towards
- that end, this document describes a series of elective
- encapsulation services and protocol extensions which cumulatively
- allow internationalized domain names to be stored and transmitted
- in the existing DNS message and within application data streams,
- according to the compliance level of the participating systems.
-
-
- \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
-
- Table of Contents
-
- 1. Abstract..................................................1
- 2. Definitions and Terminology...............................3
- 3. Introduction..............................................4
- 3.1. Background.............................................4
- 3.2. Objectives.............................................5
- 3.3. Common Usage Scenarios.................................7
- 3.4. User Audiences.........................................9
- 3.5. Service Overview......................................11
- 3.6. Process Example.......................................13
- 4. The Internationalized Namespace..........................19
- 4.1. Internationalized Domain Names and Labels.............20
- 4.2. Internationalized Host Identifiers....................27
- 4.3. STD13 Domain Names....................................28
- 4.4. STD13 Host Identifiers................................29
- 5. Transfer Encodings and Label Types.......................30
- 5.1. The EDNS/UTF-8 Label Type.............................31
- 5.2. The STD13 Legacy Label Type...........................33
- 6. Application Guidelines...................................36
- 6.1. Input and Output Charsets.............................37
- 6.2. Protocol and Application Data.........................38
- 6.3. DNS Lookups and Resolver Calls........................40
- 7. Resolver Guidelines......................................42
- 7.1. Resolver APIs.........................................42
- 7.2. Query Processing Services.............................44
- 7.3. The Hosts Database....................................48
- 8. Server Guidelines........................................49
- 8.1. Internationalized Zones...............................50
- 8.2. Namespace Visibility Restrictions.....................51
- 8.3. The Master File Format................................52
- 9. Caching Guidelines.......................................53
- 10. Security Considerations..................................53
- 11. IANA Considerations......................................54
- 12. References...............................................54
- 13. Acknowledgements.........................................55
- 14. Editor's Address.........................................55
-
-
- Hall I-D Expires: May 2002 [page 2] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
-
- 2. Definitions and Terminology
-
- This document unites, enhances and clarifies several pre-existing
- technologies. Readers are expected to be familiar with the
- following specifications:
-
- [AMC-ACE-Z] <draft-ietf-idn-amc-ace-z>, "AMC-ACE-Z version
- 0.3.1"
-
- [NAMEPREP] <draft-ietf-idn-nameprep>, "Preparation of
- Internationalized Host Names"
-
- [STD13] (RFC 1034) "Domain names - concepts and facilities",
- (RFC 1035) "Domain names - implementation and
- specification"
-
- [STD3] (RFC 1122) "Requirements for Internet Hosts --
- Communication Layers", (RFC1123) "Requirements for Internet
- Hosts -- Application and Support"
-
- [BCP18] (RFC 2277) "IETF Policy on Character Sets and
- Languages"
-
- [RFC2279] "UTF-8, a transformation format of ISO 10646"
-
- [RFC2671] "Extension Mechanisms for DNS (EDNS0)"
-
-
- The following abbreviations are used throughout this document:
-
- UCS (Universal Character Set) \93 The ISO/IEC 10646 character
- set repertoire, as represented by the Unicode 3.1
- specification.
-
- ACE (ASCII-Compatible Encoding) \93 A transfer encoding which
- encodes UCS character codes into a seven-bit codespace
- which is compatible with US-ASCII.
-
- UTF-8 (UCS Transformation Format, Eight-Bit) \93 A transfer
- encoding which encodes UCS characters into an eight-bit
- codespace which is compatible with DNS message formats.
-
- 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 RFC 2119.
-
- Hall I-D Expires: May 2002 [page 3] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
-
-
- 3. Introduction
-
- The domain name system (DNS) [STD13] currently defines a message,
- namespace and protocol. Although the DNS message is capable of
- transferring eight-bit character codes as protocol data,
- applications are currently limited to a subset of US-ASCII when
- they interact with the DNS namespace, and this restricted syntax
- is enforced by almost every TCP/IP application and protocol which
- utilizes domain names as embedded data (including, surprisingly,
- the DNS protocol).
-
- In order to allow for the use of a larger range of characters in
- the namespace, this document extends and clarifies a variety of
- Internet specifications so that characters from the Universal
- Character Set (UCS) [ISO10646] may be used in domain names. This
- document also extends the DNS message structure to allow for the
- use of UTF-8 [RFC2279] encoded characters for the purpose of
- transferring these domain names, but also provides an ASCII-
- compatible encoding (ACE) [AMC-ACE-Z] of these character codes
- which existing protocols and applications can use to access the
- internationalized domain names, and also provides identification
- mechanisms which allow the end-point systems to downwardly
- negotiate when needed. Finally, this document defines behavior for
- DNS systems which implement this architecture, including the end-
- point applications which generate and store DNS domain names, and
- the resolvers, caches and servers which process them.
-
- The mechanisms presented here are elective. Developers, zone
- administrators and network operators who wish to make use of the
- internationalized domain names may do so according to their own
- schedule. Those developers, administrators and operators who
- cannot or prefer not to implement the specified extensions can
- continue to use their legacy systems, and will still be able to
- access resources from the internationalized domain name system.
-
-
- 3.1. Background
-
- From one perspective, DNS is already an "eight-bit clean" system,
- in that the structured DNS message is capable of storing and
- transmitting eight-bit data without any additional effort.
- However, this perspective only considers one particular facet of
- the domain name system, and ignores the more critical aspect of
-
- Hall I-D Expires: May 2002 [page 4] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- the DNS namespace, which has rules that are entirely different
- from those which govern the message format.
-
- The DNS namespace (or more appropriately, the view of the
- namespace which applications use and enforce) is governed by rules
- set forth in RFC952 [RFC952], STD3 [STD3], and STD13, which
- collectively define the characters that are eligible for use with
- host names. These rules are meant to provide a common template
- which may be applied to either the DNS namespace or a local hosts
- database, such that a query for "host.example.com" can be
- processed through either system. The range of valid characters
- currently defined are the letters, numbers and hyphen characters
- from US-ASCII [ASCII] (additional rules also govern the valid
- order and length of a host name). Character code values outside of
- this range are valid in domain name messages, but are undefined
- when used in the namespace, and are subject to interpretation by
- the applications which generate them.
-
- The host name rules are enforced by almost every application and
- protocol which uses DNS to identify a host or system. This
- includes network utilities such as ping and traceroute which
- simply identify systems by name, and complex protocols such as
- SMTP which use domain names to determine message-routing paths.
- Portions of the DNS protocol itself are also affected by these
- restrictions, such as the domain names which may be used for NS
- resource records with sub-domain delegation operations (since
- these servers are connection targets, they are also required to be
- compliant with the host name rules).
-
- Because these domain names are so pervasive throughout the
- Internet (and even within proprietary applications that run on
- private networks), it is not possible to declare a "flag day" at
- which eight-bit domain names will be considered valid encodings of
- a particular character set. Instead, an extended namespace with a
- larger set of charset rules must be defined, an extended DNS
- protocol capable of supporting these domain names must be
- deployed, and a transitional mechanism which allows the old and
- new systems to interact must be established. This document
- attempts to meet these objectives.
-
-
- 3.2. Objectives
-
- In broad terms, this document has one overall goal, which is to
- facilitate the creation and use of an internationalized domain
- name system around a UCS namespace, a collection of UTF-8 and
-
- Hall I-D Expires: May 2002 [page 5] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- legacy-compatible encodings which are suitable for transferring
- internationalized domain names within DNS and the affected
- application data streams, and a negotiation mechanism which allows
- end-point systems to identify the encoding that they will use for
- a particular operation.
-
- One of the objectives stated above is to internationalize the
- existing DNS namespace, by allowing UCS characters to be used in
- host names and sub-domain delegations in old and new zones
- equally. As such, this document does not define a new namespace,
- but instead defines mechanisms by which leaf-nodes and sub-domains
- may be created within the existing hierarchy.
-
- UTF-8 was chosen as the primary transfer encoding of these domain
- names for several reasons. For one, there is a wide availability
- of tools and expertise surrounding UTF-8, and it is already widely
- deployed within development environments, operating systems and
- applications. Furthermore, BCP18 [BCP18] requires that new
- application protocols be able to use UTF-8 as application data,
- and for many applications, this specifically means domain names
- which are passed as data. All signs indicate that UTF-8 is
- currently and will continue to be the preferred eight-bit encoding
- on the Internet, and this specification embraces this position in
- its design.
-
- However, most of the network services currently in use are bound
- by the legacy host naming restrictions, and those applications and
- protocols will also need to be able to interact with resources
- from the internationalized namespace, even though they will not be
- compliant with the UTF-8 encoding mechanisms defined in this
- document. In order to allow these systems to participate, this
- specification also embraces the use of ACE as a seven-bit
- backwards-compatible encoding for legacy systems to use.
-
- Note that even though a single encoding could have been specified
- by this document, past and present requirements would not have
- been satisfied by a single choice. For example, supporting UTF-8
- alone would mean isolating legacy systems from resources in the
- UCS namespace, while supporting ACE alone would not have provided
- a truly internationalized namespace (the ACE encoded domain names
- still appear in user data quite frequently). By allowing the UTF-8
- and ACE encodings to coexist, the existing and emerging
- communities can both be served.
-
- Because both encodings will be active during the same time period,
- this document also defines DNS protocol extensions which allow the
-
- Hall I-D Expires: May 2002 [page 6] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- end-point systems to detect the encoding that is in use for a
- particular query/response pair. Note that these negotiation
- mechanisms not only allow new and legacy systems to interoperate,
- but they also provide a transition service for developers, zone
- administrators and end-users, in that ACE encoded domain names can
- be initially deployed within existing applications and DNS
- systems, while individual elements of the infrastructure can be
- upgraded without disturbing other components.
-
-
- 3.3. Common Usage Scenarios
-
- Discussion of the mechanism provided by this document depends upon
- the usage context of the domain names themselves. Domain names are
- extremely pervasive, and are used by almost every TCP/IP protocol
- and application in one form or another. However, most usages fall
- under one or more of the following scenarios:
-
- * Connection identifiers \93 Domain names are most commonly
- used as host-specific identifiers for outbound connection
- requests, whether this be for a command-line application
- such as ping, or as a host name which is stored in an
- application's configuration file. Another common usage
- scenario for connection identifiers is with reverse
- lookups, where a server is logging incoming connections by
- the corresponding domain name, or where a program such as
- netstat is displaying all of the application sessions which
- are currently active on a host. In both of these cases,
- domain names are passed through applications to a resolver,
- resulting in DNS queries and responses which eventually
- provide the requested DNS data.
-
- A related use (but one which does not generate DNS
- messages) is determining the host name of the local system.
- This is commonly found with applications and protocols that
- need to display the domain name of the local system as part
- of a protocol operation (such as an SMTP greeting banner)
- or as application data.
-
- Connection identifiers (and lookups in general) are
- probably the largest single use of domain names today, and
- this is likely to be the case with internationalized domain
- names as well. This document fully supports the use of
- internationalized domain names for lookup operations, as
- long as the calling application, the stub resolver, the
- local caching servers, and the authoritative servers for
-
- Hall I-D Expires: May 2002 [page 7] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- the specified domain name are compliant with this
- specification. If any of these components are not capable
- of supporting internationalized domain names in this
- manner, the ACE equivalent domain name will be negotiated
- for the operation at hand.
-
- * Protocol data \93 Some application protocols exchange domain
- names as protocol data, with those domain names either
- determining or altering a service-specific operation.
- Examples of this usage include SMTP envelopes ("RCPT TO
- <user@domain.dom>") where the domain name is used to
- determine whether or not a particular email message should
- be accepted for delivery, the HTTP HOST header field which
- identifies a specific document tree on a shared server,
- BOOTP/DHCP options, WHOIS input, and more.
-
- Because these protocols treat domain names as protocol
- data, most of these protocols also have specific formatting
- requirements which must be addressed before UTF-8 domain
- names can be used by these protocols directly. This
- document is intended to facilitate the use of UTF-8 encoded
- domain names in this manner, although it is expected that
- most of the protocol development groups will need to
- develop negotiation mechanisms before these protocols can
- use internationalized domain names directly. Until such
- work is completed, ACE equivalent domain names can be used
- to provide these protocols with access to the
- internationalized namespace.
-
- * Structured application data \93 Structured application data
- is similar to protocol data in that it can trigger or
- affect some protocol action, although this will not always
- occur. For example, a web browser can process an embedded
- IMG link which may be present in a web page, while a user
- can manually follow an embedded email link which is also
- stored in the same web page; even though both usage models
- share the same structured data format (URLs), they are
- processed differently by the application. Similarly, email
- messages typically contain multiple domain names as
- structured data in the message headers, and some of these
- domain names will directly affect subsequent protocol
- operations, while others will not.
-
- Because of this ambiguity, this document defines no
- specific treatment for structured application data. In some
- cases, no additional mechanisms will be required, while
-
- Hall I-D Expires: May 2002 [page 8] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- other scenarios will require negotiation mechanisms before
- an internationalized domain name can be used in the
- structured data (with ACE being required as the interim
- format). Each protocol development group is encouraged to
- analyze each usage independently, to classify the usage as
- a connection identifier, protocol data, or unstructured
- application data, and to determine the appropriate course
- of action for each usage accordingly.
-
- * Unstructured application data \93 Many application protocols
- provide free-text data which can contain domain names, but
- with those domain names existing as unstructured data. For
- example, an email message which is provided as a text/plain
- MIME body part may contain a domain name which identifies a
- system or service in the context of a specific application,
- but in an unstructured form ("your files were moved from
- server1 to server2"). Similarly, an email address may be
- provided in WHOIS output, but as unstructured data which
- does not affect the protocol.
-
- Given the application-specific nature of this data, it
- cannot be managed by any global protocol or process. Where
- a protocol has rules or restrictions on the data itself,
- then those rules are maintained, but some formatting rules
- may need to be extended before internationalized domain
- names (or their equivalents) can be encoded in the
- application data. For example, internationalized domain
- names in email messages may need to be converted to a
- preferred display charset, while ACE equivalents may be
- necessary for protocols which only support US-ASCII.
-
- Each of the above scenarios represent distinct handling cases
- where internationalized domain names may or may not be used
- directly. In some cases, the internationalized domain names may be
- used as soon as the applications and resolvers are configured to
- use them, while in other cases, measured and cautious deployment
- is required in order to prevent undue breakage. In the latter
- cases, however, the backwards-compatible ACE encoding is available
- so that the internationalized domain names can be used.
-
-
- 3.4. User Audiences
-
- Another perspective on the changes which will result from
- deploying the mechanisms described in this document can be seen by
- analyzing how any such changes will affect the different
-
- Hall I-D Expires: May 2002 [page 9] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- "audiences" who work with domain names, and who have their own
- unique context-specific usage requirements and objectives. The
- three main audiences discussed in this document are:
-
- * Developers. Protocol and application developers need to be
- able to incorporate internationalized domain names into
- their systems as easily as possible, although there are
- many factors which will affect such usage, including the
- input and output charsets and encodings which are available
- to the applications and protocols. Where feasible, this
- specification allows developers to choose any charset or
- encoding which may be required and suitable for use,
- although in most cases, a recommendation is also made for
- the use of UTF-8 in particular.
-
- Developers may adopt internationalized domain names for
- connection identifiers and lookup operations fairly
- quickly, such that users can use those system as soon as
- they have compliant systems (and they have a target domain
- name to communicate with). Implementing support for
- internationalized domain names in protocols and application
- data will require additional effort by the affected
- development groups.
-
- Support for ACE will be harder to implement, since it is a
- relatively new and untested encoding syntax, with no
- existing developer tools. This will likely be the largest
- hurdle to overcome when developing applications for use
- with this service.
-
- * Zone administrators. Organizations that wish to deploy
- internationalized domain names should be able to do so
- easily, at a reasonable cost, and without suffering
- excessive pre-conditions. Towards this objective, the
- mechanisms described by this document allow organizations
- to deploy and use internationalized domain names within any
- zone immediately, without requiring any other zone to have
- been updated beforehand (although there are specific and
- strong suggestions for upgrading the Internet's high-load
- servers as soon as possible).
-
- If an organization wishes to publish internationalized
- domain names for users to access and utilize, the
- authoritative servers for the affected zone must be
- compliant with the naming rules and message formats
- described by this document, which will almost certainly
-
- Hall I-D Expires: May 2002 [page 10] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- require the administrators of that zone to upgrade their
- servers. However, organizations may also choose to only
- deploy ACE encoded domain names if an immediate migration
- is not feasible, with the caveat that internationalized
- domain names in their native form will not be available
- from those zones.
-
- * Network operators. The systems and human users which
- generate DNS lookups are another area of concern, as these
- protocols, programs and users will expect these lookups to
- succeed, and will also expect that the visible namespace
- will be compatible with the capabilities of the requesting
- system at a minimum investment. This is a broad range of
- requirements.
-
- At a minimum, applications must be capable of generating
- and accepting the internationalized domain names if they
- are to use those domain names (see the "Developers"
- discussion above for the application requirements).
- Similarly, the local resolvers, caches and forwarders on
- the user's network must also support the message formats if
- they are to relay internationalized domain names between
- their local applications and the remote zones being
- queried. If the applications, resolvers and caches do not
- support these requirements, intermediary systems will
- perform the down-level negotiation automatically on their
- behalf such that additional effort is not required on the
- user's part.
-
- In summary, the developers, zone administrators and end-users can
- immediately participate in the internationalized namespace at no
- additional expense if they are content with using ACE encoded
- domain names, and can use internationalized domain names in their
- native form if they are willing to make the necessary investments.
- Furthermore, since the native and backwards-compatible encodings
- are not mutually exclusive, implementers of this specification
- have the option of adopting ACE for immediate use and then
- transitioning to internationalized domain names on a per-system,
- per-zone, or per-application basis, according to their schedule.
-
-
- 3.5. Service Overview
-
- This document specifies a variety of extensions to several
- different protocols and services in order to facilitate the use of
- internationalized domain names anywhere this support exists or can
-
- Hall I-D Expires: May 2002 [page 11] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- be implemented, and to provide a legacy-compatible domain name in
- all other situations.
-
- More specifically, this document defines or clarifies behavior for
- the following elements:
-
- * Host name character restrictions. Legacy protocols and
- applications are currently restricted to the legacy host
- naming rules, which only allow for a subset of US-ASCII
- characters (letters, digits and the hyphen character). This
- document redefines the characters which are valid within a
- host name so that system identifiers, domain name parts of
- host names, and new network services can use most of the
- characters from the UCS.
-
- * DNS message format. This document defines an extended label
- format based on the extended label services provided by
- RFC2671 (Extension Mechanisms for DNS - EDNS0) [RFC2671],
- with this label format being used to encapsulate UTF-8
- encoded internationalized domain names in DNS messages. Any
- DNS message which carries the UTF-8 encoded domain names is
- required to use the EDNS/UTF-8 label type defined in this
- document. Any DNS message which carries legacy domain names
- (including the ACE encoded equivalent domain names) is
- required to use the traditional message format.
-
- * Application handling rules. Applications can use
- internationalized domain names immediately for lookup
- operations that do not directly affect external services or
- protocols, and can use ACE encoding sequences to specify
- internationalized domain names in legacy protocol
- operations, and can use them both at the same time.
-
- * Stub resolvers. Stub resolvers will most likely need to
- provide a series of internationalized APIs in order to
- fully support applications that generate internationalized
- domain name lookups. For example, these APIs will almost
- certainly be required in order for the resolver to
- determine that the calling application is compliant with
- the host name requirements defined by this document, and
- that the domain names should be encoded in the proper label
- format. Although this specification does not dictate these
- APIs, it encourages their use, and provides some guidance
- on the issues surrounding their use.
-
-
- Hall I-D Expires: May 2002 [page 12] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- * Forwarders, resolving servers and caches. The user-side
- servers which process internationalized domain names have
- several protocol-specific requirements, including the
- negotiated fall-back service when UTF-8 queries fail.
-
- * Authoritative servers. A key part of this specification is
- the simultaneous support for internationalized and legacy
- compatible domain names in the UCS namespace, thereby
- allowing a domain name to be entered into an authoritative
- zone database once, and for the appropriate response to be
- generated by a server according to the label encoding from
- the associated query. In order for this to work, this
- specification requires authoritative servers which serve
- internationalized domain names to comply with specific
- conditions. This specification also allows existing servers
- to serve ACE equivalent domain names when the authoritative
- servers cannot be upgraded, although this typically results
- in lower levels of functionality.
-
- The elements listed above collectively define a completely
- internationalized domain name system, which is capable of
- servicing internationalized domain names in all compliant systems,
- and which is also capable of providing ACE encoded equivalent
- domain names when any component from the internationalized service
- is not available.
-
-
- 3.6. Process Example
-
- This section illustrates a series of query/response transactions
- under which the processes and protocols defined in this document
- function. This example uses a reverse lookup for the PTR resource
- record associated with the "14.2.0.192.in-addr.arpa." domain name
- (forward lookups work similarly, but the issues are more fully
- demonstrated by PTR lookups). Each of the various technologies
- shown below are described in later sections of this document. The
- sole purpose of this example is to provide an illustration of
- these mechanisms in order to facilitate better discussion.
-
- Note that this illustration represents a worst-case scenario
- (thereby exercising most of the functionality provided by this
- specification), and does not represent a typical scenario.
-
- a. First, a PTR resource record for 14.2.0.192.in-addr.arpa.
- is added to the internationalized zone database on the
- replication master server for the 2.0.192.in-addr.arpa.
-
- Hall I-D Expires: May 2002 [page 13] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- zone, with the resource record data value of
- "host.<idn>.example.com." (where <idn> is an
- internationalized domain name compliant with the host
- naming rules provided in this document). Both of these
- domain names have a primary representation consisting of
- UCS characters in some local encoding, but are also
- available as UTF-8 and ACE encoded data so they can be
- encapsulated within DNS queries and responses.
-
- Once the zone is reloaded and is replicated by the other
- authoritative servers for that zone, the domain names can
- be processed.
-
- b. An application on a remote system generates a DNS lookup
- for the PTR resource record associated with the
- 14.2.0.192.in-addr.arpa. domain name.
-
- If this is a legacy application, it issues the lookup using
- the only method it knows, which is to pass the domain name
- to the legacy resolver API. This would result in the
- resolver issuing a legacy DNS query for the PTR resource
- record associated with the specified domain name.
-
- If this application is compliant with this specification,
- it performs the following steps:
-
- 1. Verify that the resolver is capable of processing
- queries for UTF-8 domain names by probing for an
- internationalized API. If this step failed, then the
- domain name would be converted to the legacy STD13
- octet encoding in step 3.6.b.3 and passed to the
- resolver's legacy API.
-
- 2. Convert the domain name from its generated encoding to
- the canonical UCS characters, and then normalize and
- case-convert the UCS characters.
-
- 3. Convert the normalized and lowercased UCS characters
- to the charset or encoding used by the resolver's
- internationalized API.
-
- 4. Issue a lookup for the PTR resource record associated
- with the internationalized domain name, via the
- resolver's internationalized API.
-
-
- Hall I-D Expires: May 2002 [page 14] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- Note that even though the domain name is compatible
- with the legacy host name rules, the domain name is
- passed through the internationalized API so that
- servers can tell whether or not the original
- application is UTF-8 compliant, and can determine the
- format of any internationalized domain names which are
- to be returned in the response messages. This is
- required in case the queried resource record includes
- internationalized domain names as resource record data
- (as would be the case with PTR resource records), and
- is also required for the proper handling of any SOA or
- NS resource records which may be returned as
- additional data in the response.
-
- For the purpose of this example, we will assume that each
- of these steps were successfully performed.
-
- c. The client's stub resolver generates the query, with the
- Question Section of the query containing the UTF-8 encoded
- domain name encapsulated in an EDNS/UTF-8 extended label.
-
- d. The stub resolver sends the query to one of its configured
- resolving servers.
-
- e. The resolving server will either answer the query from its
- cache or forward the query to a name server which is
- authoritative for the namespace hierarchy, as per the
- normal query-resolution procedure. For the purpose of this
- example, we will assume that the server has no information
- about the specified domain name, so it forwards the query
- to one of the root zone's authoritative servers in order to
- begin the iterative resolution process.
-
- f. The queried server responds with a referral, providing
- delegation data for a zone in the path to the queried
- domain name. For the purposes of this example, we will use
- 192.in-addr.arpa. as the delegation domain specified in the
- referral message.
-
- The specific format of the referral will depend on whether
- or not the queried server understands the EDNS/UTF-8 label
- encoding. If the server is compliant with this
- specification (which it is, or else it wouldn't have
- answered with a referral), then the referral will also
- provide ENDS/UTF-8 encoded domain names in the Authority
- and Additional-Data Sections of the referral. If the server
-
- Hall I-D Expires: May 2002 [page 15] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- was not compliant with this specification, it would return
- an error upon seeing the extended label type, which would
- cause the resolving server to restart the query using the
- legacy label type.
-
- g. The resolving server decodes the UTF-8 encoded domain names
- to their UCS character representation, caches the resource
- records in their UCS form, and sends the query to one of
- the authoritative servers for the referral zone. Note that
- the cache did not normalize or case-convert the UCS
- characters; only the end-systems perform this work.
-
- h. In this case, the queried server does not understand the
- EDNS/UTF-8 label format, and has returned a FORMERR
- response code.
-
- i. When these errors are encountered, the current resolver
- (whether this is the client's stub resolver or a caching
- server in the query path) must convert the query domain
- name from its current form to a legacy-compatible encoding
- (either ACE or STD13 octet sequences, depending on the UCS
- characters which have been encoded), and then has to
- reissue the query in that format.
-
- In this case, the domain name only contains printable
- characters from US-ASCII, so the STD13 octet encoding is
- used for the fall-back query. Because the UCS domain name
- was normalized and lowercased before it was passed to the
- client's stub resolver, the legacy domain name will also be
- in this format (although it will be compared in a case-
- neutral form by the recipient server).
-
- Note that once this conversion takes place, the legacy
- label format is used for the remainder of the current query
- chain (this prevents excessive delays from multiple fall-
- back operations, which could result in timeouts at the
- original resolver or application).
-
-
- Hall I-D Expires: May 2002 [page 16] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- j. The queried server returns a delegation referral for the
- 2.0.192.in-addr.arpa. zone. Since the query arrived in the
- STD13 octet encoding, the server has no indicator of the
- client's capabilities, so the referral NS resource records
- will also be returned in legacy compatible form (either as
- STD13 octet sequences or as ACE encoded data, depending on
- the character codes provided in each label from each of the
- associated domain names).
-
- Note that even though these NS resource records will be
- restricted to legacy-compatible host names and label types,
- they may contain and reference ACE domain names. In this
- regard, a legacy server in the delegation path does not
- prevent internationalized domain names from being delegated
- or resolved, but only prevents them from being processed as
- EDNS/UTF-8 extended labels.
-
- Also note that once the authoritative servers for a zone
- have been discovered and cached, any subsequent UTF-8
- queries which are generated for the resources in that zone
- will be sent directly to one of those servers, bypassing
- the delegation hierarchy. As such, subsequent queries which
- are provided in EDNS/UTF-8 labels can be processed directly
- by the zone's authoritative servers, without the delegation
- servers disrupting the process.
-
- k. The resolving server decodes the STD13 octet sequences and
- ACE encoded domain names to their UCS character
- representations, caches the resource records, and resends
- the query to one of the authoritative servers for the
- referral zone.
-
- l. The queried server processes the request. Since this query
- arrived as an STD13 octet sequence, the server must compare
- the seven-bit characters from the domain name (which is all
- of them, in this example) in a case-neutral form. Note that
- if the query had arrived as ACE or UTF-8 encoded domain
- names, the server would have decoded the specified domain
- name to its canonical UCS characters and performed a case-
- exact match against the resulting characters.
-
- m. The queried server responds with the requested data. Note
- that the query was submitted in the legacy label form due
- to the fall-back processing which occurred in step 3.6.i,
- so the server will only respond to this query with STD13
-
- Hall I-D Expires: May 2002 [page 17] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- octet sequences or ACE encoded domain names, using the
- STD13 legacy label.
-
- n. The resolving server decodes the STD13 octet sequences and
- ACE encoded domain names to their UCS character
- representations, and caches the resource records. Since the
- query was originally received as an internationalized
- domain name (as indicated by the EDNS/UTF-8 extended label
- from the original query), the resolving server has to
- encode the answer data as UTF-8 before passing it back to
- the client's stub resolver. However, since the input was
- not provided in an encoded UCS form, the server has to
- normalize and case-convert the STD13 octet sequence in
- order to provide a valid internationalized domain name.
-
- o. The stub resolver decodes the UTF-8 encoded domain names
- which have been provided in the response message to their
- UCS character representation, and passes the data to the
- original calling application using the charset or encoding
- favored by the resolver.
-
- p. The application validates the received domain name by
- decoding the internationalized domain name to its canonical
- UCS characters, normalizing and down-casing the resulting
- domain name, and comparing the results with the answer data
- which was provided by the resolver.
-
- As can be seen, the UTF-8 name resolution process is identical to
- the current resolution process, with the addition of a single
- fall-back query in step 3.6.i which resulted in one extra
- query/response pair (roughly equivalent to adding one extra
- delegation referral into the query path), and with several
- different encoding conversions, as required by the participating
- systems and services. This example also illustrates the
- requirements which are placed on developers, zone administrators,
- and network operators in order for typical connection identifier
- services to function with UTF-8 domain names.
-
- However, if each system and service had used UTF-8 for encoding
- purposes (including everything between the stub resolver's APIs
- and the authoritative servers for the target zone), then no
- additional queries or conversions would have been required (other
- than the direct UCS conversions required for validation and
- caching, the latter of which can be performed separately without
- affecting the processing path). In this regard, the example above
- illustrates how this system can function even when only a portion
-
- Hall I-D Expires: May 2002 [page 18] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- of the participating systems utilize UTF-8, and also illustrates
- how effective the entire operation would be if all of the
- recommendations and requirements provided in this specification
- were adopted.
-
- It is also important to reiterate here that any such costs
- associated with this compliance are entirely elective by the
- affected parties. If they want to streamline the process, the
- option is available to them, although the system also works when
- very few optimizations are implemented.
-
-
- 4. The Internationalized Namespace
-
- In simple terms, this specification defines an internationalized
- namespace which consists of domain names and labels that contain
- UCS character codes, and also specifies a series of encoding
- formats which may be used whenever the UCS values need to be
- encapsulated for transmission within DNS messages or application
- data streams.
-
- In this regard, the internationalized namespace is the UCS
- representation of the domain names and labels as they are used for
- comparison operations once a domain name arrives for processing,
- while the transfer encodings ensure that a domain name arrives at
- the destination system intact, so that it may be processed in its
- canonical form.
-
- There are four conceptual elements to this model:
-
- * Character codes. Labels from internationalized domain names
- have a single logical canonical representation as sequences
- of UCS code point values. The UCS characters are used when
- a particular label from a domain name is created by an
- application, stored in a zone, hosts or cache database, and
- is used whenever two sets of domain names or labels need to
- be compared. However, different kinds of domain names have
- different rules which govern the character codes that may
- be used.
-
- * Storage encodings. Whenever a domain name is created or
- copied from the network, it must be stored in a format that
- is reversible to the canonical UCS character representation
- of that domain name. This specification does not mandate or
- require any particular storage encoding, and allows this
- decision to be made on a per-implementation basis, as long
-
- Hall I-D Expires: May 2002 [page 19] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- as the storage encoding supports character codes which can
- be converted to UCS equivalent values for comparison
- purposes. However, the use of UTF-8 for this purpose is
- encouraged, since it is the most common.
-
- * Transfer encodings. Whenever a domain name needs to be sent
- over the network, it must be packaged in a form which is
- compliant with the capabilities of the transfer protocol in
- use. This document specifies three transfer encodings which
- may be used to encode canonical UCS character codes in DNS
- messages or application streams, which are: the octet
- encoding from STD13, the ACE encoding from <ACE-Z>, and the
- UTF-8 encoding from RFC2279. Each encoding has different
- costs and benefits in different usage scenarios.
-
- * Comparison operations. When two domain names need to be
- compared, they also follow rules which are appropriate to
- the type of domain name being provided, and the transfer
- encoding which may have been used to provide the domain
- name to the system.
-
- This document defines four distinct types of internationalized
- domain names which may exist in the internationalized namespace,
- and also describes how each of the above considerations affect
- those domain names and their labels. These domain name types are
- described throughout the remainder of this section.
-
-
- 4.1. Internationalized Domain Names and Labels
-
- This section describes the master template rules for all domain
- names and labels which may be used in the internationalized
- namespace, although subordinate rules and restrictions are also
- applied as secondary filters, depending on the intended usage of
- the domain name.
-
- For example, domain names and labels which are to be used as
- internationalized host identifiers (either as host names, or as
- domain names which are used to specify a host) are restricted to a
- specific subset of UCS characters. Meanwhile, domain names and
- labels which are compliant with STD13's global rules are
- restricted to eight-bit code values, while the domain names and
- labels which are used as STD13 host identifiers are restricted to
- a specific subset of US-ASCII.
-
-
- Hall I-D Expires: May 2002 [page 20] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
-
- The following diagram illustrates how the subordinate rules are
- applied and interpreted against the master restrictions:
-
- +-----------------------+
- | Internationalized DNs |
- +-----------------------+
- any UCS character codes
- / |
- / |
- / |
- / |
- +-----------+ +-----------+ +------------+
- | Int. Host | | STD13 DNs +-----+ STD13 Host |
- +-----------+ +-----------+ +------------+
- normalized character ASCII letters,
- subset of codes 0x00 numbers, and
- UCS chars through 0xFF hyphen char
-
- As can be seen, the internationalized domain names and labels
- rules allow any UCS character code to be stored, although each
- particular usage of the domain names and labels will have their
- own secondary rules and restrictions.
-
- In order to allow future documents to define additional rules as
- required for their usage, this document defines very few global
- rules on the core internationalized domain names and labels.
-
-
- 4.1.1. IDN syntax and structure
-
- In this specification, an internationalized domain name consists
- of a variable number of labels, each of which contain a variable
- number of UCS character codes, not all of which will have defined
- UCS character interpretations.
-
- Furthermore, the encoding system which is used to store and
- interpret those values on a system is not relevant to this
- specification, and is therefore not defined. The characters in a
- label can be stored in memory or on disk as UTF-8, UCS-4, ACE, or
- any other storage encoding which is desired by the operators and
- implementers of the affected system, as long as that encoding
- system is reversible to the canonical UCS character code values,
- and is able to represent the necessary range of UCS characters
- (the "necessary range" varies by operation).
-
-
- Hall I-D Expires: May 2002 [page 21] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- The only universal restrictions which apply to internationalized
- domain names and labels are those which govern length. This
- specification requires that labels from internationalized domain
- names MUST be restricted to a minimum length of two characters and
- a maximum length of 63 characters, inclusive. The exception to
- this rule is the root domain, which is always represented by a
- zero-length label. Note that this rule specifically refers to the
- canonical UCS characters, rather than any encoded form (encoding
- will often result in labels and domain names with fewer actual
- characters, due to overhead from the encoding algorithm).
-
- A fully-qualified internationalized domain name is formed by
- joining a series of labels together, with the most-contextually
- specific label in the left-most position of the label sequence,
- and with the root domain occupying the right-most position. The
- sum total of all labels in an internationalized domain name MUST
- NOT exceed 255 characters, inclusive. Any number of labels MAY be
- stored in the domain name, but the sum total of their lengths MUST
- NOT exceed this limit.
-
- However, labels which contain UCS character codes greater than
- U+007F will result in multi-byte UTF-8 and ACE encodings, so the
- maximum length of a label or an internationalized domain name is
- governed by their UTF-8 and ACE encoded lengths. Both encodings
- MUST result in an encoded length of 63 octets or less in order to
- be usable, with a maximum cumulative length of 255 octets.
-
-
- 4.1.2. IDN transfer encodings
-
- The UCS is currently occupies a 21-bit range of character code
- values, containing tens of thousands of assigned characters, and
- hundreds of thousands of unassigned characters. Due to the multi-
- byte nature of the code point values, UCS characters cannot be
- passed as protocol or application data in most of the existing
- Internet protocols (including DNS messages), at least not without
- the help of some kind of encoding scheme. At the very least, the
- UCS character values have to be encoded as eight-bit sequences if
- they are to fit within existing eight-bit data structures, and
- have to be encoded as a subset of US-ASCII characters if they are
- to be usable with legacy protocols and applications which only use
- STD13's host identifier rules for their structured domain name
- data types.
-
- With this objective in mind, this document defines three different
- transfer encoding systems which can be used to convert
-
- Hall I-D Expires: May 2002 [page 22] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- internationalized domain names and labels into a form which is
- suitable for transfer in different data streams. These are the
- legacy STD13 octet encoding, ACE, and UTF-8. Each of these
- encoding schemes provide different benefits and capabilities to
- the internationalized DNS effort.
-
- * STD13 octets. The STD13 octet encoding scheme provides a
- direct one-to-one mapping between eight-bit characters and
- their eight-bit values, but it is only capable of storing
- character codes in the range of U+0000 through U+00FF,
- which severely restricts its usefulness.
-
- * ACE. The ACE encoding scheme is capable of storing UCS
- character code value as seven-bit sequences in STD13 legacy
- labels. While this makes it practically compatible with the
- legacy host identifier rules, the resulting data imposes
- additional labor on the Internet community, and the reuse
- of the legacy label also results in certain amounts of
- ambiguity with some DNS domain names and labels.
-
- * UTF-8. The UTF-8 encoding scheme is capable of encoding all
- UCS character code values as sequences of eight-bit data
- which are compatible with legacy DNS message restrictions,
- but the encoded output requires explicit support from
- internationalized applications and protocols. UTF-8 output
- uses a new label type in order to prevent additional
- ambiguity problems from arising.
-
- The table below illustrates the UCS character code sequences which
- are supported by each of the different encoding schemes.
-
- STD13
- Octets ACE UTF-8
- +-------+-------+--------
- | | |
- US-ASCII | Y | | Y
- | | |
- Eight-Bit | Y | Y | Y
- | | |
- Any UCS Chars | | Y | Y
- | | |
-
-
- Hall I-D Expires: May 2002 [page 23] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- More specifically, the character code sequence ranges and their
- valid encodings are:
-
- * US-ASCII. If a label only contains character codes from the
- range of U+0000 through U+007F, then it MAY be encoded as a
- legacy STD13 octet sequence or UTF-8, but MUST NOT be
- encoded as ACE.
-
- Note that this specification explicitly prohibits seven-bit
- labels from being encoded as ACE data, since such an action
- would be redundant, results in greater processing overhead
- for those labels, and multiple representations introduce
- problems with caches on legacy systems. Furthermore,
- certain security risks would be introduced if this were
- allowed. For example, a malicious user could register or
- purposefully create an ACE encoded representation of the
- "example.com" label sequence such that users mistakenly
- sent sensitive data to malicious systems.
-
- In order to prevent these problems from occurring, this
- specification requires that any ACE-encoded label which
- consists entirely of seven-bit characters MUST be
- immediately discarded with extreme prejudice. This rule
- applies to every implementation of this specification,
- including any applications, resolvers, caches or servers
- which process labels.
-
- * Eight-bit codes. If a label contains character codes from
- the eight-bit range of U+0000 through U+00FF, then it MAY
- be encoded as STD13 octet sequences, ACE, or UTF-8. This
- rule specifically requires that the label MUST contain at
- least one character from the eight-bit range, MAY contain
- any number of characters from the seven-bit range, but MUST
- NOT contain characters with code values which are greater
- than U+00FF.
-
- Since the STD13 octet encoding and ACE both use the legacy
- STD13 label type, this specification relies on the input
- encoding of a domain name in order to determine the output
- encoding. In some cases, however, the input encoding will
- not be clear, or will not be specified, and this can result
- in some ambiguity with label sequences from this range.
-
- For example, if the domain name provided in a query
- consists of seven-bit labels, then the STD13 octet sequence
- is the only valid encoding for the legacy STD13 label,
-
- Hall I-D Expires: May 2002 [page 24] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- meaning that ACE could not have been used in the query. If
- the specified domain name exists as a CNAME resource record
- which refers to a domain name that contains eight-bit
- character codes, then the proper output encoding for that
- domain name will not be clearly discernable. Moreover, the
- STD13 and ACE encodings will generate different results,
- since the STD13 octet sequence will only contain a single
- octet for the eight-bit character, while the ACE encoding
- will contain multiple octets of encoded data.
-
- When this situation arises, systems MUST give preference to
- the ACE encoding, on the assumption that the referenced
- character is more likely to represent a UCS character than
- an eight-bit code value (the UCS characters in this range
- are Latin-1, which are the most common characters after the
- legacy US-ASCII set). Furthermore, the ACE encoded
- representation of these characters allow for a broader
- range of subsequent operations (since it complies with the
- legacy host naming restrictions, it can be used with CNAME
- resource records that refer to hosts), while the STD13
- octet encoded representation does not.
-
- It is possible to avoid this scenario on authoritative zone
- servers (and thus the affected caches) by allowing the
- operator to specify whether or not the input is Latin-1 UCS
- character data or binary data, with the server generating
- the proper output accordingly. Also note that the default
- encoding specified by this document is UTF-8, which does
- not suffer from the ambiguity problems described above.
-
- * Any UCS character codes. If a label consists of any
- character codes greater than U+00FF, then it MAY be encoded
- as ACE or UTF-8, but MUST NOT be encoded as STD13 octet
- sequences. STD13 is not capable of representing character
- codes greater than U+00FF, so it cannot be used with any
- UCS characters beyond the eight-bit range.
-
- Encodings are performed on a per-label basis. Each label MUST NOT
- be encoded more than once. Also note that recursive encodings
- result in applications discarding the domain name.
-
- When the STD13 octet encoding is used to encode labels for
- transmission, the labels are encoded according to the rules
- specified in STD13, and are encapsulated in STD13 legacy labels.
-
-
- Hall I-D Expires: May 2002 [page 25] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- When ACE is used to encode labels for transmission, the labels are
- encoded according to the rules specified in <ACE-Z>, and are
- encapsulated in STD13 legacy labels (this process is described in
- section 5.2).
-
- When UTF-8 is used to encode labels for transmission, the labels
- are encoded according to the rules specified in RFC2279, and are
- encapsulated in EDNS/UTF-8 extended labels (the format of this
- label is described in section 5.1).
-
- Note that a domain name MAY contain any combination of STD13 octet
- encoded labels and ACE encoded labels. However, if a domain name
- contains any UTF-8 encoded labels, then ALL of the labels from
- that domain name MUST be encoded as UTF-8 data. This rule
- primarily exists so that DNS compression services can be
- maintained consistently, but it also prevents mixed referrals
- which can trigger unnecessary fall-back processing, and also
- provides a single encoding representation to internationalized
- systems which benefits efficiency.
-
- The root domain (as specified by the zero-length label at the
- right edge of the domain name) MUST NOT be encoded with ACE. More
- specifically, zero-length labels MUST NOT contain any character
- data of any kind, and since ACE labels have prefix strings, they
- are explicitly forbidden from being used for the root domain.
-
-
- 4.1.3. IDN comparison operations
-
- When an internationalized domain name label is received from the
- network as ACE or UTF-8 encoded data, the labels MUST be decoded
- to their canonical UCS character representation, and the resulting
- UCS characters MUST be compared as case-exact sequences to their
- stored equivalents. Except where specifically required in this
- specification (EG, validity tests which are performed by
- applications), normalization and case-conversion MUST NOT be
- performed against the resulting UCS character codes prior to any
- comparison operations being performed.
-
- However, internationalized domain name labels which are received
- as STD13 octet sequences MUST be given special treatment, as these
- domain names could have originated from legacy systems operating
- under STD13's rules. In this case, the seven-bit US-ASCII
- alphabetic characters (U+0041 through U+005A, and U+0061 through
- U+007A) from those labels MUST be compared in a case-neutral form.
- All other code values MUST be compared as case-exact code values
-
- Hall I-D Expires: May 2002 [page 26] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- (this particularly includes eight-bit characters, which were not
- defined by STD13).
-
-
- 4.2. Internationalized Host Identifiers
-
- Internationalized host identifiers are a subset of the
- internationalized domain names described in section 4.1, which
- only use a subset of the allowable UCS characters, but which reuse
- the global transfer encodings and comparison routines.
-
- Most of the displayable characters from the UCS can be used in
- host identifiers, and there are no additional rules governing the
- ordering or length of their labels. However, the characters which
- are used in internationalized host identifiers MUST be normalized
- and case-converted before they are encoded for storage or
- transfer. This requires more effort on the part of applications
- and servers when the internationalized domain names are initially
- created, but results in less ambiguity and lower processing
- requirements for servers, caches and resolvers during subsequent
- comparison operations.
-
- The restrictions which govern the creation of internationalized
- host identifiers are as follows:
-
- a. Labels MUST be restricted to the subset of characters which
- are permitted by <nameprep> [nameprep]. Characters which
- are prohibited by <nameprep> MUST NOT appear in any label
- of any internationalized host identifier.
-
- b. Labels MUST be normalized through <nameprep> before they
- are stored or encoded for transfer. Internationalized host
- identifiers will not be normalized as part of any
- comparison operation, so systems MUST normalize the labels
- before they are stored or transmitted.
-
- c. Labels MUST be converted to lowercase according to the
- case-mappings rules specified in <nameprep> before they are
- stored or encoded for transfer. Internationalized host
- identifiers will not be converted to lowercase as part of
- any comparison operation, so systems MUST normalize the
- labels before they are stored or transmitted.
-
- According to the rules above, a label from an internationalized
- host identifier which was originally created with the UCS
- character sequence of <LATIN CAPITAL LETTER A><COMBINING ACUTE
-
- Hall I-D Expires: May 2002 [page 27] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- ACCENT><LATIN CAPITAL LETTER B> (U+0041 U+0301 U+0042) would be
- normalized and lowercased to <LATIN SMALL LETTER A WITH
- ACUTE><LATIN SMALL LETTER B> (U+00E1 U+0062). The normalized,
- lowercase form would be used as the canonical UCS character
- representation of that label when it was encoded for storage and
- transmission purposes, and would be the form which was used for
- comparison operations on any resolvers, caches and servers.
-
- Internationalized host identifiers which are received from the
- network can contain labels which have been encoded as STD13 octet
- sequences, ACE or UTF-8. In all of these cases, the comparison
- rules defined in section 4.1.3 MUST be applied.
-
-
- 4.3. STD13 Domain Names
-
- STD13 allows any eight-bit code values to be used in domain name
- labels. However, STD13 host identifiers (as described in section
- 4.4 of this specification) are the most common form of STD13
- domain names, and have much tighter restrictions.
-
- There are common uses of STD13 domain names which do not comply
- with the STD13 host identifier subset, however. One common example
- of this is SRV identifiers, which use an underscore character
- (U+005F) as part of their label syntax. Another common example is
- found when email addresses are provided in SOA and RP resource
- records, and where the left-hand side of the email address is
- stored as an STD13 domain name label which does not represent a
- host identifier. Furthermore, email addresses often contain extra
- characters which are not legal in STD13 host identifiers, such as
- a full-stop character (U+002E). For example, "joe.admin" could be
- stored as an STD13 domain name label in the fully-qualified domain
- name of "joe.admin.example.com.", which would represent the email
- address of "joe.admin@example.com" when that domain name was
- extracted from the SOA or RP resource record and processed.
-
- Implementations of this specification MUST allow STD13 domain
- names to be created and stored, using the following rules:
-
- a. Labels MUST be restricted to the code values of U+0000
- through U+00FF. Restrictions on character content MUST NOT
- be applied (note that if this domain name will be used as
- part of an STD13 host identifier, the rules specified in
- section 4.4 MUST be used instead).
-
-
- Hall I-D Expires: May 2002 [page 28] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- b. Labels MUST NOT be normalized or lowercased before they are
- stored or encoded for transfer.
-
- c. Systems MUST allow STD13 domain names to be specified as
- exact sequences of eight-bit octet values, and MUST NOT
- treat these sequences as canonical UCS characters which are
- normalized or lowercased. STD13 defines an escaping
- mechanism whereby the decimal value of the octet is
- prefaced with a reverse-solidus (such as "\193"), which is
- suggested for this usage.
-
- STD13 domain names which are received from the network can contain
- labels which have been encoded as STD13 octet sequences, ACE or
- UTF-8. In all of these cases, the comparison rules defined in
- section 4.1.3 MUST be applied. Note that some of these sequences
- can contain octet code values which have not been normalized or
- lowercased by the originating system, since these values can be
- used to specify binary domain names.
-
-
- 4.4. STD13 Host Identifiers
-
- This document does not deprecate, replace or modify the host name
- rules defined by RFC952, STD3 or STD13 as they apply to legacy
- host identifiers. However, there are several issues which affect
- the usage of these domain names and their labels in this system.
-
- The range of characters which are currently defined as valid in
- STD13 host identifiers are the uppercase and lowercase letters,
- numbers and hyphen character from US-ASCII. No other characters
- are allowed to be used. Furthermore, the current rules also
- prohibit the use of the hyphen character in the first or last
- character position of a host identifier label.
-
- Implementations of this specification MUST allow STD13 host
- identifiers to be created and stored, using the following rules:
-
- a. Labels MUST be restricted to the code values of U+002D,
- U+0031 through U+0039, U+0041 through U+005A, and U+0061
- through U+007A.
-
- b. Labels MUST NOT contain the code value of U+002D in either
- the first or last character position of the label.
-
-
- Hall I-D Expires: May 2002 [page 29] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- c. The alphabetic characters MUST be converted to lowercase
- before they are stored or transmitted. STD13 host
- identifiers are always compared in a case-neutral form.
-
- STD13 host identifiers which are received from the network can
- contain labels which have been encoded as STD13 octet sequences
- UTF-8. In both cases, the comparison rules defined in section
- 4.1.3 MUST be applied.
-
-
- 5. Transfer Encodings and Label Types
-
- As was discussed in section 4.1.2, internationalized domain names
- and labels are required to be encoded as either eight-bit or
- seven-bit data whenever they are transmitted as protocol or
- application data.
-
- The particular output encoding format which will be used for any
- given label will be primarily determined by the capabilities of
- the participating end-point systems. If the application or
- protocol which is relaying the domain name labels supports
- internationalized domain names directly then UTF-8 encoded labels
- can be used, but if the protocol or application is only capable of
- supporting STD13 host identifiers as domain name data, then the
- STD13 octet and/or ACE encoded labels will have to be used.
-
- With DNS messages in particular, the "data type" is the label
- encapsulation in use. Although STD13 legacy labels allow for the
- use of eight-bit codes, multiple encodings for the same basic
- character data result in interpretation problems without some form
- of ancillary tagging service. For this reason, each encoding is
- represented differently by this specification. When the STD13
- legacy label contains STD13 octet sequences then no tagging is
- provided, but if the STD13 legacy label contains ACE encoded data
- then the encoded sequence is tagged with an ACE identifier (a
- character prefix which does not normally appear in labels). When
- UTF-8 domain names are provided, an EDNS/UTF-8 extended label is
- used to encapsulate the internationalized domain name.
-
- Furthermore, the encoding which is used for any label in the
- message will also determine the label type which is used to
- encapsulate and transfer the entire domain name. If any label
- contains EDNS/UTF-8 extended labels, then all of the labels from
- that domain name are required to be encapsulated for transfer in
- EDNS/UTF-8 extended labels. Conversely, if a domain name contains
- ACE or STD13 octet encoded labels, then all of the labels from
-
- Hall I-D Expires: May 2002 [page 30] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- that domain name are required to be encapsulated for transfer
- using the STD13 legacy label format.
-
- Note that other legacy applications and protocols will most likely
- be required to provide extended encodings or negotiation features
- before they can exchange internationalized domain names directly.
- However, new applications and protocols which are subsequently
- written to comply with BCP18 and this specification should not
- require any such effort, as they should be capable of transferring
- UTF-8 domain names from the beginning.
-
-
- 5.1. The EDNS/UTF-8 Label Type
-
- Any internationalized domain name label which has been encoded as
- UTF-8 for transmission in a DNS message MUST be encapsulated as a
- EDNS/UTF-8 label.
-
- The EDNS/UTF-8 extended label is an instance of EDNS extended
- label types (as defined by RFC2671). Extended labels are indicated
- by the leading bit pattern of 0b01 in the label type field (the
- first two bits from the "label length" octet of the STD13 legacy
- label type), with the remaining six bits of this octet indicating
- the extended label type in use. The EDNS/UTF-8 label type uses the
- binary value of 0b000011 for this indication (note that IANA may
- change this assignment).
-
- EDNS/UTF-8 labels contain two subordinate units of data. The first
- octet contains a length indicator which works exactly the same as
- the length octet as used by STD13 legacy labels: if the first two
- bits of this octet are 0b00 then the rest of that octet provides
- the length of the label data field, but if the first two bits of
- this octet are 0b11 then the label is a pointer to some other
- label, and the remainder of the length octet provides an off-set
- which points to the length octet of the referenced label, as per
- the rules provided in section 4.1.4 of RFC 1035 (STD13, part 2).
-
-
- Hall I-D Expires: May 2002 [page 31] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- The structure of the EDNS/UTF-8 extended label is illustrated by
- the following figure.
-
- 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |0 1|0 0 0 0 1 1| length | label data /// |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- 0b01 \93 The extended label identifier.
-
- 0b000011 \93 The EDNS/UTF-8 extended label type identifier.
-
- Length \93 The number of octets in the label data, or the off-
- set to the length octet of another EDNS/UTF-8 label.
-
- Label data \93 The label data, encoded as UTF-8 octets.
-
- The following example shows the domain name of me.com, where the
- "e" in "me" is the UCS character <LATIN SMALL LETTER E WITH ACUTE>
- (U+00E9), which has the UTF-8 encoded octet sequence of 0xC3A9.
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 20 | 0 1 0 0 0 0 1 1| 0x03 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 22 | 0x6D (m) | 0xC3 (e') |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 24 | 0xA9 (e') | 0 1 0 0 0 0 1 1|
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 26 | 0x03 | 0x63 (c) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 28 | 0x6F (o) | 0x6D (m) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 30 | 0 1 0 0 0 0 1 1| 0x00 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- Octet 20 identifies the EDNS/UTF-8 extended label type, while
- octet 21 indicates that the label is three octets long. Octet 22
- contains the UTF-8 value for lowercase "m", while octets 23 and 24
- contain the UTF-8 value for the UCS character <LATIN SMALL LETTER
- E WITH ACUTE> (encoded as 0xC3A9).
-
- Similarly, octet 25 identifies another EDNS/UTF-8 extended label
- type, while octet 26 indicates that the label is three octets
- long, while octets 27 through 29 contain the UTF-8 values for the
- lowercase alphabetic sequence of "com".
-
- Hall I-D Expires: May 2002 [page 32] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
-
- Finally, octet 30 identifies another EDNS/UTF-8 extended label
- type, while octet 31 indicates that the label is zero octets in
- length, thereby signifying the root zone (the end of the queried
- domain name).
-
- Note that the use of the EDNS/UTF-8 extended label type serves
- multiple purposes. On the one hand, it provides a method of
- signaling the resolver's capabilities to the server, so that the
- server can determine which format it needs to use when returning
- answers, referrals or errors. Moreover, using an encapsulation
- format which is not backwards compatible prevents certain
- ambiguity problems which can result from overloading the STD13
- legacy label with multiple encodings. These problems are seen in
- certain situations with STD13 octet encoding and ACE, where a
- server cannot adequately determine which encoding a resolver
- desires. By using a separate extended label type for UT-8, these
- kinds of ambiguities are avoided.
-
- There are additional benefits which come from using EDNS extended
- label types, which are best expressed as "future possibilities".
- Once the EDNS extended label mechanisms are widely deployed, it
- becomes feasible to specify additional encoding mechanisms as soon
- as the Internet community deems it desirable. In this regard,
- defining alternative encodings is much easier the second time.
-
-
- 5.2. The STD13 Legacy Label Type
-
- Any internationalized domain name label which has been encoded as
- ACE or STD13 octet sequences for transmission in a DNS message
- MUST be encapsulated within an STD13 legacy label.
-
- This document does not deprecate, replace or extend the STD13
- octet encoding or label encapsulation rules defined by STD13.
- However, this document does provide some guidance on the creation
- and interpretation of ACE encoded labels when they are stored in
- legacy labels, which is necessary in order for recipient systems
- to properly detect and decode the label contents.
-
- Note that STD13 octet sequences and ACE data MAY both be provided
- the same domain name. As such, each STD13 legacy label from a DNS
- message must be examined and processed independently.
-
-
-
- Hall I-D Expires: May 2002 [page 33] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- 5.2.1. ACE encoded labels
-
- ACE encoded labels always begin with the character sequence of
- <TBD> (this document uses "zz--" as a placeholder sequence until a
- formal assignment is made). Any label which contains ACE encoded
- data MUST begin with this character sequence prefix. Similarly,
- any label which begins with this character sequence MUST be
- recognized and processed as an ACE encoded label, according to the
- rules defined in this specification.
-
- Encoding and encapsulating a label as ACE data is a three-part
- process, as follows:
-
- a. Encode the canonical UCS character data from the
- internationalized domain name label into ACE using the
- procedure defined in <ACE-Z>
-
- b. Preface the encoded output with the "zz--" prefix sequence,
- thereby indicating that this label contains ACE encoded UCS
- character data.
-
- c. Determine the length of the encoded data and store this
- value in the STD13 legacy label's length octet.
-
- Decoding an ACE label is the opposite of that process.
-
- Note that whenever the ACE algorithm encounters a seven-bit
- character code in the input, it is passed through unmodified to
- the encoded output. If a label only contains seven-bit character
- codes, the label MUST NOT be encoded as ACE, and MUST be encoded
- as either STD13 octet sequences or UTF-8. Forcing a seven-bit
- label to be encoded as ACE serves no benefit, incurs additional
- processing on the end-point systems, and can also expose certain
- security risks. Any system which is capable of generating and
- deciphering ACE encoded labels is required to treat such sequences
- as hostile, and MUST dispose of them immediately without any
- further processing immediately; systems are forbidden to even
- return these labels in DNS error messages.
-
- Similarly, ACE MUST NOT be used to encode any zero-length labels
- (including but not specifically limited to the root domain), since
- the presence of prefix characters in these labels can invalidate
- their protocol-specific interpretations.
-
- When an STD13 legacy label is received which has "zz--" in the
- first four character positions, the label MUST be treated as an
-
- Hall I-D Expires: May 2002 [page 34] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- ACE-encoded internationalized domain name, and MUST be decoded to
- its canonical UCS character values for further processing.
-
- Note that STD13 legacy labels MUST be verified before the ACE
- encoded data is extracted (as per the rules defined in STD13 which
- govern the STD13 legacy label type), but systems which are
- compliant with this specification MUST perform all subsequent
- comparison, caching, or storage operations against the canonical
- UCS characters, and MUST NOT use the ACE encoded label sequence
- for any of these operations.
-
- Note that the legacy systems which are not compliant with this
- specification will treat ACE encoded labels as any other STD13
- legacy label.
-
-
- 5.2.2. STD13 octet encoded labels
-
- Any STD13 legacy labels which do not begin with the ACE prefix
- MUST be treated as STD13 octet encoding sequences. The rules for
- this process are defined by STD13's default label encapsulation
- services, although this document also provides some clarifications
- on the use of this encoding with internationalized domain names
- and labels.
-
- Whenever the STD13 octet sequence is used to encode the labels
- from an internationalized domain name, the octet values of the
- canonical UCS characters are stored directly in the label. Because
- the DNS message is limited to octets, the range of UCS character
- codes which are eligible for use with STD13 octet sequences is
- limited to U+0000 through U+00FF. If any UCS character codes
- outside this range need to be transferred, the internationalized
- domain name label will have to be encoded as ACE or UTF-8.
-
- Note that comparison operations for the seven-bit range of
- alphabetic character values MUST be performed in a case-neutral
- form, although eight-bit code values MUST NOT be normalized or
- case-converted as part of a comparison operation. These rules are
- required in order to ensure backwards compatibility with the STD13
- compliant systems which may be generating these labels as parts of
- an STD13 domain name while also supporting the normalization and
- case-conversion which may have been applied to the UCS characters
- in the storage or transfer encoding systems.
-
-
-
- Hall I-D Expires: May 2002 [page 35] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- 6. Application Guidelines
-
- As was discussed in section 3.3, there are multiple scenarios in
- which an application can make use of internationalized domain
- names, ranging from simple lookups of connection identifiers to
- abstract encapsulations of unstructured application data. This is
- an extremely broad range of uses, which is complicated by the
- extreme pervasiveness of applications and protocols that use
- domain names for one or more of these purposes.
-
- Furthermore, network applications face a complex array of input
- and output operations which will cumulatively affect the ability
- of that application to make use of the internationalized domain
- name system for various services and functions. These issues are
- illustrated by the figure below:
-
- [IDNs] [IDNs]
- | ^
- | |
- +------V------+ +------+------+
- | input | | output |
- | charset | | charset |
- +-----------+-+ +-+-----------+
- \ /
- +---+-----+---+
- | Application |
- +---+-----+---+
- / \
- +-----------+-+ +-+-----------+
- | lookups | | app data <---> [IDNs]
- +------+------+ +-------------+
- |
- +------+------+
- | resolver <---> [IDNs]
- +-------------+
-
- As can be seen, the ability for an applications to complete adopt
- internationalized domain names will be determined by many factors,
- any one of which could prevent the application from completely
- incorporating the restrictions and recommendations prescribed by
- this specification.
-
- In order to allow for a flexible adoption schedule, this
- specification defines very few mandates that applications must
- adopt, but instead focuses on recommendations which applications
- should comply with whenever they need to use internationalized
-
- Hall I-D Expires: May 2002 [page 36] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- domain names, and also provides recommendations for situations
- where the preferred behavior is not feasible. Applications which
- are compliant with all of the recommendations provided in this
- specification will be able to generate, store, transfer and
- resolve internationalized domain names throughout all of their
- operations, using UTF-8 as a common encoding for all of these
- operations. Meanwhile, applications which are not in complete
- compliance with this specification will still be able to make use
- of the internationalized domain names in these operations,
- although such access may be limited to using backwards-compatible
- encodings which require greater amounts of effort to implement and
- which provide fewer benefits.
-
-
- 6.1. Input and Output Charsets
-
- If an application is unable to accept, process, store or display
- characters from the complete UCS repertoire, that application's
- support for internationalized domain names will be somewhat
- limited, by definition.
-
- Although this document does not mandate any particular charset or
- encoding which all applications must use for all operations,
- applications SHOULD use coded character sets or encodings which
- can handle characters from a reasonable number of scripts.
-
- In particular, the following areas have specific requirements:
-
- * Input charsets and encodings. Since UTF-8 is used as the
- default encoding for internationalized domain names
- throughout this specification (and others, such as BCP18),
- UTF-8 is also RECOMMENDED for use with input encodings of
- internationalized domain names in particular, although this
- is not required. Many platforms and development
- environments support UTF-8 as a local encoding of the UCS
- and it can be reasonably used with many types of input
- (such as configuration files), although many systems will
- require a specific encoding (such as UCS-2, or ISO/IEC
- 8859-1) in situations which require memory access or
- keyboard input.
-
- Regardless of the input encodings used, implementations
- MUST map domain names and labels to their canonical UCS
- characters for any normalization and case-conversion work
- which is subsequently required by any DNS lookups (see
- section 6.3).
-
- Hall I-D Expires: May 2002 [page 37] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
-
- * Output choices will likely be limited to a system-preferred
- charset or encoding. In general, this document RECOMMENDS
- that output systems choose an output charset or encoding
- which reflects the data being provided. However,
- applications MUST NOT display unknown characters with
- generic replacement characters (such as boxes or circles)
- if it is known that the original characters are not
- available for display with the specified charset, as such
- characters will almost certainly trigger failure conditions
- in subsequent protocol operations.
-
- In those situations where adequate input or output charsets or
- encodings are unavailable, applications MAY use ACE to encode
- internationalized domain names for the purpose of ensuring that
- the data is provided intact. Since ACE is capable of representing
- UCS characters as sequences of seven-bit characters, it is
- functionally usable as a last line of defense in almost any
- environment, with the caveat that ACE encoding sequences are
- extremely cryptic and will likely result in lower levels of
- usability and functionality.
-
-
- 6.2. Protocol and Application Data
-
- There are several interrelated issues which will determine an
- application's ability to provide or accept internationalized
- domain names as protocol or application data, although the
- principle determining factors for any such usage will generally be
- the capabilities of the underlying protocol itself.
-
- If a protocol allows negotiation or tagging services in order to
- distinguish between different encodings, that protocol can likely
- be extended to support the use of UTF-8 as protocol or application
- data through command/response negotiation options or through data-
- type tags. Older protocols which do not provide any negotiation
- services or which mandate the use of US-ASCII in all data will
- likely require the use of ACE encoded domain names as a short-term
- measure until the protocol is made compliant with BCP18.
-
- * Protocol data. If the protocol supports UTF-8 encoded
- internationalized domain names in commands or responses,
- then that encoding SHOULD be used wherever it is allowed.
- If UTF-8 is not supported by the protocol, STD13 octet
- sequences and/or ACE encoded equivalents of the
- internationalized domain name MUST be used.
-
- Hall I-D Expires: May 2002 [page 38] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
-
- In some cases, this negotiation can be performed on a per-
- session basis, while in other cases this work will need to
- be performed for each transaction within the session, while
- in other cases the internationalized domain names will have
- to be tagged whenever they are provided as protocol or
- application data.
-
- The DNS protocol is itself an example of a protocol which
- requires tagging in order for internationalized domain
- names to be exchanged within the existing DNS message (with
- these indicators taking the form of ACE encoding prefixes
- and EDNS/UTF-8 extended label type codes). Meanwhile, a
- protocol such as WHOIS can theoretically support a session-
- wide negotiation option that allowed the use of
- internationalized domain names as protocol and application
- data for the duration of that session. Conversely, a
- protocol such as SMTP will likely require the use of
- session-specific identifiers for some operations, while
- other operations may be able to use label tags (similar to
- the existing support for domain literals, which are
- identified by a pair of surrounding square brackets).
-
- Regardless of the encodings which are used, implementations
- MUST map domain names and labels to their canonical UCS
- characters for any normalization and case-conversion work
- which is subsequently required as part of a DNS lookup (see
- section 6.3).
-
- * Structured application data. Structured application data
- such as URLs and email addresses MUST be processed
- according to the rules which govern those data formats.
- Applications MUST NOT perform any conversion or
- transliteration which is not explicitly prescribed by the
- governing documents, since non-standard usages are likely
- to result in misinterpreted data.
-
- * Unstructured application data. Domain names which appear as
- unstructured data in application content are beyond the
- control of this specification, and are generally subject to
- the encoding and formatting desires of the end-users who
- created the data. Generally speaking, it is RECOMMENDED
- that applications allow users to enter or view documents in
- whatever format they prefer, but that any conversion
- between multiple source and destination charsets and
- encodings use UCS as the translation intermediary, such
-
- Hall I-D Expires: May 2002 [page 39] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- that internationalized domain names are properly converted
- along with the rest of the application data.
-
- In some cases, the application will need to probe the resolver
- before it can use internationalized domain names as data. For
- example, a participating system may need to determine the
- internationalized domain name of the local system so that it can
- provide this data in a protocol-specific banner message, and in
- these cases, the application will have to communicate with the
- resolver before this data can be provided.
-
- Due to the usage-specific nature of internationalized domain names
- within protocol and application data streams, each development
- group will have to analyze the restrictions and capabilities which
- affect their specific services independently.
-
-
- 6.3. DNS Lookups and Resolver Calls
-
- One of the most frequent uses for domain names is for lookup
- operations, such as for locating the IP addresses associated with
- a specified domain name, determining the domain name associated
- with a specified IP address, or performing a protocol-specific
- lookup operation for a specific resource record (such as the MX or
- SOA resource records associated with a specific domain).
-
- Since these lookup operations do not directly affect external
- protocols or data, internationalized domain names can be used for
- lookup operations at the application's discretion. For example,
- applications such as ping and netstat only use domain names for
- display purposes, and can therefore make immediate use of
- internationalized domain names within their protocol operations.
- Similarly, a protocol can be limited to STD13 host identifiers as
- protocol identifiers which will require the application to provide
- internationalized domain names as ACE encoded sequences, but any
- lookup operations which are necessary for the internationalized
- domain names can still be performed in their native form. In these
- cases, the protocol operations and lookup operations are separate
- tasks with separate rules.
-
- Similarly, applications are not required to use internationalized
- domain names and internationalized resolver APIs for every lookup.
- In some cases, it may be more efficient for an application to only
- use internationalized domain names for lookup operations against
- connection identifiers, and to use STD13 octet sequences or ACE
- encoded legacy lookups for domain names which were obtained as
-
- Hall I-D Expires: May 2002 [page 40] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- protocol or application data (this will be especially true in
- those cases where the protocol does not yet provide an
- internationalized domain name data-type). In those cases where an
- application prefers to use the legacy resolution path, the
- application MUST use the resolver's legacy APIs. For lookups
- against internationalized domain names, the application MUST use
- the resolver's internationalized APIs.
-
- Note that this specification does not define a mandatory encoding
- which must be used between the applications and the local
- resolver. However, resolvers MUST provide at least one encoding
- which is capable of supporting the entire UCS repertoire of
- character codes, including character codes which are currently
- unassigned. Since UTF-8 is the default encoding which is used
- throughout this specification, it is also RECOMMENDED for use with
- resolver APIs, although this is not required. Resolvers MAY
- dictate a local encoding, with the only requirement being support
- for the entire range of UCS character codes.
-
- Regardless of the data being provided or the charset or encoding
- which is used to provide that data, applications MUST normalize
- and case-convert any internationalized host identifiers which it
- generates or receives from a lookup operation. This process MUST
- use the canonical UCS characters of the domain name according to
- the rules specified in <nameprep> for every host identifier which
- is sent to or received from a resolver.
-
- If the application knows that the requested data specifically
- refers to a host identifier, then the domain name data which is
- returned by the resolver MUST be normalized and case-converted,
- and the resulting domain name MUST be compared to the original
- domain name which was received prior to the normalization and
- case-conversion steps. If the processed domain name does not match
- the domain name which was received, the domain name MUST be
- discarded as malformed.
-
- This step is necessary in order to ensure the integrity and
- veracity of internationalized domain names which are processed by
- applications, since there are multiple opportunities for errors to
- be introduced (such as mistyped entries in the resolver's hosts
- database, or malicious data which has been purposefully provided
- in a zone), and these errors can result in sensitive data being
- directed to the wrong network. Note that the above rule
- specifically applies to host identifiers and not to all
- internationalized domain names as a whole; applications MUST NOT
- arbitrarily normalize and case-convert any and all domain names,
-
- Hall I-D Expires: May 2002 [page 41] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- but MUST apply these steps to any and all domain names which are
- known to be used as host identifiers.
-
- As part of the processing rules for DNS lookups, it is expected
- that an application can exchange internationalized domain names
- with the resolver using a charset or encoding which is capable of
- representing the entire UCS character code range. Towards this
- objective, applications SHOULD test the capabilities of the
- resolver prior to transferring internationalized domain names. In
- those situations where the resolver is unable to support this
- usage, the application MUST encode the internationalized domain
- name as STD13 octet sequences or ACE, and pass the resulting STD13
- host identifier to the resolver.
-
-
- 7. Resolver Guidelines
-
- Resolvers play a crucial role in the use of internationalized
- domain names, in that they provide the internationalized namespace
- which applications work with. As part of this service, resolvers
- provide encapsulation services for the internationalized domain
- names which are exchanged with the applications, resolve queries
- in the internationalized namespace on behalf of the applications,
- and provide lookup matching for entries which are stored in a
- local hosts database. Note that resolvers which cache answer data
- for subsequent operations are also governed by the caching
- restrictions provided in section 9.
-
-
- 7.1. Resolver APIs
-
- Stub resolvers which communicate directly with applications that
- are compliant with this specification are strongly encouraged to
- provide a separate set of APIs for those applications to use
- whenever internationalized domain names need to be provided in
- queries or response messages.
-
- The use of an internationalized API will generally facilitate
- smoother operations for the applications, in that it will allow
- the application to determine the capabilities of the resolver, to
- obtain the internationalized domain name of the local system, and
- to process queries for internationalized domain names as special
- data types.
-
- Furthermore, the use of internationalized versus legacy APIs
- provides a way for resolvers to separate internationalized and
-
- Hall I-D Expires: May 2002 [page 42] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- legacy application query paths, such that the legacy APIs only
- result in STD13 legacy labels, while the internationalized APIs
- generate and trigger EDNS/UTF-8 extended labels. The output
- formatting of the DNS messages are controlled by tight
- restrictions, and the use of alternative APIs will likely result
- in simpler resolver implementations.
-
- For example, it is suggested that applications use the
- internationalized APIs for all of the DNS lookups they generate,
- even if the domain name only contains seven-bit characters. This
- is required in case the queried domain name only exists with a
- CNAME or PTR resource record which references an internationalized
- domain name, and the server has to know which encoding to use for
- that query. If the client had not used the internationalized API
- for the original lookup of the domain name, the resolver may have
- chosen the wrong label type, and thus the response data would only
- be returned as ACE encoded data.
-
- Conversely, older applications which generate malformed eight-bit
- queries through the legacy APIs will result in those queries being
- properly rejected by the DNS servers, preventing undue problems
- with these applications from occurring. For example, an older
- application may process an internationalized domain name through
- the system-default charset or encoding (such as MacRoman), which
- would result in the domain name being malformed when the
- application tried to do something important with that domain name
- (such as send an email message over SMTP). The use of multiple
- APIs causes these malformed applications to break, and the invalid
- domain names are kept out of the application protocol space.
-
- Internationalized APIs are optional to the extent that an
- application MAY use an embedded resolver which is known to be
- capable of generating and processing internationalized domain
- names through the existing function calls. However, the use of
- separate APIs for internationalized domain names is encouraged.
-
- Although this document does not mandate any specific APIs, the
- following functions SHOULD be provided for in some form:
-
- * Test Wide. Applications MUST be able to test the resolver
- for compliance with this specification. In those cases
- where this function is performed by some other function
- (such as one of the following), the capabilities of the
- resolver MUST be detectable even if the requested operation
- fails. For example, if an application issues a call for the
- internationalized domain name of the local system, the
-
- Hall I-D Expires: May 2002 [page 43] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- capability of the resolver to handle internationalized
- domain names MUST be uniquely represented even if the local
- host name cannot be determined.
-
- * Get Wide X-By-Y. Applications SHOULD be able to specify any
- resource record associated with any internationalized
- domain name as part of a lookup operation. Whether this
- service is provided as a series of lookup-specific APIs or
- as a general purpose API is up to the resolver.
-
- * Get Wide Local Name. Applications which utilize
- internationalized domain names as data will need to be able
- to determine the internationalized form of their local
- system name for some operations (such as a protocol-
- specific welcome banner). When this function is called, the
- resulting data MUST be provided as the canonical UCS
- character code values, or their equivalent as represented
- by a locally mandated charset or encoding.
-
- Note that an ACE equivalent of the system name SHOULD be
- returned when the relevant legacy API is queried. In those
- cases where the legacy and internationalized domain names
- both contain seven-bit character codes (possibly because
- the host name is only available in US-ASCII, or because the
- host name was assigned as ACE by an external configuration
- service), the internationalized host name MUST still be
- accessible through the internationalized function.
-
- Note that this application does not specify a charset or encoding
- which must be used by the resolver APIs. However, wherever an
- internationalized API is presented, the resolver MUST utilize a
- charset or encoding which supports the entire UCS repertoire of
- character codes, including character codes which are currently
- unassigned. Since UTF-8 is the default charset for most of the
- operations specified in this document, it is also RECOMMENDED for
- this service, but is not required.
-
-
- 7.2. Query Processing Services
-
- Resolvers which are compliant with the recommendations provided in
- this specification will provide two query paths, one of which
- supports STD13 domain names and another which supports
- internationalized domain names. Technically, there is no
- requirement for two processing paths, although these paths will
-
- Hall I-D Expires: May 2002 [page 44] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- likely exist as conceptual paths even if they are not represented
- or implemented uniquely in all resolvers.
-
- The legacy processing path is defined by STD13. This document does
- not update, modify or extend the rules that resolvers operate
- under when an STD13 compliant domain name is received by a legacy
- application through any legacy APIs which may exist. However, when
- an internationalized domain name is received from an
- internationalized application through any internationalized APIs,
- the processing rules defined in this section MUST be followed.
- Note that these rules apply to all resolvers, whether they are
- stub resolvers, forwarders or caching servers.
-
- Generally speaking, the internationalized domain name resolution
- process has two major components: processing internationalized
- domain names as queries, and performing fall-back processing if an
- EDNS/UTF-8 query is rejected by an authoritative server.
-
-
- 7.2.1. Internationalized queries
-
- Queries for internationalized domain names which are received
- through internationalized APIs can be expected to have originated
- at an application which is capable of accepting and processing
- internationalized domain names in the response messages.
-
- Resolvers MUST encode the labels from the queried domain name as
- UTF-8 and encapsulate the resulting encoded labels into EDNS/UTF-8
- extended labels for transfer within DNS messages, per the
- instructions provided in section 5.1.
-
- Any and all responses to these queries will also be encoded as
- UTF-8 and encapsulated in EDNS/UTF-8 extended labels. Resolvers
- MUST decode the provided response data, convert the labels to
- their canonical UCS character codes, and return the requested data
- to the calling application.
-
- The resolver MUST NOT normalize or case convert internationalized
- domain names which may be received in queries or response
- messages. Since the queries have originated from applications
- which have indicated that they are compliant with this
- specification (via the API) while the responses will have
- originated from caches or servers which indicate that they are
- also compliant (via the EDNS/UTF-8 extended labels), those systems
- are assumed to have normalized and case-converted the domain names
- before they were generated or stored. Also note that applications
-
- Hall I-D Expires: May 2002 [page 45] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- will validate the host identifiers that they receive in response
- messages, so an additional check is expected to be performed on
- the answer data by those systems.
-
-
- 7.2.2. Fall-back processing
-
- If a queried server is unable to process EDNS/UTF-8 extended
- labels, then it is required by STD13 to generate an error
- signifying the problem. Resolvers MUST interpret these errors,
- decode the UTF-8 queried domain name, re-encode it as STD13 octets
- and/or ACE per the instructions provided in section 5.2, and then
- reissue the query as an STD13 legacy label sequence.
-
- The legacy DNS error responses which will trigger this series of
- events are FORMERR and NOTIMPL. Any other errors indicate that the
- EDNS/UTF-8 extended label was successfully processed but that the
- query was not matched, and those errors MUST be returned to the
- application. If the fallback processing results in any error
- responses whatsoever, then the resolver MUST return those errors
- to the calling application.
-
- Any servers which subsequently receive the fall-back queries and
- which are compliant with this specification will process the
- queries as internationalized domain names, and will return the
- answer data as STD13 octet sequences or ACE encoded data, using
- the STD13 legacy label.
-
- Generally speaking, fall-back processing serves two purposes:
-
- * Answering the initial query. If a UTF-8 domain name cannot
- be resolved because a server in the delegation path does
- not understand the EDNS/UTF-8 label type, the resolver can
- reissue the query as an ACE encoded legacy label type so
- that the query proceeds past the problematic server.
-
- * Seeding the resolver's cache. As a result of the above, the
- resolver will learn about the authoritative name servers
- for the target zone, and this information can be used for
- any subsequent queries for domain names within the
- specified zone (for as long as the data is cached, anyway).
- As such, any subsequent EDNS/UTF-8 queries which are issued
- for the portion of the namespace served by that zone will
- be sent directly to one of those authoritative servers
- where they can be answered directly. In this regard,
-
- Hall I-D Expires: May 2002 [page 46] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- subsequent lookups do not require fall-back processing if
- they are received during the cache window.
-
- Regardless of whether or not fall-back processing has been
- performed, if the calling application issued the original query as
- an internationalized domain name, then the resolver MUST respond
- to the query in that form as well. This means that the resolver
- MUST convert any STD13 octet sequences or ACE encoded labels into
- their canonical UCS characters, convert the answer data into the
- resolver's native charset or encoding, and return the data to the
- calling process. The resolver MUST NOT perform any normalization
- or case-conversion during this process, as such an action can
- corrupt domain names which are not used for host identifiers.
-
- If the original query was received through the resolver's legacy
- APIs, then the query MUST be generated and returned in the legacy
- format, and MUST NOT be converted to an internationalized domain
- name prior to the query or response being passed through.
-
- Once fall-back processing occurs, the process MUST NOT be repeated
- for any additional queries in the current lookup operation. No
- other queries from the current lookup operations MUST NOT be sent
- as EDNS/UTF-8 extended labels, since multiple fall-back operations
- can result in time-outs on the client systems.
-
- Because the fall-back process results in two lookups being issued
- against the rejecting zone, eliminating the fall-back processing
- as soon as possible will be an operational requirement for many
- organizations. Any caches or forwarders which are used by stub
- resolvers within an end-user network are practically required to
- be able to process the EDNS/UTF-8 queries, since those servers
- will receive every query which is issued by the stub resolvers.
- While this isn't a technical requirement (fall-back processing
- will get around the problematic servers), it will likely prove to
- be a consideration for network operators looking to support
- internationalized domain names on their local networks.
-
- This document also strongly encourages the root and TLD servers to
- be upgraded as soon as possible (even if they do not intend to
- directly provide UTF-8 domain name delegations), in order to allow
- those servers to read and process the EDNS/UTF-8 extended labels,
- thereby reducing the number of fall-back queries which are sent to
- those servers.
-
-
-
- Hall I-D Expires: May 2002 [page 47] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- 7.3. The Hosts Database
-
- Generally speaking, there are two areas of consideration for stub
- resolvers that provide local hosts databases for name resolution
- services. These are the input requirements for internationalized
- domain names which will be added to the hosts database, and the
- requirements which govern how queries will be compared to the
- entries in the hosts database.
-
- Note that resolvers are not required to implement a hosts database
- or local lookup services (STD3 says "a host MAY also implement a
- host name translation mechanism that searches a local Internet
- host table"). However, wherever a hosts database is provided with
- an internationalized resolver, compliance with the rules specified
- in this section is required.
-
- If a stub resolver offers the capability to compare
- internationalized domain names against a local hosts database,
- that database MUST be compatible with the internationalized domain
- name rules specified in section 4 of this document.
-
- In particular, the resolver SHOULD allow internationalized domain
- names with any code values to be stored, even if the canonical UCS
- characters for those values are undefined or are illegal for use
- with internationalized host identifiers (this is required to
- support domain names which are not host identifiers). In those
- cases where an internationalized domain name specifies an exact
- sequence of octets for binary comparison, the hosts database MUST
- provide a mechanism for tagging the eight-bit characters so that
- they are not interpreted, processed or compared as the canonical
- UCS character equivalents of those codes.
-
- However, entries which explicitly provide host identifiers MUST be
- normalized and case-converted prior to being stored. In order to
- satisfy both of these requirements, it is RECOMMENDED that hosts
- databases store internationalized host identifiers as untagged
- data, but that they also provide some sort of tagging service for
- character code values which are to be returned as-is. STD13
- defines an escaping mechanism whereby the decimal value of the
- octet is prefaced with a reverse-solidus (such as "\193"), which
- is suggested for this usage.
-
- The storage format of the hosts database MAY use any charset or
- encoding the resolver deems most suitable for that platform, as
- long as the rules and restrictions provided above are followed.
- Since UTF-8 is used as the default encoding throughout this
-
- Hall I-D Expires: May 2002 [page 48] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- specification, it is RECOMMENDED as the default encoding for hosts
- databases as well, although this is not required.
-
- Not all of the applications which use a resolver are likely to be
- compliant with this specification, so resolvers MUST ensure that
- they are able to interpret and process any queries from the legacy
- APIs which provide the ACE equivalent of an internationalized
- domain name that is stored in the hosts database. When such a
- query arrives, the domain name MUST be converted to the canonical
- UCS character codes represented by the ACE encoded sequence and
- compared to entries in the hosts database in that form (tagged
- octets excluded). Any internationalized domain names which are
- required to be returned through the legacy APIs MUST be converted
- to STD13 octet sequences and/or ACE before they are returned.
-
-
- 8. Server Guidelines
-
- When a zone administrator desires to provide internationalized
- domain names in a zone, they are presented with two options: they
- can add the STD13 octets or ACE encoded internationalized domain
- names to an existing zone, or they can use internationalized zone
- databases directly. Both of these usage scenarios have their own
- benefits and restrictions.
-
- Using STD13 octet sequences and ACE with legacy servers allows for
- the immediate deployment of internationalized domain names on
- existing servers, and within hierarchies which include
- internationalized domain names. However, any such queries which
- originate at applications that are compliant with this
- specification will always initially fail, guaranteeing that fall-
- back processing will always occur for those zones.
-
- Conversely, using internationalized zones directly allows servers
- to process legacy, ACE and EDNS/UTF-8 queries equally, thereby
- providing greater value to the applications and resolvers which
- have been made compliant with this specification. However,
- internationalized zones have additional requirements (most
- notably, they are required to be upgraded simultaneously), and
- these will prove burdensome to some zone operators.
-
- This specification focuses on the processing requirements for
- internationalized zones which support the use of internationalized
- domain names as explicit data, and which also support the
- necessary subordinate mechanisms such as EDNS/UTF-8 queries. When
- STD13 octet sequences or ACE encoded domain names are used with
-
- Hall I-D Expires: May 2002 [page 49] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- legacy servers, the rules defined in STD13 for those servers MUST
- be used.
-
- Note that each zone SHOULD be configurable independently. If a
- server hosts multiple zones, each of those zones SHOULD be
- operable as independent entities, with any of them using ACE or
- internationalized domain names as necessary. This rule is
- necessary since each zone is likely to have different replication
- partners and configuration rules which will require different
- migration strategies.
-
-
- 8.1. Internationalized Zones
-
- All domain names which are published by an internationalized zone
- MUST be compatible with the restrictions specified in section 4 of
- this document. In particular, the zone database MUST allow binary
- domain names to be stored as any octet value, but MUST also comply
- with the normalization and case-mapping rules when a domain name
- represents a host identifier. These restrictions MUST be applied
- as part of the process in which the domain name is being added to
- the zone database. In those cases where an internationalized
- domain name specifies an exact sequence of octets for binary
- comparison, the hosts database MUST provide a mechanism for
- tagging the eight-bit characters so that they are not interpreted,
- processed or compared as the canonical UCS character equivalents
- of those codes. STD13 defines an escaping mechanism whereby the
- decimal value of the octet is prefaced with a reverse-solidus
- (such as "\193"), which is suggested for this usage.
-
- Servers which are compliant with this specification MUST be
- capable of providing UTF-8 and ACE encoded representations of the
- UCS domain names which are stored in the zone, and servers MUST
- restrict output to only one label type for any protocol operation,
- such that queries containing STD13 legacy labels MUST be answered
- with STD13 octet sequences and/or ACE encoded domain names, while
- EDNS/UTF-8 queries MUST only be answered with UTF-8 encoded domain
- names (this not only includes basic operations such as simple
- queries, but also includes advanced operations such as zone
- transfers; see section 8.2). Similarly, external operations such
- as exporting the contents of the zone to a master file (as
- discussed in section 8.3) MUST result in a single encoding form
- being used for that specific operation.
-
- Note that the underlying zone database technology which may be
- employed by any particular server is beyond the scope of this
-
- Hall I-D Expires: May 2002 [page 50] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- document. Servers MAY use any database technology, charset or
- encoding deemed appropriate for the local environment, although
- the contents of the zone MUST be mapped to the canonical UCS
- character codes for all comparison operations (octet values
- excluded). Since UTF-8 is used as the default encoding throughout
- this specification, it is RECOMMENDED for use as the default
- encoding with zone databases as well, but is not required.
-
- Servers MUST NOT normalize or case-map any UCS characters which
- are decoded from UTF-8 or ACE encoded labels, and MUST restrict
- comparison operations of these labels to precise matches of the
- UCS domain names which are stored in the zone database. However,
- the seven bit character codes from any labels which are received
- as STD13 octet sequences MUST be compared in a case-neutral form,
- and MUST NOT be normalized as part of the comparison operation.
-
- When a zone is converted to support internationalized domain
- names, all of the servers which replicate that zone MUST be
- upgraded. This is required due to ambiguities that can occur with
- labels which may be encoded as either STD13 octet sequences or ACE
- data, and where the label only uses character codes from the
- eight-bit range of character codes (this problem is described in
- detail in section 4.1.2). In order to ensure that all of the
- servers for a zone respond to one of those queries correctly, all
- of the servers which replicate the zone MUST fully support this
- document and its requirements.
-
-
- 8.2. Namespace Visibility Restrictions
-
- In all cases, the encoding format of the domain names which are
- returned in response to a query MUST be the same as the encoding
- format which was used by the query. If the query was provided as a
- sequence of legacy labels, then all of the domain names which are
- provided in the response message MUST be provided as legacy labels
- (containing either ACE or STD13 octet encoded values).
-
- Similarly, if a query is provided as EDNS/UTF-8 encoded data, all
- domain names which are provided in the response message MUST be
- provided as UTF-8 encoded data in EDNS/UTF-8 extended labels. In
- some situations, this process may require the server to perform an
- extra conversion.
-
- For example, assume that the <idn>.example.com. domain name has
- two associated MX resource records, one of which points to the UCS
- domain name of mail.<idn>.example.com, while the other points to
-
- Hall I-D Expires: May 2002 [page 51] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- the ACE encoded domain name of mail.<ace>.example.net. (where the
- "<ace>" label is the ACE equivalent of an internationalized sub-
- domain in the example.net. zone). If a UTF-8 query arrives for the
- MX resource records associated with the <idn>.example.com. domain
- name, both resource records MUST be returned as EDNS/UTF-8 data.
- In order for this requirement to be satisfied, the server will
- have to decode the <ace> label to its UCS canonical form for zone
- storage purposes, and encode the domain name as UTF-8 for
- transmission whenever an EDNS/UTF-8 answer set is required.
-
- The visibility rules specified in this section are mandatory for
- every domain name which is provided in any message. If a system
- requests a zone transfer and uses the EDNS/UTF-8 extended label
- type in the request, all of the domain names in all of the
- messages which are sent as part of the zone transfer MUST be
- provided in their UTF-8 encoded form. Similarly, if a zone
- transfer is requested and uses the legacy label type, then all of
- the domain names from all of the messages which are sent as part
- of the zone transfer MUST be provided as either STD13 octet
- sequences or ACE encoded data, using the legacy label type.
-
-
- 8.3. The Master File Format
-
- STD13 specifies a "master file" format which is used as a
- platform-neutral storage and transfer format for importing and
- exporting the contents of a particular zone. Note that the master
- file is not the same as the operating database for a zone; the
- master file format is used (or is useful) for copying a zone to
- another server, storing a copy of the zone database off-line,
- emailing a copy of the zone to another user or system, and
- performing other off-line actions against the database' contents.
- Once a zone is loaded on a server, however, any database
- technology can be used for managing the zones and generating
- response messages.
-
- In order to facilitate the continued use of master files, any zone
- which is compliant with this specification MUST support the use of
- UTF-8 as an import and export encoding format for the master file
- associated with that zone.
-
- Furthermore, compliant versions of a master file are required to
- have the "$UTF-8" control literal at the beginning of the first
- line of text in the master file if it contains UTF-8 encoded data.
- Master files from zones which do not contain UTF-8 encoded domain
-
- Hall I-D Expires: May 2002 [page 52] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- names MUST NOT contain the "$UTF-8" control literal in the first
- print position of any line.
-
- If the master file contains the "$UTF-8" control literal, all of
- the data within the master file MUST be encoded in UTF-8 as
- specified by RFC2279, and SHOULD be managed with UTF-8 compliant
- tools (such as UTF-8 text editors, mailers that support UTF-8 MIME
- encodings, and so forth).
-
-
- 9. Caching Guidelines
-
- Whenever an internationalized domain name is stored in a cache, it
- MUST be stored in its canonical UCS character code form,
- regardless of whether the domain name was received as STD13 octet
- encoding sequences, UTF-8, or ACE data. Caches MUST NOT normalize
- or case convert any domain names that they store, as such a
- process could invalidate domain names that are not used for host
- identifiers.
-
- Any subsequent queries which are processed through the cache MUST
- be compared against the stored UCS characters. Internationalized
- domain name labels which are decoded from UTF-8 or ACE labels MUST
- NOT be normalized or case-converted as part of the comparison
- operation, although labels which are provided as STD13 octet
- sequences MUST be compared as case-neutral octet values.
-
- Caches MUST be capable of providing UTF-8 and ACE encoded
- representations of the UCS domain names which are stored in the
- cache, with the appropriate format determined by the format used
- in the corresponding query. However, answer data MUST be
- restricted to only one encoding form for any protocol operation,
- meaning that queries containing legacy labels MUST only be
- answered with STD13 octet sequences and/or ACE encoded labels,
- while UTF-8 queries MUST only be answered with UTF-8 encoded
- domain names.
-
-
- 10. Security Considerations
-
- This document defines an extension to the domain name system, and
- as such, it inherits the weaknesses which already exist in DNS.
- Where possible, this specification strengthens DNS with multiple
- checks. For example, this specification requires that domain names
- be validated three times before they are used by applications:
- once on specification, once on entry at the authoritative zone or
-
- Hall I-D Expires: May 2002 [page 53] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- hosts database, and once again when the answer data is received by
- the requesting application. Despite these checks, the root
- weaknesses inherent in DNS are still present.
-
- This document uses multiple encoding algorithms, although boundary
- conditions from the existing DNS are preserved for both the source
- and encoded representations.
-
-
- 11. IANA Considerations
-
- This document requires the use of an EDNS extended label type
- identification code. This document uses the b000011 ELT code.
-
-
- 12. References
-
- [AMC-ACE-Z] <draft-ietf-idn-amc-ace-z>, "AMC-ACE-Z version
- 0.3.1"
-
- [NAMEPREP] <draft-ietf-idn-nameprep>, "Preparation of
- Internationalized Host Names"
-
- [RFC2119] "Key words for use in RFCs to Indicate Requirement
- Levels"
-
- [RFC952] "DoD Internet host table specification"
-
- [STD13] (RFC 1034) "Domain names - concepts and facilities",
- (RFC 1035) "Domain names - implementation and
- specification"
-
- [STD3] (RFC 1122) "Requirements for Internet Hosts --
- Communication Layers", (RFC1123) "Requirements for Internet
- Hosts -- Application and Support"
-
- [BCP18] (RFC 2277) "IETF Policy on Character Sets and
- Languages"
-
- [RFC2279] "UTF-8, a transformation format of ISO 10646"
-
- [RFC2671] "Extension Mechanisms for DNS (EDNS0)"
-
- [ASCII] "ANSI X3.4-1968. USA Standard Code for Information
- Interchange"
-
-
- Hall I-D Expires: May 2002 [page 54] \f
- INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001
-
-
- [ISO10646] "ISO/IEC 10646-1:2000. International Standard --
- Information technology -- Universal Multiple-Octet Coded
- Character Set (UCS) -- Part 1: Architecture and Basic
- Multilingual Plane"
-
-
- 13. Acknowledgements
-
- This document is an assembly of multiple ideas and proposals which
- have been made on the IDN working group mailing list. Many of the
- ideas presented here have been proposed by multiple parties in one
- form or another, although Dan Oscarsson is credited for proposing
- a dual-mode operation which is capable of simultaneously
- supporting UTF-8 and legacy mode encodings. Other contributors to
- key elements from this specification (some of them unknowingly or
- unwillingly) include (alphabetically) Marc Blanchett, Adam
- Costello, Mark Davis, Martin Duerst, Patrik Faltstrom, Paul
- Hoffman, David Hopwood, and many others.
-
-
- 14. Editor's Address
-
- Eric A. Hall
- ehall@ehsco.com
-
-
-
-
- Hall I-D Expires: May 2002 [page 55] \f
+++ /dev/null
-
-
-
-Internet Engineering Task Force Jun-ichiro itojun Hagino
-INTERNET-DRAFT IIJ Research Laboratory
-Expires: January 19, 2002 July 19, 2001
-
-
- Comparison of AAAA and A6 (do we really need A6?)
- draft-ietf-dnsext-aaaa-a6-01.txt
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-Distribution of this memo is unlimited.
-
-The internet-draft will expire in 6 months. The date of expiration will
-be January 19, 2002.
-
-
-Abstract
-
-At this moment, there are two DNS resource record types defined for
-holding IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6
-[Crawford, 2000] . AAAA has been used for IPv6 network operation since
-1996. Questions arose whether we really need A6 or not, or whether it
-is really possible to migrate to A6 or not. Some says AAAA is enough
-and A6 is not necessary. Some says A6 is necessary and AAAA should get
-deprecated.
-
-The draft tries to understand pros and cons between these two record
-types, and makes suggestions on deployment of IPv6 record type.
-
-The draft does not cover the use of bit string label and DNAME resource
-record (reverse mapping), as it seems that nibble form is well accepted
-in the community, newer formats have too much deployment costs, thus we
-see few need/voice that calls for migration. Refer to IETF50 dnsext
-working group minutes for more details.
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 1]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-1. A brief summary of the IPv6 resource record types
-
-1.1. AAAA record
-
-AAAA resource record is formatted as follows. DNS record type value for
-AAAA is 28 (assigned by IANA). Note that AAAA record is formatted as a
-fixed-length data.
-
- +------------+
- |IPv6 Address|
- | (16 octets)|
- +------------+
-
-With AAAA, we can define DNS records for IPv6 address resolution as
-follows, just like A records for IPv4.
-
- $ORIGIN X.EXAMPLE.
- N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
- N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
- N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-
-1.2. A6 record
-
-A6 resource record is formatted as follows. DNS record type value for
-A6 is 38 (assigned by IANA). Note that A6 record is formatted as a
-variable-length data.
-
- +-----------+------------------+-------------------+
- |Prefix len.| Address suffix | Prefix name |
- | (1 octet) | (0..16 octets) | (0..255 octets) |
- +-----------+------------------+-------------------+
-
-With A6, it is possible to define an IPv6 address by using multiple DNS
-records. Here is an example taken from RFC2874:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 2]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
- $ORIGIN X.EXAMPLE.
- N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
- SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
-
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
-
- SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
-
- A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
-
- A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
-
- B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
-
- C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
- D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
- E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
-
-If we translate the above into AAAA records, it will be as follows:
-
- $ORIGIN X.EXAMPLE.
- N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
- N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
- N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-It is also possible to use A6 records in ``non-fragmented'' manner, like
-below.
-
- $ORIGIN X.EXAMPLE.
- N A6 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
- N A6 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
- N A6 0 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-There is a large design difference between A6 and AAAA. A6 imposes
-address resolutions tasks more to the resolver side, to reduce the
-amount of zone file maintenance cost. The complexity is in the resolver
-side. AAAA asks zone file maintainers to supply the full 128bit IPv6
-address in one record, and the resolver side can be implemented very
-simple.
-
-
-2. Deployment status
-
-2.1. Name servers/resolvers
-
-As of writing, AAAA is deployed pretty widely. BIND4 (since 4.9.4),
-BIND8, BIND9 and other implementations support AAAA, as both DNS servers
-and as resolver libraries. On the contrary, the author knows of only
-one DNS server/resolver implementation that supports A6; BIND9.
-
-
-HAGINO Expires: January 19, 2002 [Page 3]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-Almost all of the IPv6-ready operating systems ship with BIND4 or BIND8
-resolver library. [need to check situations with resolver libraries
-based on non-BIND code] Therefore, they cannot query A6 records (unless
-applications gets linked with BIND9 libraries explicitly).
-
-2.2. IPv6 network
-
-IPv6 network has been deployed widely since 1996. Though many of the
-participants consider it to be experimental, commercial IPv6 services
-has been deployed since around 1999, especially in Asian countries.
-Even today, there are numerous IPv6 networks operated just as serious as
-IPv4.
-
-2.3. DNS database
-
-There are no IPv6-reachable root DNS servers, partly because we have
-both AAAA and A6, and we are not decided about which is the one we would
-like to really deploy (so we cannot put IPv6 root NS records). The lack
-of IPv6-reachable root DNS servers is now preventing IPv6-only or
-IPv4/v6 dual stack network operations.
-
-At this moment, very small number of ccTLD registries accept
-registeration requests for IPv6 glue records. Many of the ccTLDs and
-gTLDs do not take IPv6 glue records, partly because of the lack of
-consensus between AAAA and A6. Again, the lack of IPv6 glue records is
-causing pain in IPv6-ready network operations. For example, JP ccTLD
-accepts IPv6 glue records and registers them as AAAA records. IPv6 NS
-records (with AAAA) works flawlessly from our experiences. For example,
-try the following commands to see how JP ccTLD registers IPv6 glue
-records (``/e'' is for English-language output):
-
- % whois -h whois.nic.ad.jp wide.ad.jp/e
- % whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e
-
-
-3. Deploying DNS records
-
-At this moment, the following four strategies are proposed for the
-deployment of IPv6 DNS resource record; AAAA, fragmented A6 records,
-non-fragmented A6 records, and AAAA synthesis.
-
-3.1. AAAA records
-
-AAAA records have been used on IPv6 network (also known as 6bone) since
-it has started in 1996 and has been working just fine ever since. AAAA
-record is a straight extension of A record; it needs a single query-
-response roundtrip to resolve a name into an IPv6 address.
-
-A6 was proposed to add network renumbering friendliness to AAAA. With
-AAAA, a full 128bit IPv6 address needs to be supplied in a DNS resource
-record. Therefore, in the event of network renumber, administrators
-need to update the whole DNS zone file with the new IPv6 address
-
-
-HAGINO Expires: January 19, 2002 [Page 4]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-prefixes. We will discuss the issues with renumbering in a dedicated
-section.
-
-3.2. Fragmented A6 records
-
-If we are to use fragmented A6s (128bit splitted into multiple A6s), we
-have a lot of issues/worries.
-
-If we are to resolve IPv6 addresses using fragmented A6 records, we need
-to query DNS multiple times to resolve a single DNS name into an IPv6
-address. Since there has been no DNS record types that require multiple
-queries for resolution of the address itself, we have very little
-experience on such resource records.
-
-There will be more delays in name resolution compared to queries to
-A/AAAA records. If we define a record with more number of fragments,
-there will be more query roundtrips. There are only few possibilities
-to query fragments in parallel. In the above example, we can resolve
-A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others.
-
-At this moment, there is very little documents available, regarding to
-the relationship between DNS record TTL and the query delays. For
-example, if the DNS record TTL is smaller than the communication delays
-between the querier and the DNS servers, what should happen?
-
-o If we compute DNS record TTL based on the wallclock on the DNS server
- side, the DNS records are already expired and the querier will not be
- able to reassemble a complete IPv6 record. Worse, by setting up
- records with very low TTL, we can let recursive DNS resolvers to go
- into infinite loop by letting them chase a wrong A6 chain (see the
- section on security considration) [BIND 9.2.0snap: resolver does not
- go into infinite loop, meaning that BIND 9.2.0snap resolver does not
- really honor DNS record TTL during A6 reassembly].
-
-o If we compute it starting from the time the querier got the record, we
- will have some jitter in TTL computation among multiple queriers. If
- the query delays are long enough, the querier would end up having
- inconsistent A6 fragments, and the IPv6 address can be bogus after
- reassembly. With record types other than A6, we had no such problem,
- since we have never tried to reassemble an address out of multiple DNS
- records (with CNAME chain chasing a similar problem can arise, but the
- failure mode is much simpler to diagnose as the records are considered
- as an atomic entity).
-
-Some says that caches will avoid querying fragmented A6s again and
-again. However, most of the library resolver implementations do not
-cache anything. The traffic between library resolver and the first-hop
-nameserver will not be decreased by the cached records. The TTL problem
-(see above) is unavoidable for the library resolver without cache. [XXX
-will they interpret TTL field? BIND8 resolver does not]
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 5]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-If some of the fragments are DNSSEC-signed and some are not, how should
-we treat that address? RFC2874 section 6 briefly talks about it, not
-sure if complete answer is given.
-
-It is much harder to implement A6 fragment reassemble code, than to
-implement AAAA record resolver. AAAA record resolver can be implemented
-as a straight extension of A record resolver.
-
-o It is much harder to design timeout handling for the A6 reassembly.
- There would be multiple timeout parameters, including (1) communcation
- timeout for a single A6 fragment, (2) communcation timeout for the
- IPv6 address itself (total time needed for reassembly) and (3) TTL
- timeout for A6 fragment records.
-
-o In the case of library resolver implementation, it is harder to deal
- with exceptions (signals in UNIX case) for the large code fragment for
- resolvers.
-
-o When A6 prefix length field is not multiple of 8, address suffix
- portion needs to be shifted bitwise while A6 fragments are
- reassembled. Also, resolver implementations must be careful about
- overwraps of the bits. From our implementatation experiences, the
- logic gets very complex and we (unfortunately) expect to see a lot of
- security-critical bugs in the future.
-
-In RFC2874, a suggestion is made to use limited number of fragments per
-an IPv6 address. However, there is no protocol limitation defined. The
-lack makes it easier for malicious parties to impose DoS attacks using
-lots of A6 fragments (see the section on security consideration). [BIND
-9.2.0snap: The implementation limits the number of fragments within an
-A6 chain to be smaller than 16; It is not a protocol limitation but an
-implementation choice. Not sure if it is the right choice or not]
-
-With fragmented A6 records, in multi-prefix network configuration, it is
-not possible for us to limit the address on the DNS database to the
-specific set of records, like for load distribution purposes. Consider
-the following example. Even if we would like to advertise only
-2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible
-to do so. It becomes mandatory for us to define the whole IPv6 address
-by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6
-(renumber friendliness) goes away.
-
-
-
-
-
-
-
-
-
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 6]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
- ; with the following record we would advertise both records
- $ORIGIN X.EXAMPLE.
- N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
- M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6
- SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
- A6 0 2345:00D2:DA11:1::
-
- ; we need to do the following, jeopardizing renumbering
- ; friendliness for N.X.EXAMPLE
- $ORIGIN X.EXAMPLE.
- N A6 0 2345:00C1:CA11:1:1234:5678:9ABC:DEF0
- M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6
- SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
- A6 0 2345:00D2:DA11:1::
-
-A6 resource record type and A6 fragment/reassembly were introduced to
-help administrators on network renumber. When network gets renumbered,
-the administrator needs to update A6 fragment for the higher address
-bits (prefixes) only. Again, we will discuss the issues with
-renumbering in a dedicated section.
-
-
-3.3. Non-fragmented A6 records
-
-There are proposals to use non-fragmented A6 records in most of the
-places, like ``A6 0 <128bit>'', so that we would be able to switch to
-fragmented A6 records when we find a need for A6.
-
->From the packet format point of view, the approach has no benefit
-against AAAA. Rather, there is a one-byte overhead to every
-(unfragmented) A6 record compared to a AAAA record.
-
-If the nameserver/resolver programs hardcode A6 processing to handle no
-fragments, there will be no future possibility for us to introduce
-fragmented A6 records. When there is no need for A6 reassembly, there
-will be no code deployment, and even if the reassembly code gets
-deployed they will not be tested enough. The author believes that the
-``prepare for the future, use non-fragmented A6'' argument is not
-worthwhile.
-
-In the event of renumbering, non-fragmented A6 record has the same
-property as AAAA (the whole zone file has to be updated).
-
-3.4. AAAA synthesis (A6 and AAAA hybrid approach)
-
-At this moment, end hosts support AAAA records only. Some people would
-like to see A6 deployment in DNS databases even with the lack of end
-hosts support. To workaround the deployment issues of A6, the following
-approach is proposed in IETF50 dnsext working group slot. It is called
-``AAAA synthesis'' [Austein, 2001] :
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 7]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-o Deploy A6 DNS records worldwide. The proposal was not specific about
- whether we would deploy fragmented A6 records, or non-fragmented A6
- records (``A6 0'').
-
-o When a host queries AAAA record to a DNS server, the DNS server
- queries A6 fragments, reassemble it, and respond with a AAAA record.
-
-The approach needs to be diagnosed/specified in far more detail. For
-example, the following questions need to be answered:
-
-o What is the DNS error code against AAAA querier, if the A6 reassembly
- fails?
-
-o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap
- uses TTL=0]
-
-o Which nameserver should synthesize the AAAA record, in the DNS
- recursize query chain? Is the synthesis mandatory for every DNS
- server implementation?
-
-o What should we do if the A6 reassembly takes too much time?
-
-o What should we do about DNSSEC signatures?
-
-o What if the resolver wants no synthesis? Do we want to have a flag
- bit in DNS packet, to enable/disable AAAA synthesis?
-
-o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query
- timeouts, and other timeout parameters?
-
-The approach seems to be vulnerable against DoS attacks, because the
-nameserver reassembles A6 fragments on behalf of the AAAA querier. See
-security consideration section for more details.
-
-3.5. Issues in keeping both AAAA and A6
-
-If we are to keep both AAAA and A6 records onto the worldwide DNS
-database, it would impose more query delays to the client resolvers.
-Suppose we have a dual-stack host implementation. If they need to
-resolve a name into addresses, the node would need to query in the
-following order (in the order which RFC2874 suggests):
-
-o Query A6 records, and get full IPv6 addresses by chasing and
- reassembling A6 fragment chain.
-
-o Query AAAA records.
-
-o Query A records.
-
-o Sort the result based on destination address ordering rule. An
- example of the ordering rule is presented as a draft [Draves, 2001] .
-
-
-
-HAGINO Expires: January 19, 2002 [Page 8]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-o Contact the destination addresses in sequence.
-
-The ordering imposes additional delays to the resolvers. The above
-ordering would be necessary for all approaches that use A6, as there are
-existing AAAA records in the world.
-
-
-4. Network renumbering
-
-Some says that there will be more frequent renumbers in IPv6 network
-operation, and A6 is necessary to reduce the zone modification cost as
-well as zone signing costs on renumber operation.
-
-It is not clear if we really want to renumber that frequently. With
-IPv6, it should be easier for ISPs to assign addresses statically to the
-downstream customers, rather than dynamically like we do in IPv4 dialup
-connectivity today. If ISPs do assign static IPv6 address block to the
-customers, there is no need to renumber customer network that frequently
-(unless the customer decides to switch the upstream ISPs that often).
-NOTE: Roaming dialup users, like those who carry laptop computers
-worldwide, seems to have a different issue from stationary dialup users.
-See [Hagino, 2000] for more discussions.
-
-It is questionable if it is possible to renumber IPv6 networks more
-frequently than with IPv4. Router renumbering protocol [Crawford, 2000]
-, IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998]
-can help us renumber the IPv6 network, however, network renumbering
-itself is not an easy task. If you would like to maintain reachability
-from the outside world, a site administrator needs to carefully
-coordinate site renumber. The minimal interval between renumber is
-restricted by DNS record timeouts, as DNS records will be cached around
-the world. If the TTL of DNS records are X, the interval between
-renumber must be longer than 2 * X. If we consider clients/servers that
-tries to validate addresses using reverse lookups, we also need to care
-about the relationship between IPv6 address lifetime [Thomson, 1998] and
-the interval between renumber. At IETF50 ipngwg session, there was a
-presentation by JINMEI Tatsuya regarding to site renumbering experiment.
-It is recommend to read through the IETF49 minutes and slides. [XXX
-Fred Baker had a draft on this - where?] For the network renumbering to
-be successful, no configuration files should have hardcoded (numeric) IP
-addresses. It is a very hard requirement to meet. We fail to satisfy
-this in many of the network renumbering events, and the failure causes a
-lot of troubles.
-
-At this moment there is no mechanism defined for ISPs to renumber
-downstream customers at will. Even though it may sound interesting for
-ISPs, it would cause a lot of (social and political) issues in doing so,
-so the author would say it is rather unrealistic to pursue this route.
-The only possible candidate, router renumbering protocol [Crawford,
-2000] does not really fit into the situation. The protocol is defined
-using IPsec authentication over site-local multicast packets. It would
-be cumbersome to run router renumbering protocol across multiple
-
-
-HAGINO Expires: January 19, 2002 [Page 9]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-administrative domains, as (1) customers will not want to share IPsec
-authentication key for routers with the upstream ISP, and (2) customer
-network will be administered as a separate site from the upstream ISP
-(Even though router renumbering protocol could be used with unicast
-addresess, it is not realistic to assume that we can maintain the list
-of IPv6 addresses for all the routers in both customers' and ISPs'
-networks).
-
-A6 was designed to help administators update zone files during network
-renumbering events. Even with AAAA, zone file modification itself is
-easy; you can just query-replace the addresses in the zone files. The
-difficulty of network renumber comes from elsewhere.
-
-With AAAA, we need to sign the whole zone again with DNSSEC keys, after
-renumbering the network. With A6, we need to sign upper bits only with
-DNSSEC keys. Therefore, A6 will impose less zone signing cost on the
-event of network renumbering. As seen above, it is questionable if we
-renumber network that often, so it is questionable if A6 brings us an
-overall benefit. Note, however, even if we use A6 to facilitate more
-frequent renumbering and lower signing cost, all glue records has to be
-installed as non-fragmented A6 records (``A6 0''), and required to be
-signed again on renumbering events.
-
-
-5. Security consideration
-
-There are a couple of security worries mentioned in the above. To give
-a brief summary:
-
-o There will be a higher delay imposed by query/reply roundtrips for
- fragmented A6 records. This could affect every services that relies
- upon DNS records.
-
-o There is no upper limit defined for the number of A6 fragments for
- defining an IPv6 address. Malicious parties may try to put a very
- complex A6 chains and confuse nameservers worldwide.
-
-o A6 resolver/nameserver is much harder to implement correctly than AAAA
- resolver/nameserver. A6 fragment reassembly code needs to take care
- of bitwise data reassembly, bitwise overwrap checks, and others. From
- our implementatation experiences, we expect to see a lot of security-
- issue bugs in the future.
-
-o Interaction between DNS record TTL and the DNS query delays leads to
- non-trivial timeout problem.
-
-We would like to go into more details for some of these.
-
-5.1. DoS attacks against AAAA synthesis
-
-When a DNS server is configured for AAAA synthesis, malicious parties
-can impose DoS attacks using the interaction between DNS TTL and query
-
-
-HAGINO Expires: January 19, 2002 [Page 10]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-delays. The attack can chew CPU time and/or memory, as well as some
-network bandwidth on a victim nameserver, by the following steps:
-
-o A bad guy configures a record with very complex A6 chain, onto some
- nameservers. (the bad guy has to have controls over the servers).
- The nameservers can be located anywhere in the world. The A6 chain
- should have a very low TTL (like 1 or 0 seconds). The attack works
- better if we have higher delays between the victim nameservers and the
- nameservers that serve A6 fragments.
-
-o The bad guy queries the record using AAAA request, to the victim
- nameserver.
-
-o The victim nameserver will try to reassemble A6 fragments. During the
- reassembly process, the victim nameserver puts A6 fragments into the
- local cache. The cached records will expire during the reassembly
- process. The nameserver will need to query a lot of A6 fragments
- (more traffic). The server can go into an infinite loop, if it tries
- to query the expired A6 fragments again.
-
-Note, however, this problem could be considered as a problem in
-recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA
-synthesis makes the problem more apparent, and more complex to diagnose.
-
-To remedy this problem, we have a couple of solutions:
-
-(1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the
- problem goes away.
-
-(2) Even if we use A6, do not configure nameservers for AAAA synthesis.
- Deployment issues with existing IPv6 hosts get much harder.
-
-(3) Impose a protocol limitation to the number of A6 fragments.
-
-(4) Do not query the expired records in A6 chain again. In other words,
- implement resolvers that ignore TTL on DNS records. Not sure if it
- is the right thing to do.
-
-
-6. Conclusion
-
-NOTE: the section expresses the impressions of the author.
-
-A6/AAAA discussion has been an obstacle for IPv6 deployment, as the
-deployment of IPv6 NS recodrs have been deferred because of the
-discussion. The author do not see benefit in keeping both AAAA and A6
-records, as it imposes more query delays to the clients. So the author
-believes that we need to pick one of them.
-
-Given the unlikeliness of frequent network renumbering, the author
-believes that the A6's benefit in lower zone signing cost is not
-significant. The benefit of A6 (in zone signing cost) is much less than
-
-
-HAGINO Expires: January 19, 2002 [Page 11]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-the expected complication that will be imposed by A6 operations.
-
->From the above discussions, the author suggests to keep AAAA and
-deprecate A6 (move A6 document to historic state). The author believes
-that A6 can cause a lot of problem than the benefits it may have. A6
-will make IPv6 DNS operation more complicated and vulnerable to attacks.
-AAAA is proven to work right in our IPv6 network operation since 1996.
-AAAA has been working just fine in existing IPv6 networks, and the
-author believes that it will in the coming days.
-
-
-
-References
-
-Thomson, 1995.
-S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
-RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
-
-Crawford, 2000.
-M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
-Address Aggregation and Renumbering" in RFC2874 (July 2000).
-ftp://ftp.isi.edu/in-notes/rfc2874.txt.
-
-Austein, 2001.
-R. Austein, "Tradeoffs in DNS support for IPv6" in draft-ietf-dnsext-
-ipv6-dns-tradeoffs-00.txt (July 2001). work in progress material.
-
-Draves, 2001.
-Richard Draves, "Default Address Selection for IPv6" in draft-ietf-
-ipngwg-default-addr-select-04.txt (May 2001). work in progress material.
-
-Hagino, 2000.
-Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP
-operation" in draft-itojun-ipv6-dialup-requirement-00.txt (July 2000).
-work in progress material.
-
-Crawford, 2000.
-Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000).
-ftp://ftp.isi.edu/in-notes/rfc2894.txt.
-
-Thomson, 1998.
-S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in
-RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt.
-
-
-Change history
-
-none.
-
-
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 12]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-Acknowledgements
-
-The draft was written based on discussions in IETF IPv6 and dnsext
-working groups, and help from WIDE research group.
-
-
-Author's address
-
- Jun-ichiro itojun HAGINO
- Research Laboratory, Internet Initiative Japan Inc.
- Takebashi Yasuda Bldg.,
- 3-13 Kanda Nishiki-cho,
- Chiyoda-ku,Tokyo 101-0054, JAPAN
- Tel: +81-3-5259-6350
- Fax: +81-3-5259-6351
- Email: itojun@iijlab.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 13]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Peter Koch
-Expires: September 2001 Universitaet Bielefeld
-Updates: RFC 1035 March 2001
-
- A DNS RR Type for Lists of Address Prefixes (APL RR)
- draft-ietf-dnsext-apl-rr-02.txt
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- Comments should be sent to the author or the DNSEXT WG mailing list
- <namedroppers@OPS.IETF.ORG>.
-
-Abstract
-
- The Domain Name System is primarily used to translate domain names
- into IPv4 addresses using A RRs. Several approaches exist to describe
- networks or address ranges. This document specifies a new DNS RR type
- "APL" for address prefix lists.
-
-1. Conventions used in this document
-
- 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].
-
- Domain names herein are for explanatory purposes only and should not
- be expected to lead to useful information in real life [RFC2606].
-
-
-
-
-Koch Expires September 2001 [Page 1]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
-2. Background
-
- The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
- associate addresses and other Internet infrastructure elements with
- hierarchically built domain names. Various types of resource records
- have been defined, especially those for IPv4 and IPv6 [RFC2874]
- addresses. In [RFC1101] a method is described to publish information
- about the address space allocated to an organisation. In older BIND
- versions, a weak form of controlling access to zone data was
- implemented using TXT RRs describing address ranges.
-
- This document specifies a new RR type for address prefix lists.
-
-3. APL RR Type
-
- An APL record has the DNS type of "APL" [draft, IANA: not yet applied
- for] and a numeric value of [draft, IANA:to be assigned]. The APL RR
- is defined in the IN class only. APL RRs cause no additional section
- processing.
-
-4. APL RDATA format
-
- The RDATA section consists of zero or more items (<apitem>) of the
- form
-
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- | ADDRESSFAMILY |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- | PREFIX | N | AFDLENGTH |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- / AFDPART /
- | |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
- ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
- (see IANA Considerations)
- PREFIX 8 bit unsigned binary coded prefix length.
- Upper and lower bounds and interpretation of
- this value are address family specific.
- N negation flag, indicates the presence of the
- "!" character in the textual format. It has
- the value "1" if the "!" was given, "0" else.
- AFDLENGTH length in octets of the following address
- family dependent part (7 bit unsigned).
- AFDPART address family dependent part. See below.
-
-
-
-
-
-Koch Expires September 2001 [Page 2]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
- This document defines the AFDPARTs for address families 1 (IPv4) and
- 2 (IPv6). Future revisions may deal with additional address
- families.
-
-4.1. AFDPART for IPv4
-
- The encoding of an IPv4 address (address family 1) follows the
- encoding specified for the A RR by [RFC1035], section 3.4.1.
-
- PREFIX specifies the number of bits of the IPv4 address starting at
- the most significant bit. Legal values range from 0 to 32.
-
- Trailing zero octets do not bear any information (e.g. there is no
- semantic difference between 10.0.0.0/16 and 10/16) in an address
- prefix, so the shortest possible AFDLENGTH can be used to encode it.
- However, for DNSSEC [RFC2535] a single wire encoding must be used by
- all. Therefore the sender MUST NOT include trailing zero octets in
- the AFDPART regardless of the value of PREFIX. This includes cases in
- which AFDLENGTH times 8 results in a value less than PREFIX. The
- AFDPART is padded with zero bits to match a full octet boundary.
-
- An IPv4 AFDPART has a variable length of 0 to 4 octets.
-
-4.2. AFDPART for IPv6
-
- The 128 bit IPv6 address (address family 2) is encoded in network
- byte order (high-order byte first).
-
- PREFIX specifies the number of bits of the IPv6 address starting at
- the most significant bit. Legal values range from 0 to 128.
-
- With the same reasoning as in 4.1 above, the sender MUST NOT include
- trailing zero octets in the AFDPART regardless of the value of
- PREFIX. This includes cases in which AFDLENGTH times 8 results in a
- value less than PREFIX. The AFDPART is padded with zero bits to
- match a full octet boundary.
-
- An IPv6 AFDPART has a variable length of 0 to 16 octets.
-
-5. Zone File Syntax
-
- The textual representation of an APL RR in a DNS zone file is as
- follows:
-
- <owner> IN <TTL> APL {[!]afi:address/prefix}*
-
- The data consists of zero or more strings of the address family
- indicator <afi>, immediately followed by a colon ":", an address,
-
-
-
-Koch Expires September 2001 [Page 3]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
- immediately followed by the "/" character, immediately followed by a
- decimal numeric value for the prefix length. Any such string may be
- preceded by a "!" character. The strings are separated by whitespace.
- The <afi> is the decimal numeric value of that particular address
- family.
-
-5.1. Textual Representation of IPv4 Addresses
-
- An IPv4 address in the <address> part of an <apitem> is in dotted
- quad notation, just as in an A RR. The <prefix> has values from the
- interval 0..32 (decimal).
-
-5.2. Textual Representation of IPv6 Addresses
-
- The representation of an IPv6 address in the <address> part of an
- <apitem> follows [RFC2373], section 2.2. Legal values for <prefix>
- are from the interval 0..128 (decimal).
-
-6. APL RR usage
-
- An APL RR with empty RDATA is valid and implements an empty list.
- Multiple occurrences of the same <apitem> in a single APL RR are
- allowed and MUST NOT be merged by a DNS server or resolver. <apitems>
- MUST be kept in order and MUST NOT be rearranged or aggregated.
-
- A single APL RR may contain <apitems> belonging to different address
- families. The maximum number of <apitems> is upper bounded by the
- available RDATA space.
-
- RRSets consisting of more than one APL RR are legal but the
- interpretation is left to the particular application.
-
-7. Applicability Statement
-
- The APL RR defines a framework without specifying any particular
- meaning for the list of prefixes. It is expected that APL RRs will
- be used in different application scenarios which have to be
- documented separately. Those scenarios may be distinguished by
- characteristic prefixes placed in front of the DNS owner name.
-
- An APL application specification MUST include information on
-
- o the characteristic prefix, if any
-
- o how to interpret APL RRSets consisting of more than one RR
-
- o how to interpret an empty APL RR
-
-
-
-
-Koch Expires September 2001 [Page 4]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
- o which address families are expected to appear in the APL RRs for
- that application
-
- o how to deal with APL RR list elements which belong to other
- address families, including those not yet defined
-
- o the exact semantics of list elements negated by the "!" character
-
- Possible applications include the publication of address ranges
- similar to [RFC1101], description of zones built following [RFC2317]
- and in-band access control to limit general access or zone transfer
- (AXFR) availability for zone data held in DNS servers.
-
- The specification of particular application scenarios is out of the
- scope of this document.
-
-8. Examples
-
- The following examples only illustrate some of the possible usages
- outlined in the previous section. None of those applications are
- hereby specified nor is it implied that any particular APL RR based
- application does exist now or will exist in the future.
-
- ; RFC 1101-like announcement of address ranges for foo.example
- foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
-
- ; CIDR blocks covered by classless delegation
- 42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
- 1:192.168.42.128/25 )
-
- ; Zone transfer restriction
- _axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
-
- ; List of address ranges for multicast
- multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
-
- Note that since trailing zeroes are ignored in the first APL RR the
- AFDLENGTH of both <apitems> is three.
-
-9. Security Considerations
-
- Any information obtained from the DNS should be regarded as unsafe
- unless techniques specified in [RFC2535] or [RFC2845] were used. The
- definition of a new RR type does not introduce security problems into
- the DNS, but usage of information made available by APL RRs may
- compromise security. This includes disclosure of network topology
- information and in particular the use of APL RRs to construct access
- control lists.
-
-
-
-Koch Expires September 2001 [Page 5]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
-10. IANA Considerations
-
- This section is to be interpreted as following [RFC2434].
-
- This document does not define any new namespaces. It uses the 16 bit
- identifiers for address families maintained by IANA in
- http://www.iana.org/numbers.html.
-
- IANA is asked to assign a numeric RR type value for APL.
-
-11. Acknowledgements
-
- The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
- Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
- and constructive comments.
-
-12. References
-
-
- [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
- RFC 1034, STD 13, November 1987
-
- [RFC1035] Mockapetris,P., "Domain Names - Implementation and
- Specification", RFC 1035, STD 13, November 1987
-
- [RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other
- Types", RFC 1101, April 1989
-
- [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997
-
- [RFC2181] Elz,R., Bush,R., "Clarifications to the DNS
- Specification", RFC 2181, July 1997
-
- [RFC2317] Eidnes,H., de Groot,G., Vixie,P., "Classless IN-ADDR.ARPA
- delegation", RFC 2317, March 1998
-
- [RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998
-
- [RFC2434] Narten,T., Alvestrand,H., "Guidelines for Writing an IANA
- Considerations Section in RFCs", RFC 2434, BCP 26, October
- 1998
-
- [RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
- 2535, March 1999
-
-
-
-
-
-Koch Expires September 2001 [Page 6]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
- [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
- RFC 2606, BCP 32, June 1999
-
- [RFC2845] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B.,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000
-
- [RFC2874] Crawford,M., Huitema,C., "DNS Extensions to Support IPv6
- Address Aggregation and Renumbering", RFC 2874, July 2000
-
-
-
-13. Author's Address
-
- Peter Koch
- Universitaet Bielefeld
- Technische Fakultaet
- D-33594 Bielefeld
- Germany
- +49 521 106 2902
- <pk@TechFak.Uni-Bielefeld.DE>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch Expires September 2001 [Page 7]
+++ /dev/null
-
-
-
-
-
-
- DNSEXT Working Group Olafur Gudmundsson
- INTERNET-DRAFT June 2003
- <draft-ietf-dnsext-delegation-signer-15.txt>
-
- Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
-
-
- Delegation Signer Resource Record
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This draft expires on January 19, 2004.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2003). All rights reserved.
-
-
-
-Abstract
-
- The delegation signer (DS) resource record is inserted at a zone cut
- (i.e., a delegation point) to indicate that the delegated zone is
- digitally signed and that the delegated zone recognizes the indicated
- key as a valid zone key for the delegated zone. The DS RR is a
- modification to the DNS Security Extensions definition, motivated by
- operational considerations. The intent is to use this resource record
- as an explicit statement about the delegation, rather than relying on
- inference.
-
-
-
- Gudmundsson Expires January 2004 [Page 1]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- This document defines the DS RR, gives examples of how it is used and
- describes the implications on resolvers. This change is not backwards
- compatible with RFC 2535.
- This document updates RFC1035, RFC2535, RFC3008 and RFC3090.
-
- Table of contents
-
- Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1
- Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2 Reserved Words" . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2 Specification of the Delegation key Signer" . . . . . . . . . . . 4
- 2.1 Delegation Signer Record Model" . . . . . . . . . . . . . . . . 4
- 2.2 Protocol Change" . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at
- Delegation Points" . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.2.1.1 Special processing for DS queries" . . . . . . . . . . . . 6
- 2.2.1.2 Special processing when child and an ancestor share
- server" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 2.2.1.3 Modification on use of KEY RR in the construction of
- Responses" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 2.2.2 Signer's Name (replaces RFC3008 section 2.7)" . . . . . . . . 9
- 2.2.3 Changes to RFC3090" . . . . . . . . . . . . . . . . . . . . . 9
- 2.2.3.1 RFC3090: Updates to section 1: Introduction" . . . . . . . . 9
- 2.2.3.2 RFC3090 section 2.1: Globally Secured" . . . . . . . . . . . 9
- 2.2.3.3 RFC3090 section 3: Experimental Status." . . . . . . . . . 10
- 2.2.4 NULL KEY elimination" . . . . . . . . . . . . . . . . . . . . 10
- 2.3 Comments on Protocol Changes" . . . . . . . . . . . . . . . . . 10
- 2.4 Wire Format of the DS record" . . . . . . . . . . . . . . . . . 11
- 2.4.1 Justifications for Fields" . . . . . . . . . . . . . . . . . . 12
- 2.5 Presentation Format of the DS Record" . . . . . . . . . . . . . 12
- 2.6 Transition Issues for Installed Base" . . . . . . . . . . . . . 12
- 2.6.1 Backwards compatibility with RFC2535 and RFC1035" . . . . . . 12
- 2.7 KEY and corresponding DS record example" . . . . . . . . . . . . 13
- 3 Resolver" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 3.1 DS Example" . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 3.2 Resolver Cost Estimates for DS Records" . . . . . . . . . . . . 15
- 4 Security Considerations: " . . . . . . . . . . . . . . . . . . . . 15
- 5 IANA Considerations: " . . . . . . . . . . . . . . . . . . . . . . 16
- 6 Acknowledgments" . . . . . . . . . . . . . . . . . . . . . . . . . 16
- Normative References: " . . . . . . . . . . . . . . . . . . . . . . 16
- Informational References" " . . . . . . . . . . . . . . . . . . . . 17
- Author Address" . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- Full Copyright Statement" . . . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 2]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- 1 Introduction
-
- Familiarity with the DNS system [RFC1035], DNS security extensions
- [RFC2535] and DNSSEC terminology [RFC3090] is important.
-
- Experience shows that when the same data can reside in two
- administratively different DNS zones, the data frequently gets out of
- sync. The presence of an NS RRset in a zone anywhere other than at
- the apex indicates a zone cut or delegation. The RDATA of the NS
- RRset specifies the authoritative servers for the delegated or
- "child" zone. Based on actual measurements, 10-30% of all delegations
- on the Internet have differing NS RRsets at parent and child. There
- are a number of reasons for this, including a lack of communication
- between parent and child and bogus name servers being listed to meet
- registry requirements.
-
- DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to
- have its KEY RRset signed by its parent to create a verifiable chain
- of KEYs. There has been some debate on where the signed KEY RRset
- should reside, whether at the child [RFC2535] or at the parent. If
- the KEY RRset resides at the child, maintaining the signed KEY RRset
- in the child requires frequent two-way communication between the two
- parties. First the child transmits the KEY RRset to the parent and
- then the parent sends the signature(s) to the child. Storing the KEY
- RRset at the parent was thought to simplify the communication.
-
- DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
- an unsecure child zone to indicate that the child is unsecure. A NULL
- KEY record is a waste: an entire signed RRset is used to communicate
- effectively one bit of information--that the child is unsecure.
- Chasing down NULL KEY RRsets complicates the resolution process in
- many cases, because servers for both parent and child need to be
- queried for the KEY RRset if the child server does not return it.
- Storing the KEY RRset only in the parent zone simplifies this and
- would allow the elimination of the NULL KEY RRsets entirely. For
- large delegation zones the cost of NULL keys is a significant barrier
- to deployment.
-
- Prior to the restrictions imposed by RFC3445[RFC3445], another
- implication of the DNSSEC key model is that the KEY record could be
- used to store public keys for other protocols in addition to DNSSEC
- keys. There are number of potential problems with this, including:
- 1. The KEY RRset can become quite large if many applications and
- protocols store their keys at the zone apex. Possible protocols
- are IPSEC, HTTP, SMTP, SSH and others that use public key
- cryptography.
- 2. The KEY RRset may require frequent updates.
- 3. The probability of compromised or lost keys, which trigger
- emergency key rollover procedures, increases.
-
-
-
- Gudmundsson Expires January 2004 [Page 3]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- 4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
- keys.
- 5. The parent may not meet the child's expectations of turnaround
- time for resigning the KEY RRset.
-
- Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
-
-
- 1.2 Reserved Words
-
- The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
- "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
- interpreted as described in RFC2119.
-
- 2 Specification of the Delegation key Signer
-
- This section defines the Delegation Signer (DS) RR type (type code
- TBD) and the changes to DNS to accommodate it.
-
- 2.1 Delegation Signer Record Model
-
- This document presents a replacement for the DNSSEC KEY record chain
- of trust [RFC2535] that uses a new RR that resides only at the
- parent. This record identifies the key(s) that the child uses to
- self-sign its own KEY RRset.
-
- Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
- and Zone Signing Key (ZSK), there is no requirement that zone use two
- different keys for these roles. It is expected that many small zones
- will only use one key, while larger zones will be more likely to use
- multiple keys.
-
- The chain of trust is now established by verifying the parent KEY
- RRset, the DS RRset from the parent and the KEY RRset at the child.
- This is cryptographically equivalent to using just KEY records.
-
- Communication between the parent and child is greatly reduced, since
- the child only needs to notify the parent about changes in keys that
- sign its apex KEY RRset. The parent is ignorant of all other keys in
- the child's apex KEY RRset. Furthermore, the child maintains full
- control over the apex KEY RRset and its content. The child can
- maintain any policies regarding its KEY usage for DNSSEC with minimal
- impact on the parent. Thus if the child wants to have frequent key
- rollover for its DNS zone keys, the parent does not need to be aware
- of it. The child can use one key to sign only its apex KEY RRset and
- a different key to sign the other RRsets in the zone.
-
- This model fits well with a slow roll out of DNSSEC and the islands
- of security model. In this model, someone who trusts "good.example."
-
-
-
- Gudmundsson Expires January 2004 [Page 4]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- can preconfigure a key from "good.example." as a trusted key, and
- from then on trusts any data signed by that key or that has a chain
- of trust to that key. If "example." starts advertising DS records,
- "good.example." does not have to change operations by suspending
- self-signing. DS records can be used in configuration files to
- identify trusted keys instead of KEY records. Another significant
- advantage is that the amount of information stored in large
- delegation zones is reduced: rather than the NULL KEY record at every
- unsecure delegation demanded by RFC 2535, only secure delegations
- require additional information in the form of a signed DS RRset.
-
- The main disadvantage of this approach is that verifying a zone's KEY
- RRset requires two signature verification operations instead of the
- one in RFC 2535 chain of trust. There is no impact on the number of
- signatures verified for other types of RRsets.
-
- 2.2 Protocol Change
-
- All DNS servers and resolvers that support DS MUST support the OK bit
- [RFC3225] and a larger message size [RFC3226]. In order for a
- delegation to be considered secure the delegation MUST contain a DS
- RRset. If a query contains the OK bit, a server returning a referral
- for the delegation MUST include the following RRsets in the authority
- section in this order:
- If DS RRset is present:
- parent's copy of child's NS RRset
- DS and SIG(DS)
- If no DS RRset is present:
- parent's copy of child's NS RRset
- parent's zone NXT and SIG(NXT)
-
- This increases the size of referral messages, possibly causing some
- or all glue to be omitted. If the DS or NXT RRsets with signatures do
- not fit in the DNS message, the TC bit MUST be set. Additional
- section processing is not changed.
-
- A DS RRset accompanying a NS RRset indicates that the child zone is
- secure. If a NS RRset exists without a DS RRset, the child zone is
- unsecure (from the parents point of view). DS RRsets MUST NOT appear
- at non-delegation points or at a zone's apex.
-
- Section 2.2.1 defines special considerations related to authoritative
- servers responding to DS queries and replaces RFC2535 sections 2.3.4
- and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section
- 2.2.3 updates RFC3090.
-
-
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 5]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- 2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
-
- DNS security views each zone as a unit of data completely under the
- control of the zone owner with each entry (RRset) signed by a special
- private key held by the zone manager. But the DNS protocol views the
- leaf nodes in a zone that are also the apex nodes of a child zone
- (i.e., delegation points) as "really" belonging to the child zone.
- The corresponding domain names appear in two master files and might
- have RRsets signed by both the parent and child zones' keys. A
- retrieval could get a mixture of these RRsets and SIGs, especially
- since one server could be serving both the zone above and below a
- delegation point [RFC 2181].
-
- Each DS RRset stored in the parent zone MUST be signed by at least
- one of the parent zone's private keys. The parent zone MUST NOT
- contain a KEY RRset at any delegation point. Delegations in the
- parent MAY contain only the following RR types: NS, DS, NXT and SIG.
- The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
- case: it will always appear differently and authoritatively in both
- the parent and child zones if both are secure.
-
- A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
- verifying the DS RRset from the parent, a resolver MAY trust any KEY
- identified in the DS RRset as a valid signer of the child's apex KEY
- RRset. Resolvers configured to trust one of the keys signing the KEY
- RRset MAY now treat any data signed by the zone keys in the KEY RRset
- as secure. In all other cases resolvers MUST consider the zone
- unsecure. A DS RRset MUST NOT appear at a zone's apex.
-
- An authoritative server queried for type DS MUST return the DS RRset
- in the answer section.
-
-
- 2.2.1.1 Special processing for DS queries
-
- When a server is authoritative for the parent zone at a delegation
- point and receives a query for the DS record at that name, it MUST
- answer based on data in the parent zone, return DS or negative
- answer. This is true whether or not it is also authoritative for the
- child zone.
-
- When the server is authoritative for the child zone at a delegation
- point but not the parent zone, there is no natural response, since
- the child zone is not authoritative for the DS record at the zone's
- apex. As these queries are only expected to originate from recursive
- servers which are not DS-aware, the authoritative server MUST answer
- with:
- RCODE: NOERROR
- AA bit: set
-
-
-
- Gudmundsson Expires January 2004 [Page 6]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- Answer Section: Empty
- Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
- That is, it answers as if it is authoritative and the DS record does
- not exist. DS-aware recursive servers will query the parent zone at
- delegation points, so will not be affected by this.
-
- A server authoritative for only the child zone, that is also a
- caching server MAY (if the RD bit is set in the query) perform
- recursion to find the DS record at the delegation point, or MAY
- return the DS record from its cache. In this case, the AA bit MUST
- not be set in the response.
-
-
- 2.2.1.2 Special processing when child and an ancestor share server
-
- Special rules are needed to permit DS RR aware servers to gracefully
- interact with older caches which otherwise might falsely label a
- server as lame because of the placement of the DS RR set.
-
- Such a situation might arise when a server is authoritative for both
- a zone and it's grandparent, but not the parent. This sounds like an
- obscure example, but it is very real. The root zone is currently
- served on 13 machines, and "root-servers.net." is served on 4 of the
- same 13, but "net." is served elsewhere.
-
- When a server receives a query for (<QNAME>, DS, <QCLASS>), the
- response MUST be determined from reading these rules in order:
-
-
- 1) If the server is authoritative for the zone that holds the DS RR
- set (i.e., the zone that delegates <QNAME>, aka the "parent" zone),
- the response contains the DS RR set as an authoritative answer.
-
- 2) If the server is offering recursive service and the RD bit is set
- in the query, the server performs the query itself (according to the
- rules for resolvers described below) and returns its findings.
-
- 3) If the server is authoritative for the zone that holds the
- <QNAME>'s SOA RR set, the response is an authoritative negative
- answer as described in 2.2.1.1.
-
- 4) If the server is authoritative for a zone or zones above the
- QNAME, a referral to the most enclosing zone's servers is made.
-
- 5) If the server is not authoritative for any part of the QNAME, a
- response indicating a lame server for QNAME is given.
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 7]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- Using these rules will require some special processing on the part of
- a DS RR aware resolver. To illustrate this, an example is used.
-
- Assuming a server is authoritative for roots.example.net. and for the
- root zone but not the intervening two zones (or the intervening two
- label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS,
- and QCLASS=IN.
-
- The resolver will issue this request (assuming no cached data)
- expecting a referral to a net. server. Instead, rule number 3 above
- applies and a negative answer is returned by the server. The
- reaction by the resolver is not to accept this answer as final as it
- can determine from the SOA RR in the negative answer the context
- within which the server has answered.
-
- A solution to this is to instruct the resolver to hunt for the
- authoritative zone of the data in a brute force manner.
-
- This can be accomplished by taking the owner name of the returned SOA
- RR and striping off enough left-hand labels until a successful NS
- response is obtained. A successful response here means that the
- answer has NS records in it. (Entertaining the possibility that a
- cut point can be two labels down in a zone.)
-
- Returning to the example, the response will include a negative answer
- with either the SOA RR for "roots.example.net." or "example.net."
- depending on whether roots.example.net is a delegated domain. In
- either case, removing the left most label of the SOA owner name will
- lead to the location of the desired data.
-
-
- 2.2.1.3 Modification on use of KEY RR in the construction of Responses
-
- This section updates RFC2535 section 3.5 by replacing it with the
- following:
-
- A query for KEY RR MUST NOT trigger any additional section
- processing. Security aware resolvers will include corresponding SIG
- records in the answer section.
-
- KEY records SHOULD NOT be added to the additional records section in
- response to any query.
-
- RFC2535 specified that KEY records be added to the additional section
- when SOA or NS records where included in an answer. This was done to
- reduce round trips (in the case of SOA) and to force out NULL KEYs
- (in the NS case). As this document obsoletes NULL keys there is no
- need for the inclusion of KEYs with NSs. Furthermore as SOAs are
- included in the authority section of negative answers, including the
-
-
-
- Gudmundsson Expires January 2004 [Page 8]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- KEYs each time will cause redundant transfers of KEYs.
-
- RFC2535 section 3.5 also included rule for adding the KEY RRset to
- the response for a query for A and AAAA types. As Restrict
- KEY[RFC3445] eliminated use of KEY RR by all applications this rule
- is no longer needed.
-
-
- 2.2.2 Signer's Name (replaces RFC3008 section 2.7)
-
- The signer's name field of a SIG RR MUST contain the name of the zone
- to which the data and signature belong. The combination of signer's
- name, key tag, and algorithm MUST identify a zone key if the SIG is
- to be considered material. This document defines a standard policy
- for DNSSEC validation; local policy MAY override the standard policy.
-
- There are no restrictions on the signer field of a SIG(0) record.
- The combination of signer's name, key tag, and algorithm MUST
- identify a key if this SIG(0) is to be processed.
-
-
- 2.2.3 Changes to RFC3090
-
- A number of sections of RFC3090 need to be updated to reflect the DS
- record.
-
-
- 2.2.3.1 RFC3090: Updates to section 1: Introduction
-
- Most of the text is still relevant but the words ``NULL key'' are to
- be replaced with ``missing DS RRset''. In section 1.3 the last three
- paragraphs discuss the confusion in sections of RFC 2535 that are
- replaced in section 2.2.1 above. Therefore, these paragraphs are now
- obsolete.
-
-
- 2.2.3.2 RFC3090 section 2.1: Globally Secured
-
- Rule 2.1.b is replaced by the following rule:
-
- 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
- private key whose public counterpart MUST appear in a zone signing
- KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
- implement algorithm. This KEY RR MUST be identified by a DS RR in a
- signed DS RRset in the parent zone.
-
- If a zone cannot get its parent to advertise a DS record for it, the
- child zone cannot be considered globally secured. The only exception
- to this is the root zone, for which there is no parent zone.
-
-
-
- Gudmundsson Expires January 2004 [Page 9]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- 2.2.3.3 RFC3090 section 3: Experimental Status.
-
- The only difference between experimental status and globally secured
- is the missing DS RRset in the parent zone. All locally secured zones
- are experimental.
-
-
- 2.2.4 NULL KEY elimination
-
- RFC3445 section 3 eliminates the top two bits in the flags field of
- KEY RR. These two bits were used to indicate NULL KEY or NO KEY.
- RFC3090 defines that zone is either secure or not, these rules
- eliminates the possible need to put NULL keys in the zone apex to
- indicate that the zone is not secured for a algorithm. Along with
- this document these other two eliminate all uses for the NULL KEY,
- This document obsoletes NULL KEY.
-
- 2.3 Comments on Protocol Changes
-
- Over the years there have been various discussions surrounding the
- DNS delegation model, declaring it to be broken because there is no
- good way to assert if a delegation exists. In the RFC2535 version of
- DNSSEC, the presence of the NS bit in the NXT bit map proves there is
- a delegation at this name. Something more explicit is needed and the
- DS record addresses this need for secure delegations.
-
- The DS record is a major change to DNS: it is the first resource
- record that can appear only on the upper side of a delegation. Adding
- it will cause interoperabilty problems and requires a flag day for
- DNSSEC. Many old servers and resolvers MUST be upgraded to take
- advantage of DS. Some old servers will be able to be authoritative
- for zones with DS records but will not add the NXT or DS records to
- the authority section. The same is true for caching servers; in
- fact, some might even refuse to pass on the DS or NXT records.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 10]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- 2.4 Wire Format of the DS record
-
- The DS (type=TDB) record contains these fields: key tag, algorithm,
- digest type, and the digest of a public key KEY record that is
- allowed and/or used to sign the child's apex KEY RRset. Other keys
- MAY sign the child's apex KEY RRset.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | key tag | algorithm | Digest type |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | digest (length depends on type) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | (SHA-1 digest is 20 bytes) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The key tag is calculated as specified in RFC2535. Algorithm MUST be
- an algorithm number assigned in the range 1..251 and the algorithm
- MUST be allowed to sign DNS data. The digest type is an identifier
- for the digest algorithm used. The digest is calculated over the
- canonical name of the delegated domain name followed by the whole
- RDATA of the KEY record (all four fields).
-
- digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
-
- KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
-
- Digest type value 0 is reserved, value 1 is SHA-1, and reserving
- other types requires IETF standards action. For interoperabilty
- reasons, keeping number of digest algorithms low is strongly
- RECOMMENDED. The only reason to reserve additional digest types is
- to increase security.
-
- DS records MUST point to zone KEY records that are allowed to
- authenticate DNS data. The indicated KEY records protocol field MUST
- be set to 3; flag field bit 7 MUST be set to 1. The value of other
- flag bits is not significant for the purposes of this document.
-
- The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
- of key size. New digest types probably will have larger digests.
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 11]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- 2.4.1 Justifications for Fields
-
- The algorithm and key tag fields are present to allow resolvers to
- quickly identify the candidate KEY records to examine. SHA-1 is a
- strong cryptographic checksum: it is computationally infeasible for
- an attacker to generate a KEY record that has the same SHA-1 digest.
- Combining the name of the key and the key rdata as input to the
- digest provides stronger assurance of the binding. Having the key
- tag in the DS record adds greater assurance than the SHA-1 digest
- alone, as there are now two different mapping functions.
-
- This format allows concise representation of the keys that the child
- will use, thus keeping down the size of the answer for the
- delegation, reducing the probability of DNS message overflow. The
- SHA-1 hash is strong enough to uniquely identify the key and is
- similar to the PGP key footprint. The digest type field is present
- for possible future expansion.
-
- The DS record is well suited to listing trusted keys for islands of
- security in configuration files.
-
- 2.5 Presentation Format of the DS Record
-
- The presentation format of the DS record consists of three numbers
- (key tag, algorithm and digest type) followed by the digest itself
- presented in hex:
- example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
-
- 2.6 Transition Issues for Installed Base
-
- No backwards compatibility with RFC2535 is provided.
-
- RFC2535-compliant resolvers will assume that all DS-secured
- delegations are locally secure. This is bad, but the DNSEXT Working
- Group has determined that rather than dealing with both
- RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is
- preferable. Thus the only option for early adopters is to upgrade to
- DS as soon as possible.
-
- 2.6.1 Backwards compatibility with RFC2535 and RFC1035
-
- This section documents how a resolver determines the type of
- delegation.
- RFC1035 delegation (in parent) has:
-
- RFC1035 NS
-
- RFC2535 adds the following two cases:
-
-
-
-
- Gudmundsson Expires January 2004 [Page 12]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- Secure RFC2535: NS + NXT + SIG(NXT)
- NXT bit map contains: NS SIG NXT
- Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
- NXT bit map contains: NS SIG KEY NXT
- KEY must be a NULL key.
-
- DNSSEC with DS has the following two states:
-
- Secure DS: NS + DS + SIG(DS)
- NXT bit map contains: NS SIG NXT DS
- Unsecure DS: NS + NXT + SIG(NXT)
- NXT bit map contains: NS SIG NXT
-
- It is difficult for a resolver to determine if a delegation is secure
- RFC 2535 or unsecure DS. This could be overcome by adding a flag to
- the NXT bit map, but only upgraded resolvers would understand this
- flag, anyway. Having both parent and child signatures for a KEY RRset
- might allow old resolvers to accept a zone as secure, but the cost of
- doing this for a long time is much higher than just prohibiting RFC
- 2535-style signatures at child zone apexes and forcing rapid
- deployment of DS-enabled servers and resolvers.
-
- RFC 2535 and DS can in theory be deployed in parallel, but this would
- require resolvers to deal with RFC 2535 configurations forever. This
- document obsoletes the NULL KEY in parent zones, which is a difficult
- enough change that to cause a flag day.
-
- 2.7 KEY and corresponding DS record example
-
- This is an example of a KEY record and the corresponding DS record.
-
- dskey.example. KEY 256 3 1 (
- AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
- 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
- ) ; key id = 28668
- DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 13]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- 3 Resolver
-
- 3.1 DS Example
-
- To create a chain of trust, a resolver goes from trusted KEY to DS to
- KEY.
-
- Assume the key for domain "example." is trusted. Zone "example."
- contains at least the following records:
- example. SOA <soa stuff>
- example. NS ns.example.
- example. KEY <stuff>
- example. NXT NS SOA KEY SIG NXT secure.example.
- example. SIG(SOA)
- example. SIG(NS)
- example. SIG(NXT)
- example. SIG(KEY)
- secure.example. NS ns1.secure.example.
- secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo>
- secure.example. NXT NS SIG NXT DS unsecure.example.
- secure.example. SIG(NXT)
- secure.example. SIG(DS)
- unsecure.example NS ns1.unsecure.example.
- unsecure.example. NXT NS SIG NXT example.
- unsecure.example. SIG(NXT)
-
- In zone "secure.example." following records exist:
- secure.example. SOA <soa stuff>
- secure.example. NS ns1.secure.example.
- secure.example. KEY <tag=12345 alg=3>
- secure.example. KEY <tag=54321 alg=5>
- secure.example. NXT <nxt stuff>
- secure.example. SIG(KEY) <key-tag=12345 alg=3>
- secure.example. SIG(SOA) <key-tag=54321 alg=5>
- secure.example. SIG(NS) <key-tag=54321 alg=5>
- secure.example. SIG(NXT) <key-tag=54321 alg=5>
-
- In this example the private key for "example." signs the DS record
- for "secure.example.", making that a secure delegation. The DS record
- states which key is expected to sign the KEY RRset at
- "secure.example.". Here "secure.example." signs its KEY RRset with
- the KEY identified in the DS RRset, thus the KEY RRset is validated
- and trusted.
-
- This example has only one DS record for the child, but parents MUST
- allow multiple DS records to facilitate key rollover and multiple KEY
- algorithms.
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 14]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- The resolver determines the security status of "unsecure.example." by
- examining the parent zone's NXT record for this name. The absence of
- the DS bit indicates an unsecure delegation. Note the NXT record
- SHOULD only be examined after verifying the corresponding signature.
-
- 3.2 Resolver Cost Estimates for DS Records
-
- From a RFC2535 resolver point of view, for each delegation followed
- to chase down an answer, one KEY RRset has to be verified.
- Additional RRsets might also need to be verified based on local
- policy (e.g., the contents of the NS RRset). Once the resolver gets
- to the appropriate delegation, validating the answer might require
- verifying one or more signatures. A simple A record lookup requires
- at least N delegations to be verified and one RRset. For a DS-enabled
- resolver, the cost is 2N+1. For an MX record, where the target of
- the MX record is in the same zone as the MX record, the costs are N+2
- and 2N+2, for RFC 2535 and DS, respectively. In the case of negatives
- answer the same ratios hold true.
-
- The resolver have to do an extra query to get the DS record and this
- increases the overall cost of resolving this question, but this is
- never worse than chasing down NULL KEY records from the parent in
- RFC2535 DNSSEC.
-
- DS adds processing overhead on resolvers and increases the size of
- delegation answers, but much less than storing signatures in the
- parent zone.
-
- 4 Security Considerations:
-
- This document proposes a change to the validation chain of KEY
- records in DNSSEC. The change is not believed to reduce security in
- the overall system. In RFC2535 DNSSEC, the child zone has to
- communicate keys to its parent and prudent parents will require some
- authentication with that transaction. The modified protocol will
- require the same authentication, but allows the child to exert more
- local control over its own KEY RRset.
-
- There is a remote possibility that an attacker could generate a valid
- KEY that matches all the DS fields, of a specific DS set, and thus
- forge data from the child. This possibility is considered
- impractical, as on average more than
- 2 ^ (160 - <Number of keys in DS set>)
- keys would have to be generated before a match would be found.
-
- An attacker that wants to match any DS record will have to generate
- on average at least 2^80 keys.
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 15]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- The DS record represents a change to the DNSSEC protocol and there is
- an installed base of implementations, as well as textbooks on how to
- set up secure delegations. Implementations that do not understand the
- DS record will not be able to follow the KEY to DS to KEY chain and
- will consider all zones secured that way as unsecure.
-
- 5 IANA Considerations:
-
- IANA needs to allocate an RR type code for DS from the standard RR
- type space (type 43 requested).
-
- IANA needs to open a new registry for the DS RR type for digest
- algorithms. Defined types are:
- 0 is Reserved,
- 1 is SHA-1.
- Adding new reservations requires IETF standards action.
-
- 6 Acknowledgments
-
- Over the last few years a number of people have contributed ideas
- that are captured in this document. The core idea of using one key to
- sign only the KEY RRset comes from discussions with Bill Manning and
- Perry Metzger on how to put in a single root key in all resolvers.
- Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob
- Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson,
- Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek
- Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
- Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
- Andrews, Harald Alvestrand, and others have provided useful comments.
-
- Normative References:
-
- [RFC1035] P. Mockapetris, ``Domain Names - Implementation and
- Specification'', STD 13, RFC 1035, November 1987.
-
- [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
- 2535, March 1999.
-
- [RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing
- Authority'', RFC 3008, November 2000.
-
- [RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone
- Status'', RFC 3090, March 2001.
-
- [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
- 3225, December 2001.
-
- [RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource
- Record (RR)``, RFC 3445, December 2002.
-
-
-
- Gudmundsson Expires January 2004 [Page 16]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
- Informational References
-
- [RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'',
- RFC 2181, July 1997.
-
- [RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
- message size requirements'', RFC 3226, December 2001.
-
- Author Address
-
- Olafur Gudmundsson
- 3821 Village Park Drive
- Chevy Chase, MD, 20815
- USA
- <ogud@ogud.com>
-
- Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 17]
-\f
-INTERNET-DRAFT Delegation Signer Record June 2003
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Gudmundsson Expires January 2004 [Page 1]
+++ /dev/null
-
-Internet Draft Naomasa Maruyama
-draft-ietf-idn-aceid-02.txt Yoshiro Yoneya
-Jun 19, 2000 JPNIC
-Expires Dec 19, 2001
-
- Proposal for a determining process of ACE identifier
-
-Status of this memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
- In IETF IDN WG, various kinds of ASCII Compatible Encodings,
-hereafter abbreviated as "ACE", are discussed as methods for realizing
-multilingual domain names (hereafter referred to as "MDN"). Each ACE
-uses a prefix or a suffix as an identifier in order for MDNs to fit
-within the existing ASCII domain name space. In other words,
-acceptance of an ACE proposal as an Internet standard means that the
-existing ASCII domain name space will be partitioned, in order to
-accommodate MDN space.
-
- This document describes possible trouble in the standardization
-process of ACE, and proposes a solution for it.
-
-
-1. Present situation and concern
-
- At present, some specifications relating to MDN specify their own
-ACE identifiers. In these drafts, multilingual domain names encoded
-into ASCII character strings, with the ACE identifiers in their heads
-or tails, are merely ASCII character strings. It is possible
-accidently or intentionally to register a domain name that is not an
-MDN but has the designated ACE identifier string.
-
- If this kind of registration takes place, there is no warranty
-that the domain name will be consistent with MDN semantics.
-Furthermore, there is no warranty that the name, interpreted as an
-MDN, will comply with the registration policies of the registry, when
-the ACE identifier proposal is finally accepted as an Internet
-standard. This might cause problems with name disputes and/or
-revocations.
-
- Therefore, the current situation letting independent ACE proposal
-authors arbitrarily select an ACE identifier, hence permitting domain
-name registrants registrer such names, may hinder deployment of MDN
-technology.
-
-
-2. Selecting ACE identifiers
-
- In order to maintain a smooth standardization process for ACE,
-this document proposes a strategy for selecting and reserving of ACE
-identifiers and a method for assigning them.
-
-
-2.1 The ACE identifier candidates and tentative suspension of
- registering relevant domain names
-
- All strings starting with a combination of two alpha-numericals,
-followed by two hyphens, are defined to be ACE prefix identifier
-candidates. All strings starting with two hyphens followed by two
-alpha-numericals are defined as ACE suffix identifier candidates. ACE
-prefix identifier candidates and ACE suffix identifier candidates are
-collectively called ACE identifier candidates.
-
- All the domain name registries recognized by ICANN SHOULD
-tentatively suspend registration of domain names which have an ACE
-prefix identifier candidate at the head of at least one label of the
-domain name and those which have an ACE suffix identifier candidate at
-the tail of at least one label of the name. These domain names are
-collectively called "relevant domain names".
-
- This suspension should be continued until September 1, 2001
-00:00:00 UTC.
-
-
-2.2 Survey of relevant domain name registration
-
- All registries recognized by ICANN SHOULD conduct a survey about
-relevant domain names registered in their zone, and report, no later
-than August 11, 2001 00:00:00 UTC, all of the ACE identifier
-candidates which are used by relevant domain names.
-
-
-2.3 Selection of ACE identifiers and permanent blocking of
- relevant domain names
-
- The IDN WG or other organ of IETF or ICANN MUST summarize the
-reports and list ACE identifier candidates that are not reported to be
-used in registered domain names by August 18, 2001 00:00:00 UTC, and
-select ten to twenty ACE prefix identifier candidates and ten to
-twenty ACE suffix identifier candidates for ACE identifiers. Among
-these twenty to forty ACE identifiers, one prefix identifier and one
-suffix identifier will be used for experiments. Others will be used,
-one by one as ACE standard evolves.
-
- The list of ACE identifiers will be sent to IANA, and will be
-maintained by IANA from August 25, 2001 00:00:00 UTC. Domain names
-relevant to these identifiers SHOULD NOT be registered in any DNS
-zone, except for registration of multilingual domain names compliant
-to one of future IDN standards. This new restriction about the domain
-name space will be notified to all ICANN recognized registries by IANA
-immediately after it receives the list.
-
-
-2.4 Blocking of registration for relevant domain names
-
- Domain names relevant to ACE identifiers selected by the procedure
-described in section 2.3 SHOULD NOT be registered in any zone of ICANN
-recognized registries except for registration of multilingual domain
-names compliant to one of future IDN standards. All ICANN recognized
-registries SHOULD implement this restriction no later than September 1,
-2001 00:00:00 UTC.
-
- Registration for domain names relevant to ACE identifier
-candidates, tentatively suspended by 2.1, but not relevant to ACE
-identifiers selected by section 2.3 MAY be reopened from September 1,
-2001 00:00:00 UTC.
-
-
-3. Use of an ACE identifier in writing an ACE proposal
-
- When writing an ACE proposal using an ACE identifier, the author
-SHOULD either describe the ACE identifier as "to be decided" and left
-to discretion of the IDN WG or other organ of IETF or ICANN, or use
-either of the ACE identifiers for experiment defined in section 2.3,
-with a unique version number added after or before the prefix or
-suffix.
-
- If a proposal is validated and published as an Internet Draft, the
-IDN WG or other organ of IETF or ICANN MUST replace the "to be
-decided" part with an experimental identifier with a unique version
-number added after or before the prefix or the suffix.
-
-
-4. Determination of ACE identifier
-
- When an Internet Draft relating to ACE is accepted as an Internet
-standard and becomes an RFC, IDN WG or other organ of IETF or ICANN
-MUST replace the experimental ACE identifier, augmented by the version
-number, with one of the ACE identifiers.
-
-
-5. Security considerations
-
- None in particular.
-
-
-6. Changes from the previous version
-
- We excluded suffixes of one hyphen followed by three alpha-
-numericals from the candidates. This is because we found that, as of
-Nov. 29, 2000, there were 23,921 domain names registered in the .JP
-space relevant to these suffixes. This was more than 10% of 227,852
-total registrations in the JPNIC database at the moment, and hence we
-felt these suffixes are not good candidates.
-
- In addition to this and some minor linguistic corrections, we
-changed "The IDN WG" in section 2.3 to "The IDN WG or other organ of
-IETF or ICANN".
-
-
-7. References
-
-[IDNREQ] Z Wenzel, J Seng, "Requirements of Internationalized Domain
- Names", draft-ietf-idn-requirements-03.txt, Jun 2000.
-
-[RACE] P Hoffman, "RACE: Row-based ASCII Compatible Encoding for
- IDN", draft-ietf-idn-race-02.txt, Oct 2000.
-
-[BRACE] A Costello, "BRACE: Bi-mode Row-based ASCII-Compatible
- Encoding for IDN", draft-ietf-idn-brace-00.txt, Sep 2000.
-
-[LACE] P Hoffman, "LACE: Length-based ASCII Compatible Encoding for
- IDN", draft-ietf-idn-lace-00.txt, Nov 2000.
-
-[VERSION] M Blanchet, "Handling versions of internationalized domain
- names protocols", draft-ietf-idn-version-00.txt, Nov 2000.
-
-
-8. Acknowledgements
-
- We would like to express our hearty thanks to members of JPNIC IDN
-Task Force for valuable discussions about this issue. We also would
-like to express our appreciation to Mr. Dave Crocker for checking and
-correcting the preliminary version of this draft.
-
-
-9. Author's Address
-
-Naomasa Maruyama
-Japan Network Information Center
-Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
-Chiyoda-ku Tokyo 101-0052, Japan
-maruyama@nic.ad.jp
-
-Yoshiro Yoneya
-Japan Network Information Center
-Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
-Chiyoda-ku Tokyo 101-0052, Japan
-yone@nic.ad.jp
+++ /dev/null
-\8f©ÀInternet Draft James SENG
-<draft-ietf-idn-cjk-01.txt> Yoshiro YONEYA
-11th Apr 2001 Kenny HUANG
-Expires 11 Oct 2001 KIM Kyongsok
-
- Han Ideograph (CJK) for Internationalized Domain Names
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance
- with all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet
- Engineering Task Force (IETF), its areas, and its working
- groups. Note that other groups may also distribute working
- documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of
- six months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-
- Drafts as reference material or to cite them other than as
- "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
-During the development of Internationalized Domain Name (IDN), it is
-discovered that there is a substantial lack of information and
-misunderstanding on Han ideographs and its folding mechanism.
-
-This document attempts to address some of the issues on doing han
-folding with respect to IDN. Hopefully, this will dispel some of the
-common misunderstanding of this problem and to discuss some of the
-issues with han ideograph and its folding mechanism.
-
-This document addresses very specific problem to IDN and thus is not
-meant as a reference for generic Han folding. Generic Han folding are
-much more complicated and certainly beyond this document. However, the
-use of this document may be applicable to other areas that are related
-with names, e.g. Common Name Resolution Protocol [CNRP].
-
-1. Definition and convention
-
-Characters mentioned in this document are identified by their position
-or code point in the Unicode character set [UCS]. The notation U+12AB,
-for example, indicates the character at the position 12AB (hexadecimal)
-in the [UCS]. It is strongly recommended that a [UCS] table is available
-for reference for the ideograph described.
-
-Han ideographs are defined as the Chinese ideographs starting from
-U+3400 to U+9FFF or commonly known as CJK Unification Ideographs. This
-covers Chinese 'hanzi' {U+6F22 U+5B57/U+6C49 U+5B57}, Japanese 'kanji'
-(U+6F22 U+5B57) and Korean 'hanja' {U+6F22 U+5B57/U+D55C U+C790}.
-Additional Han ideographs will appear in other location (not necessary
-in plane 0) in the future.
-
-Conversion between ideographs can be done using four different
-approaches: Code-base substitution, character-based substitution,
-lexicon-based substitution and context-based substitution. Han folding
-refers only to code-base substitution, similar to case mapping of
-alphabetic characters.
-
-2. Introduction
-
-Traditionally, domain names have been case insensitive (as defined in
-[RFC1035] Section 2.3.3). While this is not a problem when domain names
-are restricted to English alphanumeric letters and digits, it becomes a
-serious problem for IDN. An important criterion for having a robust IDN
-is to have good normalization and canonicalization forms. This is to
-ensure domain name duplications are kept to the minimal.
-
-Fortunately, Unicode Consortium is developing technical reports on
-canonicalization [UTR21] and normalization [UTR15]. Hence, it becomes
-simple for IDN to ride upon the work of Unicode and use these
-references.
-
-Unfortunately, both [UTR15] and [UTR21] are limited in scope and do not
-address many other scripts. In particular, Han ideographs are not
-discussed in detail in these documents and most experts are quick to
-point out that this problem is technically impossible.
-
-2.1 Han ideographs
-
-While there are many forms or writing style for Chinese characters, the
-most common used 'zhengti' {U+6B63 U+4F53/U+6B63 U+9AD4} represent
-Chinese ideographs by radicals (U+2E80-U+2FDF) that is composed of
-simple strokes.
-
-When the Unicode Consortium started work on Universal Character Set, it
-was suggested that Hanzi, Kanji and Hanja ideographs should be unified
-into a single code space. This resulted in the CJK Unification, whereby
-27,786 Han ideographs are allocated in U+3400-U+9FFF and U+F900-U+FAFF
-range. Another 41,000 Han ideographs will be added to Plane 2.
-
-Ideographs are common in China, Korea and Japan but as ideographs spread
-and evolve, the form of the ideographs sometimes differs slightly from
-country to country. For example, the word 'villa' {U+838A} 'zhuang' in
-Chinese, in Japanese is 'sou' {U+8358}. These are given different code
-points in Unicode.
-
-3. Chinese (Hanzi)
-
-Chinese ideographs or hanzi {U+6F22 U+5B57/U+6C49 U+5B57} originated
-from pictograph. They are 'pictures' which evolved into ideographs
-during several thousand years. For instance, the ideograph for "hill"
-{U+5C71} still bears some resembles to 3 peaks of a hill.
-
-Not all ideographs are pictograph. There are other classifications such
-as compound ideographs, phonetic ideographs etc. For example,
-'endurance' {U+5FCD} is a pierced 'knife' {U+5200} above the 'heart'
-{U+5FC3}, or as a Chinese saying goes, 'endurance is like having a
-pierced knife in your heart'.
-
-Hence, almost all Han ideographs are associated with some meaning by
-itself which is very different from most other scripts. This causes some
-confusion that Han folding is a form of lexicon-substitution.
-
-Chinese ideographs underwent a major change in the 1950s after the
-establishment of People's Republic of China. A committee on Language
-Reform was established in China whose activities include simplification
-of Chinese ideographs. The Simplified Chinese (SC) are used in China
-and Singapore and Traditional Chinese (TC) in Taiwan, Hong Kong PRC,
-Macau PRC, and most other oversea Chinese.
-
-The process is to take complex ideographs and simplify them. The main
-purposes is to make it easier to remember and write and thus to raise
-the literacy of the population.
-
-For example, 'lightning' TC {U+96FB} becomes SC {U+6535} (They drop the
-'rain' {U+96E8} part from the TC). In many cases, they bear no
-resemblance to any of the original traditional forms e.g. 'dragon' TC
-{U+9F8D} SC {U+9F99}. Two different TC may also have the same SC since
-it means fewer ideographs to learn, e.g. SC {U+53D1} can be {U+667C} or
-{U+9AEE} depending on semantics. The official 'Comprehensive List of
-Simplified Characters' latest published in 1986 listed 2244 SC
-[ZONGBIAO].
-
-Therefore, the process of SC-to-TC is very complicated. It is not
-possible to do it accurately without considering the semantics of the
-phrase.
-
-On the other hand, TC-to-SC is much simple although different TCs may
-map to one single SC. While Unicode does not handle TC & SC, in the
-informal [UNIHAN] document, it listed 2145 TC and its equivalent mapping
-of SC. However, because that document is informal and not part of the
-Unicode standard, it is incomplete and has mistakes in the code points.
-Hence, precise tables for TC-to-SC conversion have not been fully laid
-out.
-
-In domain names, we are particularly interested in is to equivalences
-comparison of the names, and not converting SC-to-TC. Therefore, for
-this purpose, it is possible that equivalency matching be done in the
-TC-to-SC folding prior to comparison, similar to lower-case English
-strings before comparing them, e.g. 'taiwan' SC {U+53F0 U+6E7E} will
-match with TC {U+81FA U+5F4E} or TC {U+53F0 U+5F4E}.
-
-The side effect of this method is that comparing SC {U+53D1} to TC
-{U+667C} or TC {U+9AEE} will both be positive. This implies that SC
-'hair' SC \85ñ³\85Åæ {U+5934 U+53D1} will match TC
-(U+982D U+9AEE). It will also match TC {U+982D U+9AEE} that does not
-have any meaning in Chinese.
-
-It should also be noted that SC are not used together with TC. Hence,
-'hair' is either written as SC {U+5934 U+53D1} or TC {U+982D U+9AEE}
-but (almost) never {U+5934 U+9AEE} or {U+982D U+53D1}. So the problem
-of SC and TC may not too serious for IDN.
-
-Unfortunately, when it comes to names in Chinese, places where SC are
-used (i.e. Singapore and China), traditional and simplified ideographs
-are sometimes mixed within a single name for artistic reasons. Some of
-them even 'create' ideographs for their names.
-
-[Need to add a section on Bopomofo U+3118 to U+312A in future draft]
-
-4. Korean (Hanja and Hangeul)
-
-Korean is one of the first cultures to imported Chinese ideographs into
-Korean language as a written form. These Korean ideographs are known as
-'hanja' {U+6F22 U+5B57/U+D55C U+C790} and they are widely used until
-recently where 'hangeul' {U+D55C U+AE00} become more popular.
-
-Hangeul {U+D55C U+AE00} is a systemic script designed by a 15th century
-ruler and linguistic expert, King Sejong {U+4E16 U+5B97}. It is based
-on the pronunciation of the Korean language, hanmal. A Korean syllable
-is composed of 'jamo' {U+5B57 U+6BCD/U+C790 U+BAA8} elements that
-represent different sound. Hence, unlike Han ideographs, each hangeul
-syllable does not have any meaning.
-
-Each hanja ideographs can be represented by hangeul syllable. For
-example, 'samsung' hanja {U+4E09 U+661F} hangeul {U+C0BC U+C131}. Note
-that {U+4E09} is pronounced as 'sa-ah-am' or in jamo {U+3145} {U+314F}
-{U+3141}, which gives hangeul {U+C0BC}. While Jamo decompositions are
-described in [UTR15] in Form D decomposition, this document also
-suggested another hanguel canonical decomposition in Appendix A to
-accommodates both modern and old hangeul.
-[Need to fill up Appendix A when information is more complete]
-
-Most hanja characters have only one pronunciation. However, some hanja
-pronunciation differs as according to orthography (same for Chinese &
-Japanese) or the position in a word, which make this more complex. And
-of course, conversation of Hangeul back to hanja is impossible by code
-substitution without consideration for semantics.
-
-Korean also invented their own ideographs that are called 'gugja'
-{U+56FD U+5B57/U+AD6D U+C790}.
-
-5. Japanese (Kanji, Hiragana, Katakana)
-
-Japanese adopted Chinese ideograph from the Korean and the Chinese since
-the 5th century. Chinese ideographs in Japanese are known as 'kanji'
-{U+6F22 U+5B57}. They also developed their own syllabary hiragana
-{U+5E73 U+4EEE U+540D} (U+3040-U+309F) and katakana {U+7247 U+4EEE
-U+540D} (U+30A0-U+30FF), both are derivative of kanji that has same
-pronunciation. Hiragana is a simplified cursive form, for example, 'a'
-{U+3042} was derived from 'an' {U+5B89}. Katakana is a simplified part
-form, for example, 'a' {U+30A2} was derived from 'a' {U+963F}. However,
-kanji all remain very integrated within the Japanese language.
-
-Japanese also invented ideographs known as 'kokuji' {U+56FD U+5B57}. For
-example, 'iwashi' {U+9C2F} is a Japanese kokuji ideograph. Kokuji are
-invented according to Han ligature rules. For example, 'touge' "mountain
-pass" {U+5CE0} is a conjunction of meaning with 'yama' "mountain"
-{U+5C71} + 'ue' "up" {U+4E0A} + 'shita' "down" {U+4E0B}.
-
-Japanese is also a vocal language, i.e. the script itself is based on
-pronunciation. Each hiragana corresponding to one pronunciation and 48
-hiragana forms the basic of the Japanese language, including the less
-commonly used 'we' {U+3091}. Furthermore, hiragana has more 35 forms to
-represent voiced sound, P-sound, double consonant. For example, 'ga'
-{U+304C} is a voiced sound of 'ka' {U+304B}. Katakana is a mirror of
-hiragana with few more forms and they are used to integrate foreign
-words or phrases into Japanese, or to emphasize words or phrases even
-in Japanese, or to represent onomatopoeia. For example, 'hamburger'
-pronounced as 'han-baa-gaa' in Japanese is written as {U+30CF U+30F3
-U+30D0 U+30FC U+30AC U+30FC} instead of {U+306F U+3093 U+3070 U+3041
-U+304C U+3041} because it is a foreign word.
-
-If Japanese uses hiragana and katakana only, then it is fairly obvious
-that written Japanese is going to be very long. Hence, kanji are used
-when referring to nouns or verbs. Each kanji corresponds to one or more
-hiragana characters. For example, 'japan' pronounced as 'nippon'
-{U+306B U+3063 U+307D U+3093} are written as {U+65E5 U+672C} instead.
-
-Hiragana, like Korean jamo, has no meaning itself. And also, Kanji can
-take on different pronunciation (which means different hiragana)
-depending where and how it is use in the sentence. For example, 'sky'
-{U+7A7A} can be pronounced as {U+305D U+3089} or {U+30BD U+30E9}.
-
-Hence, a code substitution between hiragana and kanji is impractical.
-
-On the other hand, there are Kanji that has the same meaning with the
-same pronunciation and equivalent. For example, 'river' "kawa" can be
-either {U+5DDD} or {U+6CB3}. The only differential between the two
-ideographs is that it signifies the 'size of the river' (the latter is
-bigger river).
-
-Japanese also reduce complex Chinese ideographs to a simplified form.
-For example, 'both' {U+5169} was simplified {U+4E21}. Note that Chinese
-simplified it to {U+4E24} instead. However, traditional Japanese kanji
-are seldom used nowadays beyond documenting old historical text that
-they are treated different from the more commonly used simplified form,
-or used to express proper noun such as person's name or trademarks.
-Hence, Han folding here is not recommended.
-
-4. Vietnamese
-
-While Vietnamese also adopted Chinese ideographs ('chu han') and created
-their own ideographs ('chu nom'), they were now replaced by romanized
-'quoc ngu' today. Hence, this document does not attempt to address any
-issues with 'chu han' or 'chu nom'.
-
-
-5. zVariant
-
-Unicode has a three dimension conceptual model to Ideograph
-Unification. The three dimensions are semantic (X axis - meaning,
-function), abstract shape (Y-axis - general form) and actual shape
-(Z-axis \82Çô instantiated, type-faced).
-
-When two ideographs have similar etymology but are given two different
-code points in Unicode, they are known as zVariant ideograph i.e. they
-belong to the same 'Z' axis. For example, 'villa' {U+838A} and {U+8358}.
-
-
-6. Ideographic Description
-
-In Unicode v3.0, an ideographic description (U+2FF0-U+2FFB) was
-introduced allowing Han ideograph to be constructed using radical
-(U+2E80-U+2FD5) and Han ideograph (U+3400-U+9FFF).
-
-The intention of this description method is to allow ideograph that is
-not defined by Unicode to be described. Hence, it is not necessary that
-these ideograph can be display properly. In addition, this method are
-not deterministic and allowing same ideograph to be represented in
-different sequence.
-
-For example, 'zong' {U+9B03} (for discussion sake, we are going to use
-an ideograph which is already in Unicode) can be decomposed to U+2FF1
-U+9ADF U+5B97 using descriptive code points and Unified Ideograph.
-U+9ADF can also be decomposed as U+2FF0 U+2ED2 U+2F3A and U+5B97 as
-U+2FF5 U+2F28 U+2F70. In addition, U+9ADF is equivalent to U+2FBD.
-Hence, if we were to use only descriptive code points and radicals only,
-we can get U+2FF1 U+2FBD U+2FF5 U+2F28 U+2F70 or U+2FF1 U+2FF0 U+2ED2
-U+2F3A U+2FF5 U+2F28 U+2F70.
-
-In addition, certain radical has been simplified and thus, in some
-context, equivalent. For example, the radical for 'bird' can be either
-U+2EE6 or U+2FC3.
-
-Hence, until there is a deterministic well-defined rule for
-ideographic description, ideographs formed by this method are not
-recommended for domain names use.
-
-It should be noted that the Unicode Consortium never intended the
-ideographic description to be used in protocols like IDN where exact
-comparison must be done. But it is certainly desirable to this feature
-as it is commons for Chinese to invent ideographs for names by adding
-or removing radical from standard ideographs.
-
-7. Mechanism
-
-The implicit proposal in this document is that CJKV ideographs may or
-may not be "folded" for the purposes of comparison of domain names.
-
-But if folding is required, there are four different ways that this
-folding could be done.
-
-a) Folding by DNS clients, or by user agents
-b) Folding by DNS servers
-c) Folding by Domain Name registration services for the purposes of
- preventing confusing allocations CJKV Domain Names which would,
- if transcoded, be the same
-
-Before we can give much more reaction, we need to know which use is
-planned.
-
-The third use is important. It should be put in place. This problem can
-be reduced alternately by representing non-ASCII characters that are
-domain names or other URL characters using hex-escaped character
-references in HTML pages.
-
-To characterize Han characters as ideographs or pictograms is
-inadequate, because most of the Han ideograph have both a phonetic and
-a semantic element. Indeed, this is enough to characterize Chinese
-writing as phonetic, though it is other things as well. Thus, it's
-difficult to comment on whether folding is useful for Chinese or not.
-
-The first use has the problem that lightweight devices do not have
-enough room to fit a Unicode X-axis mapping table.
-
-The second use has the problem that introducing mapping will limit the
-performance of DNS servers. Alphabetic case mapping can be performed
-using a single logical AND instruction; CJKV character folding requires
-a lookup table.
-
-In alphabetic scripts, there is also requirement to fold Latin, Greek,
-Hebrew, Cyrillic, Hebrew and Arabic together. There may be a stronger
-requirement for CJKV characters.
-
-Note also that because modern OS are Unicode based and have network-
-downloadable IMEs, "interoperability" is becoming less equivalent to
-"use BIG5 characters only" or "use GB2312 character only" or "use
-Shift-JIS characters only".
-
-If conservative safety is really required, then
-1) find the x-axis characters which are available in all major CJK
- character sets used on the internet;
-2) only allow variants of those in domain names;
-3) when one variant is used, no other can be allocated. So comparisons
- are made on x-axis characters, but the license of that domain name
- can pick which y or z variants they wish to use..
-
-Acknowledgement
-
-The editor gratefully acknowledge the contributions of:
-
-Paul Hoffman <phoffman@imc.org>
-Jiang Mingliang <jiang@i-DNS.net>
-Dongman Lee <dlee@icu.ac.kr>
-Karlsson Kent <keka@im.se>
-
-Author(s)
-
-James SENG \88Äè\86î¯\85«Å
-i-DNS.net International Pte Ltd.
-8 Temasek Boulevard
-Suntec Tower 3 #24-02
-Singapore 038988
-Email: James@Seng.cc
-Tel: +65 2468208
-
-Yoshiro YONEYA
-NTT Software Corporation
-Shinagawa IntercityBldg., B-13F
-2-15-2 Kohnan, Minato-ku Tokyo 108-6113 Japan
-Email: yone@po.ntts.co.jp
-Tel: +81-3-5782-7291
-
-Kenny HUANG \89©â\85ï¥\89¢ä
-Geotempo International Ltd; TWNIC
-3F, No 16 Kang Hwa Street, Nei Hu
-Taipei 114, Taiwan
-Email: huangk@alum.sinica.edu
-Tel: +886-2-2658-6510
-
-KIM Kyongsok/GIM Gyeongseog
-
-References
-
-[UNISTD3] The Unicode Standard v3.0. Unicode Consortium.
-[UCS] ISBN 0-201-61633-5
-
-[IDN] "IETF Internationalized Domain Names Working Group",
- idn@ops.ietf.org, James Seng, Marc Blanchet
-
-[CNRP] "Common Name Resolution Protocol",
- cnrp-ietf@lists.netsol.com, Leslie Daigle
-
-[CJKV] CJKV Information Processing ISBN 1-56592-224-7
-
-[C2C] The pitfalls and Complexities of Chinese to Chinese
- Conversion. http://www.basistech.com/articles/C2C.html,
- Jack Halpern, Jouni Kerman
-
-[KANJIDIC] Sanseido\82ÇÖs Unicode Kanji Information Dictionary
- ISBN 4-385-13690-4
-
-[UNICHART] Unicode chart http://charts.unicode.org/
-
-[ZONGBIAO] Simplified Characters Standard Chart 2nd Edition, 1986
-
-[UNIHAN] Unicode Han Database, Unicode Consortium
- ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt
-
-[ISO11941] ISO TS 11941: Information and documentation \82Çô
- Transliteration of Korean script into Latin characters.
- Technical Specification 11941. First edition. 1996-12-31.
- ISO (International Organization for Standardization).
-
-[KimK 1990] "A New Proposal for a Standard Hangeul (or Korean Script)
- Code", KIM Kyongsok. Computer Standards & Interfaces,
- Vol. 9, No. 3, pp. 187-202, 1990.
-
-[KimK 1992] "A common Approach to Designing the Hangeul Code and
- Keyboard", KIM Kyongsok. Computer Standards & Interfaces,
- Vol. 14, No. 4, pp. 297-325, Aug. 1992.
-
-[KimK 1999] A Hangeul story inside computers. KIM, Kyongsok. Busan
- National University Press. 1999. [in Hangeul]
\ No newline at end of file
+++ /dev/null
-INTERNET-DRAFT Mark Welter
-draft-ietf-idn-dude-02.txt Brian W. Spolarich
-Expires 2001-Dec-07 Adam M. Costello
- 2001-Jun-07
-
- Differential Unicode Domain Encoding (DUDE)
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note
- that other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet-Drafts as
- reference material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Distribution of this document is unlimited. Please send comments to
- the authors or to the idn working group at idn@ops.ietf.org.
-
-Abstract
-
- DUDE is a reversible transformation from a sequence of nonnegative
- integer values to a sequence of letters, digits, and hyphens (LDH
- characters). DUDE provides a simple and efficient ASCII-Compatible
- Encoding (ACE) of Unicode strings [UNICODE] for use with
- Internationalized Domain Names [IDN] [IDNA].
-
-Contents
-
- 1. Introduction
- 2. Terminology
- 3. Overview
- 4. Base-32 characters
- 5. Encoding procedure
- 6. Decoding procedure
- 7. Example strings
- 8. Security considerations
- 9. References
- A. Acknowledgements
- B. Author contact information
- C. Mixed-case annotation
- D. Differences from draft-ietf-idn-dude-01
- E. Example implementation
-\f
-1. Introduction
-
- The IDNA draft [IDNA] describes an architecture for supporting
- internationalized domain names. Each label of a domain name may
- begin with a special prefix, in which case the remainder of the
- label is an ASCII-Compatible Encoding (ACE) of a Unicode string
- satisfying certain constraints. For the details of the constraints,
- see [IDNA] and [NAMEPREP]. The prefix has not yet been specified,
- but see http://www.i-d-n.net/ for prefixes to be used for testing
- and experimentation.
-
- DUDE is intended to be used as an ACE within IDNA, and has been
- designed to have the following features:
-
- * Completeness: Every sequence of nonnegative integers maps to an
- LDH string. Restrictions on which integers are allowed, and on
- sequence length, may be imposed by higher layers.
-
- * Uniqueness: Every sequence of nonnegative integers maps to at
- most one LDH string.
-
- * Reversibility: Any Unicode string mapped to an LDH string can
- be recovered from that LDH string.
-
- * Efficient encoding: The ratio of encoded size to original size
- is small. This is important in the context of domain names
- because [RFC1034] restricts the length of a domain label to 63
- characters.
-
- * Simplicity: The encoding and decoding algorithms are reasonably
- simple to implement. The goals of efficiency and simplicity are
- at odds; DUDE places greater emphasis on simplicity.
-
- An optional feature is described in appendix C "Mixed-case
- annotation".
-
-2. Terminology
-
- The key words "must", "shall", "required", "should", "recommended",
- and "may" in this document are to be interpreted as described in
- RFC 2119 [RFC2119].
-
- LDH characters are the letters A-Z and a-z, the digits 0-9, and
- hyphen-minus.
-
- A quartet is a sequence of four bits (also known as a nibble or
- nybble).
-
- A quintet is a sequence of five bits.
-
- Hexadecimal values are shown preceeded by "0x". For example, 0x60
- is decimal 96.
-
- As in the Unicode Standard [UNICODE], Unicode code points are
- denoted by "U+" followed by four to six hexadecimal digits, while a
- range of code points is denoted by two hexadecimal numbers separated
- by "..", with no prefixes.
-\f
- XOR means bitwise exclusive or. Given two nonnegative integer
- values A and B, A XOR B is the nonnegative integer value whose
- binary representation is 1 in whichever places the binary
- representations of A and B disagree, and 0 wherever they agree.
- For the purpose of applying this rule, recall that an integer's
- representation begins with an infinite number of unwritten zeros.
- In some programming languages, care may need to be taken that A and
- B are stored in variables of the same type and size.
-
-3. Overview
-
- DUDE encodes a sequence of nonnegative integral values as a sequence
- of LDH characters, although implementations will of course need to
- represent the output characters somehow, typically as ASCII octets.
- When DUDE is used to encode Unicode characters, the input values are
- Unicode code points (integral values in the range 0..10FFFF, but not
- D800..DFFF, which are reserved for use by UTF-16).
-
- Each value in the input sequence is represented by one or more LDH
- characters in the encoded string. The value 0x2D is represented
- by hyphen-minus (U+002D). Each non-hyphen-minus character in
- the encoded string represents a quintet. A sequence of quintets
- represents the bitwise XOR between each non-0x2D integer and the
- previous one.
-
-4. Base-32 characters
-
- "a" = 0 = 0x00 = 00000 "s" = 16 = 0x10 = 10000
- "b" = 1 = 0x01 = 00001 "t" = 17 = 0x11 = 10001
- "c" = 2 = 0x02 = 00010 "u" = 18 = 0x12 = 10010
- "d" = 3 = 0x03 = 00011 "v" = 19 = 0x13 = 10011
- "e" = 4 = 0x04 = 00100 "w" = 20 = 0x14 = 10100
- "f" = 5 = 0x05 = 00101 "x" = 21 = 0x15 = 10101
- "g" = 6 = 0x06 = 00110 "y" = 22 = 0x16 = 10110
- "h" = 7 = 0x07 = 00111 "z" = 23 = 0x17 = 10111
- "i" = 8 = 0x08 = 01000 "2" = 24 = 0x18 = 11000
- "j" = 9 = 0x09 = 01001 "3" = 25 = 0x19 = 11001
- "k" = 10 = 0x0A = 01010 "4" = 26 = 0x1A = 11010
- "m" = 11 = 0x0B = 01011 "5" = 27 = 0x1B = 11011
- "n" = 12 = 0x0C = 01100 "6" = 28 = 0x1C = 11100
- "p" = 13 = 0x0D = 01101 "7" = 29 = 0x1D = 11101
- "q" = 14 = 0x0E = 01110 "8" = 30 = 0x1E = 11110
- "r" = 15 = 0x0F = 01111 "9" = 31 = 0x1F = 11111
-
- The digits "0" and "1" and the letters "o" and "l" are not used, to
- avoid transcription errors.
-
- A decoder must accept both the uppercase and lowercase forms of
- the base-32 characters (including mixtures of both forms). An
- encoder should output only lowercase forms or only uppercase forms
- (unless it uses the feature described in the appendix C "Mixed-case
- annotation").
-
-5. Encoding procedure
-
- All ordering of bits, quartets, and quintets is big-endian (most
- significant first).
-\f
- let prev = 0x60
- for each input integer n (in order) do begin
- if n == 0x2D then output hyphen-minus
- else begin
- let diff = prev XOR n
- represent diff in base 16 as a sequence of quartets,
- as few as are sufficient (but at least one)
- prepend 0 to the last quartet and 1 to each of the others
- output a base-32 character corresponding to each quintet
- let prev = n
- end
- end
-
- If an encoder encounters an input value larger than expected (for
- example, the largest Unicode code point is U+10FFFF, and nameprep
- [NAMEPREP03] can never output a code point larger than U+EFFFD),
- the encoder may either encode the value correctly, or may fail, but
- it must not produce incorrect output. The encoder must fail if it
- encounters a negative input value.
-
-6. Decoding procedure
-
- let prev = 0x60
- while the input string is not exhausted do begin
- if the next character is hyphen-minus
- then consume it and output 0x2D
- else begin
- consume characters and convert them to quintets until
- encountering a quintet whose first bit is 0
- fail upon encountering a non-base-32 character or end-of-input
- strip the first bit of each quintet
- concatenate the resulting quartets to form diff
- let prev = prev XOR diff
- output prev
- end
- end
- encode the output sequence and compare it to the input string
- fail if they do not match (case-insensitively)
-
- The comparison at the end is necessary to guarantee the uniqueness
- property (there cannot be two distinct encoded strings representing
- the same sequence of integers). This check also frees the decoder
- from having to check for overflow while decoding the base-32
- characters. (If the decoder is one step of a larger decoding
- process, it may be possible to defer the re-encoding and comparison
- to the end of that larger decoding process.)
-
-7. Example strings
-
- The first several examples are nonsense strings of mostly unassigned
- code points intended to exercise the corner cases of the algorithm.
-
- (A) u+0061
- DUDE: b
-
- (B) u+2C7EF u+2C7EF
- DUDE: u6z2ra
-\f
- (C) u+1752B u+1752A
- DUDE: tzxwmb
-
- (D) u+63AB1 u+63ABA
- DUDE: yv47bm
-
- (E) u+261AF u+261BF
- DUDE: uyt6rta
-
- (F) u+C3A31 u+C3A8C
- DUDE: 6v4xb5p
-
- (G) u+09F44 u+0954C
- DUDE: 39ue4si
-
- (H) u+8D1A3 u+8C8A3
- DUDE: 27t6dt3sa
-
- (I) u+6C2B6 u+CC266
- DUDE: y6u7g4ss7a
-
- (J) u+002D u+002D u+002D u+E848F
- DUDE: ---82w8r
-
- (K) u+BD08E u+002D u+002D u+002D
- DUDE: 57s8q---
-
- (L) u+A9A24 u+002D u+002D u+002D u+C05B7
- DUDE: 434we---y393d
-
- (M) u+7FFFFFFF
- DUDE: z999993r or explicit failure
-
- The next several examples are realistic Unicode strings that could
- be used in domain names. They exhibit single-row text, two-row
- text, ideographic text, and mixtures thereof. These examples are
- names of Japanese television programs, music artists, and songs,
- merely because one of the authors happened to have them handy.
-
- (N) 3<nen>b<gumi><kinpachi><sensei> (Latin, kanji)
- u+0033 u+5E74 u+0062 u+7D44 u+91D1 u+516B u+5148 u+751F
- DUDE: xdx8whx8tgz7ug863f6s5kuduwxh
-
- (O) <amuro><namie>-with-super-monkeys (Latin, kanji, hyphens)
- u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
- u+0068 u+002D u+0073 u+0075 u+0070 u+0065 u+0072 u+002D u+006D
- u+006F u+006E u+006B u+0065 u+0079 u+0073
- DUDE: x58jupu8nuy6gt99m-yssctqtptn-tmgftfth-trcbfqtnk
-
- (P) maji<de>koi<suru>5<byou><mae> (Latin, hiragana, kanji)
- u+006D u+0061 u+006A u+0069 u+3067 u+006B u+006F u+0069 u+3059
- u+308B u+0035 u+79D2 u+524D
- DUDE: pnmdvssqvssnegvsva7cvs5qz38hu53r
-
- (Q) <pafii>de<runba> (Latin, katakana)
- u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
- DUDE: vs5bezgxrvs3ibvs2qtiud
-\f
- (R) <sono><supiido><de> (hiragana, katakana)
- u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
- DUDE: vsvpvd7hypuivf4q
-
-8. Security considerations
-
- Users expect each domain name in DNS to be controlled by a single
- authority. If a Unicode string intended for use as a domain label
- could map to multiple ACE labels, then an internationalized domain
- name could map to multiple ACE domain names, each controlled by
- a different authority, some of which could be spoofs that hijack
- service requests intended for another. Therefore DUDE is designed
- so that each Unicode string has a unique encoding.
-
- However, there can still be multiple Unicode representations of the
- "same" text, for various definitions of "same". This problem is
- addressed to some extent by the Unicode standard under the topic of
- canonicalization, and this work is leveraged for domain names by
- "nameprep" [NAMEPREP03].
-
-9. References
-
- [IDN] Internationalized Domain Names (IETF working group),
- http://www.i-d-n.net/, idn@ops.ietf.org.
-
- [IDNA] Patrik Faltstrom, Paul Hoffman, "Internationalizing Host
- Names In Applications (IDNA)", draft-ietf-idn-idna-01.
-
- [NAMEPREP03] Paul Hoffman, Marc Blanchet, "Preparation
- of Internationalized Host Names", 2001-Feb-24,
- draft-ietf-idn-nameprep-03.
-
- [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host
- Table Specification", 1985-Oct, RFC 952.
-
- [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
- 1987-Nov, RFC 1034.
-
- [RFC1123] Internet Engineering Task Force, R. Braden (editor),
- "Requirements for Internet Hosts -- Application and Support",
- 1989-Oct, RFC 1123.
-
- [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", 1997-Mar, RFC 2119.
-
- [SFS] David Mazieres et al, "Self-certifying File System",
- http://www.fs.net/.
-
- [UNICODE] The Unicode Consortium, "The Unicode Standard",
- http://www.unicode.org/unicode/standard/standard.html.
-
-A. Acknowledgements
-
- The basic encoding of integers to quartets to quintets to base-32
- comes from earlier IETF work by Martin Duerst. DUDE uses a slight
- variation on the idea.
-\f
- Paul Hoffman provided helpful comments on this document.
-
- The idea of avoiding 0, 1, o, and l in base-32 strings was taken
- from SFS [SFS].
-
-B. Author contact information
-
- Mark Welter <mwelter@walid.com>
- Brian W. Spolarich <briansp@walid.com>
- WALID, Inc.
- State Technology Park
- 2245 S. State St.
- Ann Arbor, MI 48104
- +1 734 822 2020
-
- Adam M. Costello <amc@cs.berkeley.edu>
- University of California, Berkeley
- http://www.cs.berkeley.edu/~amc/
-
-C. Mixed-case annotation
-
- In order to use DUDE to represent case-insensitive Unicode strings,
- higher layers need to case-fold the Unicode strings prior to DUDE
- encoding. The encoded string can, however, use mixed-case base-32
- (rather than all-lowercase or all-uppercase as recommended in
- section 4 "Base-32 characters") as an annotation telling how to
- convert the folded Unicode string into a mixed-case Unicode string
- for display purposes.
-
- Each Unicode code point (unless it is U+002D hyphen-minus) is
- represented by a sequence of base-32 characters, the last of which
- is always a letter (as opposed to a digit). If that letter is
- uppercase, it is a suggestion that the Unicode character be mapped
- to uppercase (if possible); if the letter is lowercase, it is a
- suggestion that the Unicode character be mapped to lowercase (if
- possible).
-
- DUDE encoders and decoders are not required to support these
- annotations, and higher layers need not use them.
-
- Example: In order to suggest that example O in section 7 "Example
- strings" be displayed as:
-
- <amuro><namie>-with-SUPER-MONKEYS
-
- one could capitalize the DUDE encoding as:
-
- x58jupu8nuy6gt99m-yssctqtptn-tMGFtFtH-tRCBFQtNK
-
-D. Differences from draft-ietf-idn-dude-01
-
- Four changes have been made since draft-ietf-idn-dude-01 (DUDE-01):
-
- 1) DUDE-01 computed the XOR of each integer with the previous one
- in order to decide how many bits of each integer to encode, but
- now the XOR itself is encoded, so there is no need for a mask.
-\f
- 2) DUDE-01 made the first quintet of each sequence different from
- the rest, while now it is the last quintet that differs, so it's
- easier for the decoder to detect the end of the sequence.
-
- 3) The base-32 map has changed to avoid 0, 1, o, and l, to help
- humans avoid transcription errors.
-
- 4) The initial value of the previous code point has changed from 0
- to 0x60, making the encodings of a few domain names shorter and
- none longer.
-
-
-E. Example implementation
-
-
-
-/******************************************/
-/* dude.c 0.2.3 (2001-May-31-Thu) */
-/* Adam M. Costello <amc@cs.berkeley.edu> */
-/******************************************/
-
-/* This is ANSI C code (C89) implementing */
-/* DUDE (draft-ietf-idn-dude-02). */
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum dude_status {
- dude_success,
- dude_bad_input,
- dude_big_output /* Output would exceed the space provided. */
-};
-
-enum case_sensitivity { case_sensitive, case_insensitive };
-
-#if UINT_MAX >= 0x1FFFFF
-typedef unsigned int u_code_point;
-#else
-typedef unsigned long u_code_point;
-#endif
-
-enum dude_status dude_encode(
- unsigned int input_length,
- const u_code_point input[],
- const unsigned char uppercase_flags[],
- unsigned int *output_size,
- char output[] );
-\f
- /* dude_encode() converts Unicode to DUDE (without any */
- /* signature). The input must be represented as an array */
- /* of Unicode code points (not code units; surrogate pairs */
- /* are not allowed), and the output will be represented as */
- /* null-terminated ASCII. The input_length is the number of code */
- /* points in the input. The output_size is an in/out argument: */
- /* the caller must pass in the maximum number of characters */
- /* that may be output (including the terminating null), and on */
- /* successful return it will contain the number of characters */
- /* actually output (including the terminating null, so it will be */
- /* one more than strlen() would return, which is why it is called */
- /* output_size rather than output_length). The uppercase_flags */
- /* array must hold input_length boolean values, where nonzero */
- /* means the corresponding Unicode character should be forced */
- /* to uppercase after being decoded, and zero means it is */
- /* caseless or should be forced to lowercase. Alternatively, */
- /* uppercase_flags may be a null pointer, which is equivalent */
- /* to all zeros. The encoder always outputs lowercase base-32 */
- /* characters except when nonzero values of uppercase_flags */
- /* require otherwise. The return value may be any of the */
- /* dude_status values defined above; if not dude_success, then */
- /* output_size and output may contain garbage. On success, the */
- /* encoder will never need to write an output_size greater than */
- /* input_length*k+1 if all the input code points are less than 1 */
- /* << (4*k), because of how the encoding is defined. */
-
-enum dude_status dude_decode(
- enum case_sensitivity case_sensitivity,
- char scratch_space[],
- const char input[],
- unsigned int *output_length,
- u_code_point output[],
- unsigned char uppercase_flags[] );
-\f
- /* dude_decode() converts DUDE (without any signature) to */
- /* Unicode. The input must be represented as null-terminated */
- /* ASCII, and the output will be represented as an array of */
- /* Unicode code points. The case_sensitivity argument influences */
- /* the check on the well-formedness of the input string; it */
- /* must be case_sensitive if case-sensitive comparisons are */
- /* allowed on encoded strings, case_insensitive otherwise. */
- /* The scratch_space must point to space at least as large */
- /* as the input, which will get overwritten (this allows the */
- /* decoder to avoid calling malloc()). The output_length is */
- /* an in/out argument: the caller must pass in the maximum */
- /* number of code points that may be output, and on successful */
- /* return it will contain the actual number of code points */
- /* output. The uppercase_flags array must have room for at */
- /* least output_length values, or it may be a null pointer if */
- /* the case information is not needed. A nonzero flag indicates */
- /* that the corresponding Unicode character should be forced to */
- /* uppercase by the caller, while zero means it is caseless or */
- /* should be forced to lowercase. The return value may be any */
- /* of the dude_status values defined above; if not dude_success, */
- /* then output_length, output, and uppercase_flags may contain */
- /* garbage. On success, the decoder will never need to write */
- /* an output_length greater than the length of the input (not */
- /* counting the null terminator), because of how the encoding is */
- /* defined. */
-
-
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-/* Character utilities: */
-
-/* base32[q] is the lowercase base-32 character representing */
-/* the number q from the range 0 to 31. Note that we cannot */
-/* use string literals for ASCII characters because an ANSI C */
-/* compiler does not necessarily use ASCII. */
-
-static const char base32[] = {
- 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, /* a-k */
- 109, 110, /* m-n */
- 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, /* p-z */
- 50, 51, 52, 53, 54, 55, 56, 57 /* 2-9 */
-};
-
-/* base32_decode(c) returns the value of a base-32 character, in the */
-/* range 0 to 31, or the constant base32_invalid if c is not a valid */
-/* base-32 character. */
-\f
-enum { base32_invalid = 32 };
-
-static unsigned int base32_decode(char c)
-{
- if (c < 50) return base32_invalid;
- if (c <= 57) return c - 26;
- if (c < 97) c += 32;
- if (c < 97 || c == 108 || c == 111 || c > 122) return base32_invalid;
- return c - 97 - (c > 108) - (c > 111);
-}
-
-/* unequal(case_sensitivity,s1,s2) returns 0 if the strings s1 and s2 */
-/* are equal, 1 otherwise. If case_sensitivity is case_insensitive, */
-/* then ASCII A-Z are considered equal to a-z respectively. */
-
-static int unequal( enum case_sensitivity case_sensitivity,
- const char s1[], const char s2[] )
-{
- char c1, c2;
-
- if (case_sensitivity != case_insensitive) return strcmp(s1,s2) != 0;
-
- for (;;) {
- c1 = *s1;
- c2 = *s2;
- if (c1 >= 65 && c1 <= 90) c1 += 32;
- if (c2 >= 65 && c2 <= 90) c2 += 32;
- if (c1 != c2) return 1;
- if (c1 == 0) return 0;
- ++s1, ++s2;
- }
-}
-
-
-/* Encoder: */
-
-enum dude_status dude_encode(
- unsigned int input_length,
- const u_code_point input[],
- const unsigned char uppercase_flags[],
- unsigned int *output_size,
- char output[] )
-{
- unsigned int max_out, in, out, k, j;
- u_code_point prev, codept, diff, tmp;
- char shift;
-
- prev = 0x60;
- max_out = *output_size;
-
- for (in = out = 0; in < input_length; ++in) {
-
- /* At the start of each iteration, in and out are the number of */
- /* items already input/output, or equivalently, the indices of */
- /* the next items to be input/output. */
-\f
- codept = input[in];
-
- if (codept == 0x2D) {
- /* Hyphen-minus stands for itself. */
- if (max_out - out < 1) return dude_big_output;
- output[out++] = 0x2D;
- continue;
- }
-
- diff = prev ^ codept;
-
- /* Compute the number of base-32 characters (k): */
- for (tmp = diff >> 4, k = 1; tmp != 0; ++k, tmp >>= 4);
-
- if (max_out - out < k) return dude_big_output;
- shift = uppercase_flags && uppercase_flags[in] ? 32 : 0;
- /* shift controls the case of the last base-32 digit. */
-
- /* Each quintet has the form 1xxxx except the last is 0xxxx. */
- /* Computing the base-32 digits in reverse order is easiest. */
-
- out += k;
- output[out - 1] = base32[diff & 0xF] - shift;
-
- for (j = 2; j <= k; ++j) {
- diff >>= 4;
- output[out - j] = base32[0x10 | (diff & 0xF)];
- }
-
- prev = codept;
- }
-
- /* Append the null terminator: */
- if (max_out - out < 1) return dude_big_output;
- output[out++] = 0;
-
- *output_size = out;
- return dude_success;
-}
-
-
-/* Decoder: */
-
-enum dude_status dude_decode(
- enum case_sensitivity case_sensitivity,
- char scratch_space[],
- const char input[],
- unsigned int *output_length,
- u_code_point output[],
- unsigned char uppercase_flags[] )
-{
- u_code_point prev, q, diff;
- char c;
- unsigned int max_out, in, out, scratch_size;
- enum dude_status status;
-
- prev = 0x60;
- max_out = *output_length;
-\f
- for (c = input[in = 0], out = 0; c != 0; c = input[++in], ++out) {
-
- /* At the start of each iteration, in and out are the number of */
- /* items already input/output, or equivalently, the indices of */
- /* the next items to be input/output. */
-
- if (max_out - out < 1) return dude_big_output;
-
- if (c == 0x2D) output[out] = c; /* hyphen-minus is literal */
- else {
- /* Base-32 sequence. Decode quintets until 0xxxx is found: */
-
- for (diff = 0; ; c = input[++in]) {
- q = base32_decode(c);
- if (q == base32_invalid) return dude_bad_input;
- diff = (diff << 4) | (q & 0xF);
- if (q >> 4 == 0) break;
- }
-
- prev = output[out] = prev ^ diff;
- }
-
- /* Case of last character determines uppercase flag: */
- if (uppercase_flags) uppercase_flags[out] = c >= 65 && c <= 90;
- }
-
- /* Enforce the uniqueness of the encoding by re-encoding */
- /* the output and comparing the result to the input: */
-
- scratch_size = ++in;
- status = dude_encode(out, output, uppercase_flags,
- &scratch_size, scratch_space);
- if (status != dude_success || scratch_size != in ||
- unequal(case_sensitivity, scratch_space, input)
- ) return dude_bad_input;
-
- *output_length = out;
- return dude_success;
-}
-
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a */
-/* command-line option. */
-\f
-enum {
- unicode_max_length = 256,
- ace_max_size = 256,
- test_case_sensitivity = case_insensitive
- /* suitable for host names */
-};
-
-
-static void usage(char **argv)
-{
- fprintf(stderr,
- "%s -e reads code points and writes a DUDE string.\n"
- "%s -d reads a DUDE string and writes code points.\n"
- "Input and output are plain text in the native character set.\n"
- "Code points are in the form u+hex separated by whitespace.\n"
- "A DUDE string is a newline-terminated sequence of LDH characters\n"
- "(without any signature).\n"
- "The case of the u in u+hex is the force-to-uppercase flag.\n"
- , argv[0], argv[0]);
- exit(EXIT_FAILURE);
-}
-
-
-static void fail(const char *msg)
-{
- fputs(msg,stderr);
- exit(EXIT_FAILURE);
-}
-
-static const char too_big[] =
- "input or output is too large, recompile with larger limits\n";
-static const char invalid_input[] = "invalid input\n";
-static const char io_error[] = "I/O error\n";
-
-
-/* The following string is used to convert LDH */
-/* characters between ASCII and the native charset: */
-
-static const char ldh_ascii[] =
- "................"
- "................"
- ".............-.."
- "0123456789......"
- ".ABCDEFGHIJKLMNO"
- "PQRSTUVWXYZ....."
- ".abcdefghijklmno"
- "pqrstuvwxyz";
-
-
-int main(int argc, char **argv)
-{
- enum dude_status status;
- int r;
- char *p;
-
- if (argc != 2) usage(argv);
- if (argv[1][0] != '-') usage(argv);
- if (argv[1][2] != 0) usage(argv);
-\f
- if (argv[1][1] == 'e') {
- u_code_point input[unicode_max_length];
- unsigned long codept;
- unsigned char uppercase_flags[unicode_max_length];
- char output[ace_max_size], uplus[3];
- unsigned int input_length, output_size, i;
-
- /* Read the input code points: */
-
- input_length = 0;
-
- for (;;) {
- r = scanf("%2s%lx", uplus, &codept);
- if (ferror(stdin)) fail(io_error);
- if (r == EOF || r == 0) break;
-
- if (r != 2 || uplus[1] != '+' || codept > (u_code_point)-1) {
- fail(invalid_input);
- }
-
- if (input_length == unicode_max_length) fail(too_big);
-
- if (uplus[0] == 'u') uppercase_flags[input_length] = 0;
- else if (uplus[0] == 'U') uppercase_flags[input_length] = 1;
- else fail(invalid_input);
-
- input[input_length++] = codept;
- }
-
- /* Encode: */
-
- output_size = ace_max_size;
- status = dude_encode(input_length, input, uppercase_flags,
- &output_size, output);
- if (status == dude_bad_input) fail(invalid_input);
- if (status == dude_big_output) fail(too_big);
- assert(status == dude_success);
-
- /* Convert to native charset and output: */
-
- for (p = output; *p != 0; ++p) {
- i = *p;
- assert(i <= 122 && ldh_ascii[i] != '.');
- *p = ldh_ascii[i];
- }
-
- r = puts(output);
- if (r == EOF) fail(io_error);
- return EXIT_SUCCESS;
- }
-
- if (argv[1][1] == 'd') {
- char input[ace_max_size], scratch[ace_max_size], *pp;
- u_code_point output[unicode_max_length];
- unsigned char uppercase_flags[unicode_max_length];
- unsigned int input_length, output_length, i;
-\f
- /* Read the DUDE input string and convert to ASCII: */
-
- fgets(input, ace_max_size, stdin);
- if (ferror(stdin)) fail(io_error);
- if (feof(stdin)) fail(invalid_input);
- input_length = strlen(input);
- if (input[input_length - 1] != '\n') fail(too_big);
- input[--input_length] = 0;
-
- for (p = input; *p != 0; ++p) {
- pp = strchr(ldh_ascii, *p);
- if (pp == 0) fail(invalid_input);
- *p = pp - ldh_ascii;
- }
-
- /* Decode: */
-
- output_length = unicode_max_length;
- status = dude_decode(test_case_sensitivity, scratch, input,
- &output_length, output, uppercase_flags);
- if (status == dude_bad_input) fail(invalid_input);
- if (status == dude_big_output) fail(too_big);
- assert(status == dude_success);
-
- /* Output the result: */
-
- for (i = 0; i < output_length; ++i) {
- r = printf("%s+%04lX\n",
- uppercase_flags[i] ? "U" : "u",
- (unsigned long) output[i] );
- if (r < 0) fail(io_error);
- }
-
- return EXIT_SUCCESS;
- }
-
- usage(argv);
- return EXIT_SUCCESS; /* not reached, but quiets compiler warning */
-}
-
-
-
- INTERNET-DRAFT expires 2001-Dec-07
+++ /dev/null
-Internet Draft Patrik Faltstrom
-draft-ietf-idn-idna-07.txt Cisco
-February 24, 2002 Paul Hoffman
-Expires in six months IMC & VPNC
- Adam M. Costello
- UC Berkeley
-
- Internationalizing Domain Names in Applications (IDNA)
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-Until now, there has been no standard method for domain names to use
-characters outside the ASCII repertoire. This document defines
-internationalized domain names (IDNs) and a mechanism called IDNA for
-handling them in a standard fashion. IDNs use characters drawn from a
-large repertoire (Unicode), but IDNA allows the non-ASCII characters to
-be represented using the same octets used in so-called host names
-today. IDNA is only meant for processing domain names, not free
-text.
-
-
-1. Introduction
-
-IDNA works by allowing applications to use certain ASCII name labels
-(beginning with a special prefix) to represent non-ASCII name labels.
-Lower-layer protocols need not be aware of this; therefore IDNA does not
-require changes to any infrastructure. In particular, IDNA does not
-require any changes to DNS servers, resolvers, or protocol elements,
-because the ASCII name service provided by the existing DNS is entirely
-sufficient.
-
-This document does not require any applications to conform to IDNA,
-but applications can elect to use IDNA in order to support IDN while
-maintaining interoperability with existing infrastructure. Adding IDNA
-support to an existing application entails changes to the application
-only, and leaves room for flexibility in the user interface.
-
-A great deal of the discussion of IDN solutions has focused on
-transition issues and how IDN will work in a world where not all of the
-components have been updated. Other proposals would require that user
-applications, resolvers, and DNS servers be updated in order for a user
-to use an internationalized domain name. Rather than require widespread
-updating of all components, IDNA requires only user applications to be
-updated; no changes are needed to the DNS protocol or any DNS servers or
-the resolvers on user's computers.
-
-1.1 Interaction of protocol parts
-
-IDNA requires that implementations process input strings with Nameprep
-[NAMEPREP], which is a profile of Stringprep [STRINGPREP], and then with
-Punycode [PUNYCODE]. Implementations of IDNA MUST fully implement
-Nameprep and Punycode; neither Nameprep nor Punycode are optional.
-
-
-2 Terminology
-
-The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
-"MAY" in this document are to be interpreted as described in RFC 2119
-[RFC2119].
-
-A code point is an integral value associated with a character in a coded
-character set.
-
-Unicode [UNICODE] is a coded character set containing tens of thousands
-of characters. A single Unicode code point is denoted by "U+" followed
-by four to six hexadecimal digits, while a range of Unicode code points
-is denoted by two hexadecimal numbers separated by "..", with no
-prefixes.
-
-ASCII means US-ASCII, a coded character set containing 128 characters
-associated with code points in the range 0..7F. Unicode is an extension
-of ASCII: it includes all the ASCII characters and associates them with
-the same code points.
-
-The term "LDH code points" is defined in this document to mean the code
-points associated with ASCII letters, digits, and the hyphen-minus; that
-is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an abbreviation for
-"letters, digits, hyphen".
-
-[STD13] talks about "domain names" and "host names", but many people use
-the terms interchangeably. Further, because [STD13] was not terribly
-clear, many people who are sure they know the exact definitions of each
-of these terms disagree on the definitions.
-
-A label is an individual part of a domain name. Labels are usually shown
-separated by dots; for example, the domain name "www.example.com" is
-composed of three labels: "www", "example", and "com". (The zero-length
-root label that is implied in domain names, as described in [STD13], is
-not considered a label in this specification.) Throughout this document
-the term "label" is shorthand for "text label", and "every label" means
-"every text label". In IDNA, not all text strings can be labels.
-
-An "internationalized domain name" (IDN) is a domain name for which the
-ToASCII operation (see section 4) can be applied to each label without
-failing. This document does not attempt to define an "internationalized
-host name". It is expected that protocols and name-handling bodies will
-want to limit the characters allowed in IDNs further than what is
-specified in this document, such as to prohibit additional characters
-that they feel are unneeded or harmful in registered domain names.
-
-An "internationalized label" is a label composed of characters from the
-Unicode character set; note, however, that not every string of Unicode
-characters can be an internationalized label. To allow internationalized
-labels to be handled by existing applications, IDNA uses an "ACE label"
-(ACE stands for ASCII Compatible Encoding), which can be represented
-using only ASCII characters but is equivalent to a label containing
-non-ASCII characters. More rigorously, an ACE label is defined to be any
-label that the ToUnicode operation would alter (see section 4.2). For
-every internationalized label that cannot be directly represented in
-ASCII, there is an equivalent ACE label. The conversion of labels to and
-from the ACE form is specified in section 4.
-
-The "ACE prefix" is defined in this document to be a string of ASCII
-characters that appears at the beginning of every ACE label. It is
-specified in section 5.
-
-A "domain name slot" is defined in this document to be a protocol element
-or a function argument or a return value (and so on) explicitly
-designated for carrying a domain name. Examples of domain name slots
-include: the QNAME field of a DNS query; the name argument of the
-gethostbyname() library function; the part of an email address following
-the at-sign (@) in the From: field of an email message header; and the host
-portion of the URI in the src attribute of an HTML <IMG> tag.
-General text that just happens to contain a domain name is not a domain name
-slot; for example, a domain name appearing in the plain text body of an
-email message is not occupying a domain name slot.
-
-An "internationalized domain name slot" is defined in this document to
-be a domain name slot explicitly designated for carrying an
-internationalized domain name as defined in this document. The
-designation may be static (for example, in the specification of the
-protocol or interface) or dynamic (for example, as a result of
-negotiation in an interactive session).
-
-A "generic domain name slot" is defined in this document to be any
-domain name slot that is not an internationalized domain name slot.
-Obviously, this includes any domain name slot whose specification
-predates IDNA.
-
-
-3. Requirements
-
-IDNA conformance means adherence of the following three requirements:
-
-1) Whenever a domain name is put into a generic domain name slot (see
-section 2), every label MUST contain only ASCII characters. Given an
-internationalized domain name (IDN), an equivalent domain name
-satisfying this requirement can be obtained by applying the ToASCII
-operation (see section 4) to each label.
-
-2) ACE labels obtained from domain name slots SHOULD be hidden from
-users except when the use of the non-ASCII form would cause problems or
-when the ACE form is explicitly requested. Given an internationalized
-domain name, an equivalent domain name containing no ACE labels can be
-obtained by applying the ToUnicode operation (see section 4) to each
-label. When requirements 1 and 2 both apply, requirement 1 takes
-precedence.
-
-3) Whenever two labels are compared, they MUST be considered to
-match if and only if their ASCII forms (obtained by applying ToASCII)
-match using a case-insensitive ASCII comparison.
-
-
-4. Conversion operations
-
-This section specifies the ToASCII and ToUnicode operations. Each one
-operates on a sequence of Unicode code points (but remember that all
-ASCII code points are also Unicode code points). When domain names are
-represented using character sets other than Unicode and ASCII, they will
-need to first be transcoded to Unicode before these operations can be
-applied, and might need to be transcoded back afterwards.
-
-4.1 ToASCII
-
-The ToASCII operation takes a sequence of Unicode code points and
-transforms it into a sequence of code points in the ASCII range (0..7F).
-The original sequence and the resulting sequence are equivalent labels.
-(If the original is an internationalized label that cannot be directly
-represented in ASCII, the result will be the equivalent ACE label.)
-
-ToASCII fails if any step of it fails. If any step fails, the original
-sequence MUST NOT be used as a label in an IDN.
-
-The inputs to ToASCII are a sequence of code points; a flag indicating
-whether to prohibit unassigned code points (see [STRINGPREP]); and a
-flag indicating whether to apply the host name syntax rules. The output
-of ToASCII is either a sequence of ASCII code points or a failure
-condition.
-
-ToASCII never alters a sequence of code points that are all in the ASCII
-range to begin with (although it could fail).
-
-ToASCII consists of the following steps:
-
- 1. If all code points in the sequence are in the ASCII range (0..7F)
- then skip to step 3.
-
- 2. Perform the steps specified in [NAMEPREP] and fail if there is
- an error.
-
- 3. If the label is part of a host name (or is subject to the host
- name syntax rules) then perform these checks:
-
- (a) Verify the absence of non-LDH ASCII code points; that is,
- the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
-
- (b) Verify the absence of leading and trailing hyphen-minus;
- that is, the absence of U+002D at the beginning and end of
- the sequence.
-
- 4. If all code points in the sequence are in the ASCII range (0..7F),
- then skip to step 8.
-
- 5. Verify that the sequence does NOT begin with the ACE prefix.
-
- 6. Encode the sequence using the encoding algorithm in [PUNYCODE].
-
- 7. Prepend the ACE prefix.
-
- 8. Verify that the number of code points is in the range 1 to 63
- inclusive.
-
-4.2 ToUnicode
-
-The ToUnicode operation takes a sequence of Unicode code points and
-returns a sequence of Unicode code points. If the input sequence is a
-label in ACE form, then the result is an equivalent internationalized
-label that is not in ACE form, otherwise the original sequence is
-returned unaltered.
-
-ToUnicode never fails. If any step fails, then the original input
-sequence is returned immediately in that step.
-
-The inputs to ToUnicode are a sequence of code points; a flag indicating
-whether to prohibit unassigned code points (see [STRINGPREP]); and a
-flag indicating whether to apply the host name syntax rules. The output
-of ToUnicode is always a sequence of Unicode code points.
-
- 1. If all code points in the sequence are in the ASCII range (0..7F)
- then skip to step 3.
-
- 2. Perform the steps specified in [NAMEPREP] and fail if there is an
- error. (If step 3 of ToASCII is also performed here, it will not
- affect the overall behavior of ToUnicode, but it is not
- necessary.)
-
- 3. Verify that the sequence begins with the ACE prefix, and save a
- copy of the sequence.
-
- 4. Remove the ACE prefix.
-
- 5. Decode the sequence using decoding algorithm in [PUNYCODE]. Save
- a copy of the result of this step.
-
- 6. Apply ToASCII.
-
- 7. Verify that the sequence matches the saved copy from step 3, using
- a case-insensitive ASCII comparison.
-
- 8. Return the saved copy from step 5.
-
-
-5. ACE prefix
-
-[[ Note to the IESG and Internet Draft readers: The two uses of the
-string "IESG--" below are to be changed at time of publication to a
-prefix which fulfills the requirements in the first paragraph. ]]
-
-The ACE prefix, used in the conversion operations (section 4), is two
-alphanumeric ASCII characters followed by two hyphen-minuses. It cannot
-be any of the prefixes already used in earlier documents, which includes
-the following: "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--"
-and "zq--". The ToASCII and ToUnicode operations MUST recognize the ACE
-prefix in a case-insensitive manner.
-
-The ACE prefix for IDNA is "IESG--".
-
-This means that an ACE label might be "IESG--de-jg4avhby1noc0d", where
-"de-jg4avhby1noc0d" is the part of the ACE label that is generated by
-the encoding steps in [PUNYCODE].
-
-
-6. Implications for typical applications using DNS
-
-In IDNA, applications perform the processing needed to input
-internationalized domain names from users, display internationalized
-domain names to users, and process the inputs and outputs from DNS and
-other protocols that carry domain names.
-
-The components and interfaces between them can be represented
-pictorially as:
-
- +------+
- | User |
- +------+
- ^
- | Input and display: local interface methods
- | (pen, keyboard, glowing phosphorus, ...)
- +-------------------|-------------------------------+
- | v |
- | +-----------------------------+ |
- | | Application | |
- | | (conversion between local | |
- | | character set and Unicode | |
- | | is done here) | |
- | +-----------------------------+ |
- | ^ ^ | End system
- | | | |
- | Call to resolver: | | Application-specific |
- | ACE | | protocol: |
- | v | predefined by the |
- | +----------+ | protocol or defaults |
- | | Resolver | | to ACE |
- | +----------+ | |
- | ^ | |
- +-----------------|----------|----------------------+
- DNS protocol: | |
- ACE | |
- v v
- +-------------+ +---------------------+
- | DNS servers | | Application servers |
- +-------------+ +---------------------+
-
-6.1 Entry and display in applications
-
-Applications can accept domain names using any character set or sets
-desired by the application developer, and can display domain names in any
-charset. That is, the IDNA protocol does not affect the interface
-between users and applications.
-
-An IDNA-aware application can accept and display internationalized
-domain names in two formats: the internationalized character set(s)
-supported by the application, and as an ACE label. ACE labels that are
-displayed or input MUST always include the ACE prefix. Applications MAY
-allow input and display of ACE labels, but are not encouraged to do so
-except as an interface for special purposes, possibly for debugging. ACE
-encoding is opaque and ugly, and should thus only be exposed to users
-who absolutely need it. The optional use, especially during a transition
-period, of ACE encodings in the user interface is described in section
-6.4. Because name labels encoded as ACE name labels can be rendered
-either as the encoded ASCII characters or the proper decoded characters,
-the application MAY have an option for the user to select the preferred
-method of display; if it does, rendering the ACE SHOULD NOT be the
-default.
-
-Domain names are often stored and transported in many places. For example,
-they are part of documents such as mail messages and web pages. They are
-transported in many parts of many protocols, such as both the
-control commands and the RFC 2822 body parts of SMTP, and the headers
-and the body content in HTTP. It is important to remember that domain
-names appear both in domain name slots and in the content that is passed
-over protocols.
-
-In protocols and document formats that define how to handle
-specification or negotiation of charsets, labels can be encoded in any
-charset allowed by the protocol or document format. If a protocol or
-document format only allows one charset, the labels MUST be given in
-that charset.
-
-In any place where a protocol or document format allows transmission of
-the characters in internationalized labels, internationalized labels
-SHOULD be transmitted using whatever character encoding and escape
-mechanism that the protocol or document format uses at that place.
-
-All protocols that use domain name slots already have the capacity for
-handling domain names in the ASCII charset. Thus, ACE labels
-(internationalized labels that have been processed with the ToASCII
-operation) can inherently be handled by those protocols.
-
-6.2 Applications and resolver libraries
-
-Applications normally use functions in the operating system when they
-resolve DNS queries. Those functions in the operating system are often
-called "the resolver library", and the applications communicate with the
-resolver libraries through a programming interface (API).
-
-Because these resolver libraries today expect only domain names in
-ASCII, applications MUST prepare labels that are passed to the resolver
-library using the ToASCII operation. Labels received from the resolver
-library contain only ASCII characters; internationalized labels that
-cannot be represented directly in ASCII use the ACE form. ACE labels
-always include the ACE prefix.
-
-IDNA-aware applications MUST be able to work with both
-non-internationalized labels (those that conform to [STD13]
-and [STD3]) and internationalized labels.
-
-It is expected that new versions of the resolver libraries in the future
-will be able to accept domain names in other formats than ASCII, and
-application developers might one day pass not only domain names in
-Unicode, but also in local script to a new API for the resolver
-libraries in the operating system.
-
-6.3 DNS servers
-
-An operating system might have a set of libraries for performing the
-ToASCII operation. The input to such a library might be in one or more
-charsets that are used in applications (UTF-8 and UTF-16 are likely
-candidates for almost any operating system, and script-specific charsets
-are likely for localized operating systems).
-
-For internationalized labels that cannot be represented directly in
-ASCII, DNS servers MUST use the ACE form produced by the ToASCII
-operation. All IDNs served by DNS servers MUST contain only ASCII
-characters.
-
-If a signalling system which makes negotiation possible between old and
-new DNS clients and servers is standardized in the future, the encoding
-of the query in the DNS protocol itself can be changed from ACE to
-something else, such as UTF-8. The question whether or not this should
-be used is, however, a separate problem and is not discussed in this
-memo.
-
-6.4 Avoiding exposing users to the raw ACE encoding
-
-All applications that might show the user a domain name obtained from a
-domain name slot, such as from gethostbyaddr or part of a mail header,
-SHOULD be updated as soon as possible in order to prevent users from
-seeing the ACE.
-
-If an application decodes an ACE name using ToUnicode but cannot show
-all of the characters in the decoded name, such as if the name contains
-characters that the output system cannot display, the application SHOULD
-show the name in ACE format (which always includes the ACE prefix)
-instead of displaying the name with the replacement character (U+FFFD).
-This is to make it easier for the user to transfer the name correctly to
-other programs. Programs that by default show the ACE form when they
-cannot show all the characters in a name label SHOULD also have a
-mechanism to show the name that is produced by the ToUnicode operation
-with as many characters as possible and replacement characters in the
-positions where characters cannot be displayed.
-
-The ToUnicode operation does not alter labels that are not valid ACE
-labels, even if they begin with the ACE prefix. After ToUnicode has been
-applied, if a label still begins with the ACE prefix, then it is not a
-valid ACE label, and is not equivalent to any of the intermediate
-Unicode strings constructed by ToUnicode.
-
-6.5 Bidirectional text in domain names
-
-The display of domain names that contain bidirectional text is not covered
-in this document. It may be covered in a future version of this
-document, or may be covered in a different document.
-
-For developers interested in displaying domain names that have
-bidirectional text, the Unicode standard has an extensive discussion of
-how to deal with reorder glyphs for display when dealing with
-bidirectional text such as Arabic or Hebrew. See [UAX9] for more
-information. In particular, all Unicode text is stored in logical order.
-
-6.6 DNSSEC authentication of IDN domain names
-
-DNS Security [DNSSEC] is a method for supplying cryptographic
-verification information along with DNS messages. Public Key
-Cryptography is used in conjunction with digital signatures to provide a
-means for a requester of domain information to authenticate the source
-of the data. This ensures that it can be traced back to a trusted
-source, either directly, or via a chain of trust linking the source of
-the information to the top of the DNS hierarchy.
-
-IDNA specifies that all internationalized domain names served by DNS
-servers that cannot be represented directly in ASCII must use the ACE
-form produced by the ToASCII operation. This operation must be performed
-prior to a zone being signed by the private key for that zone. Because
-of this ordering, it is important to recognize that DNSSEC authenticates
-the ASCII domain name, not the Unicode form or the mapping between the
-Unicode form and the ASCII form. In other words, the output of ToASCII
-is the canonical name. In the presence of DNSSEC, this is the name that
-MUST be signed in the zone and MUST be validated against. It also SHOULD
-be used for other name comparisons, such as when a browser wants to
-indicate that a URL has been previously visited.
-
-One consequence of this for sites deploying IDNA in the presence of
-DNSSEC is that any special purpose proxies or forwarders used to
-transform user input into IDNs must be earlier in the resolution flow
-than DNSSEC authenticating nameservers for DNSSEC to work.
-
-6.7 Limitations of IDNA
-
-The IDNA protocol does not solve all linguistic issues with users
-inputting names in different scripts. Many important language-based and
-script-based mappings are not covered in IDNA and must be handled
-outside the protocol. For example, names that are entered in a mix of
-traditional and simplified Chinese characters will not be mapped to a
-single canonical name. Another example is Scandinavian names that are
-entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be
-mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE).
-
-
-7. Name Server Considerations
-
-Internationalized domain name data in zone files (as specified by section
-5 of RFC 1035) MUST be processed with ToASCII before it is entered in
-the zone files.
-
-It is imperative that there be only one ASCII encoding for a particular
-domain name. ACE is an encoding for domain name labels that use non-ASCII
-characters. Thus, a primary master name server MUST NOT contain an
-ACE-encoded label that decodes to an ASCII label. The ToASCII operation
-assures that no such names are ever output from the operation.
-
-Name servers MUST NOT serve records with domain names that contain
-non-ASCII characters; such names MUST be converted to ACE form by the
-ToASCII operation in order to be served. If names that are not processed
-by ToASCII are passed to an application, it will result in unpredictable
-behavior. Note that [STRINGPREP] describes how to handle versioning of
-unallocated codepoints.
-
-
-8. Root Server Considerations
-
-IDNs are likely to be somewhat longer than current host names, so the
-bandwidth needed by the root servers should go up by a small amount.
-Also, queries and responses for IDNs will probably be somewhat longer
-than typical queries today, so more queries and responses may be forced
-to go to TCP instead of UDP.
-
-
-9. Security Considerations
-
-Security on the Internet partly relies on the DNS. Thus, any
-change to the characteristics of the DNS can change the security of much
-of the Internet.
-
-This memo describes an algorithm which encodes characters that are not
-valid according to STD3 and STD13 into octet values that are valid. No
-security issues such as string length increases or new allowed values
-are introduced by the encoding process or the use of these encoded
-values, apart from those introduced by the ACE encoding itself.
-
-Domain names are used by users to connect to Internet servers. The
-security of the Internet would be compromised if a user entering a
-single internationalized name could be connected to different servers
-based on different interpretations of the internationalized domain name.
-
-Because this document normatively refers to [NAMEPREP], it includes the
-security considerations from that document as well.
-
-
-A. References
-
-[PUNYCODE] Adam Costello, "Punycode", draft-ietf-idn-punycode.
-
-[DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC
-2535, March 1999.
-
-[NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
-Internationalized Domain Names", draft-ietf-idn-nameprep.
-
-[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", March 1997, RFC 2119.
-
-[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
-Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
-and Support" (RFC 1123), STD 3, October 1989.
-
-[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
-1034) and "Domain names - implementation and specification" (RFC 1035),
-STD 13, November 1987.
-
-[STRINGPREP] Paul Hoffman and Marc Blanchet, "Preparation of
-Internationalized Strings ("stringprep")", draft-hoffman-stringprep,
-work in progress
-.
-[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm,
-<http://www.unicode.org/unicode/reports/tr9/>.
-
-[UNICODE] The Unicode Standard, Version 3.1.0: The Unicode Consortium.
-The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley
-Developers Press, 2000. ISBN 0-201-61633-5, as amended by: Unicode
-Standard Annex #27: Unicode 3.1,
-<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.
-
-
-B. Authors' Addresses
-
-Patrik Faltstrom
-Cisco Systems
-Arstaangsvagen 31 J
-S-117 43 Stockholm Sweden
-paf@cisco.com
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA 95060 USA
-phoffman@imc.org
-
-Adam M. Costello
-University of California, Berkeley
-idna-spec.amc @ nicemice.net
+++ /dev/null
-Internet Draft Marc Blanchet
-draft-ietf-idn-idne-02.txt Viagenie
-March 19, 2001 Paul Hoffman
-Expires in six months IMC & VPNC
-
- Internationalized domain names using EDNS (IDNE)
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-The current DNS infrastructure does not provide a way to use
-internationalized domain names (IDN). This document describes an
-extension mechanism based on EDNS which enables the use of IDN without
-causing harm to the current DNS. IDNE enables IDN host names with a as
-many characters as current ASCII-only host names. It fully supports
-UTF-8 and conforms to the IDN requirements.
-
-
-1. Introduction
-
-Various proposals for IDN have tried to integrate IDN into the current
-limited ASCII DNS. However, the compatibility issues make too many
-constraints on the architecture. Many of these proposals require
-modifications to the applications or to the DNS protocol or to the
-servers. This proposal take a different approach: it uses the
-standardized extension mechanism for DNS (EDNS) and uses UTF-8 as the
-mandatory charset. It causes no harm to the current DNS because it uses
-the EDNS extension mechanism. The major drawback of this proposal is
-that all protocols, applications and DNS servers will have to be
-upgraded to support this proposal.
-
-1.1 Terminology
-
-The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
-"MAY" in this document are to be interpreted as described in RFC 2119
-[RFC2119].
-
-Hexadecimal values are shown preceded with an "0x". For example,
-"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
-shown preceded with an "0b". For example, a nine-bit value might be
-shown as "0b101101111".
-
-Examples in this document use the notation from the Unicode Standard
-[UNICODE3] as well as the ISO 10646 [ISO10646] names. For example, the
-letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER
-A". In the lists of prohibited characters, the "U+" is left off to make
-the lists easier to read.
-
-1.2 IDN summary
-
-Using the terminology in [IDNCOMP], this protocol specifies an IDN
-architecture of arch-2 (send binary or ACE). The binary format is
-bin-1.1 (UTF-8), and the method for distinguishing binary from current
-names is bin-2.4 (mark binary with EDNS0). The transition period is not
-specified.
-
-
-2. Functional Description
-
-DNS query and responses containing IDNE labels have the following
-properties:
-
-- The string in the label MUST be pre-processed as described in
-[NAMEPREP] before the query or response is prepared.
-
-- The characters in the label MUST be encoded using UTF-8 [RFC2279].
-
-- The entire label MUST be encoded EDNS [RFC2671].
-
-- The version of the IDN protocol MUST be identified.
-
-
-3. Encoding
-
-An IDNE label uses the EDNS extended label type prefix (0b01), as
-described in [RFC2671]. (A normal label type always begin with 0b00). A
-new extended label type for IDNE is used to identify an IDNE label. This
-document uses 0b000010 as the extended label type; however, the label
-type will be assigned by IANA and it may not be 0b000010.
-
- 0 1 2
-bits 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
- |0 1| ELT | Size | IDN label ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
-
-
-ELT: The six-bit extended label type to be assigned by the IANA for an
-IDN label. In this document, the value 0b000010 is used, although that
-might be changed by IANA.
-
-Size: Size (in octets) of the IDN label following. This MUST NOT
-be zero.
-
-IDN label: Label, encoded in UTF-8 [RFC2279]. Note that this label might
-contain all ASCII characters, and thus can be used for host name labels
-that are legal in [STD13].
-
-IDNE labels can be mixed with STD13 labels in a domain name.
-
-The compression scheme in section 4.1.4 of [STD13] is supported as is.
-Pointers can refer to either IDN labels or non-IDN labels.
-
-3.1 Examples
-
-3.1.1 Basic example
-
-The following example shows the label me.com where the "e" in "me" is
-replaced by a <LATIN CAPITAL LETTER E WITH ACUTE>, which is U+00C9. The
-decomposition and downcasing specified in [NAMEPREP] changes the second
-character to <LATIN SMALL LETTER E WITH ACUTE>, U+00E9. This string is
-then transformed using UTF-8 [RFC2279] to 0x6DC3A9.
-
-Ignoring the other fields of the message, the domain name portion of the
-datagram could look like:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 20 | 0 1 0 0 0 0 1 0| 0 0 0 0 0 0 1 1|
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 22 | 0x6D (m) | 0xC3 (e'(1)) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 24 | 0xA9 (e'(2)) | 3 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 26 | 0x63 (c) | 0x6F (o) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 28 | 0x6D (m) | 0x00 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Octet 20 means EDNS extended label type (0b01) using the IDN label
- type (0b000010)
-Octet 21 means size of label is 3 octets following
-Octet 22-24 are the "m*" label encoded in UTF-8
-Octet 25-28 are "com" encoded as a STD13 label
-Octet 29 is the root domain
-
-3.1.2 Example with compression
-
-Using the previous labels, one datagram might contain "www.m*.com" and
-"m*.com" (where the "*" is <LATIN CAPITAL LETTER E WITH ACUTE>).
-
-Ignoring the other fields of the message, the domain name portions of
-the datagram could look like:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 20 | 0 1 0 0 0 0 1 0| 0 0 0 0 0 0 1 1|
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 22 | 0x6D (m) | 0xC3 (e'(1)) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 24 | 0xA9 (e'(2)) | 3 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 26 | 0x63 (c) | 0x6F (o) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 28 | 0x6D (m) | 0x00 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- . . .
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 40 | 3 | 0x77 (w) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 42 | 0x77 (w) | 0x77 (w) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 44 | 1 1| 20 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The domain name "m*.com" is shown at offset 20. The domain name
-"www.m*.com" is shown at offset 40; this definition uses a pointer to
-concatenate a label for www to the previously defined "m*.com".
-
-
-4. Label Size
-
-In IDNE, the maximum length of a label is 255 octets, and the maximum
-size for a domain name is 1023 octets. The reason for using these values
-is so that IDNE labels can have the same number of characters as the
-ASCII-based labels in [STD13]. Because character encoding in UTF-8 is
-variable length, the maximum octet length for characters expected in the
-foreseeable future (that is, 4 octets for a single character) was used.
-Note that this extension allows some IDNE labels to be longer than 63
-characters and some IDNE names to be longer than 255 octets.
-
-Software creating DNS queries or responses using IDNE MUST verify that,
-after IDN preparation and transformation to UTF8, that no labels are
-longer than 255 octets and that no names are longer than 1023 octets. If
-there is a user interface associated with the process creating the query
-or response, that interface SHOULD give the user an error message.
-
-Software MUST NOT transmit DNS queries or responses which contain labels
-that are longer than 255 octets or names that are longer than 1023
-octets. Servers MUST NOT accept DNS queries or responses which contain
-labels that are longer than 255 octets or names that are longer than
-1023 octets, and MUST send the NOTIMPL RCODE error message if such
-queries or responses are received.
-
-
-5. UDP Packet Size
-
-IDNE-capable senders and receivers MUST support UDP packet sizes of 1220
-octets, not including IP and UDP headers (note that the minimum MTU for
-IPv6 is 1280 [RFC2460]). A sender MUST announce its capability in the
-OPT pseudo-RR described in section 4.3 of [RFC2671] by having the CLASS
-sender's UDP payload size be greater than or equal to 1220.
-
-
-6. Canonalization, Prohibited Characters, and Case Folding
-
-The string in the label MUST be pre-processed as described in [NAMEPREP]
-before the query or response is prepared. A query or response MUST NOT
-contain a label that does not conform to [NAMEPREP].
-
-
-7. Versions of IDNE
-
-The IDN protocol version number MUST be included in the OPT RR RDATA of
-EDNS (described in Section 4.4 of [RFC2671]). An OPTION-CODE will be
-assigned by IANA for storing the IDNE protocol version number; this
-document uses 0x0001 for the OPTION-CODE. The value (that
-is, the OPTION-DATA) is the version number coded in 8 bits.
-
-All requesters MUST send this information as part of the OPT RR included
-in the EDNS packet.
-
-7.1 This version of IDNE
-
-This document describes version 1 of IDNE. This version is a combination
-of the protocol in this document and the rules as described in
-[NAMEPREP]. Note that [NAMEPREP] describes a single version of the list
-of canonicalization, case folding, and prohibited characters, and that
-this document is linked to that single version of [NAMEPREP].
-
-The identifiers for this specification are:
-OPTION-CODE = 0x0001 (IDNE protocol version)
-OPTION-LENGTH = 0x0001 (1 octet following)
-OPTION-DATA = 0x01 (IDNE protocol version 1)
-
-7.2 Creating new versions of IDNE
-
-A new version of IDNE is created by a standards-track RFC that
-specifies:
-
-- a normative reference to [NAMEPREP] or a successor document to
-[NAMEPREP]
-
-- an IDNE version number that is 1 greater than the highest IDNE version
-number at the time the RFC is published
-
-If there are any changes to the encoding or interpretation of the
-protocol, they must also be specified in the same standards-track RFC.
-
-7.3 Prohibited characters and versions of IDNE
-
-If a server receives a request containing an illegal or unknown
-character (as described in the version number in the request), it MUST
-send a NOTIMPL RCODE to the client. For example, if a server that
-understands both version 1 and version 2 receives a request that is
-marked as version 1, but contains a label that includes a character that
-is prohibited in version 1 but allowed in version 2, that server must
-still send a NOTIMPL RCODE to the client.
-
-
-8. API Specifications
-
-The current API for TCP/IP uses gethostbyname and gethostbyaddr for IPv4
-and getnodeipbyname and getnodeipbyaddr (specified in [RFC 2671]) for
-both IPv4 and IPv6. These function calls returns hostent structs, where
-the h_name field contains a pointer to a char. In this context,
-receiving a UTF-8 string mean that the application should know that
-UTF-8 uses more than one octet per char.
-
-A new flag "IDN" (to appear in netdb.h) is defined to be passed in the
-flags argument of getnodeipbynode and getnodeipbyaddr. This flag tells
-the resolver to request an IDNE-encoded name. No new return code is
-defined since the returned codes in RFC 2671 are meaningful in the IDNE
-context.
-
-If one has not yet converted his code to IPv6 and still wants to enable
-IDNs with this API, one can do a macro of the getnodeipby* functions
-mapped to the IPv4 gethostby* ones, including the "IDN" flag, and then
-process differently based on the presence of the flag.
-
-
-9. Transition and Deployment
-
-Deployment of this proposal means updating clients and servers, as well
-as applications and protocols, and therefore a transition strategy is
-proposed. Because many DNS servers do not yet handle IDNE and may take
-years or decades to do so, an ASCII-compatible encoding (ACE) format for
-IDN names is also needed as a transition to an all-IDNE DNS. Note that
-IDNE and an ACE are not related, and do not interact in the DNS. If the
-IETF chooses to have an ACE mechanism in use at the same time as IDNE,
-it would be wise to choose an ACE that allows as many characters as
-possible in the name parts and full names.
-
-IDNE allows names with as many characters as current names. This means
-that it is possible to create names in IDNE that are longer than those
-that can be created in the ACE protocols that have been described so
-far. Although not prohibited, it is unwise to create a name that can be
-legally represented in IDNE but not in the ACE, or a name that can be
-legally represented in the ACE but not in IDNE.
-
-The IETF should periodically evaluate the benefits and problems
-associated with having three different formats for names (STD13, IDNE,
-and ACE). If at some point it is decided that the problems outweigh the
-benefits, the IETF can state a time when one or more of the services
-should not be used on the Internet.
-
-
-10. Root Server Considerations
-
-Because this specification uses EDNS, root servers should be prepared to
-receive EDNS requests. This specification handles IDN top-level domains
-in exactly the same fashion as it does every other domain.
-Considerations about IDN top-level domains are outside of this work, but
-the first IDN top-level domains would require all root servers to be
-ready for IDNE requests.
-
-
-11. IANA Considerations
-
-[[ TBD. This section will have two parts. The first will request an EDNS
-option code. The second will specify how IDNE version numbers are
-allocated (namely, standards-track RFC only). ]]
-
-
-12. Security Considerations
-
-Because IDNE uses EDNS, it inherits the same security considerations as
-EDNS.
-
-Much of the security of the Internet relies on the DNS. Thus, any change
-to the characteristics of the DNS can change the security of much of the
-Internet.
-
-Host names are used by users to connect to Internet servers. The
-security of the Internet would be compromised if a user entering a
-single internationalized name could be connected to different servers
-based on different interpretations of the internationalized host name.
-
-Because this document normatively refers to [NAMEPREP] and [RFC2671],
-it includes the security considerations from those documents as well.
-
-
-13. References
-
-[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
-Proposals", draft-ietf-idn-compare.
-
-[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
-technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part
-1: Architecture and Basic Multilingual Plane. Five amendments and a
-technical corrigendum have been published up to now. UTF-16 is described
-in Annex Q, published as Amendment 1. 17 other amendments are currently
-at various stages of standardization. [[[ THIS REFERENCE NEEDS TO BE
-UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
-
-[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
-Internationalized Host Names", draft-ietf-idn-nameprep.
-
-[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", March 1997, RFC 2119.
-
-[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
-10646", January 1998, RFC 2279.
-
-[RFC2460] Steve Deering & Bob Hinden, "Internet Protocol, Version 6 (IPv6)
-Specification", December 1998, RFC 2460.
-
-[RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", August
-1999, RFC 2671.
-
-[STD13] Paul Mockapetris, "Domain names - implementation and
-specification", November 1987, STD 13 (RFC 1035).
-
-[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version
-3.0", ISBN 0-201-61633-5. Described at
-<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
-
-
-A. Acknowledgements
-
-This document is the result of the thinking of many people. The following
-people made significant comments on the early drafts:
-
-Andre Cormier
-Andrew Draper
-Bill Sommerfeld
-Francois Yergeau
-
-
-B. Changes from -01 to -02
-
-None.
-
-
-C. Authors' Addresses
-
-Marc Blanchet
-Viagenie
-2875 boul. Laurier, bureau 300
-Sainte-Foy, QC G1V 2M2 Canada
-Marc.Blanchet@viagenie.qc.ca
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA 95060 USA
-phoffman@imc.org
-
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Hongbo Shi
-draft-ietf-idn-iptr-02.txt Waseda University
-17 May 2001 Jiang Ming Liang
-Expires: 17 November 2001 i-DNS.net
-
-
- Internationalized PTR Resource Record (IPTR)
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- This draft attempts to address the problem of how an IP address SHOULD
- be properly mapped to a set of Internationalized Domain Names(IDNs).
- It is currently unspecified how a PTR record can be used for this
- purpose. In addition, the syntax of the PTR resource record may be
- too restrictive for such a mapping in a more culturally meaningful
- context. This document suggests a new TYPE called IPTR using EDNS0
- and a mechanism to combined language information with such a mapping.
-
-1. Introduction
-
- Reverse mapping is a very important and essential function in the DNS.
- In today's Domain Name System, PTR RRs are used to support address-
- to-domain mappings. However, a current PTR RR does not provide support
- for proper address-to-IDN mappings, without certain modifications.
- Modifying the PTR structure will also affect the current reverse
-
-
-
-Shi, Jiang [Page 1]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- mapping architecture. This document describes a new RR TYPE named IPTR
- to provide address-to-IDN mappings and it also specifies that on
- receiving of a IPTR query a name server should respond with all the
- corresponding IPTR RRs in one response. In short, "one IP several
- IDNs".
-
-1.1 Terminology
-
- The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
- and "MAY" in this document are to be interpreted as described in RFC
- 2119 [RFC2119].
-
-1.2 Background and Designs
-
- When Internationalized Domain Names come into wide use, an Internet
- host is likely to have domain names in different languages. In
- today's Internet, even thought the [RFC2181] redefine the
- consideration of PTR, because of the design of the PTR mapping
- algorithm and implementation of most resolvers, IP address to domain
- names mapping is still limited to "one IP one domain name".
-
- For example, BIND treats PTRs specially so that the normal sorting
- preference (e.g. cyclic/random) doesn't apply. But as usual, "fixed"
- order is always used. So a client that is querying a BIND server and
- doesn't look beyond the first PTR RR, no matter how many times it
- queries the name. In other words, PTR RRset is different from A RRset,
- where the first record in the RRset might differ from query to query.
-
- This is more restrictive in a world of IDNs, for choosing some names
- in a particular language. Briefly, according to the use of PTR, it is
- no meaning of returning an IDN in an unknown language.
-
- The authors also believe that putting language information into
- address-to-name mappings will be benifitial to future applications.
-
- The design purpose of the IPTR RR type is to provide a mechanism that
- can map an IP address to the corresponding IDN per language. It also
- means that IPTR suggests a new mapping algorithm for the reverse
- mapping by using an language information.
-
- CNAME MUST continue to work for IPTR as it works now for PTR records.
-
- The behavior of a resolver on the use of IPTR will be specified in a
- seperate draft or a later version of this draft.
-
-1.3 Functional Description
-
- DNS query and responses involving IPTR type MUST have the following
-
-
-
-Shi, Jiang [Page 2]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- properties:
-
-
- - When the QTYPE is IPTR, the corresponding IDNs SHOULD be
- returned in one response.
-
-
- - The characters in the label MUST be encoded using UTF-8
- [RFC2279].
-
-
- - The entire label MUST be encoded EDNS [RFC2671].
-
-
- - An exceptional handling of PTR for the IDN is REQUIRED.
-
-
-2. IPTR definition
-
- The structure of an IPTR RR is somewhat like the MX RR. In addtion to
- the IP address in the IN-ADDR.ARPA domain and the domain name field
- (similar to a PTR RR), a new field called LANGUAGE has been defined.
- A domain name in an IPTR RR MUST be encoded in UTF8. And IDN in this
- document MUST be NAMEPREPPED. [NAMEPREP] Below is an example of an
- IPTR RR:
-
- 1.2.3.4.IN-ADDR.ARPA. IPTR "LANGUAGE" "name-in-utf8"
-
- [RFC1766] describes the ISO 639/ISO 3166 conventions. A language name
- is always written in lower case, while country codes are written in
- upper case. At here, the "LANGUAGE" field in an IPTR RR SHOULD be done
- in a case-insensitive manner and MUST follow the conventions defined
- in [RFC1766].
-
- For Example:
-
- 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name-in-utf8"
- 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name-in-utf8"
- 4.3.2.1.IN-ADDR.ARPA. IPTR "ja-JP" "name-in-utf8"
- 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name-in-utf8"
-
- The notion of canonical names and aliases described in 3.6.2
- [RFC1034], and 10.2 [RFC2181] MUST be preserved for IPTR record types.
- An IPTR RR SHOULD be limited to one primary IDN per LANGUAGE, similar
- to the a PTR RR.
-
-3. IPTR on IPv6
-
-
-
-
-Shi, Jiang [Page 3]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- Mapping IPv6 to IDNs can be similarly supported. This document recom-
- mands to continue using the IP6.INT domain defined in [RFC1886] for
- IPTR mappings. For example, the lookup corresponding to the address
- 4321:0:1:2:3:4:567:89ab would be:
- b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
- IPTR "LANGUAGE" "name-in-utf8"
-
-4. Packet format for IPTR
-
- EDNS0[RFC2671] is REQUIRED to implement IPTR.
-
-
- 0 1 2 3 4
- bits 0 1 2 3 4 5 6 7 8 9 0 1...9 0...8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 ...
- +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+
- |0 1| ELT | LANGUAGE | Size | IDN label... |
- +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+
-
- LANGUAGE: An argument for IPTR to define the kind of language
- used in the following IDN label. The size is 2 octets.
- ELT: To be defined in [IDNE].
-
-
-5. Coexistence
-
-5.1 IDN Consideration
-
- IPTR described above is based on "a set of IDNs", strictly speaking, a
- set of canonical IDNs. On the other hand, confusion about IDN, such as
- "IDN MUST exist with ASCII domain name" has led to a belief that PTR
- record should have exactly RRs in its RRSet. In short, the phenomenon
- "IDN ONLY" will exist. Thus, the exceptional handling of PTR is
- REQUIRED.
-
- On the other hand, IDN is still RECOMMENDED to exist with more than
- one ASCII domain name.
-
-5.2 PTR Extension
-
- In the case of "IDN ONLY", if IPTR RR is not NULL, PTR RR MUST contain
- a domain name in ACE to coexist with those IDN unaware systems. Else a
- "Syntax Error" message SHOULD be sent back, when an administrator con-
- figures DNS zone files.
-
-5.3 IPTR and PTR
-
- It is a kind of backward compatible handle for those IDN unaware sys-
- tems that can not provide the IPTR function. Besides, if a client can
-
-
-
-Shi, Jiang [Page 4]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- not find the corresponding LANGUAGE IDN finally, then the correspond-
- ing PTR RR SHOULD be used as the answer.
-
-6. IPTR query/response
-
- When the QTYPE is IPTR in a query, all of the corresponding IPTR RRs
- SHOULD be returned in one response. DNS messages are limited to 512
- octets or less in size when sent over UDP. Therefore, if all the RRs
- cannot fit in one UDP packet, this draft describe two solutions. One
- is for recent environment and the other is for the near future.
-
-6.1 Transport
-
- Today, DNS queries and responses are carried in UDP datagrams or over
- TCP connections.[RFC1034] specifies, IPTR RRSet is RECOMMENDED to be
- returned in one response. The size of a DNS message could exceed 512
- octets, when multiple RRs are present. Therefore, this draft makes the
- two following recommendations.
-
-
- - "Use UDP first, if UDP is not large enough then change to TCP" is
- RECOMMENDED.
-
- The server MUST send back the response with the TC bit set. Then
- the resolver SHOULD resend the query using TCP on server port
- 53(decimal). This behavior is consistent with the current DNS
- specification [RFC1035].
-
-
- - In future, EDNS0 is REQUIRED to send large packets.
-
- Then, before a client send a query to ask for IPTR record, it
- MUST query the server whether it knows the EDNS0 first. If the
- server knows EDNS0, then the client MAY send the IPTR query.
- Else, unfortunally, the client MUST change the QTYPE to PTR.
-
- Hence, the size of the UDP payload is no longer limited to 512
- octets any more.
-
-6.2 Standard sample
-
- A resolver who wants to find the IDNs corresponding to an IP
- address 1.2.3.4 whould pursue a query of the form QTYPE=IPTR,
- QCLASS=IN, QNAME=4.3.2.1.IN-ADDR.ARPA, and would receive:
-
-
-
-
-
-
-
-Shi, Jiang [Page 5]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
-
- +------------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +------------------------------------------------------+
- Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR |
- +------------------------------------------------------+
- Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name1-in-utf8" |
- | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name2-in-utf8" |
- | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-JP" "name3-in-utf8" |
- | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name4-in-utf8" |
- +------------------------------------------------------+
- Authority | ... |
- +------------------------------------------------------+
- Additional | ... |
- +------------------------------------------------------+
-
-
-7. IPTR Usage
-
- The "foo1.example" in following samples MAY or MAY NOT be
- represented in the same characters.
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8"
- IPTR "zh-CN" "[foo1.example] in utf8"
- IPTR "ja-JP" "[foo1.example] in utf8"
- IPTR "ko-KR" "[foo1.example] in utf8"
-
- Moreover,
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8"
- IPTR "zh-TW" "[foo2.example] in utf8"
- ...
- IPTR "zh-CN" "[foo1.example] in utf8"
- IPTR "zh-CN" "[foo2.example] in utf8"
- ...
- IPTR "ja-JP" "[foo1.example] in utf8"
- IPTR "ja-JP" "[foo2.example] in utf8"
- ...
- IPTR "ko-KR" "[foo1.example] in utf8"
- IPTR "ko-KR" "[foo2.example] in utf8"
- ...
-
- will exist also. And "foo2.example" MUST be different from
- "foo1.example", if they are in signed with same LANGUAGE. Or a
- "Syntax Error" SHOULD be sent back, when an administrator config-
- ures the zone files. Furthermore "foo2.example" in the samples
- above MAY or MAY NOT be represented in the same characters.
-
-
-
-
-Shi, Jiang [Page 6]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- Thus,
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
- IPTR "zh-TW" "[samefoo.sample] in utf8"
-
- occurs a "Syntax Error".
-
- And,
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
- IPTR "zh-TW" "[difffoo.sample] in utf8"
- IPTR "zh-CN" "[samefoo.sample] in utf8"
- IPTR "ja-JP" "[samefoo.sample] in utf8"
- IPTR "ko-KR" "[samefoo.sample] in utf8"
-
- is allowed.
-
-8. Changes
-
- Through the discussion on the IETF49 meeting in San Diego, we
- deleted the chapter "Open Issues" of our previous draft (version
- 01).
-
- And,
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
- IPTR "zh-TW" "[difffoo.sample] in utf8"
- IPTR "zh-CN" "[samefoo.sample] in utf8"
- IPTR "ja-JP" "[samefoo.sample] in utf8"
- IPTR "ko-KR" "[samefoo.sample] in utf8"
-
- is allowed.
-
-8. Changes
-
- Through the discussion on the IETF49 meeting in San Diego, we
- deleted the chapter "Open Issues" of our previous draft (version
- 01).
-
-References
-
- [IDNREQ] Zita Wenzel & James Seng, "Requirements of International-
- ized Domain Names", draft-ietf-idn-requirements.
-
- [IDNE] Marc Blanchet & Paul Hoffman, "Internationalized domain
- names using EDNS", draft-ietf-idn-idne.
-
- [NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
-
-
-
-Shi, Jiang [Page 7]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- Internationalized Host Names", draft-ietf-idn-nameprep.
-
- [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- November 1987, RFC1034
-
- [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", November 1987, RFC1035
-
- [RFC1766] H. Alvestrand, "Tags for the Identification of
- Languages", March 1999, RFC 1766
-
- [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP
- version 6", December 1995, RFC1886
-
- [RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specifica-
- tion", July 1997, RFC2181
-
- [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
- 10646", January 1998, RFC 2279.
-
- [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)",
- August 1999, RFC 2671.
-
- [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names
- of languages - The International Organization for Standardization,
- 1st edition, 1988 17 pages Prepared by ISO/TC 37 - Terminology
- (principles and coordination).
-
- [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of
- names of countries - The International Organization for Standardi-
- zation, 3rd edition, 1988-08-15.
-
-Acknowledgements
-
- James Seng and Yoshiro Yoneya have given many comments in our e-
- mail discussions. Harald Alvestrand, Mark Davis have given many
- suggestions in the idn-wg mailing list discussions. And there are
- also a lot of people who have given us their comments in the idn-wg
- and BIND-user mailing list discussions.
-
-Authors' Information
-
- Hongbo Shi
- Waseda University
- 3-4-1 Okubo, Shinjyuku-ku
- Tokyo, 169-8555 Japan
- shi@goto.info.waseda.ac.jp
-
-
-
-
-Shi, Jiang [Page 8]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- Jiang Ming Liang
- i-DNS.net
- 8 Temasek Boulevard
- #24-02 Suntec Tower Three
- Singapore 038988
- jiang@i-DNS.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Shi, Jiang [Page 9]
-
-
+++ /dev/null
-Internet Draft Yoshiro Yoneya
-draft-ietf-idn-jpchar-01.txt Yasuhiro Morishita
-March 2, 2001 JPNIC
-Expires September 2, 2001
-
- Japanese characters in multilingual domain name labels
-
-Status of this memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
-This document explains about Japanese characters and their local mapping
-rules in multilingual domain name labels. This document is based on
-discussions and examinations in JPNIC (Japan Network Information
-Center).
-
-Despite of IDN WG's requirement [IDNREQ] that desired character set of
-multilingual domain name is UCS [UCS], most popular Japanese character
-set used in Japan is still Japanese Industrial Standards X 0208 and X
-0201 -- hereafter abbreviated as "JIS" -- [JISX0208]. This means that
-many of PCs and most of PDAs including handy phones in Japan can
-display only JIS and ASCII characters. Therefore, to handle
-multilingual domain name properly, these PCs and PDAs SHOULD meet
-conditions described below.
-
- - Use well defined widely distributed common mapping table between
- UCS and JIS.
- - Use characters commonly defined in both UCS and JIS.
-
-This document does not define common mapping table, but this document
-defines desired Japanese characters used as multilingual domain name
-labels and also describes problems and possible solutions that come
-with mapping table and normalization rules defined by the Unicode
-Consortium.
-
-
-1. Japanese characters in multilingual domain name labels
-
-In principle, domain name is a symbolic name of resources on the
-Internet for recognizing and memorizing easily to the Internet users.
-Internationalization or multilingualization of domain name MUST obey
-this principle. That is, characters in multilingualized domain name
-labels SHOULD be unambiguous.
-
-JIS has a lot of characters including graphical characters. But as
-for domain name, significant characters to represent names are
-Alpha-numerics, Kanji, Hiragana and Katakana [CJK]. Therefore,
-according to the principle, Japanese characters in multilingual domain
-name MUST be combination of Alpha-numerics, Hyphen, Kanji, Hiragana
-and Katakana.
-
-The file "idntabjp10.txt" (also included in this document) defines
-Japanese characters in the format of [VERSION], with additional
-corresponding JIS code points as 3rd field, that can be used in
-multilingual domain name labels. Some of them, such as
-KATAKANA-HIRAGANA PROLONGED SOUND MARK (U+30FC), are categorized
-into graphical character in JIS, but usage of them are part of
-Kanji, Hiragana or Katakana.
-
-
-2. Local mapping of Japanese characters in multilingual domain
- name labels
-
-Name preparation [NAMEPREP] practically works well for Japanese
-characters but there are some exceptions. These exceptions are
-depending on character mapping between UCS and JIS. As mentioned
-before, many of Japanese PCs and PDAs use JIS as local character set,
-therefore these MUST do code set conversion to handle multilingual
-domain name properly.
-
-Unfortunately, some characters such as VOICED SOUND MARK in JIS are
-mapped to characters in UCS that don't work with [NAMEPREP]. The file
-"idntabjplocalmap10.txt" (also included in this document) defines
-mapping to make these characters work with [NAMEPREP] as preferred,
-with additional corresponding UCS code points as 3rd field. This
-mapping MUST be applied before [NAMEPREP].
-
-The interfaces for mapping described in this document can be
-represented pictorially according to Internationalizing Host Names in
-Applications [IDNA] as:
-
- +------+
- | User |
- +------+
- ^
- | Input and display: local interface methods
- | (pen, keyboard, glowing phosphorus, ...)
- +--------------- v -------------------------------+
- | +-------------+ |
- | | Application | | End system
- | |+-----------+|
- | || Code conv || Code conversion between local
- | |+-----------+| encoding and UCS
- | |+-----------+|
- | || Local map || Character mapping to make NAMEPREP
- | |+-----------+| work as preferred
- | |+-----------+|
- | || NAMEPREP || Name preparation
- | |+-----------+|
- | |+-----------+|
- | || ACE conv || Encoding conversion between UCS and
- | |+-----------+| ASCII Compatible Encoding (ACE)
- | +-------------+
- | ^
- | | API call and return: nameprepped ACE
- | v
- | +----------+
- | | Resolver |
- | +----------+ |
- +----------------^--------------------------------+
- | DNS query and response: nameprepped ACE
- v
- +-------------+
- | DNS servers |
- +-------------+
-
-3. Security considerations
-
-None in particular.
-
-
-4. References
-
-[IDNREQ] "Requirements of Internationalized Domain Names",
- draft-ietf-idn-requirements-04.txt, Oct 2000, Z Wenzel, J Seng
-[UCS] "Universal Multiple-Octet Coded Character Set",
- ISO/IEC 10646-1:1993, ISBN 0-201-61633-5
-[JISX0208] "Japanese Industrial Standards",
- Information Technology (Terms/Code/Date elements)-99,
- ISBN 4-542-12976-4
-[NAMEPREP] "Preparation of Internationalized Host Names",
- draft-ietf-idn-nameprep-03.txt, Feb 2001, P Hoffman, M Blanchet
-[CJK] "Han Ideograph (CJK) for Internationalized Domain Names",
- draft-ietf-idn-cjk-00.txt, Sep 2000, J Seng, Y Yoneya,
- K Huang, K Kyongsok
-[VERSION] "Handling versions of internationalized domain names protocols",
- draft-ietf-idn-version-00.txt, Nov 2000, M Blanchet
-[IDNA] "Internationalizing Host Names In Applications (IDNA)",
- draft-ietf-idn-idna-01.txt, Feb 2001, P Hoffman, P Faltstrom
-
-
-5. Acknowledgements
-
-JPNIC IDN-TF members gave a lot of comments for early drafts.
-Mark Davis and Hideyo Imazu suggested to map KATAKANA-HIRAGANA
-VOICED/SEMI-VOICED SOUND MARK (U+309B/U+309C) onto COMBINING
-KATAKANA-HIRAGANA VOICED/SEMI-VOICED SOUND MARK (U+3099/U+309A).
-
-6. Differences between -00 and -01 drafts
-
-Focused on local mapping to make NAMEPREP work as preferred, therefore
-additional normalization rule is no longer defined and related table
-was removed.
-
-NAMEPREP now works well for compatible characters such as FULL-WIDTH
-alpha-numerics and/or HALF-WIDTH Katakana, therefore compatible
-mapping table was removed.
-
-7. Author's Address
-
-Yoshiro Yoneya
-Japan Network Information Center
-Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
-Chiyoda-ku Tokyo 101-0052, Japan
-yone@nic.ad.jp
-
-Yasuhiro Morishita
-Japan Network Information Center
-Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
-Chiyoda-ku Tokyo 101-0052, Japan
-yasuhiro@nic.ad.jp
-
-
-A. idntabjp10.txt
-
-version=1.0
-
-3005;1.0;0125
-3041;1.0;0401
-3042;1.0;0402
-3043;1.0;0403
-3044;1.0;0404
-3045;1.0;0405
-3046;1.0;0406
-3047;1.0;0407
-3048;1.0;0408
-3049;1.0;0409
-304A;1.0;0410
-304B;1.0;0411
-304C;1.0;0412
-304D;1.0;0413
-304E;1.0;0414
-304F;1.0;0415
-3050;1.0;0416
-3051;1.0;0417
-3052;1.0;0418
-3053;1.0;0419
-3054;1.0;0420
-3055;1.0;0421
-3056;1.0;0422
-3057;1.0;0423
-3058;1.0;0424
-3059;1.0;0425
-305A;1.0;0426
-305B;1.0;0427
-305C;1.0;0428
-305D;1.0;0429
-305E;1.0;0430
-305F;1.0;0431
-3060;1.0;0432
-3061;1.0;0433
-3062;1.0;0434
-3063;1.0;0435
-3064;1.0;0436
-3065;1.0;0437
-3066;1.0;0438
-3067;1.0;0439
-3068;1.0;0440
-3069;1.0;0441
-306A;1.0;0442
-306B;1.0;0443
-306C;1.0;0444
-306D;1.0;0445
-306E;1.0;0446
-306F;1.0;0447
-3070;1.0;0448
-3071;1.0;0449
-3072;1.0;0450
-3073;1.0;0451
-3074;1.0;0452
-3075;1.0;0453
-3076;1.0;0454
-3077;1.0;0455
-3078;1.0;0456
-3079;1.0;0457
-307A;1.0;0458
-307B;1.0;0459
-307C;1.0;0460
-307D;1.0;0461
-307E;1.0;0462
-307F;1.0;0463
-3080;1.0;0464
-3081;1.0;0465
-3082;1.0;0466
-3083;1.0;0467
-3084;1.0;0468
-3085;1.0;0469
-3086;1.0;0470
-3087;1.0;0471
-3088;1.0;0472
-3089;1.0;0473
-308A;1.0;0474
-308B;1.0;0475
-308C;1.0;0476
-308D;1.0;0477
-308E;1.0;0478
-308F;1.0;0479
-3090;1.0;0480
-3091;1.0;0481
-3092;1.0;0482
-3093;1.0;0483
-309D;1.0;0121
-309E;1.0;0122
-30A1;1.0;0501
-30A2;1.0;0502
-30A3;1.0;0503
-30A4;1.0;0504
-30A5;1.0;0505
-30A6;1.0;0506
-30A7;1.0;0507
-30A8;1.0;0508
-30A9;1.0;0509
-30AA;1.0;0510
-30AB;1.0;0511
-30AC;1.0;0512
-30AD;1.0;0513
-30AE;1.0;0514
-30AF;1.0;0515
-30B0;1.0;0516
-30B1;1.0;0517
-30B2;1.0;0518
-30B3;1.0;0519
-30B4;1.0;0520
-30B5;1.0;0521
-30B6;1.0;0522
-30B7;1.0;0523
-30B8;1.0;0524
-30B9;1.0;0525
-30BA;1.0;0526
-30BB;1.0;0527
-30BC;1.0;0528
-30BD;1.0;0529
-30BE;1.0;0530
-30BF;1.0;0531
-30C0;1.0;0532
-30C1;1.0;0533
-30C2;1.0;0534
-30C3;1.0;0535
-30C4;1.0;0536
-30C5;1.0;0537
-30C6;1.0;0538
-30C7;1.0;0539
-30C8;1.0;0540
-30C9;1.0;0541
-30CA;1.0;0542
-30CB;1.0;0543
-30CC;1.0;0544
-30CD;1.0;0545
-30CE;1.0;0546
-30CF;1.0;0547
-30D0;1.0;0548
-30D1;1.0;0549
-30D2;1.0;0550
-30D3;1.0;0551
-30D4;1.0;0552
-30D5;1.0;0553
-30D6;1.0;0554
-30D7;1.0;0555
-30D8;1.0;0556
-30D9;1.0;0557
-30DA;1.0;0558
-30DB;1.0;0559
-30DC;1.0;0560
-30DD;1.0;0561
-30DE;1.0;0562
-30DF;1.0;0563
-30E0;1.0;0564
-30E1;1.0;0565
-30E2;1.0;0566
-30E3;1.0;0567
-30E4;1.0;0568
-30E5;1.0;0569
-30E6;1.0;0570
-30E7;1.0;0571
-30E8;1.0;0572
-30E9;1.0;0573
-30EA;1.0;0574
-30EB;1.0;0575
-30EC;1.0;0576
-30ED;1.0;0577
-30EE;1.0;0578
-30EF;1.0;0579
-30F0;1.0;0580
-30F1;1.0;0581
-30F2;1.0;0582
-30F3;1.0;0583
-30F4;1.0;0584
-30F5;1.0;0585
-30F6;1.0;0586
-30FB;1.0;0106
-30FC;1.0;0128
-30FD;1.0;0119
-30FE;1.0;0120
-4E00;1.0;1676
-4E01;1.0;3590
-4E03;1.0;2823
-4E07;1.0;4392
-4E08;1.0;3070
-4E09;1.0;2716
-4E0A;1.0;3069
-4E0B;1.0;1828
-4E0D;1.0;4152
-4E0E;1.0;4531
-4E10;1.0;4802
-4E11;1.0;1715
-4E14;1.0;1978
-4E15;1.0;4803
-4E16;1.0;3204
-4E17;1.0;5034
-4E18;1.0;2154
-4E19;1.0;4226
-4E1E;1.0;3071
-4E21;1.0;4630
-4E26;1.0;4234
-4E2A;1.0;4804
-4E2D;1.0;3570
-4E31;1.0;4805
-4E32;1.0;2290
-4E36;1.0;4806
-4E38;1.0;2061
-4E39;1.0;3516
-4E3B;1.0;2871
-4E3C;1.0;4807
-4E3F;1.0;4808
-4E42;1.0;4809
-4E43;1.0;3921
-4E45;1.0;2155
-4E4B;1.0;3923
-4E4D;1.0;3867
-4E4E;1.0;2435
-4E4F;1.0;4319
-4E55;1.0;7341
-4E56;1.0;4810
-4E57;1.0;3072
-4E58;1.0;4811
-4E59;1.0;1821
-4E5D;1.0;2269
-4E5E;1.0;2480
-4E5F;1.0;4473
-4E62;1.0;5406
-4E71;1.0;4580
-4E73;1.0;3893
-4E7E;1.0;2005
-4E80;1.0;2121
-4E82;1.0;4812
-4E85;1.0;4813
-4E86;1.0;4627
-4E88;1.0;4529
-4E89;1.0;3372
-4E8A;1.0;4815
-4E8B;1.0;2786
-4E8C;1.0;3883
-4E8E;1.0;4818
-4E91;1.0;1730
-4E92;1.0;2463
-4E94;1.0;2462
-4E95;1.0;1670
-4E98;1.0;4743
-4E99;1.0;4742
-4E9B;1.0;2619
-4E9C;1.0;1601
-4E9E;1.0;4819
-4E9F;1.0;4820
-4EA0;1.0;4821
-4EA1;1.0;4320
-4EA2;1.0;4822
-4EA4;1.0;2482
-4EA5;1.0;1671
-4EA6;1.0;4382
-4EA8;1.0;2192
-4EAB;1.0;2193
-4EAC;1.0;2194
-4EAD;1.0;3666
-4EAE;1.0;4628
-4EB0;1.0;4823
-4EB3;1.0;4824
-4EB6;1.0;4825
-4EBA;1.0;3145
-4EC0;1.0;2926
-4EC1;1.0;3146
-4EC2;1.0;4830
-4EC4;1.0;4828
-4EC6;1.0;4829
-4EC7;1.0;2156
-4ECA;1.0;2603
-4ECB;1.0;1880
-4ECD;1.0;4827
-4ECE;1.0;4826
-4ECF;1.0;4209
-4ED4;1.0;2738
-4ED5;1.0;2737
-4ED6;1.0;3430
-4ED7;1.0;4831
-4ED8;1.0;4153
-4ED9;1.0;3271
-4EDE;1.0;4832
-4EDF;1.0;4834
-4EE3;1.0;3469
-4EE4;1.0;4665
-4EE5;1.0;1642
-4EED;1.0;4833
-4EEE;1.0;1830
-4EF0;1.0;2236
-4EF2;1.0;3571
-4EF6;1.0;2379
-4EF7;1.0;4835
-4EFB;1.0;3904
-4F01;1.0;2075
-4F09;1.0;4836
-4F0A;1.0;1643
-4F0D;1.0;2464
-4F0E;1.0;2076
-4F0F;1.0;4190
-4F10;1.0;4018
-4F11;1.0;2157
-4F1A;1.0;1881
-4F1C;1.0;4871
-4F1D;1.0;3733
-4F2F;1.0;3976
-4F30;1.0;4838
-4F34;1.0;4028
-4F36;1.0;4666
-4F38;1.0;3113
-4F3A;1.0;2739
-4F3C;1.0;2787
-4F3D;1.0;1832
-4F43;1.0;3649
-4F46;1.0;3502
-4F47;1.0;4842
-4F4D;1.0;1644
-4F4E;1.0;3667
-4F4F;1.0;2927
-4F50;1.0;2620
-4F51;1.0;4504
-4F53;1.0;3446
-4F55;1.0;1831
-4F57;1.0;4841
-4F59;1.0;4530
-4F5A;1.0;4837
-4F5B;1.0;4839
-4F5C;1.0;2678
-4F5D;1.0;4840
-4F5E;1.0;5304
-4F69;1.0;4848
-4F6F;1.0;4851
-4F70;1.0;4849
-4F73;1.0;1834
-4F75;1.0;4227
-4F76;1.0;4843
-4F7B;1.0;4847
-4F7C;1.0;2483
-4F7F;1.0;2740
-4F83;1.0;2006
-4F86;1.0;4852
-4F88;1.0;4844
-4F8B;1.0;4667
-4F8D;1.0;2788
-4F8F;1.0;4845
-4F91;1.0;4850
-4F96;1.0;4853
-4F98;1.0;4846
-4F9B;1.0;2201
-4F9D;1.0;1645
-4FA0;1.0;2202
-4FA1;1.0;1833
-4FAB;1.0;5305
-4FAD;1.0;4389
-4FAE;1.0;4178
-4FAF;1.0;2484
-4FB5;1.0;3115
-4FB6;1.0;4623
-4FBF;1.0;4256
-4FC2;1.0;2324
-4FC3;1.0;3405
-4FC4;1.0;1868
-4FCA;1.0;2951
-4FCE;1.0;4857
-4FD0;1.0;4862
-4FD1;1.0;4860
-4FD4;1.0;4855
-4FD7;1.0;3415
-4FD8;1.0;4858
-4FDA;1.0;4861
-4FDB;1.0;4859
-4FDD;1.0;4261
-4FDF;1.0;4856
-4FE1;1.0;3114
-4FE3;1.0;4383
-4FE4;1.0;4863
-4FE5;1.0;4864
-4FEE;1.0;2904
-4FEF;1.0;4877
-4FF3;1.0;3948
-4FF5;1.0;4122
-4FF6;1.0;4872
-4FF8;1.0;4280
-4FFA;1.0;1822
-4FFE;1.0;4876
-5005;1.0;4870
-5006;1.0;4879
-5009;1.0;3350
-500B;1.0;2436
-500D;1.0;3960
-500F;1.0;6439
-5011;1.0;4878
-5012;1.0;3761
-5014;1.0;4867
-5016;1.0;2486
-5019;1.0;2485
-501A;1.0;4865
-501F;1.0;2858
-5021;1.0;4873
-5023;1.0;4279
-5024;1.0;3545
-5025;1.0;4869
-5026;1.0;2381
-5028;1.0;4866
-5029;1.0;4874
-502A;1.0;4868
-502B;1.0;4649
-502C;1.0;4875
-502D;1.0;4733
-5036;1.0;2270
-5039;1.0;2380
-5043;1.0;4880
-5047;1.0;4881
-5048;1.0;4885
-5049;1.0;1646
-504F;1.0;4248
-5050;1.0;4884
-5055;1.0;4883
-5056;1.0;4887
-505A;1.0;4886
-505C;1.0;3668
-5065;1.0;2382
-506C;1.0;4888
-5072;1.0;2837
-5074;1.0;3406
-5075;1.0;3669
-5076;1.0;2286
-5078;1.0;4889
-507D;1.0;2122
-5080;1.0;4890
-5085;1.0;4892
-508D;1.0;4321
-5091;1.0;2370
-5098;1.0;2717
-5099;1.0;4087
-509A;1.0;4891
-50AC;1.0;2637
-50AD;1.0;4535
-50B2;1.0;4894
-50B3;1.0;4903
-50B4;1.0;4893
-50B5;1.0;2636
-50B7;1.0;2993
-50BE;1.0;2325
-50C2;1.0;4904
-50C5;1.0;2247
-50C9;1.0;4901
-50CA;1.0;4902
-50CD;1.0;3815
-50CF;1.0;3392
-50D1;1.0;2203
-50D5;1.0;4345
-50D6;1.0;4905
-50DA;1.0;4629
-50DE;1.0;4906
-50E3;1.0;4909
-50E5;1.0;4907
-50E7;1.0;3346
-50ED;1.0;4908
-50EE;1.0;4910
-50F5;1.0;4912
-50F9;1.0;4911
-50FB;1.0;4240
-5100;1.0;2123
-5101;1.0;4914
-5102;1.0;4915
-5104;1.0;1815
-5109;1.0;4913
-5112;1.0;2884
-5114;1.0;4918
-5115;1.0;4917
-5116;1.0;4916
-5118;1.0;4854
-511A;1.0;4919
-511F;1.0;2994
-5121;1.0;4920
-512A;1.0;4505
-5132;1.0;4457
-5137;1.0;4922
-513A;1.0;4921
-513B;1.0;4924
-513C;1.0;4923
-513F;1.0;4925
-5140;1.0;4926
-5141;1.0;1684
-5143;1.0;2421
-5144;1.0;2327
-5145;1.0;2928
-5146;1.0;3591
-5147;1.0;2204
-5148;1.0;3272
-5149;1.0;2487
-514B;1.0;2578
-514C;1.0;4928
-514D;1.0;4440
-514E;1.0;3738
-5150;1.0;2789
-5152;1.0;4927
-5154;1.0;4929
-515A;1.0;3762
-515C;1.0;1985
-5162;1.0;4930
-5165;1.0;3894
-5168;1.0;3320
-5169;1.0;4932
-516A;1.0;4933
-516B;1.0;4012
-516C;1.0;2488
-516D;1.0;4727
-516E;1.0;4934
-5171;1.0;2206
-5175;1.0;4228
-5176;1.0;3422
-5177;1.0;2281
-5178;1.0;3721
-517C;1.0;2383
-5180;1.0;4935
-5182;1.0;4936
-5185;1.0;3866
-5186;1.0;1763
-5189;1.0;4939
-518A;1.0;2693
-518C;1.0;4938
-518D;1.0;2638
-518F;1.0;4940
-5190;1.0;7078
-5191;1.0;4941
-5192;1.0;4333
-5193;1.0;4942
-5195;1.0;4943
-5196;1.0;4944
-5197;1.0;3073
-5199;1.0;2844
-51A0;1.0;2007
-51A2;1.0;4947
-51A4;1.0;4945
-51A5;1.0;4429
-51A6;1.0;4946
-51A8;1.0;4158
-51A9;1.0;4948
-51AA;1.0;4949
-51AB;1.0;4950
-51AC;1.0;3763
-51B0;1.0;4954
-51B1;1.0;4952
-51B2;1.0;4953
-51B3;1.0;4951
-51B4;1.0;2667
-51B5;1.0;4955
-51B6;1.0;4474
-51B7;1.0;4668
-51BD;1.0;4956
-51C4;1.0;3208
-51C5;1.0;4957
-51C6;1.0;2958
-51C9;1.0;4958
-51CB;1.0;3592
-51CC;1.0;4631
-51CD;1.0;3764
-51D6;1.0;5037
-51DB;1.0;4959
-51DC;1.0;8405
-51DD;1.0;2237
-51E0;1.0;4960
-51E1;1.0;4362
-51E6;1.0;2972
-51E7;1.0;3492
-51E9;1.0;4962
-51EA;1.0;3868
-51ED;1.0;4963
-51F0;1.0;4964
-51F1;1.0;1914
-51F5;1.0;4965
-51F6;1.0;2207
-51F8;1.0;3844
-51F9;1.0;1790
-51FA;1.0;2948
-51FD;1.0;4001
-51FE;1.0;4966
-5200;1.0;3765
-5203;1.0;3147
-5204;1.0;4967
-5206;1.0;4212
-5207;1.0;3258
-5208;1.0;2002
-520A;1.0;2009
-520B;1.0;4968
-520E;1.0;4970
-5211;1.0;2326
-5214;1.0;4969
-5217;1.0;4683
-521D;1.0;2973
-5224;1.0;4029
-5225;1.0;4244
-5227;1.0;4971
-5229;1.0;4588
-522A;1.0;4972
-522E;1.0;4973
-5230;1.0;3794
-5233;1.0;4974
-5236;1.0;3209
-5237;1.0;2694
-5238;1.0;2384
-5239;1.0;4975
-523A;1.0;2741
-523B;1.0;2579
-5243;1.0;3670
-5244;1.0;4977
-5247;1.0;3407
-524A;1.0;2679
-524B;1.0;4978
-524C;1.0;4979
-524D;1.0;3316
-524F;1.0;4976
-5254;1.0;4981
-5256;1.0;4322
-525B;1.0;2568
-525E;1.0;4980
-5263;1.0;2385
-5264;1.0;2662
-5265;1.0;3977
-5269;1.0;4984
-526A;1.0;4982
-526F;1.0;4191
-5270;1.0;3074
-5271;1.0;4991
-5272;1.0;1968
-5273;1.0;4985
-5274;1.0;4983
-5275;1.0;3347
-527D;1.0;4987
-527F;1.0;4986
-5283;1.0;1936
-5287;1.0;2364
-5288;1.0;4992
-5289;1.0;4613
-528D;1.0;4988
-5291;1.0;4993
-5292;1.0;4990
-5294;1.0;4989
-529B;1.0;4647
-529F;1.0;2489
-52A0;1.0;1835
-52A3;1.0;4684
-52A9;1.0;2985
-52AA;1.0;3756
-52AB;1.0;2569
-52AC;1.0;5002
-52AD;1.0;5003
-52B1;1.0;4669
-52B4;1.0;4711
-52B5;1.0;5005
-52B9;1.0;2490
-52BC;1.0;5004
-52BE;1.0;1915
-52C1;1.0;5006
-52C3;1.0;4354
-52C5;1.0;3628
-52C7;1.0;4506
-52C9;1.0;4257
-52CD;1.0;5007
-52D2;1.0;8053
-52D5;1.0;3816
-52D7;1.0;5008
-52D8;1.0;2010
-52D9;1.0;4419
-52DD;1.0;3001
-52DE;1.0;5009
-52DF;1.0;4271
-52E0;1.0;5013
-52E2;1.0;3210
-52E3;1.0;5010
-52E4;1.0;2248
-52E6;1.0;5011
-52E7;1.0;2011
-52F2;1.0;2314
-52F3;1.0;5014
-52F5;1.0;5015
-52F8;1.0;5016
-52F9;1.0;5017
-52FA;1.0;2859
-52FE;1.0;2491
-52FF;1.0;4462
-5301;1.0;4472
-5302;1.0;3887
-5305;1.0;4281
-5306;1.0;5018
-5308;1.0;5019
-530D;1.0;5021
-530F;1.0;5023
-5310;1.0;5022
-5315;1.0;5024
-5316;1.0;1829
-5317;1.0;4344
-5319;1.0;2692
-531A;1.0;5025
-531D;1.0;3357
-5320;1.0;3002
-5321;1.0;2209
-5323;1.0;5026
-532A;1.0;4059
-532F;1.0;5027
-5331;1.0;5028
-5333;1.0;5029
-5338;1.0;5030
-5339;1.0;4104
-533A;1.0;2272
-533B;1.0;1669
-533F;1.0;3831
-5340;1.0;5031
-5341;1.0;2929
-5343;1.0;3273
-5345;1.0;5033
-5346;1.0;5032
-5347;1.0;3003
-5348;1.0;2465
-5349;1.0;5035
-534A;1.0;4030
-534D;1.0;5036
-5351;1.0;4060
-5352;1.0;3420
-5353;1.0;3478
-5354;1.0;2208
-5357;1.0;3878
-5358;1.0;3517
-535A;1.0;3978
-535C;1.0;4346
-535E;1.0;5038
-5360;1.0;3274
-5366;1.0;2321
-5369;1.0;5039
-536E;1.0;5040
-536F;1.0;1712
-5370;1.0;1685
-5371;1.0;2077
-5373;1.0;3408
-5374;1.0;2149
-5375;1.0;4581
-5377;1.0;5043
-5378;1.0;1823
-537B;1.0;5042
-537F;1.0;2210
-5382;1.0;5044
-5384;1.0;4481
-5396;1.0;5045
-5398;1.0;4650
-539A;1.0;2492
-539F;1.0;2422
-53A0;1.0;5046
-53A5;1.0;5048
-53A6;1.0;5047
-53A8;1.0;3163
-53A9;1.0;1725
-53AD;1.0;1762
-53AE;1.0;5049
-53B0;1.0;5050
-53B3;1.0;2423
-53B6;1.0;5051
-53BB;1.0;2178
-53C2;1.0;2718
-53C3;1.0;5052
-53C8;1.0;4384
-53C9;1.0;2621
-53CA;1.0;2158
-53CB;1.0;4507
-53CC;1.0;3348
-53CD;1.0;4031
-53CE;1.0;2893
-53D4;1.0;2939
-53D6;1.0;2872
-53D7;1.0;2885
-53D9;1.0;2986
-53DB;1.0;4032
-53DF;1.0;5055
-53E1;1.0;1735
-53E2;1.0;3349
-53E3;1.0;2493
-53E4;1.0;2437
-53E5;1.0;2271
-53E8;1.0;5059
-53E9;1.0;3501
-53EA;1.0;3494
-53EB;1.0;2211
-53EC;1.0;3004
-53ED;1.0;5060
-53EE;1.0;5058
-53EF;1.0;1836
-53F0;1.0;3470
-53F1;1.0;2824
-53F2;1.0;2743
-53F3;1.0;1706
-53F6;1.0;1980
-53F7;1.0;2570
-53F8;1.0;2742
-53FA;1.0;5061
-5401;1.0;5062
-5403;1.0;2141
-5404;1.0;1938
-5408;1.0;2571
-5409;1.0;2140
-540A;1.0;3663
-540B;1.0;1705
-540C;1.0;3817
-540D;1.0;4430
-540E;1.0;2501
-540F;1.0;4589
-5410;1.0;3739
-5411;1.0;2494
-541B;1.0;2315
-541D;1.0;5071
-541F;1.0;2267
-5420;1.0;4342
-5426;1.0;4061
-5429;1.0;5070
-542B;1.0;2062
-542C;1.0;5065
-542D;1.0;5066
-542E;1.0;5068
-5436;1.0;5069
-5438;1.0;2159
-5439;1.0;3165
-543B;1.0;4213
-543C;1.0;5067
-543D;1.0;5063
-543E;1.0;2467
-5440;1.0;5064
-5442;1.0;4704
-5446;1.0;4282
-5448;1.0;3672
-5449;1.0;2466
-544A;1.0;2580
-544E;1.0;5072
-5451;1.0;3861
-545F;1.0;5076
-5468;1.0;2894
-546A;1.0;2886
-5470;1.0;5079
-5471;1.0;5077
-5473;1.0;4403
-5475;1.0;5074
-5476;1.0;5083
-5477;1.0;5078
-547B;1.0;5081
-547C;1.0;2438
-547D;1.0;4431
-5480;1.0;5082
-5484;1.0;5084
-5486;1.0;5086
-548B;1.0;2680
-548C;1.0;4734
-548E;1.0;5075
-548F;1.0;5073
-5490;1.0;5085
-5492;1.0;5080
-54A2;1.0;5088
-54A4;1.0;5103
-54A5;1.0;5090
-54A8;1.0;5094
-54AB;1.0;5101
-54AC;1.0;5091
-54AF;1.0;5130
-54B2;1.0;2673
-54B3;1.0;1917
-54B8;1.0;5089
-54BC;1.0;5105
-54BD;1.0;1686
-54BE;1.0;5104
-54C0;1.0;1605
-54C1;1.0;4142
-54C2;1.0;5102
-54C4;1.0;5092
-54C7;1.0;5087
-54C8;1.0;5093
-54C9;1.0;2640
-54D8;1.0;5106
-54E1;1.0;1687
-54E2;1.0;5115
-54E5;1.0;5107
-54E6;1.0;5108
-54E8;1.0;3005
-54E9;1.0;4373
-54ED;1.0;5113
-54EE;1.0;5112
-54F2;1.0;3715
-54FA;1.0;5114
-54FD;1.0;5111
-5504;1.0;1720
-5506;1.0;2622
-5507;1.0;3116
-550F;1.0;5109
-5510;1.0;3766
-5514;1.0;5110
-5516;1.0;1602
-552E;1.0;5120
-552F;1.0;4503
-5531;1.0;3007
-5533;1.0;5126
-5538;1.0;5125
-5539;1.0;5116
-553E;1.0;3435
-5540;1.0;5117
-5544;1.0;3479
-5545;1.0;5122
-5546;1.0;3006
-554C;1.0;5119
-554F;1.0;4468
-5553;1.0;2328
-5556;1.0;5123
-5557;1.0;5124
-555C;1.0;5121
-555D;1.0;5127
-5563;1.0;5118
-557B;1.0;5133
-557C;1.0;5138
-557E;1.0;5134
-5580;1.0;5129
-5583;1.0;5139
-5584;1.0;3317
-5587;1.0;5141
-5589;1.0;2502
-558A;1.0;5131
-558B;1.0;3593
-5598;1.0;5135
-5599;1.0;5128
-559A;1.0;2013
-559C;1.0;2078
-559D;1.0;1969
-559E;1.0;5136
-559F;1.0;5132
-55A7;1.0;2386
-55A8;1.0;5142
-55A9;1.0;5140
-55AA;1.0;3351
-55AB;1.0;2142
-55AC;1.0;2212
-55AE;1.0;5137
-55B0;1.0;2284
-55B6;1.0;1736
-55C4;1.0;5146
-55C5;1.0;5144
-55C7;1.0;5207
-55D4;1.0;5149
-55DA;1.0;5143
-55DC;1.0;5147
-55DF;1.0;5145
-55E3;1.0;2744
-55E4;1.0;5148
-55F7;1.0;5151
-55F9;1.0;5156
-55FD;1.0;5154
-55FE;1.0;5153
-5606;1.0;3518
-5609;1.0;1837
-5614;1.0;5150
-5616;1.0;5152
-5617;1.0;3008
-5618;1.0;1719
-561B;1.0;5155
-5629;1.0;1862
-562F;1.0;5166
-5631;1.0;3092
-5632;1.0;5162
-5634;1.0;5160
-5636;1.0;5161
-5638;1.0;5163
-5642;1.0;1729
-564C;1.0;3325
-564E;1.0;5157
-5650;1.0;5158
-565B;1.0;1990
-5664;1.0;5165
-5668;1.0;2079
-566A;1.0;5168
-566B;1.0;5164
-566C;1.0;5167
-5674;1.0;4214
-5678;1.0;3853
-567A;1.0;4024
-5680;1.0;5170
-5686;1.0;5169
-5687;1.0;1937
-568A;1.0;5171
-568F;1.0;5174
-5694;1.0;5173
-56A0;1.0;5172
-56A2;1.0;3925
-56A5;1.0;5175
-56AE;1.0;5176
-56B4;1.0;5178
-56B6;1.0;5177
-56BC;1.0;5180
-56C0;1.0;5183
-56C1;1.0;5181
-56C2;1.0;5179
-56C3;1.0;5182
-56C8;1.0;5184
-56CE;1.0;5185
-56D1;1.0;5186
-56D3;1.0;5187
-56D7;1.0;5188
-56D8;1.0;4937
-56DA;1.0;2892
-56DB;1.0;2745
-56DE;1.0;1883
-56E0;1.0;1688
-56E3;1.0;3536
-56EE;1.0;5189
-56F0;1.0;2604
-56F2;1.0;1647
-56F3;1.0;3162
-56F9;1.0;5190
-56FA;1.0;2439
-56FD;1.0;2581
-56FF;1.0;5192
-5700;1.0;5191
-5703;1.0;4264
-5704;1.0;5193
-5708;1.0;5201
-5709;1.0;5194
-570B;1.0;5202
-570D;1.0;5203
-570F;1.0;2387
-5712;1.0;1764
-5713;1.0;5204
-5716;1.0;5206
-5718;1.0;5205
-571C;1.0;5208
-571F;1.0;3758
-5726;1.0;5209
-5727;1.0;1621
-5728;1.0;2663
-572D;1.0;2329
-5730;1.0;3547
-5737;1.0;5210
-5738;1.0;5211
-573B;1.0;5213
-5740;1.0;5214
-5742;1.0;2668
-5747;1.0;2249
-574A;1.0;4323
-574E;1.0;5212
-574F;1.0;5215
-5750;1.0;2633
-5751;1.0;2503
-5761;1.0;5219
-5764;1.0;2605
-5766;1.0;3519
-5769;1.0;5216
-576A;1.0;3658
-577F;1.0;5220
-5782;1.0;3166
-5788;1.0;5218
-5789;1.0;5221
-578B;1.0;2331
-5793;1.0;5222
-57A0;1.0;5223
-57A2;1.0;2504
-57A3;1.0;1932
-57A4;1.0;5225
-57AA;1.0;5226
-57B0;1.0;5227
-57B3;1.0;5224
-57C0;1.0;5217
-57C3;1.0;5228
-57C6;1.0;5229
-57CB;1.0;4368
-57CE;1.0;3075
-57D2;1.0;5231
-57D3;1.0;5232
-57D4;1.0;5230
-57D6;1.0;5234
-57DC;1.0;3924
-57DF;1.0;1672
-57E0;1.0;4154
-57E3;1.0;5235
-57F4;1.0;3093
-57F7;1.0;2825
-57F9;1.0;3961
-57FA;1.0;2080
-57FC;1.0;2675
-5800;1.0;4357
-5802;1.0;3818
-5805;1.0;2388
-5806;1.0;3447
-580A;1.0;5233
-580B;1.0;5236
-5815;1.0;3436
-5819;1.0;5237
-581D;1.0;5238
-5821;1.0;5240
-5824;1.0;3673
-582A;1.0;2014
-582F;1.0;8401
-5830;1.0;1765
-5831;1.0;4283
-5834;1.0;3076
-5835;1.0;3740
-583A;1.0;2670
-583D;1.0;5246
-5840;1.0;4229
-5841;1.0;4661
-584A;1.0;1884
-584B;1.0;5242
-5851;1.0;3326
-5852;1.0;5245
-5854;1.0;3767
-5857;1.0;3741
-5858;1.0;3768
-5859;1.0;4025
-585A;1.0;3645
-585E;1.0;2641
-5862;1.0;5241
-5869;1.0;1786
-586B;1.0;3722
-5870;1.0;5243
-5872;1.0;5239
-5875;1.0;3148
-5879;1.0;5247
-587E;1.0;2946
-5883;1.0;2213
-5885;1.0;5248
-5893;1.0;4272
-5897;1.0;3393
-589C;1.0;3638
-589F;1.0;5250
-58A8;1.0;4347
-58AB;1.0;5251
-58AE;1.0;5256
-58B3;1.0;4215
-58B8;1.0;5255
-58B9;1.0;5249
-58BA;1.0;5252
-58BB;1.0;5254
-58BE;1.0;2606
-58C1;1.0;4241
-58C5;1.0;5257
-58C7;1.0;3537
-58CA;1.0;1885
-58CC;1.0;3077
-58D1;1.0;5259
-58D3;1.0;5258
-58D5;1.0;2572
-58D7;1.0;5260
-58D8;1.0;5262
-58D9;1.0;5261
-58DC;1.0;5264
-58DE;1.0;5253
-58DF;1.0;5266
-58E4;1.0;5265
-58E5;1.0;5263
-58EB;1.0;2746
-58EC;1.0;3149
-58EE;1.0;3352
-58EF;1.0;5267
-58F0;1.0;3228
-58F1;1.0;1677
-58F2;1.0;3968
-58F7;1.0;3659
-58F9;1.0;5269
-58FA;1.0;5268
-58FB;1.0;5270
-58FC;1.0;5271
-58FD;1.0;5272
-5902;1.0;5273
-5909;1.0;4249
-590A;1.0;5274
-590F;1.0;1838
-5910;1.0;5275
-5915;1.0;4528
-5916;1.0;1916
-5918;1.0;5041
-5919;1.0;2940
-591A;1.0;3431
-591B;1.0;5276
-591C;1.0;4475
-5922;1.0;4420
-5925;1.0;5278
-5927;1.0;3471
-5929;1.0;3723
-592A;1.0;3432
-592B;1.0;4155
-592C;1.0;5279
-592D;1.0;5280
-592E;1.0;1791
-5931;1.0;2826
-5932;1.0;5281
-5937;1.0;1648
-5938;1.0;5282
-593E;1.0;5283
-5944;1.0;1766
-5947;1.0;2081
-5948;1.0;3864
-5949;1.0;4284
-594E;1.0;5287
-594F;1.0;3353
-5950;1.0;5286
-5951;1.0;2332
-5954;1.0;4359
-5955;1.0;5285
-5957;1.0;3769
-5958;1.0;5289
-595A;1.0;5288
-5960;1.0;5291
-5962;1.0;5290
-5965;1.0;1792
-5967;1.0;5292
-5968;1.0;3009
-5969;1.0;5294
-596A;1.0;3505
-596C;1.0;5293
-596E;1.0;4219
-5973;1.0;2987
-5974;1.0;3759
-5978;1.0;5301
-597D;1.0;2505
-5981;1.0;5302
-5982;1.0;3901
-5983;1.0;4062
-5984;1.0;4449
-598A;1.0;3905
-598D;1.0;5311
-5993;1.0;2124
-5996;1.0;4537
-5999;1.0;4415
-599B;1.0;5412
-599D;1.0;5303
-59A3;1.0;5306
-59A5;1.0;3437
-59A8;1.0;4324
-59AC;1.0;3742
-59B2;1.0;5307
-59B9;1.0;4369
-59BB;1.0;2642
-59BE;1.0;3010
-59C6;1.0;5308
-59C9;1.0;2748
-59CB;1.0;2747
-59D0;1.0;1625
-59D1;1.0;2440
-59D3;1.0;3211
-59D4;1.0;1649
-59D9;1.0;5312
-59DA;1.0;5313
-59DC;1.0;5310
-59E5;1.0;1724
-59E6;1.0;2015
-59E8;1.0;5309
-59EA;1.0;4437
-59EB;1.0;4117
-59F6;1.0;1608
-59FB;1.0;1689
-59FF;1.0;2749
-5A01;1.0;1650
-5A03;1.0;1603
-5A09;1.0;5318
-5A11;1.0;5316
-5A18;1.0;4428
-5A1A;1.0;5319
-5A1C;1.0;5317
-5A1F;1.0;5315
-5A20;1.0;3117
-5A25;1.0;5314
-5A29;1.0;4258
-5A2F;1.0;2468
-5A35;1.0;5323
-5A36;1.0;5324
-5A3C;1.0;3011
-5A40;1.0;5320
-5A41;1.0;4712
-5A46;1.0;3944
-5A49;1.0;5322
-5A5A;1.0;2607
-5A62;1.0;5325
-5A66;1.0;4156
-5A6A;1.0;5326
-5A6C;1.0;5321
-5A7F;1.0;4427
-5A92;1.0;3962
-5A9A;1.0;5327
-5A9B;1.0;4118
-5ABC;1.0;5328
-5ABD;1.0;5332
-5ABE;1.0;5329
-5AC1;1.0;1839
-5AC2;1.0;5331
-5AC9;1.0;2827
-5ACB;1.0;5330
-5ACC;1.0;2389
-5AD0;1.0;5344
-5AD6;1.0;5337
-5AD7;1.0;5334
-5AE1;1.0;3568
-5AE3;1.0;5333
-5AE6;1.0;5335
-5AE9;1.0;5336
-5AFA;1.0;5338
-5AFB;1.0;5339
-5B09;1.0;2082
-5B0B;1.0;5341
-5B0C;1.0;5340
-5B16;1.0;5342
-5B22;1.0;3078
-5B2A;1.0;5345
-5B2C;1.0;3660
-5B30;1.0;1737
-5B32;1.0;5343
-5B36;1.0;5346
-5B3E;1.0;5347
-5B40;1.0;5350
-5B43;1.0;5348
-5B45;1.0;5349
-5B50;1.0;2750
-5B51;1.0;5351
-5B54;1.0;2506
-5B55;1.0;5352
-5B57;1.0;2790
-5B58;1.0;3424
-5B5A;1.0;5353
-5B5B;1.0;5354
-5B5C;1.0;2758
-5B5D;1.0;2507
-5B5F;1.0;4450
-5B63;1.0;2108
-5B64;1.0;2441
-5B65;1.0;5355
-5B66;1.0;1956
-5B69;1.0;5356
-5B6B;1.0;3425
-5B70;1.0;5357
-5B71;1.0;5403
-5B73;1.0;5358
-5B75;1.0;5359
-5B78;1.0;5360
-5B7A;1.0;5362
-5B80;1.0;5363
-5B83;1.0;5364
-5B85;1.0;3480
-5B87;1.0;1707
-5B88;1.0;2873
-5B89;1.0;1634
-5B8B;1.0;3355
-5B8C;1.0;2016
-5B8D;1.0;2821
-5B8F;1.0;2508
-5B95;1.0;3770
-5B97;1.0;2901
-5B98;1.0;2017
-5B99;1.0;3572
-5B9A;1.0;3674
-5B9B;1.0;1624
-5B9C;1.0;2125
-5B9D;1.0;4285
-5B9F;1.0;2834
-5BA2;1.0;2150
-5BA3;1.0;3275
-5BA4;1.0;2828
-5BA5;1.0;4508
-5BA6;1.0;5365
-5BAE;1.0;2160
-5BB0;1.0;2643
-5BB3;1.0;1918
-5BB4;1.0;1767
-5BB5;1.0;3012
-5BB6;1.0;1840
-5BB8;1.0;5366
-5BB9;1.0;4538
-5BBF;1.0;2941
-5BC2;1.0;2868
-5BC3;1.0;5367
-5BC4;1.0;2083
-5BC5;1.0;3850
-5BC6;1.0;4409
-5BC7;1.0;5368
-5BC9;1.0;5369
-5BCC;1.0;4157
-5BD0;1.0;5371
-5BD2;1.0;2008
-5BD3;1.0;2287
-5BD4;1.0;5370
-5BDB;1.0;2018
-5BDD;1.0;3118
-5BDE;1.0;5375
-5BDF;1.0;2701
-5BE1;1.0;1841
-5BE2;1.0;5374
-5BE4;1.0;5372
-5BE5;1.0;5376
-5BE6;1.0;5373
-5BE7;1.0;3911
-5BE8;1.0;6045
-5BE9;1.0;3119
-5BEB;1.0;5377
-5BEE;1.0;4632
-5BF0;1.0;5378
-5BF3;1.0;5380
-5BF5;1.0;3594
-5BF6;1.0;5379
-5BF8;1.0;3203
-5BFA;1.0;2791
-5BFE;1.0;3448
-5BFF;1.0;2887
-5C01;1.0;4185
-5C02;1.0;3276
-5C04;1.0;2845
-5C05;1.0;5381
-5C06;1.0;3013
-5C07;1.0;5382
-5C08;1.0;5383
-5C09;1.0;1651
-5C0A;1.0;3426
-5C0B;1.0;3150
-5C0D;1.0;5384
-5C0E;1.0;3819
-5C0F;1.0;3014
-5C11;1.0;3015
-5C13;1.0;5385
-5C16;1.0;3277
-5C1A;1.0;3016
-5C20;1.0;5386
-5C22;1.0;5387
-5C24;1.0;4464
-5C28;1.0;5388
-5C2D;1.0;2238
-5C31;1.0;2902
-5C38;1.0;5389
-5C39;1.0;5390
-5C3A;1.0;2860
-5C3B;1.0;3112
-5C3C;1.0;3884
-5C3D;1.0;3152
-5C3E;1.0;4088
-5C3F;1.0;3902
-5C40;1.0;2241
-5C41;1.0;5391
-5C45;1.0;2179
-5C46;1.0;5392
-5C48;1.0;2294
-5C4A;1.0;3847
-5C4B;1.0;1816
-5C4D;1.0;2751
-5C4E;1.0;5393
-5C4F;1.0;5402
-5C50;1.0;5401
-5C51;1.0;2293
-5C53;1.0;5394
-5C55;1.0;3724
-5C5E;1.0;3416
-5C60;1.0;3743
-5C61;1.0;2840
-5C64;1.0;3356
-5C65;1.0;4590
-5C6C;1.0;5404
-5C6E;1.0;5405
-5C6F;1.0;3854
-5C71;1.0;2719
-5C76;1.0;5407
-5C79;1.0;5408
-5C8C;1.0;5409
-5C90;1.0;2084
-5C91;1.0;5410
-5C94;1.0;5411
-5CA1;1.0;1812
-5CA8;1.0;3327
-5CA9;1.0;2068
-5CAB;1.0;5413
-5CAC;1.0;4408
-5CB1;1.0;3450
-5CB3;1.0;1957
-5CB6;1.0;5415
-5CB7;1.0;5417
-5CB8;1.0;2063
-5CBB;1.0;5414
-5CBC;1.0;5416
-5CBE;1.0;5419
-5CC5;1.0;5418
-5CC7;1.0;5420
-5CD9;1.0;5421
-5CE0;1.0;3829
-5CE1;1.0;2214
-5CE8;1.0;1869
-5CE9;1.0;5422
-5CEA;1.0;5427
-5CED;1.0;5425
-5CEF;1.0;4287
-5CF0;1.0;4286
-5CF6;1.0;3771
-5CFA;1.0;5424
-5CFB;1.0;2952
-5CFD;1.0;5423
-5D07;1.0;3182
-5D0B;1.0;5428
-5D0E;1.0;2674
-5D11;1.0;5434
-5D14;1.0;5435
-5D15;1.0;5429
-5D16;1.0;1919
-5D17;1.0;5430
-5D18;1.0;5439
-5D19;1.0;5438
-5D1A;1.0;5437
-5D1B;1.0;5433
-5D1F;1.0;5432
-5D22;1.0;5436
-5D29;1.0;4288
-5D4B;1.0;5443
-5D4C;1.0;5440
-5D4E;1.0;5442
-5D50;1.0;4582
-5D52;1.0;5441
-5D5C;1.0;5431
-5D69;1.0;3183
-5D6C;1.0;5444
-5D6F;1.0;2623
-5D73;1.0;5445
-5D76;1.0;5446
-5D82;1.0;5449
-5D84;1.0;5448
-5D87;1.0;5447
-5D8B;1.0;3772
-5D8C;1.0;5426
-5D90;1.0;5455
-5D9D;1.0;5451
-5DA2;1.0;5450
-5DAC;1.0;5452
-5DAE;1.0;5453
-5DB7;1.0;5456
-5DBA;1.0;4670
-5DBC;1.0;5457
-5DBD;1.0;5454
-5DC9;1.0;5458
-5DCC;1.0;2064
-5DCD;1.0;5459
-5DD2;1.0;5461
-5DD3;1.0;5460
-5DD6;1.0;5462
-5DDB;1.0;5463
-5DDD;1.0;3278
-5DDE;1.0;2903
-5DE1;1.0;2968
-5DE3;1.0;3367
-5DE5;1.0;2509
-5DE6;1.0;2624
-5DE7;1.0;2510
-5DE8;1.0;2180
-5DEB;1.0;5464
-5DEE;1.0;2625
-5DF1;1.0;2442
-5DF2;1.0;5465
-5DF3;1.0;4406
-5DF4;1.0;3935
-5DF5;1.0;5466
-5DF7;1.0;2511
-5DFB;1.0;2012
-5DFD;1.0;3507
-5DFE;1.0;2250
-5E02;1.0;2752
-5E03;1.0;4159
-5E06;1.0;4033
-5E0B;1.0;5467
-5E0C;1.0;2085
-5E11;1.0;5470
-5E16;1.0;3601
-5E19;1.0;5469
-5E1A;1.0;5468
-5E1B;1.0;5471
-5E1D;1.0;3675
-5E25;1.0;3167
-5E2B;1.0;2753
-5E2D;1.0;3242
-5E2F;1.0;3451
-5E30;1.0;2102
-5E33;1.0;3602
-5E36;1.0;5472
-5E37;1.0;5473
-5E38;1.0;3079
-5E3D;1.0;4325
-5E40;1.0;5476
-5E43;1.0;5475
-5E44;1.0;5474
-5E45;1.0;4193
-5E47;1.0;5483
-5E4C;1.0;4358
-5E4E;1.0;5477
-5E54;1.0;5479
-5E55;1.0;4375
-5E57;1.0;5478
-5E5F;1.0;5480
-5E61;1.0;4008
-5E62;1.0;5481
-5E63;1.0;4230
-5E64;1.0;5482
-5E72;1.0;2019
-5E73;1.0;4231
-5E74;1.0;3915
-5E75;1.0;5484
-5E76;1.0;5485
-5E78;1.0;2512
-5E79;1.0;2020
-5E7A;1.0;5486
-5E7B;1.0;2424
-5E7C;1.0;4536
-5E7D;1.0;4509
-5E7E;1.0;2086
-5E7F;1.0;5488
-5E81;1.0;3603
-5E83;1.0;2513
-5E84;1.0;3017
-5E87;1.0;4063
-5E8A;1.0;3018
-5E8F;1.0;2988
-5E95;1.0;3676
-5E96;1.0;4289
-5E97;1.0;3725
-5E9A;1.0;2514
-5E9C;1.0;4160
-5EA0;1.0;5489
-5EA6;1.0;3757
-5EA7;1.0;2634
-5EAB;1.0;2443
-5EAD;1.0;3677
-5EB5;1.0;1635
-5EB6;1.0;2978
-5EB7;1.0;2515
-5EB8;1.0;4539
-5EC1;1.0;5490
-5EC2;1.0;5491
-5EC3;1.0;3949
-5EC8;1.0;5492
-5EC9;1.0;4687
-5ECA;1.0;4713
-5ECF;1.0;5494
-5ED0;1.0;5493
-5ED3;1.0;1939
-5ED6;1.0;5501
-5EDA;1.0;5504
-5EDB;1.0;5505
-5EDD;1.0;5503
-5EDF;1.0;4132
-5EE0;1.0;3019
-5EE1;1.0;5507
-5EE2;1.0;5506
-5EE3;1.0;5502
-5EE8;1.0;5508
-5EE9;1.0;5509
-5EEC;1.0;5510
-5EF0;1.0;5513
-5EF1;1.0;5511
-5EF3;1.0;5512
-5EF4;1.0;5514
-5EF6;1.0;1768
-5EF7;1.0;3678
-5EF8;1.0;5515
-5EFA;1.0;2390
-5EFB;1.0;1886
-5EFC;1.0;3922
-5EFE;1.0;5516
-5EFF;1.0;3891
-5F01;1.0;4259
-5F03;1.0;5517
-5F04;1.0;4714
-5F09;1.0;5518
-5F0A;1.0;4232
-5F0B;1.0;5521
-5F0C;1.0;4801
-5F0D;1.0;4817
-5F0F;1.0;2816
-5F10;1.0;3885
-5F11;1.0;5522
-5F13;1.0;2161
-5F14;1.0;3604
-5F15;1.0;1690
-5F16;1.0;5523
-5F17;1.0;4206
-5F18;1.0;2516
-5F1B;1.0;3548
-5F1F;1.0;3679
-5F25;1.0;4479
-5F26;1.0;2425
-5F27;1.0;2444
-5F29;1.0;5524
-5F2D;1.0;5525
-5F2F;1.0;5531
-5F31;1.0;2869
-5F35;1.0;3605
-5F37;1.0;2215
-5F38;1.0;5526
-5F3C;1.0;4111
-5F3E;1.0;3538
-5F41;1.0;5527
-5F48;1.0;5528
-5F4A;1.0;2216
-5F4C;1.0;5529
-5F4E;1.0;5530
-5F51;1.0;5532
-5F53;1.0;3786
-5F56;1.0;5533
-5F57;1.0;5534
-5F59;1.0;5535
-5F5C;1.0;5520
-5F5D;1.0;5519
-5F61;1.0;5536
-5F62;1.0;2333
-5F66;1.0;4107
-5F69;1.0;2644
-5F6A;1.0;4123
-5F6B;1.0;3606
-5F6C;1.0;4143
-5F6D;1.0;5537
-5F70;1.0;3020
-5F71;1.0;1738
-5F73;1.0;5538
-5F77;1.0;5539
-5F79;1.0;4482
-5F7C;1.0;4064
-5F7F;1.0;5542
-5F80;1.0;1793
-5F81;1.0;3212
-5F82;1.0;5541
-5F83;1.0;5540
-5F84;1.0;2334
-5F85;1.0;3452
-5F87;1.0;5546
-5F88;1.0;5544
-5F8A;1.0;5543
-5F8B;1.0;4607
-5F8C;1.0;2469
-5F90;1.0;2989
-5F91;1.0;5545
-5F92;1.0;3744
-5F93;1.0;2930
-5F97;1.0;3832
-5F98;1.0;5549
-5F99;1.0;5548
-5F9E;1.0;5547
-5FA0;1.0;5550
-5FA1;1.0;2470
-5FA8;1.0;5551
-5FA9;1.0;4192
-5FAA;1.0;2959
-5FAD;1.0;5552
-5FAE;1.0;4089
-5FB3;1.0;3833
-5FB4;1.0;3607
-5FB9;1.0;3716
-5FBC;1.0;5553
-5FBD;1.0;2111
-5FC3;1.0;3120
-5FC5;1.0;4112
-5FCC;1.0;2087
-5FCD;1.0;3906
-5FD6;1.0;5554
-5FD7;1.0;2754
-5FD8;1.0;4326
-5FD9;1.0;4327
-5FDC;1.0;1794
-5FDD;1.0;5559
-5FE0;1.0;3573
-5FE4;1.0;5556
-5FEB;1.0;1887
-5FF0;1.0;5613
-5FF1;1.0;5558
-5FF5;1.0;3916
-5FF8;1.0;5557
-5FFB;1.0;5555
-5FFD;1.0;2590
-5FFF;1.0;5561
-600E;1.0;5567
-600F;1.0;5573
-6010;1.0;5565
-6012;1.0;3760
-6015;1.0;5570
-6016;1.0;4161
-6019;1.0;5564
-601B;1.0;5569
-601C;1.0;4671
-601D;1.0;2755
-6020;1.0;3453
-6021;1.0;5562
-6025;1.0;2162
-6026;1.0;5572
-6027;1.0;3213
-6028;1.0;1769
-6029;1.0;5566
-602A;1.0;1888
-602B;1.0;5571
-602F;1.0;2217
-6031;1.0;5568
-603A;1.0;5574
-6041;1.0;5576
-6042;1.0;5586
-6043;1.0;5584
-6046;1.0;5581
-604A;1.0;5580
-604B;1.0;4688
-604D;1.0;5582
-6050;1.0;2218
-6052;1.0;2517
-6055;1.0;2990
-6059;1.0;5589
-605A;1.0;5575
-605F;1.0;5579
-6060;1.0;5563
-6062;1.0;1890
-6063;1.0;5583
-6064;1.0;5585
-6065;1.0;3549
-6068;1.0;2608
-6069;1.0;1824
-606A;1.0;5577
-606B;1.0;5588
-606C;1.0;5587
-606D;1.0;2219
-606F;1.0;3409
-6070;1.0;1970
-6075;1.0;2335
-6077;1.0;5578
-6081;1.0;5590
-6083;1.0;5593
-6084;1.0;5601
-6089;1.0;2829
-608B;1.0;5607
-608C;1.0;3680
-608D;1.0;5591
-6092;1.0;5605
-6094;1.0;1889
-6096;1.0;5603
-6097;1.0;5604
-609A;1.0;5594
-609B;1.0;5602
-609F;1.0;2471
-60A0;1.0;4510
-60A3;1.0;2021
-60A6;1.0;1757
-60A7;1.0;5606
-60A9;1.0;3926
-60AA;1.0;1613
-60B2;1.0;4065
-60B3;1.0;5560
-60B4;1.0;5612
-60B5;1.0;5616
-60B6;1.0;4469
-60B8;1.0;5609
-60BC;1.0;3773
-60BD;1.0;5614
-60C5;1.0;3080
-60C6;1.0;5615
-60C7;1.0;3855
-60D1;1.0;4739
-60D3;1.0;5611
-60D8;1.0;5617
-60DA;1.0;2591
-60DC;1.0;3243
-60DF;1.0;1652
-60E0;1.0;5610
-60E1;1.0;5608
-60E3;1.0;3358
-60E7;1.0;5592
-60E8;1.0;2720
-60F0;1.0;3438
-60F1;1.0;5629
-60F3;1.0;3359
-60F4;1.0;5624
-60F6;1.0;5621
-60F7;1.0;5622
-60F9;1.0;2870
-60FA;1.0;5625
-60FB;1.0;5628
-6100;1.0;5623
-6101;1.0;2905
-6103;1.0;5626
-6106;1.0;5620
-6108;1.0;4492
-6109;1.0;4491
-610D;1.0;5630
-610E;1.0;5631
-610F;1.0;1653
-6115;1.0;5619
-611A;1.0;2282
-611B;1.0;1606
-611F;1.0;2022
-6121;1.0;5627
-6127;1.0;5635
-6128;1.0;5634
-612C;1.0;5639
-6134;1.0;5640
-613C;1.0;5638
-613D;1.0;5641
-613E;1.0;5633
-613F;1.0;5637
-6142;1.0;5642
-6144;1.0;5643
-6147;1.0;5632
-6148;1.0;2792
-614A;1.0;5636
-614B;1.0;3454
-614C;1.0;2518
-614D;1.0;5618
-614E;1.0;3121
-6153;1.0;5656
-6155;1.0;4273
-6158;1.0;5646
-6159;1.0;5647
-615A;1.0;5648
-615D;1.0;5655
-615F;1.0;5654
-6162;1.0;4393
-6163;1.0;2023
-6165;1.0;5652
-6167;1.0;2337
-6168;1.0;1920
-616B;1.0;5649
-616E;1.0;4624
-616F;1.0;5651
-6170;1.0;1654
-6171;1.0;5653
-6173;1.0;5644
-6174;1.0;5650
-6175;1.0;5657
-6176;1.0;2336
-6177;1.0;5645
-617E;1.0;4561
-6182;1.0;4511
-6187;1.0;5660
-618A;1.0;5664
-618E;1.0;3394
-6190;1.0;4689
-6191;1.0;5665
-6194;1.0;5662
-6196;1.0;5659
-6199;1.0;5658
-619A;1.0;5663
-61A4;1.0;4216
-61A7;1.0;3820
-61A9;1.0;2338
-61AB;1.0;5666
-61AC;1.0;5661
-61AE;1.0;5667
-61B2;1.0;2391
-61B6;1.0;1817
-61BA;1.0;5675
-61BE;1.0;2024
-61C3;1.0;5673
-61C6;1.0;5674
-61C7;1.0;2609
-61C8;1.0;5672
-61C9;1.0;5670
-61CA;1.0;5669
-61CB;1.0;5676
-61CC;1.0;5668
-61CD;1.0;5678
-61D0;1.0;1891
-61E3;1.0;5680
-61E6;1.0;5679
-61F2;1.0;3608
-61F4;1.0;5683
-61F6;1.0;5681
-61F7;1.0;5671
-61F8;1.0;2392
-61FA;1.0;5682
-61FC;1.0;5686
-61FD;1.0;5685
-61FE;1.0;5687
-61FF;1.0;5684
-6200;1.0;5688
-6208;1.0;5689
-6209;1.0;5690
-620A;1.0;4274
-620C;1.0;5692
-620D;1.0;5691
-620E;1.0;2931
-6210;1.0;3214
-6211;1.0;1870
-6212;1.0;1892
-6214;1.0;5693
-6216;1.0;1631
-621A;1.0;3244
-621B;1.0;5694
-621D;1.0;7635
-621E;1.0;5701
-621F;1.0;2365
-6221;1.0;5702
-6226;1.0;3279
-622A;1.0;5703
-622E;1.0;5704
-622F;1.0;2126
-6230;1.0;5705
-6232;1.0;5706
-6233;1.0;5707
-6234;1.0;3455
-6238;1.0;2445
-623B;1.0;4465
-623F;1.0;4328
-6240;1.0;2974
-6241;1.0;5708
-6247;1.0;3280
-6248;1.0;7829
-6249;1.0;4066
-624B;1.0;2874
-624D;1.0;2645
-624E;1.0;5709
-6253;1.0;3439
-6255;1.0;4207
-6258;1.0;3481
-625B;1.0;5712
-625E;1.0;5710
-6260;1.0;5713
-6263;1.0;5711
-6268;1.0;5714
-626E;1.0;4217
-6271;1.0;1623
-6276;1.0;4162
-6279;1.0;4067
-627C;1.0;5715
-627E;1.0;5718
-627F;1.0;3021
-6280;1.0;2127
-6282;1.0;5716
-6283;1.0;5723
-6284;1.0;3022
-6289;1.0;5717
-628A;1.0;3936
-6291;1.0;4562
-6292;1.0;5719
-6293;1.0;5720
-6294;1.0;5724
-6295;1.0;3774
-6296;1.0;5721
-6297;1.0;2519
-6298;1.0;3262
-629B;1.0;5738
-629C;1.0;4020
-629E;1.0;3482
-62AB;1.0;4068
-62AC;1.0;5813
-62B1;1.0;4290
-62B5;1.0;3681
-62B9;1.0;4385
-62BB;1.0;5727
-62BC;1.0;1801
-62BD;1.0;3574
-62C2;1.0;5736
-62C5;1.0;3520
-62C6;1.0;5730
-62C7;1.0;5737
-62C8;1.0;5732
-62C9;1.0;5739
-62CA;1.0;5735
-62CC;1.0;5734
-62CD;1.0;3979
-62CF;1.0;5728
-62D0;1.0;1893
-62D1;1.0;5726
-62D2;1.0;2181
-62D3;1.0;3483
-62D4;1.0;5722
-62D7;1.0;5725
-62D8;1.0;2520
-62D9;1.0;3259
-62DB;1.0;3023
-62DC;1.0;5733
-62DD;1.0;3950
-62E0;1.0;2182
-62E1;1.0;1940
-62EC;1.0;1971
-62ED;1.0;3101
-62EE;1.0;5741
-62EF;1.0;5746
-62F1;1.0;5742
-62F3;1.0;2393
-62F5;1.0;5747
-62F6;1.0;2702
-62F7;1.0;2573
-62FE;1.0;2906
-62FF;1.0;5729
-6301;1.0;2793
-6302;1.0;5744
-6307;1.0;2756
-6308;1.0;5745
-6309;1.0;1636
-630C;1.0;5740
-6311;1.0;3609
-6319;1.0;2183
-631F;1.0;2220
-6327;1.0;5743
-6328;1.0;1607
-632B;1.0;2635
-632F;1.0;3122
-633A;1.0;3682
-633D;1.0;4052
-633E;1.0;5749
-633F;1.0;3362
-6349;1.0;3410
-634C;1.0;2711
-634D;1.0;5750
-634F;1.0;5752
-6350;1.0;5748
-6355;1.0;4265
-6357;1.0;3629
-635C;1.0;3360
-6367;1.0;4291
-6368;1.0;2846
-6369;1.0;5764
-636B;1.0;5763
-636E;1.0;3188
-6372;1.0;2394
-6376;1.0;5757
-6377;1.0;3025
-637A;1.0;3872
-637B;1.0;3917
-6380;1.0;5755
-6383;1.0;3361
-6388;1.0;2888
-6389;1.0;5760
-638C;1.0;3024
-638E;1.0;5754
-638F;1.0;5759
-6392;1.0;3951
-6396;1.0;5753
-6398;1.0;2301
-639B;1.0;1961
-639F;1.0;5761
-63A0;1.0;4611
-63A1;1.0;2646
-63A2;1.0;3521
-63A3;1.0;5758
-63A5;1.0;3260
-63A7;1.0;2521
-63A8;1.0;3168
-63A9;1.0;1770
-63AA;1.0;3328
-63AB;1.0;5756
-63AC;1.0;2137
-63B2;1.0;2339
-63B4;1.0;3647
-63B5;1.0;5762
-63BB;1.0;3363
-63BE;1.0;5765
-63C0;1.0;5767
-63C3;1.0;3423
-63C4;1.0;5773
-63C6;1.0;5768
-63C9;1.0;5770
-63CF;1.0;4133
-63D0;1.0;3683
-63D2;1.0;5771
-63D6;1.0;4512
-63DA;1.0;4540
-63DB;1.0;2025
-63E1;1.0;1614
-63E3;1.0;5769
-63E9;1.0;5766
-63EE;1.0;2088
-63F4;1.0;1771
-63F6;1.0;5772
-63FA;1.0;4541
-6406;1.0;5776
-640D;1.0;3427
-640F;1.0;5783
-6413;1.0;5777
-6416;1.0;5774
-6417;1.0;5781
-641C;1.0;5751
-6426;1.0;5778
-6428;1.0;5782
-642C;1.0;4034
-642D;1.0;3775
-6434;1.0;5775
-6436;1.0;5779
-643A;1.0;2340
-643E;1.0;2681
-6442;1.0;3261
-644E;1.0;5787
-6458;1.0;3706
-6467;1.0;5784
-6469;1.0;4364
-646F;1.0;5785
-6476;1.0;5786
-6478;1.0;4446
-647A;1.0;3202
-6483;1.0;2366
-6488;1.0;5793
-6492;1.0;2721
-6493;1.0;5790
-6495;1.0;5789
-649A;1.0;3918
-649E;1.0;3821
-64A4;1.0;3717
-64A5;1.0;5791
-64A9;1.0;5792
-64AB;1.0;4179
-64AD;1.0;3937
-64AE;1.0;2703
-64B0;1.0;3281
-64B2;1.0;4348
-64B9;1.0;1941
-64BB;1.0;5805
-64BC;1.0;5794
-64C1;1.0;4542
-64C2;1.0;5807
-64C5;1.0;5803
-64C7;1.0;5804
-64CD;1.0;3364
-64D2;1.0;5802
-64D4;1.0;5731
-64D8;1.0;5806
-64DA;1.0;5801
-64E0;1.0;5811
-64E1;1.0;5812
-64E2;1.0;3707
-64E3;1.0;5814
-64E6;1.0;2704
-64E7;1.0;5809
-64EC;1.0;2128
-64EF;1.0;5815
-64F1;1.0;5808
-64F2;1.0;5819
-64F4;1.0;5818
-64F6;1.0;5817
-64FA;1.0;5820
-64FD;1.0;5822
-64FE;1.0;3081
-6500;1.0;5821
-6505;1.0;5825
-6518;1.0;5823
-651C;1.0;5824
-651D;1.0;5780
-6523;1.0;5827
-6524;1.0;5826
-652A;1.0;5788
-652B;1.0;5828
-652C;1.0;5816
-652F;1.0;2757
-6534;1.0;5829
-6535;1.0;5830
-6536;1.0;5832
-6537;1.0;5831
-6538;1.0;5833
-6539;1.0;1894
-653B;1.0;2522
-653E;1.0;4292
-653F;1.0;3215
-6545;1.0;2446
-6548;1.0;5835
-654D;1.0;5838
-654F;1.0;4150
-6551;1.0;2163
-6555;1.0;5837
-6556;1.0;5836
-6557;1.0;3952
-6558;1.0;5839
-6559;1.0;2221
-655D;1.0;5841
-655E;1.0;5840
-6562;1.0;2026
-6563;1.0;2722
-6566;1.0;3856
-656C;1.0;2341
-6570;1.0;3184
-6572;1.0;5842
-6574;1.0;3216
-6575;1.0;3708
-6577;1.0;4163
-6578;1.0;5843
-6582;1.0;5844
-6583;1.0;5845
-6587;1.0;4224
-6588;1.0;5361
-6589;1.0;3238
-658C;1.0;4144
-658E;1.0;2656
-6590;1.0;4069
-6591;1.0;4035
-6597;1.0;3745
-6599;1.0;4633
-659B;1.0;5847
-659C;1.0;2848
-659F;1.0;5848
-65A1;1.0;1622
-65A4;1.0;2252
-65A5;1.0;3245
-65A7;1.0;4164
-65AB;1.0;5849
-65AC;1.0;2734
-65AD;1.0;3539
-65AF;1.0;2759
-65B0;1.0;3123
-65B7;1.0;5850
-65B9;1.0;4293
-65BC;1.0;1787
-65BD;1.0;2760
-65C1;1.0;5853
-65C3;1.0;5851
-65C4;1.0;5854
-65C5;1.0;4625
-65C6;1.0;5852
-65CB;1.0;3291
-65CC;1.0;5855
-65CF;1.0;3418
-65D2;1.0;5856
-65D7;1.0;2090
-65D9;1.0;5858
-65DB;1.0;5857
-65E0;1.0;5859
-65E1;1.0;5860
-65E2;1.0;2091
-65E5;1.0;3892
-65E6;1.0;3522
-65E7;1.0;2176
-65E8;1.0;2761
-65E9;1.0;3365
-65EC;1.0;2960
-65ED;1.0;1616
-65F1;1.0;5861
-65FA;1.0;1802
-65FB;1.0;5865
-6602;1.0;2523
-6603;1.0;5864
-6606;1.0;2611
-6607;1.0;3026
-660A;1.0;5863
-660C;1.0;3027
-660E;1.0;4432
-660F;1.0;2610
-6613;1.0;1655
-6614;1.0;3246
-661C;1.0;5870
-661F;1.0;3217
-6620;1.0;1739
-6625;1.0;2953
-6627;1.0;4370
-6628;1.0;2682
-662D;1.0;3028
-662F;1.0;3207
-6634;1.0;5869
-6635;1.0;5867
-6636;1.0;5868
-663C;1.0;3575
-663F;1.0;5906
-6641;1.0;5874
-6642;1.0;2794
-6643;1.0;2524
-6644;1.0;5872
-6649;1.0;5873
-664B;1.0;3124
-664F;1.0;5871
-6652;1.0;2715
-665D;1.0;5876
-665E;1.0;5875
-665F;1.0;5880
-6662;1.0;5881
-6664;1.0;5877
-6666;1.0;1902
-6667;1.0;5878
-6668;1.0;5879
-6669;1.0;4053
-666E;1.0;4165
-666F;1.0;2342
-6670;1.0;5882
-6674;1.0;3218
-6676;1.0;3029
-667A;1.0;3550
-6681;1.0;2239
-6683;1.0;5883
-6684;1.0;5887
-6687;1.0;1843
-6688;1.0;5884
-6689;1.0;5886
-668E;1.0;5885
-6691;1.0;2975
-6696;1.0;3540
-6697;1.0;1637
-6698;1.0;5888
-669D;1.0;5889
-66A2;1.0;3610
-66A6;1.0;4681
-66AB;1.0;2735
-66AE;1.0;4275
-66B4;1.0;4329
-66B8;1.0;5902
-66B9;1.0;5891
-66BC;1.0;5894
-66BE;1.0;5893
-66C1;1.0;5890
-66C4;1.0;5901
-66C7;1.0;3862
-66C9;1.0;5892
-66D6;1.0;5903
-66D9;1.0;2976
-66DA;1.0;5904
-66DC;1.0;4543
-66DD;1.0;3988
-66E0;1.0;5905
-66E6;1.0;5907
-66E9;1.0;5908
-66F0;1.0;5909
-66F2;1.0;2242
-66F3;1.0;1740
-66F4;1.0;2525
-66F5;1.0;5910
-66F7;1.0;5911
-66F8;1.0;2981
-66F9;1.0;3366
-66FC;1.0;5056
-66FD;1.0;3330
-66FE;1.0;3329
-66FF;1.0;3456
-6700;1.0;2639
-6703;1.0;4882
-6708;1.0;2378
-6709;1.0;4513
-670B;1.0;4294
-670D;1.0;4194
-670F;1.0;5912
-6714;1.0;2683
-6715;1.0;3631
-6716;1.0;5913
-6717;1.0;4715
-671B;1.0;4330
-671D;1.0;3611
-671E;1.0;5914
-671F;1.0;2092
-6726;1.0;5915
-6727;1.0;5916
-6728;1.0;4458
-672A;1.0;4404
-672B;1.0;4386
-672C;1.0;4360
-672D;1.0;2705
-672E;1.0;5918
-6731;1.0;2875
-6734;1.0;4349
-6736;1.0;5920
-6737;1.0;5923
-6738;1.0;5922
-673A;1.0;2089
-673D;1.0;2164
-673F;1.0;5919
-6741;1.0;5921
-6746;1.0;5924
-6749;1.0;3189
-674E;1.0;4591
-674F;1.0;1641
-6750;1.0;2664
-6751;1.0;3428
-6753;1.0;2861
-6756;1.0;3083
-6759;1.0;5927
-675C;1.0;3746
-675E;1.0;5925
-675F;1.0;3411
-6760;1.0;5926
-6761;1.0;3082
-6762;1.0;4461
-6763;1.0;5928
-6764;1.0;5929
-6765;1.0;4572
-676A;1.0;5934
-676D;1.0;2526
-676F;1.0;3953
-6770;1.0;5931
-6771;1.0;3776
-6772;1.0;5862
-6773;1.0;5866
-6775;1.0;2147
-6777;1.0;3939
-677C;1.0;5933
-677E;1.0;3030
-677F;1.0;4036
-6785;1.0;5939
-6787;1.0;4090
-6789;1.0;5930
-678B;1.0;5936
-678C;1.0;5935
-6790;1.0;3247
-6795;1.0;4377
-6797;1.0;4651
-679A;1.0;4371
-679C;1.0;1844
-679D;1.0;2762
-67A0;1.0;4740
-67A1;1.0;5938
-67A2;1.0;3185
-67A6;1.0;5937
-67A9;1.0;5932
-67AF;1.0;2447
-67B3;1.0;5944
-67B4;1.0;5942
-67B6;1.0;1845
-67B7;1.0;5940
-67B8;1.0;5946
-67B9;1.0;5952
-67C1;1.0;3440
-67C4;1.0;4233
-67C6;1.0;5954
-67CA;1.0;4102
-67CE;1.0;5953
-67CF;1.0;3980
-67D0;1.0;4331
-67D1;1.0;2027
-67D3;1.0;3287
-67D4;1.0;2932
-67D8;1.0;3651
-67DA;1.0;4514
-67DD;1.0;5949
-67DE;1.0;5948
-67E2;1.0;5950
-67E4;1.0;5947
-67E7;1.0;5955
-67E9;1.0;5945
-67EC;1.0;5943
-67EE;1.0;5951
-67EF;1.0;5941
-67F1;1.0;3576
-67F3;1.0;4488
-67F4;1.0;2838
-67F5;1.0;2684
-67FB;1.0;2626
-67FE;1.0;4379
-67FF;1.0;1933
-6802;1.0;3646
-6803;1.0;3842
-6804;1.0;1741
-6813;1.0;3282
-6816;1.0;3220
-6817;1.0;2310
-681E;1.0;5957
-6821;1.0;2527
-6822;1.0;1992
-6829;1.0;5959
-682A;1.0;1984
-682B;1.0;5965
-6832;1.0;5962
-6834;1.0;3283
-6838;1.0;1943
-6839;1.0;2612
-683C;1.0;1942
-683D;1.0;2647
-6840;1.0;5960
-6841;1.0;2369
-6842;1.0;2343
-6843;1.0;3777
-6846;1.0;5958
-6848;1.0;1638
-684D;1.0;5961
-684E;1.0;5963
-6850;1.0;2245
-6851;1.0;2312
-6853;1.0;2028
-6854;1.0;2143
-6859;1.0;5966
-685C;1.0;2689
-685D;1.0;4381
-685F;1.0;2723
-6863;1.0;5967
-6867;1.0;4116
-6874;1.0;5979
-6876;1.0;1819
-6877;1.0;5968
-687E;1.0;5985
-687F;1.0;5969
-6881;1.0;4634
-6883;1.0;5976
-6885;1.0;3963
-688D;1.0;5984
-688F;1.0;5971
-6893;1.0;1620
-6894;1.0;5973
-6897;1.0;2528
-689B;1.0;5975
-689D;1.0;5974
-689F;1.0;5970
-68A0;1.0;5981
-68A2;1.0;3031
-68A6;1.0;5277
-68A7;1.0;2472
-68A8;1.0;4592
-68AD;1.0;5972
-68AF;1.0;3684
-68B0;1.0;1903
-68B1;1.0;2613
-68B3;1.0;5964
-68B5;1.0;5980
-68B6;1.0;1965
-68B9;1.0;5978
-68BA;1.0;5982
-68BC;1.0;3778
-68C4;1.0;2094
-68C6;1.0;6018
-68C9;1.0;4441
-68CA;1.0;5987
-68CB;1.0;2093
-68CD;1.0;5994
-68D2;1.0;4332
-68D4;1.0;6001
-68D5;1.0;6003
-68D7;1.0;6007
-68D8;1.0;5989
-68DA;1.0;3510
-68DF;1.0;3779
-68E0;1.0;6011
-68E1;1.0;5992
-68E3;1.0;6008
-68E7;1.0;6002
-68EE;1.0;3125
-68EF;1.0;6012
-68F2;1.0;3219
-68F9;1.0;6010
-68FA;1.0;2029
-6900;1.0;4748
-6901;1.0;5986
-6904;1.0;6006
-6905;1.0;1656
-6908;1.0;5988
-690B;1.0;4426
-690C;1.0;5993
-690D;1.0;3102
-690E;1.0;3639
-690F;1.0;5983
-6912;1.0;6005
-6919;1.0;3190
-691A;1.0;6015
-691B;1.0;1981
-691C;1.0;2401
-6921;1.0;6017
-6922;1.0;5990
-6923;1.0;6016
-6925;1.0;6009
-6926;1.0;5991
-6928;1.0;6013
-692A;1.0;6014
-6930;1.0;6031
-6934;1.0;3846
-6936;1.0;6004
-6939;1.0;6027
-693D;1.0;6029
-693F;1.0;3656
-694A;1.0;4544
-6953;1.0;4186
-6954;1.0;6024
-6955;1.0;3442
-6959;1.0;6030
-695A;1.0;3331
-695C;1.0;6021
-695D;1.0;6034
-695E;1.0;6033
-6960;1.0;3879
-6961;1.0;6032
-6962;1.0;3874
-696A;1.0;6036
-696B;1.0;6023
-696D;1.0;2240
-696E;1.0;6026
-696F;1.0;2961
-6973;1.0;3964
-6974;1.0;6028
-6975;1.0;2243
-6977;1.0;6020
-6978;1.0;6022
-6979;1.0;6019
-697C;1.0;4716
-697D;1.0;1958
-697E;1.0;6025
-6981;1.0;6035
-6982;1.0;1921
-698A;1.0;2671
-698E;1.0;1761
-6991;1.0;6052
-6994;1.0;4717
-6995;1.0;6055
-699B;1.0;3126
-699C;1.0;6054
-69A0;1.0;6053
-69A7;1.0;6050
-69AE;1.0;6038
-69B1;1.0;6067
-69B2;1.0;6037
-69B4;1.0;6056
-69BB;1.0;6048
-69BE;1.0;6043
-69BF;1.0;6040
-69C1;1.0;6041
-69C3;1.0;6049
-69C7;1.0;8402
-69CA;1.0;6046
-69CB;1.0;2529
-69CC;1.0;3640
-69CD;1.0;3368
-69CE;1.0;6044
-69D0;1.0;6039
-69D3;1.0;6042
-69D8;1.0;4545
-69D9;1.0;4374
-69DD;1.0;6047
-69DE;1.0;6057
-69E7;1.0;6065
-69E8;1.0;6058
-69EB;1.0;6071
-69ED;1.0;6069
-69F2;1.0;6064
-69F9;1.0;6063
-69FB;1.0;3648
-69FD;1.0;3369
-69FF;1.0;6061
-6A02;1.0;6059
-6A05;1.0;6066
-6A0A;1.0;6072
-6A0B;1.0;4085
-6A0C;1.0;6078
-6A12;1.0;6073
-6A13;1.0;6076
-6A14;1.0;6070
-6A17;1.0;3584
-6A19;1.0;4124
-6A1B;1.0;6060
-6A1E;1.0;6068
-6A1F;1.0;3032
-6A21;1.0;4447
-6A22;1.0;6088
-6A23;1.0;6075
-6A29;1.0;2402
-6A2A;1.0;1803
-6A2B;1.0;1963
-6A2E;1.0;6051
-6A35;1.0;3033
-6A36;1.0;6080
-6A38;1.0;6087
-6A39;1.0;2889
-6A3A;1.0;1982
-6A3D;1.0;3514
-6A44;1.0;6077
-6A47;1.0;6082
-6A48;1.0;6086
-6A4B;1.0;2222
-6A58;1.0;2144
-6A59;1.0;6084
-6A5F;1.0;2101
-6A61;1.0;3843
-6A62;1.0;6083
-6A66;1.0;6085
-6A72;1.0;6079
-6A78;1.0;6081
-6A7F;1.0;1964
-6A80;1.0;3541
-6A84;1.0;6092
-6A8D;1.0;6090
-6A8E;1.0;2473
-6A90;1.0;6089
-6A97;1.0;6101
-6A9C;1.0;5956
-6AA0;1.0;6091
-6AA2;1.0;6093
-6AA3;1.0;6094
-6AAA;1.0;6112
-6AAC;1.0;6108
-6AAE;1.0;5977
-6AB3;1.0;6107
-6AB8;1.0;6106
-6ABB;1.0;6103
-6AC1;1.0;6074
-6AC2;1.0;6105
-6AC3;1.0;6104
-6AD1;1.0;6110
-6AD3;1.0;4706
-6ADA;1.0;6113
-6ADB;1.0;2291
-6ADE;1.0;6109
-6ADF;1.0;6111
-6AE8;1.0;4007
-6AEA;1.0;6114
-6AFA;1.0;6118
-6AFB;1.0;6115
-6B04;1.0;4583
-6B05;1.0;6116
-6B0A;1.0;6062
-6B12;1.0;6119
-6B16;1.0;6120
-6B1D;1.0;1721
-6B1F;1.0;6122
-6B20;1.0;2371
-6B21;1.0;2801
-6B23;1.0;2253
-6B27;1.0;1804
-6B32;1.0;4563
-6B37;1.0;6124
-6B38;1.0;6123
-6B39;1.0;6126
-6B3A;1.0;2129
-6B3D;1.0;2254
-6B3E;1.0;2030
-6B43;1.0;6129
-6B47;1.0;6128
-6B49;1.0;6130
-6B4C;1.0;1846
-6B4E;1.0;3523
-6B50;1.0;6131
-6B53;1.0;2031
-6B54;1.0;6133
-6B59;1.0;6132
-6B5B;1.0;6134
-6B5F;1.0;6135
-6B61;1.0;6136
-6B62;1.0;2763
-6B63;1.0;3221
-6B64;1.0;2601
-6B66;1.0;4180
-6B69;1.0;4266
-6B6A;1.0;4736
-6B6F;1.0;2785
-6B73;1.0;2648
-6B74;1.0;4682
-6B78;1.0;6137
-6B79;1.0;6138
-6B7B;1.0;2764
-6B7F;1.0;6139
-6B80;1.0;6140
-6B83;1.0;6142
-6B84;1.0;6141
-6B86;1.0;4356
-6B89;1.0;2962
-6B8A;1.0;2876
-6B8B;1.0;2736
-6B8D;1.0;6143
-6B95;1.0;6145
-6B96;1.0;3103
-6B98;1.0;6144
-6B9E;1.0;6146
-6BA4;1.0;6147
-6BAA;1.0;6148
-6BAB;1.0;6149
-6BAF;1.0;6150
-6BB1;1.0;6152
-6BB2;1.0;6151
-6BB3;1.0;6153
-6BB4;1.0;1805
-6BB5;1.0;3542
-6BB7;1.0;6154
-6BBA;1.0;2706
-6BBB;1.0;1944
-6BBC;1.0;6155
-6BBF;1.0;3734
-6BC0;1.0;5244
-6BC5;1.0;2103
-6BC6;1.0;6156
-6BCB;1.0;6157
-6BCD;1.0;4276
-6BCE;1.0;4372
-6BD2;1.0;3839
-6BD3;1.0;6158
-6BD4;1.0;4070
-6BD8;1.0;4091
-6BDB;1.0;4451
-6BDF;1.0;6159
-6BEB;1.0;6161
-6BEC;1.0;6160
-6BEF;1.0;6163
-6BF3;1.0;6162
-6C08;1.0;6165
-6C0F;1.0;2765
-6C11;1.0;4417
-6C13;1.0;6166
-6C14;1.0;6167
-6C17;1.0;2104
-6C1B;1.0;6168
-6C23;1.0;6170
-6C24;1.0;6169
-6C34;1.0;3169
-6C37;1.0;4125
-6C38;1.0;1742
-6C3E;1.0;4037
-6C40;1.0;3685
-6C41;1.0;2933
-6C42;1.0;2165
-6C4E;1.0;4038
-6C50;1.0;2814
-6C55;1.0;6172
-6C57;1.0;2032
-6C5A;1.0;1788
-6C5D;1.0;3882
-6C5E;1.0;6171
-6C5F;1.0;2530
-6C60;1.0;3551
-6C62;1.0;6173
-6C68;1.0;6181
-6C6A;1.0;6174
-6C70;1.0;3433
-6C72;1.0;2166
-6C73;1.0;6182
-6C7A;1.0;2372
-6C7D;1.0;2105
-6C7E;1.0;6180
-6C81;1.0;6178
-6C82;1.0;6175
-6C83;1.0;4564
-6C88;1.0;3632
-6C8C;1.0;3857
-6C8D;1.0;6176
-6C90;1.0;6184
-6C92;1.0;6183
-6C93;1.0;2303
-6C96;1.0;1813
-6C99;1.0;2627
-6C9A;1.0;6177
-6C9B;1.0;6179
-6CA1;1.0;4355
-6CA2;1.0;3484
-6CAB;1.0;4387
-6CAE;1.0;6192
-6CB1;1.0;6193
-6CB3;1.0;1847
-6CB8;1.0;4208
-6CB9;1.0;4493
-6CBA;1.0;6201
-6CBB;1.0;2803
-6CBC;1.0;3034
-6CBD;1.0;6188
-6CBE;1.0;6194
-6CBF;1.0;1772
-6CC1;1.0;2223
-6CC4;1.0;6185
-6CC5;1.0;6190
-6CC9;1.0;3284
-6CCA;1.0;3981
-6CCC;1.0;4071
-6CD3;1.0;6187
-6CD5;1.0;4301
-6CD7;1.0;6189
-6CD9;1.0;6204
-6CDB;1.0;6202
-6CDD;1.0;6191
-6CE1;1.0;4302
-6CE2;1.0;3940
-6CE3;1.0;2167
-6CE5;1.0;3705
-6CE8;1.0;3577
-6CEA;1.0;6205
-6CEF;1.0;6203
-6CF0;1.0;3457
-6CF1;1.0;6186
-6CF3;1.0;1743
-6D0B;1.0;4546
-6D0C;1.0;6216
-6D12;1.0;6215
-6D17;1.0;3286
-6D19;1.0;6212
-6D1B;1.0;4576
-6D1E;1.0;3822
-6D1F;1.0;6206
-6D25;1.0;3637
-6D29;1.0;1744
-6D2A;1.0;2531
-6D2B;1.0;6209
-6D32;1.0;2907
-6D33;1.0;6214
-6D35;1.0;6213
-6D36;1.0;6208
-6D38;1.0;6211
-6D3B;1.0;1972
-6D3D;1.0;6210
-6D3E;1.0;3941
-6D41;1.0;4614
-6D44;1.0;3084
-6D45;1.0;3285
-6D59;1.0;6222
-6D5A;1.0;6220
-6D5C;1.0;4145
-6D63;1.0;6217
-6D64;1.0;6219
-6D66;1.0;1726
-6D69;1.0;2532
-6D6A;1.0;4718
-6D6C;1.0;1929
-6D6E;1.0;4166
-6D74;1.0;4565
-6D77;1.0;1904
-6D78;1.0;3127
-6D79;1.0;6221
-6D85;1.0;6226
-6D88;1.0;3035
-6D8C;1.0;4516
-6D8E;1.0;6223
-6D93;1.0;6218
-6D95;1.0;6224
-6D99;1.0;4662
-6D9B;1.0;3783
-6D9C;1.0;3834
-6DAF;1.0;1922
-6DB2;1.0;1753
-6DB5;1.0;6230
-6DB8;1.0;6233
-6DBC;1.0;4635
-6DC0;1.0;4568
-6DC5;1.0;6240
-6DC6;1.0;6234
-6DC7;1.0;6231
-6DCB;1.0;4652
-6DCC;1.0;6237
-6DD1;1.0;2942
-6DD2;1.0;6239
-6DD5;1.0;6244
-6DD8;1.0;3781
-6DD9;1.0;6242
-6DDE;1.0;6236
-6DE1;1.0;3524
-6DE4;1.0;6243
-6DE6;1.0;6232
-6DE8;1.0;6238
-6DEA;1.0;6245
-6DEB;1.0;1692
-6DEC;1.0;6235
-6DEE;1.0;6246
-6DF1;1.0;3128
-6DF3;1.0;2963
-6DF5;1.0;4205
-6DF7;1.0;2614
-6DF9;1.0;6227
-6DFA;1.0;6241
-6DFB;1.0;3726
-6E05;1.0;3222
-6E07;1.0;1973
-6E08;1.0;2649
-6E09;1.0;3036
-6E0A;1.0;6229
-6E0B;1.0;2934
-6E13;1.0;2344
-6E15;1.0;6228
-6E19;1.0;6250
-6E1A;1.0;2977
-6E1B;1.0;2426
-6E1D;1.0;6265
-6E1F;1.0;6259
-6E20;1.0;2184
-6E21;1.0;3747
-6E23;1.0;6254
-6E24;1.0;6263
-6E25;1.0;1615
-6E26;1.0;1718
-6E29;1.0;1825
-6E2B;1.0;6256
-6E2C;1.0;3412
-6E2D;1.0;6247
-6E2E;1.0;6249
-6E2F;1.0;2533
-6E38;1.0;6266
-6E3A;1.0;6261
-6E3E;1.0;6253
-6E43;1.0;6260
-6E4A;1.0;4411
-6E4D;1.0;6258
-6E4E;1.0;6262
-6E56;1.0;2448
-6E58;1.0;3037
-6E5B;1.0;3525
-6E5F;1.0;6252
-6E67;1.0;4515
-6E6B;1.0;6255
-6E6E;1.0;6248
-6E6F;1.0;3782
-6E72;1.0;6251
-6E76;1.0;6257
-6E7E;1.0;4749
-6E7F;1.0;2830
-6E80;1.0;4394
-6E82;1.0;6267
-6E8C;1.0;4014
-6E8F;1.0;6279
-6E90;1.0;2427
-6E96;1.0;2964
-6E98;1.0;6269
-6E9C;1.0;4615
-6E9D;1.0;2534
-6E9F;1.0;6282
-6EA2;1.0;1678
-6EA5;1.0;6280
-6EAA;1.0;6268
-6EAF;1.0;6274
-6EB2;1.0;6276
-6EB6;1.0;4547
-6EB7;1.0;6271
-6EBA;1.0;3714
-6EBD;1.0;6273
-6EC2;1.0;6281
-6EC4;1.0;6275
-6EC5;1.0;4439
-6EC9;1.0;6270
-6ECB;1.0;2802
-6ECC;1.0;6294
-6ED1;1.0;1974
-6ED3;1.0;6272
-6ED4;1.0;6277
-6ED5;1.0;6278
-6EDD;1.0;3476
-6EDE;1.0;3458
-6EEC;1.0;6286
-6EEF;1.0;6292
-6EF2;1.0;6290
-6EF4;1.0;3709
-6EF7;1.0;6303
-6EF8;1.0;6287
-6EFE;1.0;6288
-6EFF;1.0;6264
-6F01;1.0;2189
-6F02;1.0;4126
-6F06;1.0;2831
-6F09;1.0;2587
-6F0F;1.0;4719
-6F11;1.0;6284
-6F13;1.0;6302
-6F14;1.0;1773
-6F15;1.0;3370
-6F20;1.0;3989
-6F22;1.0;2033
-6F23;1.0;4690
-6F2B;1.0;4401
-6F2C;1.0;3650
-6F31;1.0;6291
-6F32;1.0;6293
-6F38;1.0;3318
-6F3E;1.0;6301
-6F3F;1.0;6289
-6F41;1.0;6283
-6F45;1.0;2035
-6F54;1.0;2373
-6F58;1.0;6315
-6F5B;1.0;6310
-6F5C;1.0;3288
-6F5F;1.0;1967
-6F64;1.0;2965
-6F66;1.0;6319
-6F6D;1.0;6312
-6F6E;1.0;3612
-6F6F;1.0;6309
-6F70;1.0;3657
-6F74;1.0;6344
-6F78;1.0;6306
-6F7A;1.0;6305
-6F7C;1.0;6314
-6F80;1.0;6308
-6F81;1.0;6307
-6F82;1.0;6313
-6F84;1.0;3201
-6F86;1.0;6304
-6F8E;1.0;6316
-6F91;1.0;6317
-6F97;1.0;2034
-6FA1;1.0;6322
-6FA3;1.0;6321
-6FA4;1.0;6323
-6FAA;1.0;6326
-6FB1;1.0;3735
-6FB3;1.0;6320
-6FB9;1.0;6324
-6FC0;1.0;2367
-6FC1;1.0;3489
-6FC2;1.0;6318
-6FC3;1.0;3927
-6FC6;1.0;6325
-6FD4;1.0;6330
-6FD5;1.0;6328
-6FD8;1.0;6331
-6FDB;1.0;6334
-6FDF;1.0;6327
-6FE0;1.0;2574
-6FE1;1.0;3908
-6FE4;1.0;6225
-6FEB;1.0;4584
-6FEC;1.0;6329
-6FEE;1.0;6333
-6FEF;1.0;3485
-6FF1;1.0;6332
-6FF3;1.0;6311
-6FF6;1.0;7973
-6FFA;1.0;6337
-6FFE;1.0;6341
-7001;1.0;6339
-7009;1.0;6335
-700B;1.0;6336
-700F;1.0;6340
-7011;1.0;6338
-7015;1.0;4146
-7018;1.0;6346
-701A;1.0;6343
-701B;1.0;6342
-701D;1.0;6345
-701E;1.0;3852
-701F;1.0;6347
-7026;1.0;3585
-7027;1.0;3477
-702C;1.0;3205
-7030;1.0;6348
-7032;1.0;6350
-703E;1.0;6349
-704C;1.0;6285
-7051;1.0;6351
-7058;1.0;3871
-7063;1.0;6352
-706B;1.0;1848
-706F;1.0;3784
-7070;1.0;1905
-7078;1.0;2168
-707C;1.0;2862
-707D;1.0;2650
-7089;1.0;4707
-708A;1.0;3170
-708E;1.0;1774
-7092;1.0;6354
-7099;1.0;6353
-70AC;1.0;6357
-70AD;1.0;3526
-70AE;1.0;6360
-70AF;1.0;6355
-70B3;1.0;6359
-70B8;1.0;6358
-70B9;1.0;3732
-70BA;1.0;1657
-70C8;1.0;4685
-70CB;1.0;6362
-70CF;1.0;1708
-70D9;1.0;6364
-70DD;1.0;6363
-70DF;1.0;6361
-70F1;1.0;6356
-70F9;1.0;4303
-70FD;1.0;6366
-7109;1.0;6365
-7114;1.0;1775
-7119;1.0;6368
-711A;1.0;4218
-711C;1.0;6367
-7121;1.0;4421
-7126;1.0;3039
-7136;1.0;3319
-713C;1.0;3038
-7149;1.0;4691
-714C;1.0;6374
-714E;1.0;3289
-7155;1.0;6370
-7156;1.0;6375
-7159;1.0;1776
-7162;1.0;6373
-7164;1.0;3965
-7165;1.0;6369
-7166;1.0;6372
-7167;1.0;3040
-7169;1.0;4049
-716C;1.0;6376
-716E;1.0;2849
-717D;1.0;3290
-7184;1.0;6379
-7188;1.0;6371
-718A;1.0;2307
-718F;1.0;6377
-7194;1.0;4548
-7195;1.0;6380
-7199;1.0;8406
-719F;1.0;2947
-71A8;1.0;6381
-71AC;1.0;6382
-71B1;1.0;3914
-71B9;1.0;6384
-71BE;1.0;6385
-71C3;1.0;3919
-71C8;1.0;3785
-71C9;1.0;6387
-71CE;1.0;6389
-71D0;1.0;4653
-71D2;1.0;6386
-71D4;1.0;6388
-71D5;1.0;1777
-71D7;1.0;6383
-71DF;1.0;5159
-71E0;1.0;6390
-71E5;1.0;3371
-71E6;1.0;2724
-71E7;1.0;6392
-71EC;1.0;6391
-71ED;1.0;3104
-71EE;1.0;5057
-71F5;1.0;6393
-71F9;1.0;6401
-71FB;1.0;6378
-71FC;1.0;6394
-71FF;1.0;6402
-7206;1.0;3990
-720D;1.0;6403
-7210;1.0;6404
-721B;1.0;6405
-7228;1.0;6406
-722A;1.0;3662
-722C;1.0;6408
-722D;1.0;6407
-7230;1.0;6409
-7232;1.0;6410
-7235;1.0;2863
-7236;1.0;4167
-723A;1.0;4476
-723B;1.0;6411
-723C;1.0;6412
-723D;1.0;3354
-723E;1.0;2804
-723F;1.0;6413
-7240;1.0;6414
-7246;1.0;6415
-7247;1.0;4250
-7248;1.0;4039
-724B;1.0;6416
-724C;1.0;3955
-7252;1.0;3613
-7258;1.0;6417
-7259;1.0;1871
-725B;1.0;2177
-725D;1.0;4438
-725F;1.0;4422
-7261;1.0;1820
-7262;1.0;4720
-7267;1.0;4350
-7269;1.0;4210
-7272;1.0;3223
-7274;1.0;6418
-7279;1.0;3835
-727D;1.0;2403
-727E;1.0;6419
-7280;1.0;2652
-7281;1.0;6421
-7282;1.0;6420
-7287;1.0;6422
-7292;1.0;6423
-7296;1.0;6424
-72A0;1.0;2130
-72A2;1.0;6425
-72A7;1.0;6426
-72AC;1.0;2404
-72AF;1.0;4040
-72B2;1.0;6428
-72B6;1.0;3085
-72B9;1.0;6427
-72C2;1.0;2224
-72C3;1.0;6429
-72C4;1.0;6431
-72C6;1.0;6430
-72CE;1.0;6432
-72D0;1.0;2449
-72D2;1.0;6433
-72D7;1.0;2273
-72D9;1.0;3332
-72DB;1.0;2593
-72E0;1.0;6435
-72E1;1.0;6436
-72E2;1.0;6434
-72E9;1.0;2877
-72EC;1.0;3840
-72ED;1.0;2225
-72F7;1.0;6438
-72F8;1.0;3512
-72F9;1.0;6437
-72FC;1.0;4721
-72FD;1.0;3966
-730A;1.0;6441
-7316;1.0;6443
-7317;1.0;6440
-731B;1.0;4452
-731C;1.0;6442
-731D;1.0;6444
-731F;1.0;4636
-7325;1.0;6448
-7329;1.0;6447
-732A;1.0;3586
-732B;1.0;3913
-732E;1.0;2405
-732F;1.0;6446
-7334;1.0;6445
-7336;1.0;4517
-7337;1.0;4518
-733E;1.0;6449
-733F;1.0;1778
-7344;1.0;2586
-7345;1.0;2766
-734E;1.0;6450
-734F;1.0;6451
-7357;1.0;6453
-7363;1.0;2935
-7368;1.0;6455
-736A;1.0;6454
-7370;1.0;6456
-7372;1.0;1945
-7375;1.0;6458
-7378;1.0;6457
-737A;1.0;6460
-737B;1.0;6459
-7384;1.0;2428
-7387;1.0;4608
-7389;1.0;2244
-738B;1.0;1806
-7396;1.0;2274
-73A9;1.0;2065
-73B2;1.0;4672
-73B3;1.0;6462
-73BB;1.0;6464
-73C0;1.0;6465
-73C2;1.0;1849
-73C8;1.0;6461
-73CA;1.0;2725
-73CD;1.0;3633
-73CE;1.0;6463
-73DE;1.0;6468
-73E0;1.0;2878
-73E5;1.0;6466
-73EA;1.0;2330
-73ED;1.0;4041
-73EE;1.0;6467
-73F1;1.0;6494
-73F8;1.0;6473
-73FE;1.0;2429
-7403;1.0;2169
-7405;1.0;6470
-7406;1.0;4593
-7409;1.0;4616
-7422;1.0;3486
-7425;1.0;6472
-7432;1.0;6474
-7433;1.0;4654
-7434;1.0;2255
-7435;1.0;4092
-7436;1.0;3942
-743A;1.0;6475
-743F;1.0;6477
-7441;1.0;6480
-7455;1.0;6476
-7459;1.0;6479
-745A;1.0;2474
-745B;1.0;1745
-745C;1.0;6481
-745E;1.0;3180
-745F;1.0;6478
-7460;1.0;4660
-7463;1.0;6484
-7464;1.0;8404
-7469;1.0;6482
-746A;1.0;6485
-746F;1.0;6471
-7470;1.0;6483
-7473;1.0;2628
-7476;1.0;6486
-747E;1.0;6487
-7483;1.0;4594
-748B;1.0;6488
-749E;1.0;6489
-74A2;1.0;6469
-74A7;1.0;6490
-74B0;1.0;2036
-74BD;1.0;2805
-74CA;1.0;6491
-74CF;1.0;6492
-74D4;1.0;6493
-74DC;1.0;1727
-74E0;1.0;6501
-74E2;1.0;4127
-74E3;1.0;6502
-74E6;1.0;2004
-74E7;1.0;6503
-74E9;1.0;6504
-74EE;1.0;6505
-74F0;1.0;6507
-74F1;1.0;6508
-74F2;1.0;6506
-74F6;1.0;4151
-74F7;1.0;6510
-74F8;1.0;6509
-7503;1.0;6512
-7504;1.0;6511
-7505;1.0;6513
-750C;1.0;6514
-750D;1.0;6516
-750E;1.0;6515
-7511;1.0;2589
-7513;1.0;6518
-7515;1.0;6517
-7518;1.0;2037
-751A;1.0;3151
-751C;1.0;3728
-751E;1.0;6519
-751F;1.0;3224
-7523;1.0;2726
-7525;1.0;1789
-7526;1.0;6520
-7528;1.0;4549
-752B;1.0;4267
-752C;1.0;6521
-7530;1.0;3736
-7531;1.0;4519
-7532;1.0;2535
-7533;1.0;3129
-7537;1.0;3543
-7538;1.0;5020
-753A;1.0;3614
-753B;1.0;1872
-753C;1.0;6522
-7544;1.0;6523
-7546;1.0;6528
-7549;1.0;6526
-754A;1.0;6525
-754B;1.0;5834
-754C;1.0;1906
-754D;1.0;6524
-754F;1.0;1658
-7551;1.0;4010
-7554;1.0;4042
-7559;1.0;4617
-755A;1.0;6529
-755B;1.0;6527
-755C;1.0;3560
-755D;1.0;3206
-7560;1.0;4011
-7562;1.0;4113
-7564;1.0;6531
-7565;1.0;4612
-7566;1.0;2345
-7567;1.0;6532
-7569;1.0;6530
-756A;1.0;4054
-756B;1.0;6533
-756D;1.0;6534
-7570;1.0;1659
-7573;1.0;3086
-7574;1.0;6539
-7576;1.0;6536
-7577;1.0;3877
-7578;1.0;6535
-757F;1.0;2106
-7582;1.0;6542
-7586;1.0;6537
-7587;1.0;6538
-7589;1.0;6541
-758A;1.0;6540
-758B;1.0;4105
-758E;1.0;3334
-758F;1.0;3333
-7591;1.0;2131
-7594;1.0;6543
-759A;1.0;6544
-759D;1.0;6545
-75A3;1.0;6547
-75A5;1.0;6546
-75AB;1.0;1754
-75B1;1.0;6555
-75B2;1.0;4072
-75B3;1.0;6549
-75B5;1.0;6551
-75B8;1.0;6553
-75B9;1.0;3130
-75BC;1.0;6554
-75BD;1.0;6552
-75BE;1.0;2832
-75C2;1.0;6548
-75C3;1.0;6550
-75C5;1.0;4134
-75C7;1.0;3041
-75CA;1.0;6557
-75CD;1.0;6556
-75D2;1.0;6558
-75D4;1.0;2806
-75D5;1.0;2615
-75D8;1.0;3787
-75D9;1.0;6559
-75DB;1.0;3643
-75DE;1.0;6561
-75E2;1.0;4601
-75E3;1.0;6560
-75E9;1.0;3373
-75F0;1.0;6566
-75F2;1.0;6568
-75F3;1.0;6569
-75F4;1.0;3552
-75FA;1.0;6567
-75FC;1.0;6564
-75FE;1.0;6562
-75FF;1.0;6563
-7601;1.0;6565
-7609;1.0;6572
-760B;1.0;6570
-760D;1.0;6571
-761F;1.0;6573
-7620;1.0;6575
-7621;1.0;6576
-7622;1.0;6577
-7624;1.0;6578
-7627;1.0;6574
-7630;1.0;6580
-7634;1.0;6579
-763B;1.0;6581
-7642;1.0;4637
-7646;1.0;6584
-7647;1.0;6582
-7648;1.0;6583
-764C;1.0;2066
-7652;1.0;4494
-7656;1.0;4242
-7658;1.0;6586
-765C;1.0;6585
-7661;1.0;6587
-7662;1.0;6588
-7667;1.0;6592
-7668;1.0;6589
-7669;1.0;6590
-766A;1.0;6591
-766C;1.0;6593
-7670;1.0;6594
-7672;1.0;6601
-7676;1.0;6602
-7678;1.0;6603
-767A;1.0;4015
-767B;1.0;3748
-767C;1.0;6604
-767D;1.0;3982
-767E;1.0;4120
-7680;1.0;6605
-7683;1.0;6606
-7684;1.0;3710
-7686;1.0;1907
-7687;1.0;2536
-7688;1.0;6607
-768B;1.0;6608
-768E;1.0;6609
-7690;1.0;2709
-7693;1.0;6611
-7696;1.0;6610
-7699;1.0;6612
-769A;1.0;6613
-76AE;1.0;4073
-76B0;1.0;6614
-76B4;1.0;6615
-76B7;1.0;8373
-76B8;1.0;6616
-76B9;1.0;6617
-76BA;1.0;6618
-76BF;1.0;2714
-76C2;1.0;6619
-76C3;1.0;3954
-76C6;1.0;4363
-76C8;1.0;1746
-76CA;1.0;1755
-76CD;1.0;6620
-76D2;1.0;6622
-76D6;1.0;6621
-76D7;1.0;3780
-76DB;1.0;3225
-76DC;1.0;6125
-76DE;1.0;6623
-76DF;1.0;4433
-76E1;1.0;6624
-76E3;1.0;2038
-76E4;1.0;4055
-76E5;1.0;6625
-76E7;1.0;6626
-76EA;1.0;6627
-76EE;1.0;4460
-76F2;1.0;4453
-76F4;1.0;3630
-76F8;1.0;3374
-76FB;1.0;6629
-76FE;1.0;2966
-7701;1.0;3042
-7704;1.0;6632
-7707;1.0;6631
-7708;1.0;6630
-7709;1.0;4093
-770B;1.0;2039
-770C;1.0;2409
-771B;1.0;6638
-771E;1.0;6635
-771F;1.0;3131
-7720;1.0;4418
-7724;1.0;6634
-7725;1.0;6636
-7726;1.0;6637
-7729;1.0;6633
-7737;1.0;6639
-7738;1.0;6640
-773A;1.0;3615
-773C;1.0;2067
-7740;1.0;3569
-7747;1.0;6641
-775A;1.0;6642
-775B;1.0;6645
-7761;1.0;3171
-7763;1.0;3836
-7765;1.0;6646
-7766;1.0;4351
-7768;1.0;6643
-776B;1.0;6644
-7779;1.0;6649
-777E;1.0;6648
-777F;1.0;6647
-778B;1.0;6651
-778E;1.0;6650
-7791;1.0;6652
-779E;1.0;6654
-77A0;1.0;6653
-77A5;1.0;4245
-77AC;1.0;2954
-77AD;1.0;4638
-77B0;1.0;6655
-77B3;1.0;3823
-77B6;1.0;6656
-77B9;1.0;6657
-77BB;1.0;6661
-77BC;1.0;6659
-77BD;1.0;6660
-77BF;1.0;6658
-77C7;1.0;6662
-77CD;1.0;6663
-77D7;1.0;6664
-77DA;1.0;6665
-77DB;1.0;4423
-77DC;1.0;6666
-77E2;1.0;4480
-77E3;1.0;6667
-77E5;1.0;3546
-77E7;1.0;3974
-77E9;1.0;2275
-77ED;1.0;3527
-77EE;1.0;6668
-77EF;1.0;2226
-77F3;1.0;3248
-77FC;1.0;6669
-7802;1.0;2629
-780C;1.0;6670
-7812;1.0;6671
-7814;1.0;2406
-7815;1.0;2653
-7820;1.0;6673
-7825;1.0;3754
-7826;1.0;2654
-7827;1.0;2146
-7832;1.0;4304
-7834;1.0;3943
-783A;1.0;3755
-783F;1.0;2560
-7845;1.0;6675
-785D;1.0;3043
-786B;1.0;4618
-786C;1.0;2537
-786F;1.0;2407
-7872;1.0;4003
-7874;1.0;6677
-787C;1.0;6679
-7881;1.0;2475
-7886;1.0;6678
-7887;1.0;3686
-788C;1.0;6681
-788D;1.0;1923
-788E;1.0;6676
-7891;1.0;4074
-7893;1.0;1716
-7895;1.0;2676
-7897;1.0;4750
-789A;1.0;6680
-78A3;1.0;6682
-78A7;1.0;4243
-78A9;1.0;3257
-78AA;1.0;6684
-78AF;1.0;6685
-78B5;1.0;6683
-78BA;1.0;1946
-78BC;1.0;6691
-78BE;1.0;6690
-78C1;1.0;2807
-78C5;1.0;6692
-78C6;1.0;6687
-78CA;1.0;6693
-78CB;1.0;6688
-78D0;1.0;4056
-78D1;1.0;6686
-78D4;1.0;6689
-78DA;1.0;6702
-78E7;1.0;6701
-78E8;1.0;4365
-78EC;1.0;6694
-78EF;1.0;1675
-78F4;1.0;6704
-78FD;1.0;6703
-7901;1.0;3044
-7907;1.0;6705
-790E;1.0;3335
-7911;1.0;6707
-7912;1.0;6706
-7919;1.0;6708
-7926;1.0;6672
-792A;1.0;6674
-792B;1.0;6710
-792C;1.0;6709
-793A;1.0;2808
-793C;1.0;4673
-793E;1.0;2850
-7940;1.0;6711
-7941;1.0;2323
-7947;1.0;2132
-7948;1.0;2107
-7949;1.0;2767
-7950;1.0;4520
-7953;1.0;6717
-7955;1.0;6716
-7956;1.0;3336
-7957;1.0;6713
-795A;1.0;6715
-795D;1.0;2943
-795E;1.0;3132
-795F;1.0;6714
-7960;1.0;6712
-7962;1.0;3910
-7965;1.0;3045
-7968;1.0;4128
-796D;1.0;2655
-7977;1.0;3788
-797A;1.0;6718
-797F;1.0;6719
-7980;1.0;6741
-7981;1.0;2256
-7984;1.0;4729
-7985;1.0;3321
-798A;1.0;6720
-798D;1.0;1850
-798E;1.0;3687
-798F;1.0;4201
-799D;1.0;6721
-79A6;1.0;2190
-79A7;1.0;6722
-79AA;1.0;6724
-79AE;1.0;6725
-79B0;1.0;3909
-79B3;1.0;6726
-79B9;1.0;6727
-79BA;1.0;6728
-79BD;1.0;2257
-79BE;1.0;1851
-79BF;1.0;3837
-79C0;1.0;2908
-79C1;1.0;2768
-79C9;1.0;6729
-79CB;1.0;2909
-79D1;1.0;1842
-79D2;1.0;4135
-79D5;1.0;6730
-79D8;1.0;4075
-79DF;1.0;3337
-79E1;1.0;6733
-79E3;1.0;6734
-79E4;1.0;3973
-79E6;1.0;3133
-79E7;1.0;6731
-79E9;1.0;3565
-79EC;1.0;6732
-79F0;1.0;3046
-79FB;1.0;1660
-7A00;1.0;2109
-7A08;1.0;6735
-7A0B;1.0;3688
-7A0D;1.0;6736
-7A0E;1.0;3239
-7A14;1.0;4413
-7A17;1.0;4103
-7A18;1.0;6737
-7A19;1.0;6738
-7A1A;1.0;3553
-7A1C;1.0;4639
-7A1F;1.0;6740
-7A20;1.0;6739
-7A2E;1.0;2879
-7A31;1.0;6742
-7A32;1.0;1680
-7A37;1.0;6745
-7A3B;1.0;6743
-7A3C;1.0;1852
-7A3D;1.0;2346
-7A3E;1.0;6744
-7A3F;1.0;2538
-7A40;1.0;2582
-7A42;1.0;4270
-7A43;1.0;6746
-7A46;1.0;4352
-7A49;1.0;6748
-7A4D;1.0;3249
-7A4E;1.0;1747
-7A4F;1.0;1826
-7A50;1.0;1612
-7A57;1.0;6747
-7A61;1.0;6749
-7A62;1.0;6750
-7A63;1.0;3087
-7A69;1.0;6751
-7A6B;1.0;1947
-7A70;1.0;6753
-7A74;1.0;2374
-7A76;1.0;2170
-7A79;1.0;6754
-7A7A;1.0;2285
-7A7D;1.0;6755
-7A7F;1.0;3292
-7A81;1.0;3845
-7A83;1.0;3264
-7A84;1.0;2685
-7A88;1.0;6756
-7A92;1.0;3566
-7A93;1.0;3375
-7A95;1.0;6758
-7A96;1.0;6760
-7A97;1.0;6757
-7A98;1.0;6759
-7A9F;1.0;2302
-7AA9;1.0;6761
-7AAA;1.0;2306
-7AAE;1.0;2171
-7AAF;1.0;4550
-7AB0;1.0;6763
-7AB6;1.0;6764
-7ABA;1.0;1714
-7ABF;1.0;6767
-7AC3;1.0;1986
-7AC4;1.0;6766
-7AC5;1.0;6765
-7AC7;1.0;6769
-7AC8;1.0;6762
-7ACA;1.0;6770
-7ACB;1.0;4609
-7ACD;1.0;6771
-7ACF;1.0;6772
-7AD2;1.0;5284
-7AD3;1.0;6774
-7AD5;1.0;6773
-7AD9;1.0;6775
-7ADA;1.0;6776
-7ADC;1.0;4621
-7ADD;1.0;6777
-7ADF;1.0;8079
-7AE0;1.0;3047
-7AE1;1.0;6778
-7AE2;1.0;6779
-7AE3;1.0;2955
-7AE5;1.0;3824
-7AE6;1.0;6780
-7AEA;1.0;3508
-7AED;1.0;6781
-7AEF;1.0;3528
-7AF0;1.0;6782
-7AF6;1.0;2205
-7AF8;1.0;4931
-7AF9;1.0;3561
-7AFA;1.0;2819
-7AFF;1.0;2040
-7B02;1.0;6783
-7B04;1.0;6802
-7B06;1.0;6786
-7B08;1.0;2172
-7B0A;1.0;6785
-7B0B;1.0;6804
-7B0F;1.0;6784
-7B11;1.0;3048
-7B18;1.0;6788
-7B19;1.0;6789
-7B1B;1.0;3711
-7B1E;1.0;6790
-7B20;1.0;1962
-7B25;1.0;3158
-7B26;1.0;4168
-7B28;1.0;6792
-7B2C;1.0;3472
-7B33;1.0;6787
-7B35;1.0;6791
-7B36;1.0;6793
-7B39;1.0;2691
-7B45;1.0;6806
-7B46;1.0;4114
-7B48;1.0;4006
-7B49;1.0;3789
-7B4B;1.0;2258
-7B4C;1.0;6805
-7B4D;1.0;6803
-7B4F;1.0;4021
-7B50;1.0;6794
-7B51;1.0;3562
-7B52;1.0;3791
-7B54;1.0;3790
-7B56;1.0;2686
-7B5D;1.0;6824
-7B65;1.0;6808
-7B67;1.0;6810
-7B6C;1.0;6813
-7B6E;1.0;6814
-7B70;1.0;6811
-7B71;1.0;6812
-7B74;1.0;6809
-7B75;1.0;6807
-7B7A;1.0;6801
-7B86;1.0;4247
-7B87;1.0;1853
-7B8B;1.0;6821
-7B8D;1.0;6818
-7B8F;1.0;6823
-7B92;1.0;6822
-7B94;1.0;3983
-7B95;1.0;4407
-7B97;1.0;2727
-7B98;1.0;6816
-7B99;1.0;6825
-7B9A;1.0;6820
-7B9C;1.0;6819
-7B9D;1.0;6815
-7B9F;1.0;6817
-7BA1;1.0;2041
-7BAA;1.0;3529
-7BAD;1.0;3293
-7BB1;1.0;4002
-7BB4;1.0;6830
-7BB8;1.0;4004
-7BC0;1.0;3265
-7BC1;1.0;6827
-7BC4;1.0;4047
-7BC6;1.0;6831
-7BC7;1.0;4251
-7BC9;1.0;3559
-7BCB;1.0;6826
-7BCC;1.0;6828
-7BCF;1.0;6829
-7BDD;1.0;6832
-7BE0;1.0;2836
-7BE4;1.0;3838
-7BE5;1.0;6837
-7BE6;1.0;6836
-7BE9;1.0;6833
-7BED;1.0;4722
-7BF3;1.0;6842
-7BF6;1.0;6846
-7BF7;1.0;6843
-7C00;1.0;6839
-7C07;1.0;6840
-7C0D;1.0;6845
-7C11;1.0;6834
-7C12;1.0;5053
-7C13;1.0;6841
-7C14;1.0;6835
-7C17;1.0;6844
-7C1F;1.0;6850
-7C21;1.0;2042
-7C23;1.0;6847
-7C27;1.0;6848
-7C2A;1.0;6849
-7C2B;1.0;6852
-7C37;1.0;6851
-7C38;1.0;4086
-7C3D;1.0;6853
-7C3E;1.0;4692
-7C3F;1.0;4277
-7C40;1.0;6858
-7C43;1.0;6855
-7C4C;1.0;6854
-7C4D;1.0;3250
-7C4F;1.0;6857
-7C50;1.0;6859
-7C54;1.0;6856
-7C56;1.0;6863
-7C58;1.0;6860
-7C5F;1.0;6861
-7C60;1.0;6838
-7C64;1.0;6862
-7C65;1.0;6864
-7C6C;1.0;6865
-7C73;1.0;4238
-7C75;1.0;6866
-7C7E;1.0;4466
-7C81;1.0;2246
-7C82;1.0;2309
-7C83;1.0;6867
-7C89;1.0;4220
-7C8B;1.0;3172
-7C8D;1.0;4416
-7C90;1.0;6868
-7C92;1.0;4619
-7C95;1.0;3984
-7C97;1.0;3338
-7C98;1.0;3920
-7C9B;1.0;2945
-7C9F;1.0;1632
-7CA1;1.0;6873
-7CA2;1.0;6871
-7CA4;1.0;6869
-7CA5;1.0;2001
-7CA7;1.0;3049
-7CA8;1.0;6874
-7CAB;1.0;6872
-7CAD;1.0;6870
-7CAE;1.0;6878
-7CB1;1.0;6877
-7CB2;1.0;6876
-7CB3;1.0;6875
-7CB9;1.0;6879
-7CBD;1.0;6880
-7CBE;1.0;3226
-7CC0;1.0;6881
-7CC2;1.0;6883
-7CC5;1.0;6882
-7CCA;1.0;2450
-7CCE;1.0;3324
-7CD2;1.0;6885
-7CD6;1.0;3792
-7CD8;1.0;6884
-7CDC;1.0;6886
-7CDE;1.0;4221
-7CDF;1.0;3376
-7CE0;1.0;2539
-7CE2;1.0;6887
-7CE7;1.0;4640
-7CEF;1.0;6889
-7CF2;1.0;6890
-7CF4;1.0;6891
-7CF6;1.0;6892
-7CF8;1.0;2769
-7CFA;1.0;6893
-7CFB;1.0;2347
-7CFE;1.0;2174
-7D00;1.0;2110
-7D02;1.0;6901
-7D04;1.0;4483
-7D05;1.0;2540
-7D06;1.0;6894
-7D0A;1.0;6904
-7D0B;1.0;4470
-7D0D;1.0;3928
-7D10;1.0;4119
-7D14;1.0;2967
-7D15;1.0;6903
-7D17;1.0;2851
-7D18;1.0;2541
-7D19;1.0;2770
-7D1A;1.0;2173
-7D1B;1.0;4222
-7D1C;1.0;6902
-7D20;1.0;3339
-7D21;1.0;4334
-7D22;1.0;2687
-7D2B;1.0;2771
-7D2C;1.0;3661
-7D2E;1.0;6907
-7D2F;1.0;4663
-7D30;1.0;2657
-7D32;1.0;6908
-7D33;1.0;3134
-7D35;1.0;6910
-7D39;1.0;3050
-7D3A;1.0;2616
-7D3F;1.0;6909
-7D42;1.0;2910
-7D43;1.0;2430
-7D44;1.0;3340
-7D45;1.0;6905
-7D46;1.0;6911
-7D4B;1.0;6906
-7D4C;1.0;2348
-7D4E;1.0;6914
-7D4F;1.0;6918
-7D50;1.0;2375
-7D56;1.0;6913
-7D5B;1.0;6922
-7D5E;1.0;2542
-7D61;1.0;4577
-7D62;1.0;1628
-7D63;1.0;6919
-7D66;1.0;2175
-7D68;1.0;6916
-7D6E;1.0;6917
-7D71;1.0;3793
-7D72;1.0;6915
-7D73;1.0;6912
-7D75;1.0;1908
-7D76;1.0;3268
-7D79;1.0;2408
-7D7D;1.0;6924
-7D89;1.0;6921
-7D8F;1.0;6923
-7D93;1.0;6920
-7D99;1.0;2349
-7D9A;1.0;3419
-7D9B;1.0;6925
-7D9C;1.0;3378
-7D9F;1.0;6938
-7DA2;1.0;6934
-7DA3;1.0;6928
-7DAB;1.0;6932
-7DAC;1.0;2890
-7DAD;1.0;1661
-7DAE;1.0;6927
-7DAF;1.0;6935
-7DB0;1.0;6939
-7DB1;1.0;2543
-7DB2;1.0;4454
-7DB4;1.0;3654
-7DB5;1.0;6929
-7DB8;1.0;6937
-7DBA;1.0;6926
-7DBB;1.0;3530
-7DBD;1.0;6931
-7DBE;1.0;1629
-7DBF;1.0;4442
-7DC7;1.0;6930
-7DCA;1.0;2259
-7DCB;1.0;4076
-7DCF;1.0;3377
-7DD1;1.0;4648
-7DD2;1.0;2979
-7DD5;1.0;6978
-7DD8;1.0;6940
-7DDA;1.0;3294
-7DDC;1.0;6936
-7DDD;1.0;6941
-7DDE;1.0;6943
-7DE0;1.0;3689
-7DE1;1.0;6946
-7DE4;1.0;6942
-7DE8;1.0;4252
-7DE9;1.0;2043
-7DEC;1.0;4443
-7DEF;1.0;1662
-7DF2;1.0;6945
-7DF4;1.0;4693
-7DFB;1.0;6944
-7E01;1.0;1779
-7E04;1.0;3876
-7E05;1.0;6947
-7E09;1.0;6954
-7E0A;1.0;6948
-7E0B;1.0;6955
-7E12;1.0;6951
-7E1B;1.0;3991
-7E1E;1.0;2842
-7E1F;1.0;6953
-7E21;1.0;6950
-7E22;1.0;6956
-7E23;1.0;6949
-7E26;1.0;2936
-7E2B;1.0;4305
-7E2E;1.0;2944
-7E31;1.0;6952
-7E32;1.0;6964
-7E35;1.0;6960
-7E37;1.0;6963
-7E39;1.0;6961
-7E3A;1.0;6965
-7E3B;1.0;6959
-7E3D;1.0;6933
-7E3E;1.0;3251
-7E41;1.0;4043
-7E43;1.0;6962
-7E46;1.0;6957
-7E4A;1.0;3301
-7E4B;1.0;2350
-7E4D;1.0;2911
-7E54;1.0;3105
-7E55;1.0;3322
-7E56;1.0;6968
-7E59;1.0;6970
-7E5A;1.0;6971
-7E5D;1.0;6967
-7E5E;1.0;6969
-7E66;1.0;6958
-7E67;1.0;6966
-7E69;1.0;6974
-7E6A;1.0;6973
-7E6D;1.0;4390
-7E70;1.0;2311
-7E79;1.0;6972
-7E7B;1.0;6976
-7E7C;1.0;6975
-7E7D;1.0;6979
-7E7F;1.0;6981
-7E82;1.0;2728
-7E83;1.0;6977
-7E88;1.0;6982
-7E89;1.0;6983
-7E8C;1.0;6984
-7E8E;1.0;6990
-7E8F;1.0;3727
-7E90;1.0;6986
-7E92;1.0;6985
-7E93;1.0;6987
-7E94;1.0;6988
-7E96;1.0;6989
-7E9B;1.0;6991
-7E9C;1.0;6992
-7F36;1.0;2044
-7F38;1.0;6993
-7F3A;1.0;6994
-7F45;1.0;7001
-7F4C;1.0;7002
-7F4D;1.0;7003
-7F4E;1.0;7004
-7F50;1.0;7005
-7F51;1.0;7006
-7F54;1.0;7008
-7F55;1.0;7007
-7F58;1.0;7009
-7F5F;1.0;7010
-7F60;1.0;7011
-7F67;1.0;7014
-7F68;1.0;7012
-7F69;1.0;7013
-7F6A;1.0;2665
-7F6B;1.0;2351
-7F6E;1.0;3554
-7F70;1.0;4019
-7F72;1.0;2980
-7F75;1.0;3945
-7F77;1.0;4077
-7F78;1.0;7015
-7F79;1.0;5677
-7F82;1.0;7016
-7F83;1.0;7018
-7F85;1.0;4569
-7F86;1.0;7017
-7F87;1.0;7020
-7F88;1.0;7019
-7F8A;1.0;4551
-7F8C;1.0;7021
-7F8E;1.0;4094
-7F94;1.0;7022
-7F9A;1.0;7025
-7F9D;1.0;7024
-7F9E;1.0;7023
-7FA3;1.0;7026
-7FA4;1.0;2318
-7FA8;1.0;3302
-7FA9;1.0;2133
-7FAE;1.0;7030
-7FAF;1.0;7027
-7FB2;1.0;7028
-7FB6;1.0;7031
-7FB8;1.0;7032
-7FB9;1.0;7029
-7FBD;1.0;1709
-7FC1;1.0;1807
-7FC5;1.0;7034
-7FC6;1.0;7035
-7FCA;1.0;7036
-7FCC;1.0;4566
-7FD2;1.0;2912
-7FD4;1.0;7038
-7FD5;1.0;7037
-7FE0;1.0;3173
-7FE1;1.0;7039
-7FE6;1.0;7040
-7FE9;1.0;7041
-7FEB;1.0;2069
-7FF0;1.0;2045
-7FF3;1.0;7042
-7FF9;1.0;7043
-7FFB;1.0;4361
-7FFC;1.0;4567
-8000;1.0;4552
-8001;1.0;4723
-8003;1.0;2545
-8004;1.0;7046
-8005;1.0;2852
-8006;1.0;7045
-800B;1.0;7047
-800C;1.0;2809
-8010;1.0;3449
-8012;1.0;7048
-8015;1.0;2544
-8017;1.0;4455
-8018;1.0;7049
-8019;1.0;7050
-801C;1.0;7051
-8021;1.0;7052
-8028;1.0;7053
-8033;1.0;2810
-8036;1.0;4477
-803B;1.0;7055
-803D;1.0;3531
-803F;1.0;7054
-8046;1.0;7057
-804A;1.0;7056
-8052;1.0;7058
-8056;1.0;3227
-8058;1.0;7059
-805A;1.0;7060
-805E;1.0;4225
-805F;1.0;7061
-8061;1.0;3379
-8062;1.0;7062
-8068;1.0;7063
-806F;1.0;4694
-8070;1.0;7066
-8072;1.0;7065
-8073;1.0;7064
-8074;1.0;3616
-8076;1.0;7067
-8077;1.0;3106
-8079;1.0;7068
-807D;1.0;7069
-807E;1.0;4724
-807F;1.0;7070
-8084;1.0;7071
-8085;1.0;7073
-8086;1.0;7072
-8087;1.0;4005
-8089;1.0;3889
-808B;1.0;4730
-808C;1.0;4009
-8093;1.0;7075
-8096;1.0;3051
-8098;1.0;4110
-809A;1.0;7076
-809B;1.0;7074
-809D;1.0;2046
-80A1;1.0;2452
-80A2;1.0;2772
-80A5;1.0;4078
-80A9;1.0;2410
-80AA;1.0;4335
-80AC;1.0;7079
-80AD;1.0;7077
-80AF;1.0;2546
-80B1;1.0;2547
-80B2;1.0;1673
-80B4;1.0;2672
-80BA;1.0;3957
-80C3;1.0;1663
-80C4;1.0;7084
-80C6;1.0;3532
-80CC;1.0;3956
-80CE;1.0;3459
-80D6;1.0;7086
-80D9;1.0;7082
-80DA;1.0;7085
-80DB;1.0;7080
-80DD;1.0;7083
-80DE;1.0;4306
-80E1;1.0;2453
-80E4;1.0;1693
-80E5;1.0;7081
-80EF;1.0;7088
-80F1;1.0;7089
-80F4;1.0;3825
-80F8;1.0;2227
-80FC;1.0;7106
-80FD;1.0;3929
-8102;1.0;2773
-8105;1.0;2228
-8106;1.0;3240
-8107;1.0;4738
-8108;1.0;4414
-8109;1.0;7087
-810A;1.0;3252
-811A;1.0;2151
-811B;1.0;7090
-8123;1.0;7092
-8129;1.0;7091
-812F;1.0;7093
-8131;1.0;3506
-8133;1.0;3930
-8139;1.0;3617
-813E;1.0;7103
-8146;1.0;7102
-814B;1.0;7094
-814E;1.0;3153
-8150;1.0;4169
-8151;1.0;7105
-8153;1.0;7104
-8154;1.0;2548
-8155;1.0;4751
-815F;1.0;7121
-8165;1.0;7109
-8166;1.0;7110
-816B;1.0;2880
-816E;1.0;7108
-8170;1.0;2588
-8171;1.0;7107
-8174;1.0;7111
-8178;1.0;3618
-8179;1.0;4202
-817A;1.0;3303
-817F;1.0;3460
-8180;1.0;7115
-8182;1.0;7116
-8183;1.0;7112
-8188;1.0;7113
-818A;1.0;7114
-818F;1.0;2549
-8193;1.0;7122
-8195;1.0;7118
-819A;1.0;4170
-819C;1.0;4376
-819D;1.0;4108
-81A0;1.0;7117
-81A3;1.0;7120
-81A4;1.0;7119
-81A8;1.0;4336
-81A9;1.0;7123
-81B0;1.0;7124
-81B3;1.0;3323
-81B5;1.0;7125
-81B8;1.0;7127
-81BA;1.0;7131
-81BD;1.0;7128
-81BE;1.0;7126
-81BF;1.0;3931
-81C0;1.0;7129
-81C2;1.0;7130
-81C6;1.0;1818
-81C8;1.0;7137
-81C9;1.0;7132
-81CD;1.0;7133
-81D1;1.0;7134
-81D3;1.0;3401
-81D8;1.0;7136
-81D9;1.0;7135
-81DA;1.0;7138
-81DF;1.0;7139
-81E0;1.0;7140
-81E3;1.0;3135
-81E5;1.0;1873
-81E7;1.0;7141
-81E8;1.0;4655
-81EA;1.0;2811
-81ED;1.0;2913
-81F3;1.0;2774
-81F4;1.0;3555
-81FA;1.0;7142
-81FB;1.0;7143
-81FC;1.0;1717
-81FE;1.0;7144
-8201;1.0;7145
-8202;1.0;7146
-8205;1.0;7147
-8207;1.0;7148
-8208;1.0;2229
-8209;1.0;5810
-820A;1.0;7149
-820C;1.0;3269
-820D;1.0;7150
-820E;1.0;2843
-8210;1.0;7151
-8212;1.0;4816
-8216;1.0;7152
-8217;1.0;4262
-8218;1.0;2060
-821B;1.0;3304
-821C;1.0;2956
-821E;1.0;4181
-821F;1.0;2914
-8229;1.0;7153
-822A;1.0;2550
-822B;1.0;7154
-822C;1.0;4044
-822E;1.0;7168
-8233;1.0;7156
-8235;1.0;3441
-8236;1.0;3985
-8237;1.0;2431
-8238;1.0;7155
-8239;1.0;3305
-8240;1.0;7157
-8247;1.0;3690
-8258;1.0;7159
-8259;1.0;7158
-825A;1.0;7161
-825D;1.0;7160
-825F;1.0;7162
-8262;1.0;7164
-8264;1.0;7163
-8266;1.0;2047
-8268;1.0;7165
-826A;1.0;7166
-826B;1.0;7167
-826E;1.0;2617
-826F;1.0;4641
-8271;1.0;7169
-8272;1.0;3107
-8276;1.0;1780
-8277;1.0;7170
-8278;1.0;7171
-827E;1.0;7172
-828B;1.0;1682
-828D;1.0;7173
-8292;1.0;7174
-8299;1.0;4171
-829D;1.0;2839
-829F;1.0;7176
-82A5;1.0;1909
-82A6;1.0;1618
-82AB;1.0;7175
-82AC;1.0;7178
-82AD;1.0;3946
-82AF;1.0;3136
-82B1;1.0;1854
-82B3;1.0;4307
-82B8;1.0;2361
-82B9;1.0;2260
-82BB;1.0;7177
-82BD;1.0;1874
-82C5;1.0;2003
-82D1;1.0;1781
-82D2;1.0;7182
-82D3;1.0;4674
-82D4;1.0;3461
-82D7;1.0;4136
-82D9;1.0;7194
-82DB;1.0;1855
-82DC;1.0;7192
-82DE;1.0;7190
-82DF;1.0;7181
-82E1;1.0;7179
-82E3;1.0;7180
-82E5;1.0;2867
-82E6;1.0;2276
-82E7;1.0;3587
-82EB;1.0;3849
-82F1;1.0;1749
-82F3;1.0;7184
-82F4;1.0;7183
-82F9;1.0;7189
-82FA;1.0;7185
-82FB;1.0;7188
-8302;1.0;4448
-8303;1.0;7187
-8304;1.0;1856
-8305;1.0;1993
-8306;1.0;7191
-8309;1.0;7193
-830E;1.0;2352
-8316;1.0;7203
-8317;1.0;7212
-8318;1.0;7213
-831C;1.0;1611
-8323;1.0;7220
-8328;1.0;1681
-832B;1.0;7211
-832F;1.0;7210
-8331;1.0;7205
-8332;1.0;7204
-8334;1.0;7202
-8335;1.0;7201
-8336;1.0;3567
-8338;1.0;3491
-8339;1.0;7207
-8340;1.0;7206
-8345;1.0;7209
-8349;1.0;3380
-834A;1.0;2353
-834F;1.0;1733
-8350;1.0;7208
-8352;1.0;2551
-8358;1.0;3381
-8373;1.0;7226
-8375;1.0;7227
-8377;1.0;1857
-837B;1.0;1814
-837C;1.0;7224
-8385;1.0;7214
-8387;1.0;7222
-8389;1.0;7229
-838A;1.0;7223
-838E;1.0;7221
-8393;1.0;7186
-8396;1.0;7219
-839A;1.0;7215
-839E;1.0;2048
-839F;1.0;7217
-83A0;1.0;7228
-83A2;1.0;7218
-83A8;1.0;7230
-83AA;1.0;7216
-83AB;1.0;3992
-83B1;1.0;4573
-83B5;1.0;7225
-83BD;1.0;7247
-83C1;1.0;7239
-83C5;1.0;3191
-83CA;1.0;2138
-83CC;1.0;2261
-83CE;1.0;7234
-83D3;1.0;1859
-83D6;1.0;3052
-83D8;1.0;7237
-83DC;1.0;2658
-83DF;1.0;3749
-83E0;1.0;7242
-83E9;1.0;4278
-83EB;1.0;7233
-83EF;1.0;1858
-83F0;1.0;2454
-83F1;1.0;4109
-83F2;1.0;7243
-83F4;1.0;7231
-83F7;1.0;7240
-83FB;1.0;7250
-83FD;1.0;7235
-8403;1.0;7236
-8404;1.0;3826
-8407;1.0;7241
-840B;1.0;7238
-840C;1.0;4308
-840D;1.0;7244
-840E;1.0;1664
-8413;1.0;7232
-8420;1.0;7246
-8422;1.0;7245
-8429;1.0;3975
-842A;1.0;7252
-842C;1.0;7263
-8431;1.0;1994
-8435;1.0;7266
-8438;1.0;7248
-843C;1.0;7253
-843D;1.0;4578
-8446;1.0;7262
-8449;1.0;4553
-844E;1.0;4610
-8457;1.0;3588
-845B;1.0;1975
-8461;1.0;4182
-8462;1.0;7268
-8463;1.0;3801
-8466;1.0;1617
-8469;1.0;7261
-846B;1.0;7257
-846C;1.0;3382
-846D;1.0;7251
-846E;1.0;7259
-846F;1.0;7264
-8471;1.0;3912
-8475;1.0;1610
-8477;1.0;7256
-8479;1.0;7265
-847A;1.0;4188
-8482;1.0;7260
-8484;1.0;7255
-848B;1.0;3053
-8490;1.0;2915
-8494;1.0;2812
-8499;1.0;4456
-849C;1.0;4139
-849F;1.0;7271
-84A1;1.0;7280
-84AD;1.0;7258
-84B2;1.0;1987
-84B8;1.0;3088
-84B9;1.0;7269
-84BB;1.0;7274
-84BC;1.0;3383
-84BF;1.0;7270
-84C1;1.0;7277
-84C4;1.0;3563
-84C6;1.0;7278
-84C9;1.0;4554
-84CA;1.0;7267
-84CB;1.0;1924
-84CD;1.0;7273
-84D0;1.0;7276
-84D1;1.0;4412
-84D6;1.0;7279
-84D9;1.0;7272
-84DA;1.0;7275
-84EC;1.0;4309
-84EE;1.0;4701
-84F4;1.0;7283
-84FC;1.0;7290
-84FF;1.0;7282
-8500;1.0;2835
-8506;1.0;7249
-8511;1.0;4246
-8513;1.0;4402
-8514;1.0;7289
-8515;1.0;7288
-8517;1.0;7284
-8518;1.0;7285
-851A;1.0;1722
-851F;1.0;7287
-8521;1.0;7281
-8526;1.0;3653
-852C;1.0;7286
-852D;1.0;1694
-8535;1.0;3402
-853D;1.0;4235
-8540;1.0;7291
-8541;1.0;7301
-8543;1.0;4057
-8548;1.0;7294
-8549;1.0;3054
-854A;1.0;2841
-854B;1.0;7303
-854E;1.0;2230
-8555;1.0;7304
-8557;1.0;4189
-8558;1.0;7293
-855A;1.0;7254
-8563;1.0;7292
-8568;1.0;4747
-8569;1.0;3802
-856A;1.0;4183
-856D;1.0;7311
-8577;1.0;7317
-857E;1.0;7318
-8580;1.0;7305
-8584;1.0;3986
-8587;1.0;7315
-8588;1.0;7307
-858A;1.0;7309
-8590;1.0;7319
-8591;1.0;7308
-8594;1.0;7312
-8597;1.0;1782
-8599;1.0;3869
-859B;1.0;7313
-859C;1.0;7316
-85A4;1.0;7306
-85A6;1.0;3306
-85A8;1.0;7310
-85A9;1.0;2707
-85AA;1.0;3137
-85AB;1.0;2316
-85AC;1.0;4484
-85AE;1.0;4489
-85AF;1.0;2982
-85B9;1.0;7323
-85BA;1.0;7321
-85C1;1.0;4746
-85C9;1.0;7320
-85CD;1.0;4585
-85CF;1.0;7322
-85D0;1.0;7324
-85D5;1.0;7325
-85DC;1.0;7328
-85DD;1.0;7326
-85E4;1.0;3803
-85E5;1.0;7327
-85E9;1.0;4045
-85EA;1.0;7314
-85F7;1.0;2983
-85F9;1.0;7329
-85FA;1.0;7334
-85FB;1.0;3384
-85FE;1.0;7333
-8602;1.0;7302
-8606;1.0;7335
-8607;1.0;3341
-860A;1.0;7330
-860B;1.0;7332
-8613;1.0;7331
-8616;1.0;6117
-8617;1.0;6102
-861A;1.0;7337
-8622;1.0;7336
-862D;1.0;4586
-862F;1.0;6628
-8630;1.0;7338
-863F;1.0;7339
-864D;1.0;7340
-864E;1.0;2455
-8650;1.0;2152
-8654;1.0;7342
-8655;1.0;4961
-865A;1.0;2185
-865C;1.0;4626
-865E;1.0;2283
-865F;1.0;7343
-8667;1.0;7344
-866B;1.0;3578
-8671;1.0;7345
-8679;1.0;3890
-867B;1.0;1626
-868A;1.0;1867
-868B;1.0;7350
-868C;1.0;7351
-8693;1.0;7346
-8695;1.0;2729
-86A3;1.0;7347
-86A4;1.0;3934
-86A9;1.0;7348
-86AA;1.0;7349
-86AB;1.0;7359
-86AF;1.0;7353
-86B0;1.0;7356
-86B6;1.0;7352
-86C4;1.0;7354
-86C6;1.0;7355
-86C7;1.0;2856
-86C9;1.0;7357
-86CB;1.0;3533
-86CD;1.0;2354
-86CE;1.0;1934
-86D4;1.0;7360
-86D9;1.0;1931
-86DB;1.0;7365
-86DE;1.0;7361
-86DF;1.0;7364
-86E4;1.0;4026
-86E9;1.0;7362
-86EC;1.0;7363
-86ED;1.0;4140
-86EE;1.0;4058
-86EF;1.0;7366
-86F8;1.0;3493
-86F9;1.0;7376
-86FB;1.0;7372
-86FE;1.0;1875
-8700;1.0;7370
-8702;1.0;4310
-8703;1.0;7371
-8706;1.0;7368
-8708;1.0;7369
-8709;1.0;7374
-870A;1.0;7377
-870D;1.0;7375
-8711;1.0;7373
-8712;1.0;7367
-8718;1.0;3556
-871A;1.0;7384
-871C;1.0;4410
-8725;1.0;7382
-8729;1.0;7383
-8734;1.0;7378
-8737;1.0;7380
-873B;1.0;7381
-873F;1.0;7379
-8749;1.0;3270
-874B;1.0;4725
-874C;1.0;7388
-874E;1.0;7389
-8753;1.0;7401
-8755;1.0;3110
-8757;1.0;7391
-8759;1.0;7394
-875F;1.0;7386
-8760;1.0;7385
-8763;1.0;7402
-8766;1.0;1860
-8768;1.0;7392
-876A;1.0;7403
-876E;1.0;7393
-8774;1.0;7390
-8776;1.0;3619
-8778;1.0;7387
-877F;1.0;3972
-8782;1.0;7407
-878D;1.0;4527
-879F;1.0;7406
-87A2;1.0;7405
-87AB;1.0;7414
-87AF;1.0;7408
-87B3;1.0;7416
-87BA;1.0;4570
-87BB;1.0;7419
-87BD;1.0;7410
-87C0;1.0;7411
-87C4;1.0;7415
-87C6;1.0;7418
-87C7;1.0;7417
-87CB;1.0;7409
-87D0;1.0;7412
-87D2;1.0;7429
-87E0;1.0;7422
-87EF;1.0;7420
-87F2;1.0;7421
-87F6;1.0;7426
-87F7;1.0;7427
-87F9;1.0;1910
-87FB;1.0;2134
-87FE;1.0;7425
-8805;1.0;7404
-880D;1.0;7424
-880E;1.0;7428
-880F;1.0;7423
-8811;1.0;7430
-8815;1.0;7432
-8816;1.0;7431
-8821;1.0;7434
-8822;1.0;7433
-8823;1.0;7358
-8827;1.0;7438
-8831;1.0;7435
-8836;1.0;7436
-8839;1.0;7437
-883B;1.0;7439
-8840;1.0;2376
-8842;1.0;7441
-8844;1.0;7440
-8846;1.0;2916
-884C;1.0;2552
-884D;1.0;6207
-8852;1.0;7442
-8853;1.0;2949
-8857;1.0;1925
-8859;1.0;7443
-885B;1.0;1750
-885D;1.0;3055
-885E;1.0;7444
-8861;1.0;2553
-8862;1.0;7445
-8863;1.0;1665
-8868;1.0;4129
-886B;1.0;7446
-8870;1.0;3174
-8872;1.0;7453
-8875;1.0;7450
-8877;1.0;3579
-887D;1.0;7451
-887E;1.0;7448
-887F;1.0;2262
-8881;1.0;7447
-8882;1.0;7454
-8888;1.0;2322
-888B;1.0;3462
-888D;1.0;7460
-8892;1.0;7456
-8896;1.0;3421
-8897;1.0;7455
-8899;1.0;7458
-889E;1.0;7449
-88A2;1.0;7459
-88A4;1.0;7461
-88AB;1.0;4079
-88AE;1.0;7457
-88B0;1.0;7462
-88B1;1.0;7464
-88B4;1.0;2451
-88B5;1.0;7452
-88B7;1.0;1633
-88BF;1.0;7463
-88C1;1.0;2659
-88C2;1.0;4686
-88C3;1.0;7465
-88C4;1.0;7466
-88C5;1.0;3385
-88CF;1.0;4602
-88D4;1.0;7467
-88D5;1.0;4521
-88D8;1.0;7468
-88D9;1.0;7469
-88DC;1.0;4268
-88DD;1.0;7470
-88DF;1.0;2632
-88E1;1.0;4603
-88E8;1.0;7475
-88F2;1.0;7476
-88F3;1.0;3056
-88F4;1.0;7474
-88F8;1.0;4571
-88F9;1.0;7471
-88FC;1.0;7473
-88FD;1.0;3229
-88FE;1.0;3194
-8902;1.0;7472
-8904;1.0;7477
-8907;1.0;4203
-890A;1.0;7479
-890C;1.0;7478
-8910;1.0;1976
-8912;1.0;4311
-8913;1.0;7480
-891D;1.0;7492
-891E;1.0;7482
-8925;1.0;7483
-892A;1.0;7484
-892B;1.0;7485
-8936;1.0;7489
-8938;1.0;7490
-893B;1.0;7488
-8941;1.0;7486
-8943;1.0;7481
-8944;1.0;7487
-894C;1.0;7491
-894D;1.0;8023
-8956;1.0;1808
-895E;1.0;7494
-895F;1.0;2263
-8960;1.0;7493
-8964;1.0;7502
-8966;1.0;7501
-896A;1.0;7504
-896D;1.0;7503
-896F;1.0;7505
-8972;1.0;2917
-8974;1.0;7506
-8977;1.0;7507
-897E;1.0;7508
-897F;1.0;3230
-8981;1.0;4555
-8983;1.0;7509
-8986;1.0;4204
-8987;1.0;3938
-8988;1.0;7510
-898A;1.0;7511
-898B;1.0;2411
-898F;1.0;2112
-8993;1.0;7512
-8996;1.0;2775
-8997;1.0;3933
-8998;1.0;7513
-899A;1.0;1948
-89A1;1.0;7514
-89A6;1.0;7516
-89A7;1.0;4587
-89A9;1.0;7515
-89AA;1.0;3138
-89AC;1.0;7517
-89AF;1.0;7518
-89B2;1.0;7519
-89B3;1.0;2049
-89BA;1.0;7520
-89BD;1.0;7521
-89BF;1.0;7522
-89C0;1.0;7523
-89D2;1.0;1949
-89DA;1.0;7524
-89DC;1.0;7525
-89DD;1.0;7526
-89E3;1.0;1882
-89E6;1.0;3108
-89E7;1.0;7527
-89F4;1.0;7528
-89F8;1.0;7529
-8A00;1.0;2432
-8A02;1.0;3691
-8A03;1.0;7530
-8A08;1.0;2355
-8A0A;1.0;3154
-8A0C;1.0;7533
-8A0E;1.0;3804
-8A10;1.0;7532
-8A13;1.0;2317
-8A16;1.0;7531
-8A17;1.0;3487
-8A18;1.0;2113
-8A1B;1.0;7534
-8A1D;1.0;7535
-8A1F;1.0;3057
-8A23;1.0;2377
-8A25;1.0;7536
-8A2A;1.0;4312
-8A2D;1.0;3263
-8A31;1.0;2186
-8A33;1.0;4485
-8A34;1.0;3342
-8A36;1.0;7537
-8A3A;1.0;3139
-8A3B;1.0;3580
-8A3C;1.0;3058
-8A41;1.0;7538
-8A46;1.0;7541
-8A48;1.0;7542
-8A50;1.0;2630
-8A51;1.0;3434
-8A52;1.0;7540
-8A54;1.0;3059
-8A55;1.0;4130
-8A5B;1.0;7539
-8A5E;1.0;2776
-8A60;1.0;1751
-8A62;1.0;7546
-8A63;1.0;2356
-8A66;1.0;2778
-8A69;1.0;2777
-8A6B;1.0;4745
-8A6C;1.0;7545
-8A6D;1.0;7544
-8A6E;1.0;3307
-8A70;1.0;2145
-8A71;1.0;4735
-8A72;1.0;1926
-8A73;1.0;3060
-8A7C;1.0;7543
-8A82;1.0;7548
-8A84;1.0;7549
-8A85;1.0;7547
-8A87;1.0;2456
-8A89;1.0;4532
-8A8C;1.0;2779
-8A8D;1.0;3907
-8A91;1.0;7552
-8A93;1.0;3232
-8A95;1.0;3534
-8A98;1.0;4522
-8A9A;1.0;7555
-8A9E;1.0;2476
-8AA0;1.0;3231
-8AA1;1.0;7551
-8AA3;1.0;7556
-8AA4;1.0;2477
-8AA5;1.0;7553
-8AA6;1.0;7554
-8AA8;1.0;7550
-8AAC;1.0;3266
-8AAD;1.0;3841
-8AB0;1.0;3515
-8AB2;1.0;1861
-8AB9;1.0;4080
-8ABC;1.0;2135
-8ABF;1.0;3620
-8AC2;1.0;7559
-8AC4;1.0;7557
-8AC7;1.0;3544
-8ACB;1.0;3233
-8ACC;1.0;2050
-8ACD;1.0;7558
-8ACF;1.0;3159
-8AD2;1.0;4642
-8AD6;1.0;4732
-8ADA;1.0;7560
-8ADB;1.0;7571
-8ADC;1.0;3621
-8ADE;1.0;7570
-8AE0;1.0;7567
-8AE1;1.0;7575
-8AE2;1.0;7568
-8AE4;1.0;7564
-8AE6;1.0;3692
-8AE7;1.0;7563
-8AEB;1.0;7561
-8AED;1.0;4501
-8AEE;1.0;2780
-8AF1;1.0;7565
-8AF3;1.0;7562
-8AF7;1.0;7569
-8AF8;1.0;2984
-8AFA;1.0;2433
-8AFE;1.0;3490
-8B00;1.0;4337
-8B01;1.0;1758
-8B02;1.0;1666
-8B04;1.0;3805
-8B07;1.0;7573
-8B0C;1.0;7572
-8B0E;1.0;3870
-8B10;1.0;7577
-8B14;1.0;7566
-8B16;1.0;7576
-8B17;1.0;7578
-8B19;1.0;2412
-8B1A;1.0;7574
-8B1B;1.0;2554
-8B1D;1.0;2853
-8B20;1.0;7579
-8B21;1.0;4556
-8B26;1.0;7582
-8B28;1.0;7585
-8B2B;1.0;7583
-8B2C;1.0;4121
-8B33;1.0;7580
-8B39;1.0;2264
-8B3E;1.0;7584
-8B41;1.0;7586
-8B49;1.0;7590
-8B4C;1.0;7587
-8B4E;1.0;7589
-8B4F;1.0;7588
-8B56;1.0;7591
-8B58;1.0;2817
-8B5A;1.0;7593
-8B5B;1.0;7592
-8B5C;1.0;4172
-8B5F;1.0;7601
-8B66;1.0;2357
-8B6B;1.0;7594
-8B6C;1.0;7602
-8B6F;1.0;7603
-8B70;1.0;2136
-8B71;1.0;7033
-8B72;1.0;3089
-8B74;1.0;7604
-8B77;1.0;2478
-8B7D;1.0;7605
-8B80;1.0;7606
-8B83;1.0;2730
-8B8A;1.0;5846
-8B8C;1.0;7607
-8B8E;1.0;7608
-8B90;1.0;2918
-8B92;1.0;7609
-8B93;1.0;7610
-8B96;1.0;7611
-8B99;1.0;7612
-8B9A;1.0;7613
-8C37;1.0;3511
-8C3A;1.0;7614
-8C3F;1.0;7616
-8C41;1.0;7615
-8C46;1.0;3806
-8C48;1.0;7617
-8C4A;1.0;4313
-8C4C;1.0;7618
-8C4E;1.0;7619
-8C50;1.0;7620
-8C55;1.0;7621
-8C5A;1.0;3858
-8C61;1.0;3061
-8C62;1.0;7622
-8C6A;1.0;2575
-8C6B;1.0;4814
-8C6C;1.0;7623
-8C78;1.0;7624
-8C79;1.0;4131
-8C7A;1.0;7625
-8C7C;1.0;7633
-8C82;1.0;7626
-8C85;1.0;7628
-8C89;1.0;7627
-8C8A;1.0;7629
-8C8C;1.0;4338
-8C8D;1.0;7630
-8C8E;1.0;7631
-8C94;1.0;7632
-8C98;1.0;7634
-8C9D;1.0;1913
-8C9E;1.0;3671
-8CA0;1.0;4173
-8CA1;1.0;2666
-8CA2;1.0;2555
-8CA7;1.0;4147
-8CA8;1.0;1863
-8CA9;1.0;4046
-8CAA;1.0;7637
-8CAB;1.0;2051
-8CAC;1.0;3253
-8CAD;1.0;7636
-8CAE;1.0;7641
-8CAF;1.0;3589
-8CB0;1.0;4467
-8CB2;1.0;7639
-8CB3;1.0;7640
-8CB4;1.0;2114
-8CB6;1.0;7642
-8CB7;1.0;3967
-8CB8;1.0;3463
-8CBB;1.0;4081
-8CBC;1.0;3729
-8CBD;1.0;7638
-8CBF;1.0;4339
-8CC0;1.0;1876
-8CC1;1.0;7644
-8CC2;1.0;4708
-8CC3;1.0;3634
-8CC4;1.0;4737
-8CC7;1.0;2781
-8CC8;1.0;7643
-8CCA;1.0;3417
-8CCD;1.0;7660
-8CCE;1.0;3308
-8CD1;1.0;3888
-8CD3;1.0;4148
-8CDA;1.0;7647
-8CDB;1.0;2731
-8CDC;1.0;2782
-8CDE;1.0;3062
-8CE0;1.0;3969
-8CE2;1.0;2413
-8CE3;1.0;7646
-8CE4;1.0;7645
-8CE6;1.0;4174
-8CEA;1.0;2833
-8CED;1.0;3750
-8CFA;1.0;7649
-8CFB;1.0;7650
-8CFC;1.0;2556
-8CFD;1.0;7648
-8D04;1.0;7651
-8D05;1.0;7652
-8D07;1.0;7654
-8D08;1.0;3403
-8D0A;1.0;7653
-8D0B;1.0;2070
-8D0D;1.0;7656
-8D0F;1.0;7655
-8D10;1.0;7657
-8D13;1.0;7659
-8D14;1.0;7661
-8D16;1.0;7662
-8D64;1.0;3254
-8D66;1.0;2847
-8D67;1.0;7663
-8D6B;1.0;1950
-8D6D;1.0;7664
-8D70;1.0;3386
-8D71;1.0;7665
-8D73;1.0;7666
-8D74;1.0;4175
-8D77;1.0;2115
-8D81;1.0;7667
-8D85;1.0;3622
-8D8A;1.0;1759
-8D99;1.0;7668
-8DA3;1.0;2881
-8DA8;1.0;3186
-8DB3;1.0;3413
-8DBA;1.0;7671
-8DBE;1.0;7670
-8DC2;1.0;7669
-8DCB;1.0;7677
-8DCC;1.0;7675
-8DCF;1.0;7672
-8DD6;1.0;7674
-8DDA;1.0;7673
-8DDB;1.0;7676
-8DDD;1.0;2187
-8DDF;1.0;7680
-8DE1;1.0;3255
-8DE3;1.0;7681
-8DE8;1.0;2457
-8DEA;1.0;7678
-8DEB;1.0;7679
-8DEF;1.0;4709
-8DF3;1.0;3623
-8DF5;1.0;3309
-8DFC;1.0;7682
-8DFF;1.0;7685
-8E08;1.0;7683
-8E09;1.0;7684
-8E0A;1.0;4557
-8E0F;1.0;3807
-8E10;1.0;7688
-8E1D;1.0;7686
-8E1E;1.0;7687
-8E1F;1.0;7689
-8E2A;1.0;7709
-8E30;1.0;7692
-8E34;1.0;7693
-8E35;1.0;7691
-8E42;1.0;7690
-8E44;1.0;3693
-8E47;1.0;7701
-8E48;1.0;7705
-8E49;1.0;7702
-8E4A;1.0;7694
-8E4C;1.0;7703
-8E50;1.0;7704
-8E55;1.0;7711
-8E59;1.0;7706
-8E5F;1.0;3256
-8E60;1.0;7708
-8E63;1.0;7710
-8E64;1.0;7707
-8E72;1.0;7713
-8E74;1.0;2919
-8E76;1.0;7712
-8E7C;1.0;7714
-8E81;1.0;7715
-8E84;1.0;7718
-8E85;1.0;7717
-8E87;1.0;7716
-8E8A;1.0;7720
-8E8B;1.0;7719
-8E8D;1.0;4486
-8E91;1.0;7722
-8E93;1.0;7721
-8E94;1.0;7723
-8E99;1.0;7724
-8EA1;1.0;7726
-8EAA;1.0;7725
-8EAB;1.0;3140
-8EAC;1.0;7727
-8EAF;1.0;2277
-8EB0;1.0;7728
-8EB1;1.0;7730
-8EBE;1.0;7731
-8EC5;1.0;7732
-8EC6;1.0;7729
-8EC8;1.0;7733
-8ECA;1.0;2854
-8ECB;1.0;7734
-8ECC;1.0;2116
-8ECD;1.0;2319
-8ED2;1.0;2414
-8EDB;1.0;7735
-8EDF;1.0;3880
-8EE2;1.0;3730
-8EE3;1.0;7736
-8EEB;1.0;7739
-8EF8;1.0;2820
-8EFB;1.0;7738
-8EFC;1.0;7737
-8EFD;1.0;2358
-8EFE;1.0;7740
-8F03;1.0;1951
-8F05;1.0;7742
-8F09;1.0;2660
-8F0A;1.0;7741
-8F0C;1.0;7750
-8F12;1.0;7744
-8F13;1.0;7746
-8F14;1.0;4269
-8F15;1.0;7743
-8F19;1.0;7745
-8F1B;1.0;7749
-8F1C;1.0;7747
-8F1D;1.0;2117
-8F1F;1.0;7748
-8F26;1.0;7751
-8F29;1.0;3958
-8F2A;1.0;4656
-8F2F;1.0;2920
-8F33;1.0;7752
-8F38;1.0;4502
-8F39;1.0;7754
-8F3B;1.0;7753
-8F3E;1.0;7757
-8F3F;1.0;4533
-8F42;1.0;7756
-8F44;1.0;1977
-8F45;1.0;7755
-8F46;1.0;7760
-8F49;1.0;7759
-8F4C;1.0;7758
-8F4D;1.0;3718
-8F4E;1.0;7761
-8F57;1.0;7762
-8F5C;1.0;7763
-8F5F;1.0;2576
-8F61;1.0;2305
-8F62;1.0;7764
-8F63;1.0;7765
-8F64;1.0;7766
-8F9B;1.0;3141
-8F9C;1.0;7767
-8F9E;1.0;2813
-8F9F;1.0;7768
-8FA3;1.0;7769
-8FA7;1.0;5001
-8FA8;1.0;4994
-8FAD;1.0;7770
-8FAE;1.0;6980
-8FAF;1.0;7771
-8FB0;1.0;3504
-8FB1;1.0;3111
-8FB2;1.0;3932
-8FB7;1.0;7772
-8FBA;1.0;4253
-8FBB;1.0;3652
-8FBC;1.0;2594
-8FBF;1.0;3509
-8FC2;1.0;1710
-8FC4;1.0;4388
-8FC5;1.0;3155
-8FCE;1.0;2362
-8FD1;1.0;2265
-8FD4;1.0;4254
-8FDA;1.0;7773
-8FE2;1.0;7775
-8FE5;1.0;7774
-8FE6;1.0;1864
-8FE9;1.0;3886
-8FEA;1.0;7776
-8FEB;1.0;3987
-8FED;1.0;3719
-8FEF;1.0;7777
-8FF0;1.0;2950
-8FF4;1.0;7779
-8FF7;1.0;4434
-8FF8;1.0;7794
-8FF9;1.0;7781
-8FFA;1.0;7782
-8FFD;1.0;3641
-9000;1.0;3464
-9001;1.0;3387
-9003;1.0;3808
-9005;1.0;7780
-9006;1.0;2153
-900B;1.0;7789
-900D;1.0;7786
-900E;1.0;7805
-900F;1.0;3809
-9010;1.0;3564
-9011;1.0;7783
-9013;1.0;3694
-9014;1.0;3751
-9015;1.0;7784
-9016;1.0;7788
-9017;1.0;3164
-9019;1.0;3971
-901A;1.0;3644
-901D;1.0;3234
-901E;1.0;7787
-901F;1.0;3414
-9020;1.0;3404
-9021;1.0;7785
-9022;1.0;1609
-9023;1.0;4702
-9027;1.0;7790
-902E;1.0;3465
-9031;1.0;2921
-9032;1.0;3142
-9035;1.0;7792
-9036;1.0;7791
-9038;1.0;1679
-9039;1.0;7793
-903C;1.0;4115
-903E;1.0;7807
-9041;1.0;3859
-9042;1.0;3175
-9045;1.0;3557
-9047;1.0;2288
-9049;1.0;7806
-904A;1.0;4523
-904B;1.0;1731
-904D;1.0;4255
-904E;1.0;1865
-904F;1.0;7801
-9050;1.0;7802
-9051;1.0;7803
-9052;1.0;7804
-9053;1.0;3827
-9054;1.0;3503
-9055;1.0;1667
-9056;1.0;7808
-9058;1.0;7809
-9059;1.0;8403
-905C;1.0;3429
-905E;1.0;7810
-9060;1.0;1783
-9061;1.0;3344
-9063;1.0;2415
-9065;1.0;4558
-9068;1.0;7811
-9069;1.0;3712
-906D;1.0;3388
-906E;1.0;2855
-906F;1.0;7812
-9072;1.0;7815
-9075;1.0;2969
-9076;1.0;7813
-9077;1.0;3311
-9078;1.0;3310
-907A;1.0;1668
-907C;1.0;4643
-907D;1.0;7817
-907F;1.0;4082
-9080;1.0;7819
-9081;1.0;7818
-9082;1.0;7816
-9083;1.0;6768
-9084;1.0;2052
-9087;1.0;7778
-9089;1.0;7821
-908A;1.0;7820
-908F;1.0;7822
-9091;1.0;4524
-90A3;1.0;3865
-90A6;1.0;4314
-90A8;1.0;7823
-90AA;1.0;2857
-90AF;1.0;7824
-90B1;1.0;7825
-90B5;1.0;7826
-90B8;1.0;3701
-90C1;1.0;1674
-90CA;1.0;2557
-90CE;1.0;4726
-90DB;1.0;7830
-90E1;1.0;2320
-90E2;1.0;7827
-90E4;1.0;7828
-90E8;1.0;4184
-90ED;1.0;1952
-90F5;1.0;4525
-90F7;1.0;2231
-90FD;1.0;3752
-9102;1.0;7831
-9112;1.0;7832
-9119;1.0;7833
-912D;1.0;3702
-9130;1.0;7835
-9132;1.0;7834
-9149;1.0;3851
-914A;1.0;7836
-914B;1.0;2922
-914C;1.0;2864
-914D;1.0;3959
-914E;1.0;3581
-9152;1.0;2882
-9154;1.0;3176
-9156;1.0;7837
-9158;1.0;7838
-9162;1.0;3161
-9163;1.0;7839
-9165;1.0;7840
-9169;1.0;7841
-916A;1.0;4579
-916C;1.0;2923
-9172;1.0;7843
-9173;1.0;7842
-9175;1.0;2558
-9177;1.0;2583
-9178;1.0;2732
-9182;1.0;7846
-9187;1.0;2970
-9189;1.0;7845
-918B;1.0;7844
-918D;1.0;3473
-9190;1.0;2479
-9192;1.0;3235
-9197;1.0;4016
-919C;1.0;2925
-91A2;1.0;7847
-91A4;1.0;3063
-91AA;1.0;7850
-91AB;1.0;7848
-91AF;1.0;7849
-91B4;1.0;7852
-91B5;1.0;7851
-91B8;1.0;3090
-91BA;1.0;7853
-91C0;1.0;7854
-91C1;1.0;7855
-91C6;1.0;4048
-91C7;1.0;2651
-91C8;1.0;2865
-91C9;1.0;7856
-91CB;1.0;7857
-91CC;1.0;4604
-91CD;1.0;2937
-91CE;1.0;4478
-91CF;1.0;4644
-91D0;1.0;7858
-91D1;1.0;2266
-91D6;1.0;7859
-91D8;1.0;3703
-91DB;1.0;7862
-91DC;1.0;1988
-91DD;1.0;3143
-91DF;1.0;7860
-91E1;1.0;7861
-91E3;1.0;3664
-91E6;1.0;4353
-91E7;1.0;2292
-91F5;1.0;7864
-91F6;1.0;7865
-91FC;1.0;7863
-91FF;1.0;7867
-920D;1.0;3863
-920E;1.0;1935
-9211;1.0;7871
-9214;1.0;7868
-9215;1.0;7870
-921E;1.0;7866
-9229;1.0;7947
-922C;1.0;7869
-9234;1.0;4675
-9237;1.0;2458
-923F;1.0;7879
-9244;1.0;3720
-9245;1.0;7874
-9248;1.0;7877
-9249;1.0;7875
-924B;1.0;7880
-9250;1.0;7881
-9257;1.0;7873
-925A;1.0;7886
-925B;1.0;1784
-925E;1.0;7872
-9262;1.0;4013
-9264;1.0;7876
-9266;1.0;3064
-9271;1.0;2559
-927E;1.0;4340
-9280;1.0;2268
-9283;1.0;2938
-9285;1.0;3828
-9291;1.0;3313
-9293;1.0;7884
-9295;1.0;7878
-9296;1.0;7883
-9298;1.0;4435
-929A;1.0;3624
-929B;1.0;7885
-929C;1.0;7882
-92AD;1.0;3312
-92B7;1.0;7889
-92B9;1.0;7888
-92CF;1.0;7887
-92D2;1.0;4315
-92E4;1.0;2991
-92E9;1.0;7890
-92EA;1.0;4263
-92ED;1.0;1752
-92F2;1.0;4138
-92F3;1.0;3582
-92F8;1.0;2188
-92FA;1.0;7892
-92FC;1.0;2561
-9306;1.0;2712
-930F;1.0;7891
-9310;1.0;3177
-9318;1.0;3178
-9319;1.0;7901
-931A;1.0;7903
-9320;1.0;3091
-9322;1.0;7902
-9323;1.0;7904
-9326;1.0;2251
-9328;1.0;4137
-932B;1.0;2866
-932C;1.0;4703
-932E;1.0;7894
-932F;1.0;2688
-9332;1.0;4731
-9335;1.0;7906
-933A;1.0;7905
-933B;1.0;7907
-9344;1.0;7893
-934B;1.0;3873
-934D;1.0;3753
-9354;1.0;3655
-9356;1.0;7912
-935B;1.0;3535
-935C;1.0;7908
-9360;1.0;7909
-936C;1.0;2313
-936E;1.0;7911
-9375;1.0;2416
-937C;1.0;7910
-937E;1.0;3065
-938C;1.0;1989
-9394;1.0;7916
-9396;1.0;2631
-9397;1.0;3389
-939A;1.0;3642
-93A7;1.0;1927
-93AC;1.0;7914
-93AD;1.0;7915
-93AE;1.0;3635
-93B0;1.0;7913
-93B9;1.0;7917
-93C3;1.0;7923
-93C8;1.0;7926
-93D0;1.0;7925
-93D1;1.0;3713
-93D6;1.0;7918
-93D7;1.0;7919
-93D8;1.0;7922
-93DD;1.0;7924
-93E1;1.0;2232
-93E4;1.0;7927
-93E5;1.0;7921
-93E8;1.0;7920
-9403;1.0;7931
-9407;1.0;7932
-9410;1.0;7933
-9413;1.0;7930
-9414;1.0;7929
-9418;1.0;3066
-9419;1.0;3810
-941A;1.0;7928
-9421;1.0;7937
-942B;1.0;7935
-9435;1.0;7936
-9436;1.0;7934
-9438;1.0;3488
-943A;1.0;7938
-9441;1.0;7939
-9444;1.0;7941
-9451;1.0;2053
-9452;1.0;7940
-9453;1.0;4490
-945A;1.0;7952
-945B;1.0;7942
-945E;1.0;7945
-9460;1.0;7943
-9462;1.0;7944
-946A;1.0;7946
-9470;1.0;7948
-9475;1.0;7949
-9477;1.0;7950
-947C;1.0;7953
-947D;1.0;7951
-947E;1.0;7954
-947F;1.0;7956
-9481;1.0;7955
-9577;1.0;3625
-9580;1.0;4471
-9582;1.0;7957
-9583;1.0;3314
-9587;1.0;7958
-9589;1.0;4236
-958A;1.0;7959
-958B;1.0;1911
-958F;1.0;1728
-9591;1.0;2055
-9593;1.0;2054
-9594;1.0;7960
-9596;1.0;7961
-9598;1.0;7962
-9599;1.0;7963
-95A0;1.0;7964
-95A2;1.0;2056
-95A3;1.0;1953
-95A4;1.0;2562
-95A5;1.0;4022
-95A7;1.0;7966
-95A8;1.0;7965
-95AD;1.0;7967
-95B2;1.0;1760
-95B9;1.0;7970
-95BB;1.0;7969
-95BC;1.0;7968
-95BE;1.0;7971
-95C3;1.0;7974
-95C7;1.0;1639
-95CA;1.0;7972
-95CC;1.0;7976
-95CD;1.0;7975
-95D4;1.0;7978
-95D5;1.0;7977
-95D6;1.0;7979
-95D8;1.0;3814
-95DC;1.0;7980
-95E1;1.0;7981
-95E2;1.0;7983
-95E5;1.0;7982
-961C;1.0;4176
-9621;1.0;7984
-9628;1.0;7985
-962A;1.0;2669
-962E;1.0;7986
-962F;1.0;7987
-9632;1.0;4341
-963B;1.0;3343
-963F;1.0;1604
-9640;1.0;3443
-9642;1.0;7988
-9644;1.0;4177
-964B;1.0;7991
-964C;1.0;7989
-964D;1.0;2563
-964F;1.0;7990
-9650;1.0;2434
-965B;1.0;4237
-965C;1.0;7993
-965D;1.0;8001
-965E;1.0;7994
-965F;1.0;8002
-9662;1.0;1701
-9663;1.0;3156
-9664;1.0;2992
-9665;1.0;2057
-9666;1.0;8003
-966A;1.0;3970
-966C;1.0;8005
-9670;1.0;1702
-9672;1.0;8004
-9673;1.0;3636
-9675;1.0;4645
-9676;1.0;3811
-9677;1.0;7992
-9678;1.0;4606
-967A;1.0;2417
-967D;1.0;4559
-9685;1.0;2289
-9686;1.0;4620
-9688;1.0;2308
-968A;1.0;3466
-968B;1.0;7101
-968D;1.0;8006
-968E;1.0;1912
-968F;1.0;3179
-9694;1.0;1954
-9695;1.0;8008
-9697;1.0;8009
-9698;1.0;8007
-9699;1.0;2368
-969B;1.0;2661
-969C;1.0;3067
-96A0;1.0;1703
-96A3;1.0;4657
-96A7;1.0;8011
-96A8;1.0;7814
-96AA;1.0;8010
-96B0;1.0;8014
-96B1;1.0;8012
-96B2;1.0;8013
-96B4;1.0;8015
-96B6;1.0;8016
-96B7;1.0;4676
-96B8;1.0;8017
-96B9;1.0;8018
-96BB;1.0;3241
-96BC;1.0;4027
-96C0;1.0;3193
-96C1;1.0;2071
-96C4;1.0;4526
-96C5;1.0;1877
-96C6;1.0;2924
-96C7;1.0;2459
-96C9;1.0;8021
-96CB;1.0;8020
-96CC;1.0;2783
-96CD;1.0;8022
-96CE;1.0;8019
-96D1;1.0;2708
-96D5;1.0;8026
-96D6;1.0;7413
-96D9;1.0;5054
-96DB;1.0;3187
-96DC;1.0;8024
-96E2;1.0;4605
-96E3;1.0;3881
-96E8;1.0;1711
-96EA;1.0;3267
-96EB;1.0;2822
-96F0;1.0;4223
-96F2;1.0;1732
-96F6;1.0;4677
-96F7;1.0;4575
-96F9;1.0;8027
-96FB;1.0;3737
-9700;1.0;2891
-9704;1.0;8028
-9706;1.0;8029
-9707;1.0;3144
-9708;1.0;8030
-970A;1.0;4678
-970D;1.0;8025
-970E;1.0;8032
-970F;1.0;8034
-9711;1.0;8033
-9713;1.0;8031
-9716;1.0;8035
-9719;1.0;8036
-971C;1.0;3390
-971E;1.0;1866
-9724;1.0;8037
-9727;1.0;4424
-972A;1.0;8038
-9730;1.0;8039
-9732;1.0;4710
-9738;1.0;5917
-9739;1.0;8040
-973D;1.0;8041
-973E;1.0;8042
-9742;1.0;8046
-9744;1.0;8043
-9746;1.0;8044
-9748;1.0;8045
-9749;1.0;8047
-9752;1.0;3236
-9756;1.0;4487
-9759;1.0;3237
-975C;1.0;8048
-975E;1.0;4083
-9760;1.0;8049
-9761;1.0;8351
-9762;1.0;4444
-9764;1.0;8050
-9766;1.0;8051
-9768;1.0;8052
-9769;1.0;1955
-976B;1.0;8054
-976D;1.0;3157
-9771;1.0;8055
-9774;1.0;2304
-9779;1.0;8056
-977A;1.0;8060
-977C;1.0;8058
-9781;1.0;8059
-9784;1.0;1983
-9785;1.0;8057
-9786;1.0;8061
-978B;1.0;8062
-978D;1.0;1640
-978F;1.0;8063
-9790;1.0;8064
-9798;1.0;3068
-979C;1.0;8065
-97A0;1.0;2139
-97A3;1.0;8068
-97A6;1.0;8067
-97A8;1.0;8066
-97AB;1.0;7581
-97AD;1.0;4260
-97B3;1.0;8069
-97B4;1.0;8070
-97C3;1.0;8071
-97C6;1.0;8072
-97C8;1.0;8073
-97CB;1.0;8074
-97D3;1.0;2058
-97DC;1.0;8075
-97ED;1.0;8076
-97EE;1.0;3903
-97F2;1.0;8078
-97F3;1.0;1827
-97F5;1.0;8081
-97F6;1.0;8080
-97FB;1.0;1704
-97FF;1.0;2233
-9801;1.0;4239
-9802;1.0;3626
-9803;1.0;2602
-9805;1.0;2564
-9806;1.0;2971
-9808;1.0;3160
-980C;1.0;8083
-980F;1.0;8082
-9810;1.0;4534
-9811;1.0;2072
-9812;1.0;4050
-9813;1.0;3860
-9817;1.0;3192
-9818;1.0;4646
-981A;1.0;2359
-9821;1.0;8086
-9824;1.0;8085
-982C;1.0;4343
-982D;1.0;3812
-9834;1.0;1748
-9837;1.0;8087
-9838;1.0;8084
-983B;1.0;4149
-983C;1.0;4574
-983D;1.0;8088
-9846;1.0;8089
-984B;1.0;8091
-984C;1.0;3474
-984D;1.0;1959
-984E;1.0;1960
-984F;1.0;8090
-9854;1.0;2073
-9855;1.0;2418
-9858;1.0;2074
-985B;1.0;3731
-985E;1.0;4664
-9867;1.0;2460
-986B;1.0;8092
-986F;1.0;8093
-9870;1.0;8094
-9871;1.0;8101
-9873;1.0;8103
-9874;1.0;8102
-98A8;1.0;4187
-98AA;1.0;8104
-98AF;1.0;8105
-98B1;1.0;8106
-98B6;1.0;8107
-98C3;1.0;8109
-98C4;1.0;8108
-98C6;1.0;8110
-98DB;1.0;4084
-98DC;1.0;7044
-98DF;1.0;3109
-98E2;1.0;2118
-98E9;1.0;8111
-98EB;1.0;8112
-98ED;1.0;5012
-98EE;1.0;6127
-98EF;1.0;4051
-98F2;1.0;1691
-98F4;1.0;1627
-98FC;1.0;2784
-98FD;1.0;4316
-98FE;1.0;3094
-9903;1.0;8113
-9905;1.0;4463
-9909;1.0;8114
-990A;1.0;4560
-990C;1.0;1734
-9910;1.0;2733
-9912;1.0;8115
-9913;1.0;1878
-9914;1.0;8116
-9918;1.0;8117
-991D;1.0;8119
-991E;1.0;8120
-9920;1.0;8122
-9921;1.0;8118
-9924;1.0;8121
-9928;1.0;2059
-992C;1.0;8123
-992E;1.0;8124
-993D;1.0;8125
-993E;1.0;8126
-9942;1.0;8127
-9945;1.0;8129
-9949;1.0;8128
-994B;1.0;8131
-994C;1.0;8134
-9950;1.0;8130
-9951;1.0;8132
-9952;1.0;8133
-9955;1.0;8135
-9957;1.0;2234
-9996;1.0;2883
-9997;1.0;8136
-9998;1.0;8137
-9999;1.0;2565
-99A5;1.0;8138
-99A8;1.0;1930
-99AC;1.0;3947
-99AD;1.0;8139
-99AE;1.0;8140
-99B3;1.0;3558
-99B4;1.0;3875
-99BC;1.0;8141
-99C1;1.0;3993
-99C4;1.0;3444
-99C5;1.0;1756
-99C6;1.0;2278
-99C8;1.0;2279
-99D0;1.0;3583
-99D1;1.0;8146
-99D2;1.0;2280
-99D5;1.0;1879
-99D8;1.0;8145
-99DB;1.0;8143
-99DD;1.0;8144
-99DF;1.0;8142
-99E2;1.0;8156
-99ED;1.0;8147
-99EE;1.0;8148
-99F1;1.0;8149
-99F2;1.0;8150
-99F8;1.0;8152
-99FB;1.0;8151
-99FF;1.0;2957
-9A01;1.0;8153
-9A05;1.0;8155
-9A0E;1.0;2119
-9A0F;1.0;8154
-9A12;1.0;3391
-9A13;1.0;2419
-9A19;1.0;8157
-9A28;1.0;3445
-9A2B;1.0;8158
-9A30;1.0;3813
-9A37;1.0;8159
-9A3E;1.0;8164
-9A40;1.0;8162
-9A42;1.0;8161
-9A43;1.0;8163
-9A45;1.0;8160
-9A4D;1.0;8166
-9A55;1.0;8165
-9A57;1.0;8168
-9A5A;1.0;2235
-9A5B;1.0;8167
-9A5F;1.0;8169
-9A62;1.0;8170
-9A64;1.0;8172
-9A65;1.0;8171
-9A69;1.0;8173
-9A6A;1.0;8175
-9A6B;1.0;8174
-9AA8;1.0;2592
-9AAD;1.0;8176
-9AB0;1.0;8177
-9AB8;1.0;1928
-9ABC;1.0;8178
-9AC0;1.0;8179
-9AC4;1.0;3181
-9ACF;1.0;8180
-9AD1;1.0;8181
-9AD3;1.0;8182
-9AD4;1.0;8183
-9AD8;1.0;2566
-9ADE;1.0;8184
-9ADF;1.0;8185
-9AE2;1.0;8186
-9AE3;1.0;8187
-9AE6;1.0;8188
-9AEA;1.0;4017
-9AEB;1.0;8190
-9AED;1.0;4106
-9AEE;1.0;8191
-9AEF;1.0;8189
-9AF1;1.0;8193
-9AF4;1.0;8192
-9AF7;1.0;8194
-9AFB;1.0;8201
-9B06;1.0;8202
-9B18;1.0;8203
-9B1A;1.0;8204
-9B1F;1.0;8205
-9B22;1.0;8206
-9B23;1.0;8207
-9B25;1.0;8208
-9B27;1.0;8209
-9B28;1.0;8210
-9B29;1.0;8211
-9B2A;1.0;8212
-9B2E;1.0;8213
-9B2F;1.0;8214
-9B31;1.0;6121
-9B32;1.0;8215
-9B3B;1.0;6888
-9B3C;1.0;2120
-9B41;1.0;1901
-9B42;1.0;2618
-9B43;1.0;8217
-9B44;1.0;8216
-9B45;1.0;4405
-9B4D;1.0;8219
-9B4E;1.0;8220
-9B4F;1.0;8218
-9B51;1.0;8221
-9B54;1.0;4366
-9B58;1.0;8222
-9B5A;1.0;2191
-9B6F;1.0;4705
-9B74;1.0;8223
-9B83;1.0;8225
-9B8E;1.0;1630
-9B91;1.0;8226
-9B92;1.0;4211
-9B93;1.0;8224
-9B96;1.0;8227
-9B97;1.0;8228
-9B9F;1.0;8229
-9BA0;1.0;8230
-9BA8;1.0;8231
-9BAA;1.0;4378
-9BAB;1.0;2713
-9BAD;1.0;2690
-9BAE;1.0;3315
-9BB4;1.0;8232
-9BB9;1.0;8235
-9BC0;1.0;8233
-9BC6;1.0;8236
-9BC9;1.0;2481
-9BCA;1.0;8234
-9BCF;1.0;8237
-9BD1;1.0;8238
-9BD2;1.0;8239
-9BD4;1.0;8243
-9BD6;1.0;2710
-9BDB;1.0;3468
-9BE1;1.0;8244
-9BE2;1.0;8241
-9BE3;1.0;8240
-9BE4;1.0;8242
-9BE8;1.0;2363
-9BF0;1.0;8248
-9BF1;1.0;8247
-9BF2;1.0;8246
-9BF5;1.0;1619
-9C04;1.0;8258
-9C06;1.0;8254
-9C08;1.0;8255
-9C09;1.0;8251
-9C0A;1.0;8257
-9C0C;1.0;8253
-9C0D;1.0;1966
-9C10;1.0;4744
-9C12;1.0;8256
-9C13;1.0;8252
-9C14;1.0;8250
-9C15;1.0;8249
-9C1B;1.0;8260
-9C21;1.0;8263
-9C24;1.0;8262
-9C25;1.0;8261
-9C2D;1.0;4141
-9C2E;1.0;8259
-9C2F;1.0;1683
-9C30;1.0;8264
-9C32;1.0;8266
-9C39;1.0;1979
-9C3A;1.0;8245
-9C3B;1.0;1723
-9C3E;1.0;8268
-9C46;1.0;8267
-9C47;1.0;8265
-9C48;1.0;3513
-9C52;1.0;4380
-9C57;1.0;4658
-9C5A;1.0;8269
-9C60;1.0;8270
-9C67;1.0;8271
-9C76;1.0;8272
-9C78;1.0;8273
-9CE5;1.0;3627
-9CE7;1.0;8274
-9CE9;1.0;4023
-9CEB;1.0;8279
-9CEC;1.0;8275
-9CF0;1.0;8276
-9CF3;1.0;4317
-9CF4;1.0;4436
-9CF6;1.0;3848
-9D03;1.0;8280
-9D06;1.0;8281
-9D07;1.0;3830
-9D08;1.0;8278
-9D09;1.0;8277
-9D0E;1.0;1810
-9D12;1.0;8289
-9D15;1.0;8288
-9D1B;1.0;1785
-9D1F;1.0;8286
-9D23;1.0;8285
-9D26;1.0;8283
-9D28;1.0;1991
-9D2A;1.0;8282
-9D2B;1.0;2818
-9D2C;1.0;1809
-9D3B;1.0;2567
-9D3E;1.0;8292
-9D3F;1.0;8291
-9D41;1.0;8290
-9D44;1.0;8287
-9D46;1.0;8293
-9D48;1.0;8294
-9D50;1.0;8305
-9D51;1.0;8304
-9D59;1.0;8306
-9D5C;1.0;1713
-9D5D;1.0;8301
-9D5E;1.0;8302
-9D60;1.0;2584
-9D61;1.0;4425
-9D64;1.0;8303
-9D6C;1.0;4318
-9D6F;1.0;8311
-9D72;1.0;8307
-9D7A;1.0;8312
-9D87;1.0;8309
-9D89;1.0;8308
-9D8F;1.0;2360
-9D9A;1.0;8313
-9DA4;1.0;8314
-9DA9;1.0;8315
-9DAB;1.0;8310
-9DAF;1.0;8284
-9DB2;1.0;8316
-9DB4;1.0;3665
-9DB8;1.0;8320
-9DBA;1.0;8321
-9DBB;1.0;8319
-9DC1;1.0;8318
-9DC2;1.0;8324
-9DC4;1.0;8317
-9DC6;1.0;8322
-9DCF;1.0;8323
-9DD3;1.0;8326
-9DD9;1.0;8325
-9DE6;1.0;8328
-9DED;1.0;8329
-9DEF;1.0;8330
-9DF2;1.0;4741
-9DF8;1.0;8327
-9DF9;1.0;3475
-9DFA;1.0;2677
-9DFD;1.0;8331
-9E1A;1.0;8332
-9E1B;1.0;8333
-9E1E;1.0;8334
-9E75;1.0;8335
-9E78;1.0;2420
-9E79;1.0;8336
-9E7D;1.0;8337
-9E7F;1.0;2815
-9E81;1.0;8338
-9E88;1.0;8339
-9E8B;1.0;8340
-9E8C;1.0;8341
-9E91;1.0;8344
-9E92;1.0;8342
-9E93;1.0;4728
-9E95;1.0;8343
-9E97;1.0;4679
-9E9D;1.0;8345
-9E9F;1.0;4659
-9EA5;1.0;8346
-9EA6;1.0;3994
-9EA9;1.0;8347
-9EAA;1.0;8349
-9EAD;1.0;8350
-9EB8;1.0;8348
-9EB9;1.0;2577
-9EBA;1.0;4445
-9EBB;1.0;4367
-9EBC;1.0;5487
-9EBE;1.0;6164
-9EBF;1.0;4391
-9EC4;1.0;1811
-9ECC;1.0;8352
-9ECD;1.0;2148
-9ECE;1.0;8353
-9ECF;1.0;8354
-9ED0;1.0;8355
-9ED2;1.0;2585
-9ED4;1.0;8356
-9ED8;1.0;6452
-9ED9;1.0;4459
-9EDB;1.0;3467
-9EDC;1.0;8357
-9EDD;1.0;8359
-9EDE;1.0;8358
-9EE0;1.0;8360
-9EE5;1.0;8361
-9EE8;1.0;8362
-9EEF;1.0;8363
-9EF4;1.0;8364
-9EF6;1.0;8365
-9EF7;1.0;8366
-9EF9;1.0;8367
-9EFB;1.0;8368
-9EFC;1.0;8369
-9EFD;1.0;8370
-9F07;1.0;8371
-9F08;1.0;8372
-9F0E;1.0;3704
-9F13;1.0;2461
-9F15;1.0;8374
-9F20;1.0;3345
-9F21;1.0;8375
-9F2C;1.0;8376
-9F3B;1.0;4101
-9F3E;1.0;8377
-9F4A;1.0;8378
-9F4B;1.0;6723
-9F4E;1.0;7658
-9F4F;1.0;8077
-9F52;1.0;8379
-9F54;1.0;8380
-9F5F;1.0;8382
-9F60;1.0;8383
-9F61;1.0;8384
-9F62;1.0;4680
-9F63;1.0;8381
-9F66;1.0;8385
-9F67;1.0;8386
-9F6A;1.0;8388
-9F6C;1.0;8387
-9F72;1.0;8390
-9F76;1.0;8391
-9F77;1.0;8389
-9F8D;1.0;4622
-9F95;1.0;8392
-9F9C;1.0;8393
-9F9D;1.0;6752
-9FA0;1.0;8394
-
-
-B. idntabjplocalmap10.txt
-
-version=1.0
-
-2212;1.0;FF0D
-309B;1.0;3099
-309C;1.0;309A
+++ /dev/null
-Internet Draft Paul Hoffman
-draft-ietf-idn-nameprep-08.txt IMC & VPNC
-February 24, 2002 Marc Blanchet
-Expires in six months ViaGenie
-
- Nameprep: A Stringprep Profile for Internationalized Domain Names
-
-Status of this memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-This document describes how to prepare internationalized domain name
-labels in order to increase the likelihood that name input and name
-comparison work in ways that make sense for typical users throughout the
-world. This profile of the stringprep protocol is used as part of a
-suite of on-the-wire protocols for internationalizing the DNS.
-
-1. Introduction
-
-This document specifies processing rules that will allow users to enter
-internationalized domain name labels in applications and have the highest
-chance of getting the content of the strings correct. It is a profile of
-stringprep [STRINGPREP]. These processing rules are only intended for
-internationalized domain names, not for arbitrary text.
-
-This profile defines the following, as required by [STRINGPREP]
-
-- The intended applicability of the profile: internationalized
-domain name labels
-
-- The character repertoire that is the input and output to stringprep:
-defined in Section 2
-
-- The list of unassigned code points for the repertoire: defined
-in Appendix F.
-
-- The mappings used: defined in Section 3.
-
-- The Unicode normalization used: defined in Section 4
-
-- The characters that are prohibited as output: Defined in section 5
-
-1.1 Interaction of protocol parts
-
-Nameprep is used by the IDNA [IDNA] protocol for preparing domain names;
-it is not designed for any other purpose. It is explicitly not designed
-for processing arbitrary free text and SHOULD NOT be used for that
-purpose. Nameprep is a profile of Stringprep [STRINGPREP].
-Implementations of Nameprep MUST fully implement Stringprep.
-
-1.2 Terminology
-
-The key words "MUST", "SHOULD", and "MAY" in this document are to be
-interpreted as described in RFC 2119 [RFC2119].
-
-Examples in this document use the notation for code points and names
-from the Unicode Standard [Unicode3.1] and ISO/IEC 10646 [ISO10646]. For
-example, the letter "a" may be represented as either "U+0061" or "LATIN
-SMALL LETTER A". In the lists of prohibited characters, the "U+" is left
-off to make the lists easier to read. The comments for character ranges
-are shown in square brackets (such as "[CONTROL CHARACTERS]") and do not
-come from the standards.
-
-
-2. Character Repertoire
-
-Unicode 3.1 [Unicode3.1] is the repertoire used in this profile.
-The reason Unicode 3.1 was chosen instead of a version of
-ISO/IEC 10646 is that ISO/IEC 10646 is expected to be updated soon after
-this document becomes an RFC. Unicode 3.1 has the exact repertoire that
-is expected in the next version of ISO/IEC 10646, and is therefore used
-here.
-
-
-3. Mapping
-
-This profile specifies stringprep mapping using the mapping table
-in Appendix D. That table includes all the steps described in this
-section.
-
-Note that text in this section describes how Appendix D was formed. It is
-here for people who want to understand more, but it should be ignored
-by implementors. Implementations of this profile MUST map based on
-Appendix D, not based on the descriptions in this section of how
-Appendix D was created.
-
-3.1 Mapped out
-
-The following characters are simply deleted from the input (that is,
-they are mapped to nothing) because their presence or absence should not
-make two strings different.
-
-Some characters are only useful in line-based text, and are otherwise
-invisible and ignored.
-
-00AD; SOFT HYPHEN
-1806; MONGOLIAN TODO SOFT HYPHEN
-200B; ZERO WIDTH SPACE
-FEFF; ZERO WIDTH NO-BREAK SPACE
-
-Variation selectors and cursive connectors select different glyphs, but
-do not bear semantics.
-
-180B; MONGOLIAN FREE VARIATION SELECTOR ONE
-180C; MONGOLIAN FREE VARIATION SELECTOR TWO
-180D; MONGOLIAN FREE VARIATION SELECTOR THREE
-200C; ZERO WIDTH NON-JOINER
-200D; ZERO WIDTH JOINER
-
-3.2 Case mapping
-
-This profile folds case in domain names where possible because the
-current DNS has case-insensitive matching for domain names. If this
-profile did not do that for the additional characters being added, it
-would lead to even greater user confusion. For example, "Abc" matches
-"abc", but "<Uppercase-A-with-accent>bc" would not match
-"<lowercase-a-with-accent>bc".
-
-The input string is case folded according to [UTR21]. For most
-characters, this is the same as changing the input character to a
-lowercase character. For some characters, however, more complex
-transformations occur. The "CaseFolding.txt" file from the Unicode
-database was used to prepare the mapping table.
-
-There are some characters that do not have mappings in [UTR21] but still
-need processing. These characters include a few Greek characters and
-many symbols that contain Latin characters. The list of characters to
-add to the mapping table were determined by the following algorithm:
-
-b = NormalizeWithKC(Fold(a));
-c = NormalizeWithKC(Fold(b));
-if c is not the same as b, add a mapping for "a to c".
-
-Because NormalizeWithKC(Fold(c)) always equals c, the table is stable
-from that point on. The "DerivedNormalizationProperties.txt" file from
-the Unicode database was used to prepare Appendix D. These mappings were
-added to reduce the number of processing steps, that is, to avoid doing
-case mapping and normalization twice.
-
-
-4. Normalization
-
-This profile specifies using Unicode normalization form KC, as described
-in [UAX15].
-
-
-5. Prohibited Output
-
-This profile specifies using the prohibition table in Appendix E.
-
-Note that the subsections below describe how Appendix E was formed. They
-are here for people who want to understand more, but they should be
-ignored by implementors. Implementations of this profile MUST map based
-on Appendix E, not based on the descriptions in this section of how
-Appendix E was created.
-
-The collected list of code points prohibited by this profile can be
-found in Appendix E of this document; note that IDNA prohibits
-additional characters. The lists in Appendix E MUST be used by
-implementations of this specification. If there are any discrepancies
-between the lists in Appendix E and subsections below, the lists in
-Appendix E always takes precedence.
-
-Some code points listed in one section would also appear in other
-sections. Each code point is only listed once in the tables in Appendix
-E.
-
-IMPORTANT NOTE: This profile MUST be used with the IDNA protocol. The
-IDNA protocol has additional prohibitions that are checked outside of
-this profile.
-
-5.1 Space characters
-
-Space characters would make visual transcription of domain names nearly
-impossible and could lead to user entry errors in many ways. Note that
-an additional space character (U+0020) is prohibited in IDNA.
-
-00A0; NO-BREAK SPACE
-1680; OGHAM SPACE MARK
-2000; EN QUAD
-2001; EM QUAD
-2002; EN SPACE
-2003; EM SPACE
-2004; THREE-PER-EM SPACE
-2005; FOUR-PER-EM SPACE
-2006; SIX-PER-EM SPACE
-2007; FIGURE SPACE
-2008; PUNCTUATION SPACE
-2009; THIN SPACE
-200A; HAIR SPACE
-202F; NARROW NO-BREAK SPACE
-3000; IDEOGRAPHIC SPACE
-
-5.2 Control characters
-
-Control characters (or characters with control function) cannot be seen
-and can cause unpredictable results when displayed. Note that additional
-control characters (U+0000 through U+001F, and U+007F) are prohibited in
-IDNA.
-
-0080-009F; [CONTROL CHARACTERS]
-070F; SYRIAC ABBREVIATION MARK
-180E; MONGOLIAN VOWEL SEPARATOR
-2028; LINE SEPARATOR
-2029; PARAGRAPH SEPARATOR
-206A-206F; [CONTROL CHARACTERS]
-FFF9-FFFC; [CONTROL CHARACTERS]
-1D173-1D17A; [MUSICAL CONTROL CHARACTERS]
-
-5.3 Private use and replacement characters
-
-Because private-use characters do not have defined meanings, they are
-prohibited. The private-use characters are:
-
-E000-F8FF; [PRIVATE USE, PLANE 0]
-F0000-FFFFD; [PRIVATE USE, PLANE 15]
-100000-10FFFD; [PRIVATE USE, PLANE 16]
-
-The replacement character (U+FFFD) has no known semantic definition in a
-name, and is often displayed by renderers to indicate "there would be
-some character here, but it cannot be rendered". For example, on a
-computer with no Asian fonts, a name with three ideographs might be
-rendered with three replacement characters.
-
-FFFD; REPLACEMENT CHARACTER
-
-5.4 Non-character code points
-
-Non-character code points are code points that have been allocated in
-ISO/IEC 10646 but are not characters. Because they are already assigned,
-they are guaranteed not to later change into characters.
-
-FDD0-FDEF; [NONCHARACTER CODE POINTS]
-FFFE-FFFF; [NONCHARACTER CODE POINTS]
-1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
-2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
-3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
-4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
-5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
-6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
-7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
-8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
-9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
-AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
-BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
-CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
-DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
-EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
-FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
-10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
-
-The non-character code points are listed the PropList.txt file from the
-Unicode database.
-
-5.5 Surrogate codes
-
-The following code points are permanently reserved for use as surrogate
-code values in the UTF-16 encoding, will never be assigned to
-characters, and are therefore prohibited:
-
-D800-DFFF; [SURROGATE CODES]
-
-5.6 Inappropriate for plain text
-
-The following characters do not appear in regular text.
-
-FFF9; INTERLINEAR ANNOTATION ANCHOR
-FFFA; INTERLINEAR ANNOTATION SEPARATOR
-FFFB; INTERLINEAR ANNOTATION TERMINATOR
-FFFC; OBJECT REPLACEMENT CHARACTER
-
-5.7 Inappropriate for canonical representation
-
-The ideographic description characters allow different sequences of
-characters to be rendered the same way, which makes them inappropriate
-for domain names that have to have a single canonical representation.
-
-2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
-
-5.8 Change display properties
-
-The following characters, some of which are deprecated in ISO/IEC 10646,
-can cause changes in display or the order in which characters appear
-when rendered.
-
-200E; LEFT-TO-RIGHT MARK
-200F; RIGHT-TO-LEFT MARK
-202A; LEFT-TO-RIGHT EMBEDDING
-202B; RIGHT-TO-LEFT EMBEDDING
-202C; POP DIRECTIONAL FORMATTING
-202D; LEFT-TO-RIGHT OVERRIDE
-202E; RIGHT-TO-LEFT OVERRIDE
-206A; INHIBIT SYMMETRIC SWAPPING
-206B; ACTIVATE SYMMETRIC SWAPPING
-206C; INHIBIT ARABIC FORM SHAPING
-206D; ACTIVATE ARABIC FORM SHAPING
-206E; NATIONAL DIGIT SHAPES
-206F; NOMINAL DIGIT SHAPES
-
-5.9 Inappropriate characters from common input mechanisms
-
-U+3002 is used as if it were U+002E in many input mechanisms,
-particularly in Asia. This prohibition allows input mechanisms to safely
-map U+3002 to U+002E before doing stringprep without worrying about
-preventing users from accessing legitimate domain name labels.
-
-3002; IDEOGRAPHIC FULL STOP
-
-5.10 Tagging characters
-
-The following characters are used for tagging text and are invisible.
-
-E0001; LANGUAGE TAG
-E0020-E007F; [TAGGING CHARACTERS]
-
-
-6. Unassigned Code Points in Internationalized Domain Names
-
-This profile lists the unassigned code points in the
-range 0 to 10FFFF for Unicode 3.1 in
-Appendix F. The list in Appendix F MUST be used by implementations of
-this specification. If there are any discrepancies between the list in
-Appendix F and the Unicode 3.1 specification, the list in Appendix F
-always takes precedence.
-
-
-7. Security Considerations
-
-The Unicode and ISO/IEC 10646 repertoires have many characters that look
-similar. In many cases, users of security protocols might do visual
-matching, such as when comparing the names of trusted third parties.
-This profile does nothing to map similar-looking characters together nor
-to prohibit some characters because they look like others.
-
-Security on the Internet partly relies on the DNS. Thus, any change
-to the characteristics of the DNS can change the security of much of the
-Internet.
-
-Domain names are used by users to connect to Internet servers. The
-security of the Internet would be compromised if a user entering a
-single internationalized name could be connected to different servers
-based on different interpretations of the internationalized domain name.
-
-Current applications might assume that the characters allowed in domain
-names will always be the same as they are in [STD13]. This document
-vastly increases the number of characters available in domain names.
-Every program that uses "special" characters in conjunction with domain
-names may be vulnerable to attack based on the new characters allowed by
-this specification.
-
-
-8. References
-
-[Glossary] Unicode Glossary, <http://www.unicode.org/glossary/>.
-
-[IDNA] Patrik Faltstrom, Paul Hoffman, and Adam M. Costello,
-"Internationalizing Domain Names in Applications (IDNA)",
-draft-ietf-idn-idna, work-in-progress.
-
-[ISO10646] ISO/IEC 10646-1:2000. International Standard -- Information
-technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part
-1: Architecture and Basic Multilingual Plane.
-
-[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", March 1997, RFC 2119.
-
-[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
-1034) and "Domain names - implementation and specification" (RFC 1035,
-STD 13, November 1987.
-
-[STRINGPREP] Paul Hoffman and Marc Blanchet, "Preparation of
-Internationalized Strings ("stringprep")", draft-hoffman-stringprep,
-work in progress.
-
-[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode
-Consortium. The Unicode Standard, Version 3.0. Reading, MA,
-Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended
-by: Unicode Standard Annex #27: Unicode 3.1
-<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.
-
-[UAX15] Mark Davis and Martin Duerst. Unicode Standard Annex #15:
-Unicode Normalization Forms, Version 3.1.0.
-<http://www.unicode.org/unicode/reports/tr15/tr15-21.html>.
-
-[UTR21] Mark Davis. Case Mappings. Unicode Technical Report;21.
-<http://www.unicode.org/unicode/reports/tr21/>.
-
-
-A. Acknowledgements
-
-Many people from the IETF IDN Working Group and the Unicode Technical
-Committee contributed ideas that went into the first draft of this
-document.
-
-The IDN namprep design team made many useful changes to the first
-draft. That team and its advisors include:
-
-Asmus Freytag
-Cathy Wissink
-Francois Yergeau
-James Seng
-Marc Blanchet
-Mark Davis
-Martin Duerst
-Patrik Faltstrom
-Paul Hoffman
-
-Additional significant improvements were proposed by:
-
-Jonathan Rosenne
-Kent Karlsson
-Scott Hollenbeck
-Dave Crocker
-
-
-B. IANA Considerations
-
-This is a profile of stringprep. When it becomes an RFC, it
-should be registered in the stringprep profile registry.
-
-
-C. Author Contact Information
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA 95060 USA
-paul.hoffman@imc.org and paul.hoffman@vpnc.org
-
-Marc Blanchet
-Viagenie inc.
-2875 boul. Laurier, bur. 300
-Ste-Foy, Quebec, Canada, G1V 2M2
-Marc.Blanchet@viagenie.qc.ca
-
-
-D. Mapping Tables
-
-The following is the mapping table from Section 3. The table has three
-columns:
-- the code point that is mapped from
-- the zero or more code points that it is mapped to
-- the reason for the mapping
-The columns are separated by semicolons. Note that the second column may
-be empty, or it may have one code point, or it may have more than one
-code point, with each code point separated by a space.
-
------ Start Mapping Table -----
-0041; 0061; Case map
-0042; 0062; Case map
-0043; 0063; Case map
-0044; 0064; Case map
-0045; 0065; Case map
-0046; 0066; Case map
-0047; 0067; Case map
-0048; 0068; Case map
-0049; 0069; Case map
-004A; 006A; Case map
-004B; 006B; Case map
-004C; 006C; Case map
-004D; 006D; Case map
-004E; 006E; Case map
-004F; 006F; Case map
-0050; 0070; Case map
-0051; 0071; Case map
-0052; 0072; Case map
-0053; 0073; Case map
-0054; 0074; Case map
-0055; 0075; Case map
-0056; 0076; Case map
-0057; 0077; Case map
-0058; 0078; Case map
-0059; 0079; Case map
-005A; 007A; Case map
-00AD; ; Map out
-00B5; 03BC; Case map
-00C0; 00E0; Case map
-00C1; 00E1; Case map
-00C2; 00E2; Case map
-00C3; 00E3; Case map
-00C4; 00E4; Case map
-00C5; 00E5; Case map
-00C6; 00E6; Case map
-00C7; 00E7; Case map
-00C8; 00E8; Case map
-00C9; 00E9; Case map
-00CA; 00EA; Case map
-00CB; 00EB; Case map
-00CC; 00EC; Case map
-00CD; 00ED; Case map
-00CE; 00EE; Case map
-00CF; 00EF; Case map
-00D0; 00F0; Case map
-00D1; 00F1; Case map
-00D2; 00F2; Case map
-00D3; 00F3; Case map
-00D4; 00F4; Case map
-00D5; 00F5; Case map
-00D6; 00F6; Case map
-00D8; 00F8; Case map
-00D9; 00F9; Case map
-00DA; 00FA; Case map
-00DB; 00FB; Case map
-00DC; 00FC; Case map
-00DD; 00FD; Case map
-00DE; 00FE; Case map
-00DF; 0073 0073; Case map
-0100; 0101; Case map
-0102; 0103; Case map
-0104; 0105; Case map
-0106; 0107; Case map
-0108; 0109; Case map
-010A; 010B; Case map
-010C; 010D; Case map
-010E; 010F; Case map
-0110; 0111; Case map
-0112; 0113; Case map
-0114; 0115; Case map
-0116; 0117; Case map
-0118; 0119; Case map
-011A; 011B; Case map
-011C; 011D; Case map
-011E; 011F; Case map
-0120; 0121; Case map
-0122; 0123; Case map
-0124; 0125; Case map
-0126; 0127; Case map
-0128; 0129; Case map
-012A; 012B; Case map
-012C; 012D; Case map
-012E; 012F; Case map
-0130; 0069; Case map
-0131; 0069; Case map
-0132; 0133; Case map
-0134; 0135; Case map
-0136; 0137; Case map
-0139; 013A; Case map
-013B; 013C; Case map
-013D; 013E; Case map
-013F; 0140; Case map
-0141; 0142; Case map
-0143; 0144; Case map
-0145; 0146; Case map
-0147; 0148; Case map
-0149; 02BC 006E; Case map
-014A; 014B; Case map
-014C; 014D; Case map
-014E; 014F; Case map
-0150; 0151; Case map
-0152; 0153; Case map
-0154; 0155; Case map
-0156; 0157; Case map
-0158; 0159; Case map
-015A; 015B; Case map
-015C; 015D; Case map
-015E; 015F; Case map
-0160; 0161; Case map
-0162; 0163; Case map
-0164; 0165; Case map
-0166; 0167; Case map
-0168; 0169; Case map
-016A; 016B; Case map
-016C; 016D; Case map
-016E; 016F; Case map
-0170; 0171; Case map
-0172; 0173; Case map
-0174; 0175; Case map
-0176; 0177; Case map
-0178; 00FF; Case map
-0179; 017A; Case map
-017B; 017C; Case map
-017D; 017E; Case map
-017F; 0073; Case map
-0181; 0253; Case map
-0182; 0183; Case map
-0184; 0185; Case map
-0186; 0254; Case map
-0187; 0188; Case map
-0189; 0256; Case map
-018A; 0257; Case map
-018B; 018C; Case map
-018E; 01DD; Case map
-018F; 0259; Case map
-0190; 025B; Case map
-0191; 0192; Case map
-0193; 0260; Case map
-0194; 0263; Case map
-0196; 0269; Case map
-0197; 0268; Case map
-0198; 0199; Case map
-019C; 026F; Case map
-019D; 0272; Case map
-019F; 0275; Case map
-01A0; 01A1; Case map
-01A2; 01A3; Case map
-01A4; 01A5; Case map
-01A6; 0280; Case map
-01A7; 01A8; Case map
-01A9; 0283; Case map
-01AC; 01AD; Case map
-01AE; 0288; Case map
-01AF; 01B0; Case map
-01B1; 028A; Case map
-01B2; 028B; Case map
-01B3; 01B4; Case map
-01B5; 01B6; Case map
-01B7; 0292; Case map
-01B8; 01B9; Case map
-01BC; 01BD; Case map
-01C4; 01C6; Case map
-01C5; 01C6; Case map
-01C7; 01C9; Case map
-01C8; 01C9; Case map
-01CA; 01CC; Case map
-01CB; 01CC; Case map
-01CD; 01CE; Case map
-01CF; 01D0; Case map
-01D1; 01D2; Case map
-01D3; 01D4; Case map
-01D5; 01D6; Case map
-01D7; 01D8; Case map
-01D9; 01DA; Case map
-01DB; 01DC; Case map
-01DE; 01DF; Case map
-01E0; 01E1; Case map
-01E2; 01E3; Case map
-01E4; 01E5; Case map
-01E6; 01E7; Case map
-01E8; 01E9; Case map
-01EA; 01EB; Case map
-01EC; 01ED; Case map
-01EE; 01EF; Case map
-01F0; 006A 030C; Case map
-01F1; 01F3; Case map
-01F2; 01F3; Case map
-01F4; 01F5; Case map
-01F6; 0195; Case map
-01F7; 01BF; Case map
-01F8; 01F9; Case map
-01FA; 01FB; Case map
-01FC; 01FD; Case map
-01FE; 01FF; Case map
-0200; 0201; Case map
-0202; 0203; Case map
-0204; 0205; Case map
-0206; 0207; Case map
-0208; 0209; Case map
-020A; 020B; Case map
-020C; 020D; Case map
-020E; 020F; Case map
-0210; 0211; Case map
-0212; 0213; Case map
-0214; 0215; Case map
-0216; 0217; Case map
-0218; 0219; Case map
-021A; 021B; Case map
-021C; 021D; Case map
-021E; 021F; Case map
-0222; 0223; Case map
-0224; 0225; Case map
-0226; 0227; Case map
-0228; 0229; Case map
-022A; 022B; Case map
-022C; 022D; Case map
-022E; 022F; Case map
-0230; 0231; Case map
-0232; 0233; Case map
-0345; 03B9; Case map
-037A; 0020 03B9; Additional folding
-0386; 03AC; Case map
-0388; 03AD; Case map
-0389; 03AE; Case map
-038A; 03AF; Case map
-038C; 03CC; Case map
-038E; 03CD; Case map
-038F; 03CE; Case map
-0390; 03B9 0308 0301; Case map
-0391; 03B1; Case map
-0392; 03B2; Case map
-0393; 03B3; Case map
-0394; 03B4; Case map
-0395; 03B5; Case map
-0396; 03B6; Case map
-0397; 03B7; Case map
-0398; 03B8; Case map
-0399; 03B9; Case map
-039A; 03BA; Case map
-039B; 03BB; Case map
-039C; 03BC; Case map
-039D; 03BD; Case map
-039E; 03BE; Case map
-039F; 03BF; Case map
-03A0; 03C0; Case map
-03A1; 03C1; Case map
-03A3; 03C3; Case map
-03A4; 03C4; Case map
-03A5; 03C5; Case map
-03A6; 03C6; Case map
-03A7; 03C7; Case map
-03A8; 03C8; Case map
-03A9; 03C9; Case map
-03AA; 03CA; Case map
-03AB; 03CB; Case map
-03B0; 03C5 0308 0301; Case map
-03C2; 03C3; Case map
-03D0; 03B2; Case map
-03D1; 03B8; Case map
-03D2; 03C5; Additional folding
-03D3; 03CD; Additional folding
-03D4; 03CB; Additional folding
-03D5; 03C6; Case map
-03D6; 03C0; Case map
-03DA; 03DB; Case map
-03DC; 03DD; Case map
-03DE; 03DF; Case map
-03E0; 03E1; Case map
-03E2; 03E3; Case map
-03E4; 03E5; Case map
-03E6; 03E7; Case map
-03E8; 03E9; Case map
-03EA; 03EB; Case map
-03EC; 03ED; Case map
-03EE; 03EF; Case map
-03F0; 03BA; Case map
-03F1; 03C1; Case map
-03F2; 03C3; Case map
-03F4; 03B8; Case map
-03F5; 03B5; Case map
-0400; 0450; Case map
-0401; 0451; Case map
-0402; 0452; Case map
-0403; 0453; Case map
-0404; 0454; Case map
-0405; 0455; Case map
-0406; 0456; Case map
-0407; 0457; Case map
-0408; 0458; Case map
-0409; 0459; Case map
-040A; 045A; Case map
-040B; 045B; Case map
-040C; 045C; Case map
-040D; 045D; Case map
-040E; 045E; Case map
-040F; 045F; Case map
-0410; 0430; Case map
-0411; 0431; Case map
-0412; 0432; Case map
-0413; 0433; Case map
-0414; 0434; Case map
-0415; 0435; Case map
-0416; 0436; Case map
-0417; 0437; Case map
-0418; 0438; Case map
-0419; 0439; Case map
-041A; 043A; Case map
-041B; 043B; Case map
-041C; 043C; Case map
-041D; 043D; Case map
-041E; 043E; Case map
-041F; 043F; Case map
-0420; 0440; Case map
-0421; 0441; Case map
-0422; 0442; Case map
-0423; 0443; Case map
-0424; 0444; Case map
-0425; 0445; Case map
-0426; 0446; Case map
-0427; 0447; Case map
-0428; 0448; Case map
-0429; 0449; Case map
-042A; 044A; Case map
-042B; 044B; Case map
-042C; 044C; Case map
-042D; 044D; Case map
-042E; 044E; Case map
-042F; 044F; Case map
-0460; 0461; Case map
-0462; 0463; Case map
-0464; 0465; Case map
-0466; 0467; Case map
-0468; 0469; Case map
-046A; 046B; Case map
-046C; 046D; Case map
-046E; 046F; Case map
-0470; 0471; Case map
-0472; 0473; Case map
-0474; 0475; Case map
-0476; 0477; Case map
-0478; 0479; Case map
-047A; 047B; Case map
-047C; 047D; Case map
-047E; 047F; Case map
-0480; 0481; Case map
-048C; 048D; Case map
-048E; 048F; Case map
-0490; 0491; Case map
-0492; 0493; Case map
-0494; 0495; Case map
-0496; 0497; Case map
-0498; 0499; Case map
-049A; 049B; Case map
-049C; 049D; Case map
-049E; 049F; Case map
-04A0; 04A1; Case map
-04A2; 04A3; Case map
-04A4; 04A5; Case map
-04A6; 04A7; Case map
-04A8; 04A9; Case map
-04AA; 04AB; Case map
-04AC; 04AD; Case map
-04AE; 04AF; Case map
-04B0; 04B1; Case map
-04B2; 04B3; Case map
-04B4; 04B5; Case map
-04B6; 04B7; Case map
-04B8; 04B9; Case map
-04BA; 04BB; Case map
-04BC; 04BD; Case map
-04BE; 04BF; Case map
-04C1; 04C2; Case map
-04C3; 04C4; Case map
-04C7; 04C8; Case map
-04CB; 04CC; Case map
-04D0; 04D1; Case map
-04D2; 04D3; Case map
-04D4; 04D5; Case map
-04D6; 04D7; Case map
-04D8; 04D9; Case map
-04DA; 04DB; Case map
-04DC; 04DD; Case map
-04DE; 04DF; Case map
-04E0; 04E1; Case map
-04E2; 04E3; Case map
-04E4; 04E5; Case map
-04E6; 04E7; Case map
-04E8; 04E9; Case map
-04EA; 04EB; Case map
-04EC; 04ED; Case map
-04EE; 04EF; Case map
-04F0; 04F1; Case map
-04F2; 04F3; Case map
-04F4; 04F5; Case map
-04F8; 04F9; Case map
-0531; 0561; Case map
-0532; 0562; Case map
-0533; 0563; Case map
-0534; 0564; Case map
-0535; 0565; Case map
-0536; 0566; Case map
-0537; 0567; Case map
-0538; 0568; Case map
-0539; 0569; Case map
-053A; 056A; Case map
-053B; 056B; Case map
-053C; 056C; Case map
-053D; 056D; Case map
-053E; 056E; Case map
-053F; 056F; Case map
-0540; 0570; Case map
-0541; 0571; Case map
-0542; 0572; Case map
-0543; 0573; Case map
-0544; 0574; Case map
-0545; 0575; Case map
-0546; 0576; Case map
-0547; 0577; Case map
-0548; 0578; Case map
-0549; 0579; Case map
-054A; 057A; Case map
-054B; 057B; Case map
-054C; 057C; Case map
-054D; 057D; Case map
-054E; 057E; Case map
-054F; 057F; Case map
-0550; 0580; Case map
-0551; 0581; Case map
-0552; 0582; Case map
-0553; 0583; Case map
-0554; 0584; Case map
-0555; 0585; Case map
-0556; 0586; Case map
-0587; 0565 0582; Case map
-1806; ; Map out
-180B; ; Map out
-180C; ; Map out
-180D; ; Map out
-1E00; 1E01; Case map
-1E02; 1E03; Case map
-1E04; 1E05; Case map
-1E06; 1E07; Case map
-1E08; 1E09; Case map
-1E0A; 1E0B; Case map
-1E0C; 1E0D; Case map
-1E0E; 1E0F; Case map
-1E10; 1E11; Case map
-1E12; 1E13; Case map
-1E14; 1E15; Case map
-1E16; 1E17; Case map
-1E18; 1E19; Case map
-1E1A; 1E1B; Case map
-1E1C; 1E1D; Case map
-1E1E; 1E1F; Case map
-1E20; 1E21; Case map
-1E22; 1E23; Case map
-1E24; 1E25; Case map
-1E26; 1E27; Case map
-1E28; 1E29; Case map
-1E2A; 1E2B; Case map
-1E2C; 1E2D; Case map
-1E2E; 1E2F; Case map
-1E30; 1E31; Case map
-1E32; 1E33; Case map
-1E34; 1E35; Case map
-1E36; 1E37; Case map
-1E38; 1E39; Case map
-1E3A; 1E3B; Case map
-1E3C; 1E3D; Case map
-1E3E; 1E3F; Case map
-1E40; 1E41; Case map
-1E42; 1E43; Case map
-1E44; 1E45; Case map
-1E46; 1E47; Case map
-1E48; 1E49; Case map
-1E4A; 1E4B; Case map
-1E4C; 1E4D; Case map
-1E4E; 1E4F; Case map
-1E50; 1E51; Case map
-1E52; 1E53; Case map
-1E54; 1E55; Case map
-1E56; 1E57; Case map
-1E58; 1E59; Case map
-1E5A; 1E5B; Case map
-1E5C; 1E5D; Case map
-1E5E; 1E5F; Case map
-1E60; 1E61; Case map
-1E62; 1E63; Case map
-1E64; 1E65; Case map
-1E66; 1E67; Case map
-1E68; 1E69; Case map
-1E6A; 1E6B; Case map
-1E6C; 1E6D; Case map
-1E6E; 1E6F; Case map
-1E70; 1E71; Case map
-1E72; 1E73; Case map
-1E74; 1E75; Case map
-1E76; 1E77; Case map
-1E78; 1E79; Case map
-1E7A; 1E7B; Case map
-1E7C; 1E7D; Case map
-1E7E; 1E7F; Case map
-1E80; 1E81; Case map
-1E82; 1E83; Case map
-1E84; 1E85; Case map
-1E86; 1E87; Case map
-1E88; 1E89; Case map
-1E8A; 1E8B; Case map
-1E8C; 1E8D; Case map
-1E8E; 1E8F; Case map
-1E90; 1E91; Case map
-1E92; 1E93; Case map
-1E94; 1E95; Case map
-1E96; 0068 0331; Case map
-1E97; 0074 0308; Case map
-1E98; 0077 030A; Case map
-1E99; 0079 030A; Case map
-1E9A; 0061 02BE; Case map
-1E9B; 1E61; Case map
-1EA0; 1EA1; Case map
-1EA2; 1EA3; Case map
-1EA4; 1EA5; Case map
-1EA6; 1EA7; Case map
-1EA8; 1EA9; Case map
-1EAA; 1EAB; Case map
-1EAC; 1EAD; Case map
-1EAE; 1EAF; Case map
-1EB0; 1EB1; Case map
-1EB2; 1EB3; Case map
-1EB4; 1EB5; Case map
-1EB6; 1EB7; Case map
-1EB8; 1EB9; Case map
-1EBA; 1EBB; Case map
-1EBC; 1EBD; Case map
-1EBE; 1EBF; Case map
-1EC0; 1EC1; Case map
-1EC2; 1EC3; Case map
-1EC4; 1EC5; Case map
-1EC6; 1EC7; Case map
-1EC8; 1EC9; Case map
-1ECA; 1ECB; Case map
-1ECC; 1ECD; Case map
-1ECE; 1ECF; Case map
-1ED0; 1ED1; Case map
-1ED2; 1ED3; Case map
-1ED4; 1ED5; Case map
-1ED6; 1ED7; Case map
-1ED8; 1ED9; Case map
-1EDA; 1EDB; Case map
-1EDC; 1EDD; Case map
-1EDE; 1EDF; Case map
-1EE0; 1EE1; Case map
-1EE2; 1EE3; Case map
-1EE4; 1EE5; Case map
-1EE6; 1EE7; Case map
-1EE8; 1EE9; Case map
-1EEA; 1EEB; Case map
-1EEC; 1EED; Case map
-1EEE; 1EEF; Case map
-1EF0; 1EF1; Case map
-1EF2; 1EF3; Case map
-1EF4; 1EF5; Case map
-1EF6; 1EF7; Case map
-1EF8; 1EF9; Case map
-1F08; 1F00; Case map
-1F09; 1F01; Case map
-1F0A; 1F02; Case map
-1F0B; 1F03; Case map
-1F0C; 1F04; Case map
-1F0D; 1F05; Case map
-1F0E; 1F06; Case map
-1F0F; 1F07; Case map
-1F18; 1F10; Case map
-1F19; 1F11; Case map
-1F1A; 1F12; Case map
-1F1B; 1F13; Case map
-1F1C; 1F14; Case map
-1F1D; 1F15; Case map
-1F28; 1F20; Case map
-1F29; 1F21; Case map
-1F2A; 1F22; Case map
-1F2B; 1F23; Case map
-1F2C; 1F24; Case map
-1F2D; 1F25; Case map
-1F2E; 1F26; Case map
-1F2F; 1F27; Case map
-1F38; 1F30; Case map
-1F39; 1F31; Case map
-1F3A; 1F32; Case map
-1F3B; 1F33; Case map
-1F3C; 1F34; Case map
-1F3D; 1F35; Case map
-1F3E; 1F36; Case map
-1F3F; 1F37; Case map
-1F48; 1F40; Case map
-1F49; 1F41; Case map
-1F4A; 1F42; Case map
-1F4B; 1F43; Case map
-1F4C; 1F44; Case map
-1F4D; 1F45; Case map
-1F50; 03C5 0313; Case map
-1F52; 03C5 0313 0300; Case map
-1F54; 03C5 0313 0301; Case map
-1F56; 03C5 0313 0342; Case map
-1F59; 1F51; Case map
-1F5B; 1F53; Case map
-1F5D; 1F55; Case map
-1F5F; 1F57; Case map
-1F68; 1F60; Case map
-1F69; 1F61; Case map
-1F6A; 1F62; Case map
-1F6B; 1F63; Case map
-1F6C; 1F64; Case map
-1F6D; 1F65; Case map
-1F6E; 1F66; Case map
-1F6F; 1F67; Case map
-1F80; 1F00 03B9; Case map
-1F81; 1F01 03B9; Case map
-1F82; 1F02 03B9; Case map
-1F83; 1F03 03B9; Case map
-1F84; 1F04 03B9; Case map
-1F85; 1F05 03B9; Case map
-1F86; 1F06 03B9; Case map
-1F87; 1F07 03B9; Case map
-1F88; 1F00 03B9; Case map
-1F89; 1F01 03B9; Case map
-1F8A; 1F02 03B9; Case map
-1F8B; 1F03 03B9; Case map
-1F8C; 1F04 03B9; Case map
-1F8D; 1F05 03B9; Case map
-1F8E; 1F06 03B9; Case map
-1F8F; 1F07 03B9; Case map
-1F90; 1F20 03B9; Case map
-1F91; 1F21 03B9; Case map
-1F92; 1F22 03B9; Case map
-1F93; 1F23 03B9; Case map
-1F94; 1F24 03B9; Case map
-1F95; 1F25 03B9; Case map
-1F96; 1F26 03B9; Case map
-1F97; 1F27 03B9; Case map
-1F98; 1F20 03B9; Case map
-1F99; 1F21 03B9; Case map
-1F9A; 1F22 03B9; Case map
-1F9B; 1F23 03B9; Case map
-1F9C; 1F24 03B9; Case map
-1F9D; 1F25 03B9; Case map
-1F9E; 1F26 03B9; Case map
-1F9F; 1F27 03B9; Case map
-1FA0; 1F60 03B9; Case map
-1FA1; 1F61 03B9; Case map
-1FA2; 1F62 03B9; Case map
-1FA3; 1F63 03B9; Case map
-1FA4; 1F64 03B9; Case map
-1FA5; 1F65 03B9; Case map
-1FA6; 1F66 03B9; Case map
-1FA7; 1F67 03B9; Case map
-1FA8; 1F60 03B9; Case map
-1FA9; 1F61 03B9; Case map
-1FAA; 1F62 03B9; Case map
-1FAB; 1F63 03B9; Case map
-1FAC; 1F64 03B9; Case map
-1FAD; 1F65 03B9; Case map
-1FAE; 1F66 03B9; Case map
-1FAF; 1F67 03B9; Case map
-1FB2; 1F70 03B9; Case map
-1FB3; 03B1 03B9; Case map
-1FB4; 03AC 03B9; Case map
-1FB6; 03B1 0342; Case map
-1FB7; 03B1 0342 03B9; Case map
-1FB8; 1FB0; Case map
-1FB9; 1FB1; Case map
-1FBA; 1F70; Case map
-1FBB; 1F71; Case map
-1FBC; 03B1 03B9; Case map
-1FBE; 03B9; Case map
-1FC2; 1F74 03B9; Case map
-1FC3; 03B7 03B9; Case map
-1FC4; 03AE 03B9; Case map
-1FC6; 03B7 0342; Case map
-1FC7; 03B7 0342 03B9; Case map
-1FC8; 1F72; Case map
-1FC9; 1F73; Case map
-1FCA; 1F74; Case map
-1FCB; 1F75; Case map
-1FCC; 03B7 03B9; Case map
-1FD2; 03B9 0308 0300; Case map
-1FD3; 03B9 0308 0301; Case map
-1FD6; 03B9 0342; Case map
-1FD7; 03B9 0308 0342; Case map
-1FD8; 1FD0; Case map
-1FD9; 1FD1; Case map
-1FDA; 1F76; Case map
-1FDB; 1F77; Case map
-1FE2; 03C5 0308 0300; Case map
-1FE3; 03C5 0308 0301; Case map
-1FE4; 03C1 0313; Case map
-1FE6; 03C5 0342; Case map
-1FE7; 03C5 0308 0342; Case map
-1FE8; 1FE0; Case map
-1FE9; 1FE1; Case map
-1FEA; 1F7A; Case map
-1FEB; 1F7B; Case map
-1FEC; 1FE5; Case map
-1FF2; 1F7C 03B9; Case map
-1FF3; 03C9 03B9; Case map
-1FF4; 03CE 03B9; Case map
-1FF6; 03C9 0342; Case map
-1FF7; 03C9 0342 03B9; Case map
-1FF8; 1F78; Case map
-1FF9; 1F79; Case map
-1FFA; 1F7C; Case map
-1FFB; 1F7D; Case map
-1FFC; 03C9 03B9; Case map
-200B; ; Map out
-200C; ; Map out
-200D; ; Map out
-20A8; 0072 0073; Additional folding
-2102; 0063; Additional folding
-2103; 00B0 0063; Additional folding
-2107; 025B; Additional folding
-2109; 00B0 0066; Additional folding
-210B; 0068; Additional folding
-210C; 0068; Additional folding
-210D; 0068; Additional folding
-2110; 0069; Additional folding
-2111; 0069; Additional folding
-2112; 006C; Additional folding
-2115; 006E; Additional folding
-2116; 006E 006F; Additional folding
-2119; 0070; Additional folding
-211A; 0071; Additional folding
-211B; 0072; Additional folding
-211C; 0072; Additional folding
-211D; 0072; Additional folding
-2120; 0073 006D; Additional folding
-2121; 0074 0065 006C; Additional folding
-2122; 0074 006D; Additional folding
-2124; 007A; Additional folding
-2126; 03C9; Case map
-2128; 007A; Additional folding
-212A; 006B; Case map
-212B; 00E5; Case map
-212C; 0062; Additional folding
-212D; 0063; Additional folding
-2130; 0065; Additional folding
-2131; 0066; Additional folding
-2133; 006D; Additional folding
-2160; 2170; Case map
-2161; 2171; Case map
-2162; 2172; Case map
-2163; 2173; Case map
-2164; 2174; Case map
-2165; 2175; Case map
-2166; 2176; Case map
-2167; 2177; Case map
-2168; 2178; Case map
-2169; 2179; Case map
-216A; 217A; Case map
-216B; 217B; Case map
-216C; 217C; Case map
-216D; 217D; Case map
-216E; 217E; Case map
-216F; 217F; Case map
-24B6; 24D0; Case map
-24B7; 24D1; Case map
-24B8; 24D2; Case map
-24B9; 24D3; Case map
-24BA; 24D4; Case map
-24BB; 24D5; Case map
-24BC; 24D6; Case map
-24BD; 24D7; Case map
-24BE; 24D8; Case map
-24BF; 24D9; Case map
-24C0; 24DA; Case map
-24C1; 24DB; Case map
-24C2; 24DC; Case map
-24C3; 24DD; Case map
-24C4; 24DE; Case map
-24C5; 24DF; Case map
-24C6; 24E0; Case map
-24C7; 24E1; Case map
-24C8; 24E2; Case map
-24C9; 24E3; Case map
-24CA; 24E4; Case map
-24CB; 24E5; Case map
-24CC; 24E6; Case map
-24CD; 24E7; Case map
-24CE; 24E8; Case map
-24CF; 24E9; Case map
-3371; 0068 0070 0061; Additional folding
-3373; 0061 0075; Additional folding
-3375; 006F 0076; Additional folding
-3380; 0070 0061; Additional folding
-3381; 006E 0061; Additional folding
-3382; 03BC 0061; Additional folding
-3383; 006D 0061; Additional folding
-3384; 006B 0061; Additional folding
-3385; 006B 0062; Additional folding
-3386; 006D 0062; Additional folding
-3387; 0067 0062; Additional folding
-338A; 0070 0066; Additional folding
-338B; 006E 0066; Additional folding
-338C; 03BC 0066; Additional folding
-3390; 0068 007A; Additional folding
-3391; 006B 0068 007A; Additional folding
-3392; 006D 0068 007A; Additional folding
-3393; 0067 0068 007A; Additional folding
-3394; 0074 0068 007A; Additional folding
-33A9; 0070 0061; Additional folding
-33AA; 006B 0070 0061; Additional folding
-33AB; 006D 0070 0061; Additional folding
-33AC; 0067 0070 0061; Additional folding
-33B4; 0070 0076; Additional folding
-33B5; 006E 0076; Additional folding
-33B6; 03BC 0076; Additional folding
-33B7; 006D 0076; Additional folding
-33B8; 006B 0076; Additional folding
-33B9; 006D 0076; Additional folding
-33BA; 0070 0077; Additional folding
-33BB; 006E 0077; Additional folding
-33BC; 03BC 0077; Additional folding
-33BD; 006D 0077; Additional folding
-33BE; 006B 0077; Additional folding
-33BF; 006D 0077; Additional folding
-33C0; 006B 03C9; Additional folding
-33C1; 006D 03C9; Additional folding
-33C3; 0062 0071; Additional folding
-33C6; 0063 2215 006B 0067; Additional folding
-33C7; 0063 006F 002E; Additional folding
-33C8; 0064 0062; Additional folding
-33C9; 0067 0079; Additional folding
-33CB; 0068 0070; Additional folding
-33CD; 006B 006B; Additional folding
-33CE; 006B 006D; Additional folding
-33D7; 0070 0068; Additional folding
-33D9; 0070 0070 006D; Additional folding
-33DA; 0070 0072; Additional folding
-33DC; 0073 0076; Additional folding
-33DD; 0077 0062; Additional folding
-FB00; 0066 0066; Case map
-FB01; 0066 0069; Case map
-FB02; 0066 006C; Case map
-FB03; 0066 0066 0069; Case map
-FB04; 0066 0066 006C; Case map
-FB05; 0073 0074; Case map
-FB06; 0073 0074; Case map
-FB13; 0574 0576; Case map
-FB14; 0574 0565; Case map
-FB15; 0574 056B; Case map
-FB16; 057E 0576; Case map
-FB17; 0574 056D; Case map
-FEFF; ; Map out
-FF21; FF41; Case map
-FF22; FF42; Case map
-FF23; FF43; Case map
-FF24; FF44; Case map
-FF25; FF45; Case map
-FF26; FF46; Case map
-FF27; FF47; Case map
-FF28; FF48; Case map
-FF29; FF49; Case map
-FF2A; FF4A; Case map
-FF2B; FF4B; Case map
-FF2C; FF4C; Case map
-FF2D; FF4D; Case map
-FF2E; FF4E; Case map
-FF2F; FF4F; Case map
-FF30; FF50; Case map
-FF31; FF51; Case map
-FF32; FF52; Case map
-FF33; FF53; Case map
-FF34; FF54; Case map
-FF35; FF55; Case map
-FF36; FF56; Case map
-FF37; FF57; Case map
-FF38; FF58; Case map
-FF39; FF59; Case map
-FF3A; FF5A; Case map
-10400; 10428; Case map
-10401; 10429; Case map
-10402; 1042A; Case map
-10403; 1042B; Case map
-10404; 1042C; Case map
-10405; 1042D; Case map
-10406; 1042E; Case map
-10407; 1042F; Case map
-10408; 10430; Case map
-10409; 10431; Case map
-1040A; 10432; Case map
-1040B; 10433; Case map
-1040C; 10434; Case map
-1040D; 10435; Case map
-1040E; 10436; Case map
-1040F; 10437; Case map
-10410; 10438; Case map
-10411; 10439; Case map
-10412; 1043A; Case map
-10413; 1043B; Case map
-10414; 1043C; Case map
-10415; 1043D; Case map
-10416; 1043E; Case map
-10417; 1043F; Case map
-10418; 10440; Case map
-10419; 10441; Case map
-1041A; 10442; Case map
-1041B; 10443; Case map
-1041C; 10444; Case map
-1041D; 10445; Case map
-1041E; 10446; Case map
-1041F; 10447; Case map
-10420; 10448; Case map
-10421; 10449; Case map
-10422; 1044A; Case map
-10423; 1044B; Case map
-10424; 1044C; Case map
-10425; 1044D; Case map
-1D400; 0061; Additional folding
-1D401; 0062; Additional folding
-1D402; 0063; Additional folding
-1D403; 0064; Additional folding
-1D404; 0065; Additional folding
-1D405; 0066; Additional folding
-1D406; 0067; Additional folding
-1D407; 0068; Additional folding
-1D408; 0069; Additional folding
-1D409; 006A; Additional folding
-1D40A; 006B; Additional folding
-1D40B; 006C; Additional folding
-1D40C; 006D; Additional folding
-1D40D; 006E; Additional folding
-1D40E; 006F; Additional folding
-1D40F; 0070; Additional folding
-1D410; 0071; Additional folding
-1D411; 0072; Additional folding
-1D412; 0073; Additional folding
-1D413; 0074; Additional folding
-1D414; 0075; Additional folding
-1D415; 0076; Additional folding
-1D416; 0077; Additional folding
-1D417; 0078; Additional folding
-1D418; 0079; Additional folding
-1D419; 007A; Additional folding
-1D434; 0061; Additional folding
-1D435; 0062; Additional folding
-1D436; 0063; Additional folding
-1D437; 0064; Additional folding
-1D438; 0065; Additional folding
-1D439; 0066; Additional folding
-1D43A; 0067; Additional folding
-1D43B; 0068; Additional folding
-1D43C; 0069; Additional folding
-1D43D; 006A; Additional folding
-1D43E; 006B; Additional folding
-1D43F; 006C; Additional folding
-1D440; 006D; Additional folding
-1D441; 006E; Additional folding
-1D442; 006F; Additional folding
-1D443; 0070; Additional folding
-1D444; 0071; Additional folding
-1D445; 0072; Additional folding
-1D446; 0073; Additional folding
-1D447; 0074; Additional folding
-1D448; 0075; Additional folding
-1D449; 0076; Additional folding
-1D44A; 0077; Additional folding
-1D44B; 0078; Additional folding
-1D44C; 0079; Additional folding
-1D44D; 007A; Additional folding
-1D468; 0061; Additional folding
-1D469; 0062; Additional folding
-1D46A; 0063; Additional folding
-1D46B; 0064; Additional folding
-1D46C; 0065; Additional folding
-1D46D; 0066; Additional folding
-1D46E; 0067; Additional folding
-1D46F; 0068; Additional folding
-1D470; 0069; Additional folding
-1D471; 006A; Additional folding
-1D472; 006B; Additional folding
-1D473; 006C; Additional folding
-1D474; 006D; Additional folding
-1D475; 006E; Additional folding
-1D476; 006F; Additional folding
-1D477; 0070; Additional folding
-1D478; 0071; Additional folding
-1D479; 0072; Additional folding
-1D47A; 0073; Additional folding
-1D47B; 0074; Additional folding
-1D47C; 0075; Additional folding
-1D47D; 0076; Additional folding
-1D47E; 0077; Additional folding
-1D47F; 0078; Additional folding
-1D480; 0079; Additional folding
-1D481; 007A; Additional folding
-1D49C; 0061; Additional folding
-1D49E; 0063; Additional folding
-1D49F; 0064; Additional folding
-1D4A2; 0067; Additional folding
-1D4A5; 006A; Additional folding
-1D4A6; 006B; Additional folding
-1D4A9; 006E; Additional folding
-1D4AA; 006F; Additional folding
-1D4AB; 0070; Additional folding
-1D4AC; 0071; Additional folding
-1D4AE; 0073; Additional folding
-1D4AF; 0074; Additional folding
-1D4B0; 0075; Additional folding
-1D4B1; 0076; Additional folding
-1D4B2; 0077; Additional folding
-1D4B3; 0078; Additional folding
-1D4B4; 0079; Additional folding
-1D4B5; 007A; Additional folding
-1D4D0; 0061; Additional folding
-1D4D1; 0062; Additional folding
-1D4D2; 0063; Additional folding
-1D4D3; 0064; Additional folding
-1D4D4; 0065; Additional folding
-1D4D5; 0066; Additional folding
-1D4D6; 0067; Additional folding
-1D4D7; 0068; Additional folding
-1D4D8; 0069; Additional folding
-1D4D9; 006A; Additional folding
-1D4DA; 006B; Additional folding
-1D4DB; 006C; Additional folding
-1D4DC; 006D; Additional folding
-1D4DD; 006E; Additional folding
-1D4DE; 006F; Additional folding
-1D4DF; 0070; Additional folding
-1D4E0; 0071; Additional folding
-1D4E1; 0072; Additional folding
-1D4E2; 0073; Additional folding
-1D4E3; 0074; Additional folding
-1D4E4; 0075; Additional folding
-1D4E5; 0076; Additional folding
-1D4E6; 0077; Additional folding
-1D4E7; 0078; Additional folding
-1D4E8; 0079; Additional folding
-1D4E9; 007A; Additional folding
-1D504; 0061; Additional folding
-1D505; 0062; Additional folding
-1D507; 0064; Additional folding
-1D508; 0065; Additional folding
-1D509; 0066; Additional folding
-1D50A; 0067; Additional folding
-1D50D; 006A; Additional folding
-1D50E; 006B; Additional folding
-1D50F; 006C; Additional folding
-1D510; 006D; Additional folding
-1D511; 006E; Additional folding
-1D512; 006F; Additional folding
-1D513; 0070; Additional folding
-1D514; 0071; Additional folding
-1D516; 0073; Additional folding
-1D517; 0074; Additional folding
-1D518; 0075; Additional folding
-1D519; 0076; Additional folding
-1D51A; 0077; Additional folding
-1D51B; 0078; Additional folding
-1D51C; 0079; Additional folding
-1D538; 0061; Additional folding
-1D539; 0062; Additional folding
-1D53B; 0064; Additional folding
-1D53C; 0065; Additional folding
-1D53D; 0066; Additional folding
-1D53E; 0067; Additional folding
-1D540; 0069; Additional folding
-1D541; 006A; Additional folding
-1D542; 006B; Additional folding
-1D543; 006C; Additional folding
-1D544; 006D; Additional folding
-1D546; 006F; Additional folding
-1D54A; 0073; Additional folding
-1D54B; 0074; Additional folding
-1D54C; 0075; Additional folding
-1D54D; 0076; Additional folding
-1D54E; 0077; Additional folding
-1D54F; 0078; Additional folding
-1D550; 0079; Additional folding
-1D56C; 0061; Additional folding
-1D56D; 0062; Additional folding
-1D56E; 0063; Additional folding
-1D56F; 0064; Additional folding
-1D570; 0065; Additional folding
-1D571; 0066; Additional folding
-1D572; 0067; Additional folding
-1D573; 0068; Additional folding
-1D574; 0069; Additional folding
-1D575; 006A; Additional folding
-1D576; 006B; Additional folding
-1D577; 006C; Additional folding
-1D578; 006D; Additional folding
-1D579; 006E; Additional folding
-1D57A; 006F; Additional folding
-1D57B; 0070; Additional folding
-1D57C; 0071; Additional folding
-1D57D; 0072; Additional folding
-1D57E; 0073; Additional folding
-1D57F; 0074; Additional folding
-1D580; 0075; Additional folding
-1D581; 0076; Additional folding
-1D582; 0077; Additional folding
-1D583; 0078; Additional folding
-1D584; 0079; Additional folding
-1D585; 007A; Additional folding
-1D5A0; 0061; Additional folding
-1D5A1; 0062; Additional folding
-1D5A2; 0063; Additional folding
-1D5A3; 0064; Additional folding
-1D5A4; 0065; Additional folding
-1D5A5; 0066; Additional folding
-1D5A6; 0067; Additional folding
-1D5A7; 0068; Additional folding
-1D5A8; 0069; Additional folding
-1D5A9; 006A; Additional folding
-1D5AA; 006B; Additional folding
-1D5AB; 006C; Additional folding
-1D5AC; 006D; Additional folding
-1D5AD; 006E; Additional folding
-1D5AE; 006F; Additional folding
-1D5AF; 0070; Additional folding
-1D5B0; 0071; Additional folding
-1D5B1; 0072; Additional folding
-1D5B2; 0073; Additional folding
-1D5B3; 0074; Additional folding
-1D5B4; 0075; Additional folding
-1D5B5; 0076; Additional folding
-1D5B6; 0077; Additional folding
-1D5B7; 0078; Additional folding
-1D5B8; 0079; Additional folding
-1D5B9; 007A; Additional folding
-1D5D4; 0061; Additional folding
-1D5D5; 0062; Additional folding
-1D5D6; 0063; Additional folding
-1D5D7; 0064; Additional folding
-1D5D8; 0065; Additional folding
-1D5D9; 0066; Additional folding
-1D5DA; 0067; Additional folding
-1D5DB; 0068; Additional folding
-1D5DC; 0069; Additional folding
-1D5DD; 006A; Additional folding
-1D5DE; 006B; Additional folding
-1D5DF; 006C; Additional folding
-1D5E0; 006D; Additional folding
-1D5E1; 006E; Additional folding
-1D5E2; 006F; Additional folding
-1D5E3; 0070; Additional folding
-1D5E4; 0071; Additional folding
-1D5E5; 0072; Additional folding
-1D5E6; 0073; Additional folding
-1D5E7; 0074; Additional folding
-1D5E8; 0075; Additional folding
-1D5E9; 0076; Additional folding
-1D5EA; 0077; Additional folding
-1D5EB; 0078; Additional folding
-1D5EC; 0079; Additional folding
-1D5ED; 007A; Additional folding
-1D608; 0061; Additional folding
-1D609; 0062; Additional folding
-1D60A; 0063; Additional folding
-1D60B; 0064; Additional folding
-1D60C; 0065; Additional folding
-1D60D; 0066; Additional folding
-1D60E; 0067; Additional folding
-1D60F; 0068; Additional folding
-1D610; 0069; Additional folding
-1D611; 006A; Additional folding
-1D612; 006B; Additional folding
-1D613; 006C; Additional folding
-1D614; 006D; Additional folding
-1D615; 006E; Additional folding
-1D616; 006F; Additional folding
-1D617; 0070; Additional folding
-1D618; 0071; Additional folding
-1D619; 0072; Additional folding
-1D61A; 0073; Additional folding
-1D61B; 0074; Additional folding
-1D61C; 0075; Additional folding
-1D61D; 0076; Additional folding
-1D61E; 0077; Additional folding
-1D61F; 0078; Additional folding
-1D620; 0079; Additional folding
-1D621; 007A; Additional folding
-1D63C; 0061; Additional folding
-1D63D; 0062; Additional folding
-1D63E; 0063; Additional folding
-1D63F; 0064; Additional folding
-1D640; 0065; Additional folding
-1D641; 0066; Additional folding
-1D642; 0067; Additional folding
-1D643; 0068; Additional folding
-1D644; 0069; Additional folding
-1D645; 006A; Additional folding
-1D646; 006B; Additional folding
-1D647; 006C; Additional folding
-1D648; 006D; Additional folding
-1D649; 006E; Additional folding
-1D64A; 006F; Additional folding
-1D64B; 0070; Additional folding
-1D64C; 0071; Additional folding
-1D64D; 0072; Additional folding
-1D64E; 0073; Additional folding
-1D64F; 0074; Additional folding
-1D650; 0075; Additional folding
-1D651; 0076; Additional folding
-1D652; 0077; Additional folding
-1D653; 0078; Additional folding
-1D654; 0079; Additional folding
-1D655; 007A; Additional folding
-1D670; 0061; Additional folding
-1D671; 0062; Additional folding
-1D672; 0063; Additional folding
-1D673; 0064; Additional folding
-1D674; 0065; Additional folding
-1D675; 0066; Additional folding
-1D676; 0067; Additional folding
-1D677; 0068; Additional folding
-1D678; 0069; Additional folding
-1D679; 006A; Additional folding
-1D67A; 006B; Additional folding
-1D67B; 006C; Additional folding
-1D67C; 006D; Additional folding
-1D67D; 006E; Additional folding
-1D67E; 006F; Additional folding
-1D67F; 0070; Additional folding
-1D680; 0071; Additional folding
-1D681; 0072; Additional folding
-1D682; 0073; Additional folding
-1D683; 0074; Additional folding
-1D684; 0075; Additional folding
-1D685; 0076; Additional folding
-1D686; 0077; Additional folding
-1D687; 0078; Additional folding
-1D688; 0079; Additional folding
-1D689; 007A; Additional folding
-1D6A8; 03B1; Additional folding
-1D6A9; 03B2; Additional folding
-1D6AA; 03B3; Additional folding
-1D6AB; 03B4; Additional folding
-1D6AC; 03B5; Additional folding
-1D6AD; 03B6; Additional folding
-1D6AE; 03B7; Additional folding
-1D6AF; 03B8; Additional folding
-1D6B0; 03B9; Additional folding
-1D6B1; 03BA; Additional folding
-1D6B2; 03BB; Additional folding
-1D6B3; 03BC; Additional folding
-1D6B4; 03BD; Additional folding
-1D6B5; 03BE; Additional folding
-1D6B6; 03BF; Additional folding
-1D6B7; 03C0; Additional folding
-1D6B8; 03C1; Additional folding
-1D6B9; 03B8; Additional folding
-1D6BA; 03C3; Additional folding
-1D6BB; 03C4; Additional folding
-1D6BC; 03C5; Additional folding
-1D6BD; 03C6; Additional folding
-1D6BE; 03C7; Additional folding
-1D6BF; 03C8; Additional folding
-1D6C0; 03C9; Additional folding
-1D6D3; 03C3; Additional folding
-1D6E2; 03B1; Additional folding
-1D6E3; 03B2; Additional folding
-1D6E4; 03B3; Additional folding
-1D6E5; 03B4; Additional folding
-1D6E6; 03B5; Additional folding
-1D6E7; 03B6; Additional folding
-1D6E8; 03B7; Additional folding
-1D6E9; 03B8; Additional folding
-1D6EA; 03B9; Additional folding
-1D6EB; 03BA; Additional folding
-1D6EC; 03BB; Additional folding
-1D6ED; 03BC; Additional folding
-1D6EE; 03BD; Additional folding
-1D6EF; 03BE; Additional folding
-1D6F0; 03BF; Additional folding
-1D6F1; 03C0; Additional folding
-1D6F2; 03C1; Additional folding
-1D6F3; 03B8; Additional folding
-1D6F4; 03C3; Additional folding
-1D6F5; 03C4; Additional folding
-1D6F6; 03C5; Additional folding
-1D6F7; 03C6; Additional folding
-1D6F8; 03C7; Additional folding
-1D6F9; 03C8; Additional folding
-1D6FA; 03C9; Additional folding
-1D70D; 03C3; Additional folding
-1D71C; 03B1; Additional folding
-1D71D; 03B2; Additional folding
-1D71E; 03B3; Additional folding
-1D71F; 03B4; Additional folding
-1D720; 03B5; Additional folding
-1D721; 03B6; Additional folding
-1D722; 03B7; Additional folding
-1D723; 03B8; Additional folding
-1D724; 03B9; Additional folding
-1D725; 03BA; Additional folding
-1D726; 03BB; Additional folding
-1D727; 03BC; Additional folding
-1D728; 03BD; Additional folding
-1D729; 03BE; Additional folding
-1D72A; 03BF; Additional folding
-1D72B; 03C0; Additional folding
-1D72C; 03C1; Additional folding
-1D72D; 03B8; Additional folding
-1D72E; 03C3; Additional folding
-1D72F; 03C4; Additional folding
-1D730; 03C5; Additional folding
-1D731; 03C6; Additional folding
-1D732; 03C7; Additional folding
-1D733; 03C8; Additional folding
-1D734; 03C9; Additional folding
-1D747; 03C3; Additional folding
-1D756; 03B1; Additional folding
-1D757; 03B2; Additional folding
-1D758; 03B3; Additional folding
-1D759; 03B4; Additional folding
-1D75A; 03B5; Additional folding
-1D75B; 03B6; Additional folding
-1D75C; 03B7; Additional folding
-1D75D; 03B8; Additional folding
-1D75E; 03B9; Additional folding
-1D75F; 03BA; Additional folding
-1D760; 03BB; Additional folding
-1D761; 03BC; Additional folding
-1D762; 03BD; Additional folding
-1D763; 03BE; Additional folding
-1D764; 03BF; Additional folding
-1D765; 03C0; Additional folding
-1D766; 03C1; Additional folding
-1D767; 03B8; Additional folding
-1D768; 03C3; Additional folding
-1D769; 03C4; Additional folding
-1D76A; 03C5; Additional folding
-1D76B; 03C6; Additional folding
-1D76C; 03C7; Additional folding
-1D76D; 03C8; Additional folding
-1D76E; 03C9; Additional folding
-1D781; 03C3; Additional folding
-1D790; 03B1; Additional folding
-1D791; 03B2; Additional folding
-1D792; 03B3; Additional folding
-1D793; 03B4; Additional folding
-1D794; 03B5; Additional folding
-1D795; 03B6; Additional folding
-1D796; 03B7; Additional folding
-1D797; 03B8; Additional folding
-1D798; 03B9; Additional folding
-1D799; 03BA; Additional folding
-1D79A; 03BB; Additional folding
-1D79B; 03BC; Additional folding
-1D79C; 03BD; Additional folding
-1D79D; 03BE; Additional folding
-1D79E; 03BF; Additional folding
-1D79F; 03C0; Additional folding
-1D7A0; 03C1; Additional folding
-1D7A1; 03B8; Additional folding
-1D7A2; 03C3; Additional folding
-1D7A3; 03C4; Additional folding
-1D7A4; 03C5; Additional folding
-1D7A5; 03C6; Additional folding
-1D7A6; 03C7; Additional folding
-1D7A7; 03C8; Additional folding
-1D7A8; 03C9; Additional folding
-1D7BB; 03C3; Additional folding
------ End Mapping Table -----
-
-
-E. Prohibited Code Point List
-
------ Start Prohibited Table -----
-0080-00A0
-070F
-1680
-180E
-2000-200A
-200E-200F
-2028-2029
-202A-202F
-206A-206F
-2FF0-2FFB
-3000
-3002
-D800-F8FF
-FDD0-FDEF
-FFF9-FFFF
-1D173-1D17A
-1FFFE-1FFFF
-2FFFE-2FFFF
-3FFFE-3FFFF
-4FFFE-4FFFF
-5FFFE-5FFFF
-6FFFE-6FFFF
-7FFFE-7FFFF
-8FFFE-8FFFF
-9FFFE-9FFFF
-AFFFE-AFFFF
-BFFFE-BFFFF
-CFFFE-CFFFF
-DFFFE-DFFFF
-E0001
-E0020-E007F
-EFFFE-EFFFF
-F0000-FFFFF
-100000-10FFFF
------ End Prohibited Table -----
-
-NOTE WELL: Software that follows this specification that will be used to
-check names before they are put in authoritative name servers MUST add
-all unassigned code points to the list of characters that are prohibited.
-See Section 6 of [STRINGPREP] for more details.
-
-
-F. Unassigned Code Point List
-
------ Start Unassigned Table -----
-0220-0221
-0234-024F
-02AE-02AF
-02EF-02FF
-034F-035F
-0363-0373
-0376-0379
-037B-037D
-037F-0383
-038B
-038D
-03A2
-03CF
-03D8-03D9
-03F6-03FF
-0487
-048A-048B
-04C5-04C6
-04C9-04CA
-04CD-04CF
-04F6-04F7
-04FA-0530
-0557-0558
-0560
-0588
-058B-0590
-05A2
-05BA
-05C5-05CF
-05EB-05EF
-05F5-060B
-060D-061A
-061C-061E
-0620
-063B-063F
-0656-065F
-066E-066F
-06EE-06EF
-06FF
-070E
-072D-072F
-074B-077F
-07B1-0900
-0904
-093A-093B
-094E-094F
-0955-0957
-0971-0980
-0984
-098D-098E
-0991-0992
-09A9
-09B1
-09B3-09B5
-09BA-09BB
-09BD
-09C5-09C6
-09C9-09CA
-09CE-09D6
-09D8-09DB
-09DE
-09E4-09E5
-09FB-0A01
-0A03-0A04
-0A0B-0A0E
-0A11-0A12
-0A29
-0A31
-0A34
-0A37
-0A3A-0A3B
-0A3D
-0A43-0A46
-0A49-0A4A
-0A4E-0A58
-0A5D
-0A5F-0A65
-0A75-0A80
-0A84
-0A8C
-0A8E
-0A92
-0AA9
-0AB1
-0AB4
-0ABA-0ABB
-0AC6
-0ACA
-0ACE-0ACF
-0AD1-0ADF
-0AE1-0AE5
-0AF0-0B00
-0B04
-0B0D-0B0E
-0B11-0B12
-0B29
-0B31
-0B34-0B35
-0B3A-0B3B
-0B44-0B46
-0B49-0B4A
-0B4E-0B55
-0B58-0B5B
-0B5E
-0B62-0B65
-0B71-0B81
-0B84
-0B8B-0B8D
-0B91
-0B96-0B98
-0B9B
-0B9D
-0BA0-0BA2
-0BA5-0BA7
-0BAB-0BAD
-0BB6
-0BBA-0BBD
-0BC3-0BC5
-0BC9
-0BCE-0BD6
-0BD8-0BE6
-0BF3-0C00
-0C04
-0C0D
-0C11
-0C29
-0C34
-0C3A-0C3D
-0C45
-0C49
-0C4E-0C54
-0C57-0C5F
-0C62-0C65
-0C70-0C81
-0C84
-0C8D
-0C91
-0CA9
-0CB4
-0CBA-0CBD
-0CC5
-0CC9
-0CCE-0CD4
-0CD7-0CDD
-0CDF
-0CE2-0CE5
-0CF0-0D01
-0D04
-0D0D
-0D11
-0D29
-0D3A-0D3D
-0D44-0D45
-0D49
-0D4E-0D56
-0D58-0D5F
-0D62-0D65
-0D70-0D81
-0D84
-0D97-0D99
-0DB2
-0DBC
-0DBE-0DBF
-0DC7-0DC9
-0DCB-0DCE
-0DD5
-0DD7
-0DE0-0DF1
-0DF5-0E00
-0E3B-0E3E
-0E5C-0E80
-0E83
-0E85-0E86
-0E89
-0E8B-0E8C
-0E8E-0E93
-0E98
-0EA0
-0EA4
-0EA6
-0EA8-0EA9
-0EAC
-0EBA
-0EBE-0EBF
-0EC5
-0EC7
-0ECE-0ECF
-0EDA-0EDB
-0EDE-0EFF
-0F48
-0F6B-0F70
-0F8C-0F8F
-0F98
-0FBD
-0FCD-0FCE
-0FD0-0FFF
-1022
-1028
-102B
-1033-1035
-103A-103F
-105A-109F
-10C6-10CF
-10F7-10FA
-10FC-10FF
-115A-115E
-11A3-11A7
-11FA-11FF
-1207
-1247
-1249
-124E-124F
-1257
-1259
-125E-125F
-1287
-1289
-128E-128F
-12AF
-12B1
-12B6-12B7
-12BF
-12C1
-12C6-12C7
-12CF
-12D7
-12EF
-130F
-1311
-1316-1317
-131F
-1347
-135B-1360
-137D-139F
-13F5-1400
-1677-167F
-169D-169F
-16F1-177F
-17DD-17DF
-17EA-17FF
-180F
-181A-181F
-1878-187F
-18AA-1DFF
-1E9C-1E9F
-1EFA-1EFF
-1F16-1F17
-1F1E-1F1F
-1F46-1F47
-1F4E-1F4F
-1F58
-1F5A
-1F5C
-1F5E
-1F7E-1F7F
-1FB5
-1FC5
-1FD4-1FD5
-1FDC
-1FF0-1FF1
-1FF5
-1FFF
-2047
-204E-2069
-2071-2073
-208F-209F
-20B0-20CF
-20E4-20FF
-213B-2152
-2184-218F
-21F4-21FF
-22F2-22FF
-237C
-239B-23FF
-2427-243F
-244B-245F
-24EB-24FF
-2596-259F
-25F8-25FF
-2614-2618
-2672-2700
-2705
-270A-270B
-2728
-274C
-274E
-2753-2755
-2757
-275F-2760
-2768-2775
-2795-2797
-27B0
-27BF-27FF
-2900-2E7F
-2E9A
-2EF4-2EFF
-2FD6-2FEF
-2FFC-2FFF
-303B-303D
-3040
-3095-3098
-309F-30A0
-30FF-3104
-312D-3130
-318F
-31B8-31FF
-321D-321F
-3244-325F
-327C-327E
-32B1-32BF
-32CC-32CF
-32FF
-3377-337A
-33DE-33DF
-33FF
-4DB6-4DFF
-9FA6-9FFF
-A48D-A48F
-A4A2-A4A3
-A4B4
-A4C1
-A4C5
-A4C7-ABFF
-D7A4-D7FF
-FA2E-FAFF
-FB07-FB12
-FB18-FB1C
-FB37
-FB3D
-FB3F
-FB42
-FB45
-FBB2-FBD2
-FD40-FD4F
-FD90-FD91
-FDC8-FDCF
-FDFC-FE1F
-FE24-FE2F
-FE45-FE48
-FE53
-FE67
-FE6C-FE6F
-FE73
-FE75
-FEFD-FEFE
-FF00
-FF5F-FF60
-FFBF-FFC1
-FFC8-FFC9
-FFD0-FFD1
-FFD8-FFD9
-FFDD-FFDF
-FFE7
-FFEF-FFF8
-10000-102FF
-1031F
-10324-1032F
-1034B-103FF
-10426-10427
-1044E-1CFFF
-1D0F6-1D0FF
-1D127-1D129
-1D1DE-1D3FF
-1D455
-1D49D
-1D4A0-1D4A1
-1D4A3-1D4A4
-1D4A7-1D4A8
-1D4AD
-1D4BA
-1D4BC
-1D4C1
-1D4C4
-1D506
-1D50B-1D50C
-1D515
-1D51D
-1D53A
-1D53F
-1D545
-1D547-1D549
-1D551
-1D6A4-1D6A7
-1D7CA-1D7CD
-1D800-1FFFD
-2A6D7-2F7FF
-2FA1E-2FFFD
-30000-3FFFD
-40000-4FFFD
-50000-5FFFD
-60000-6FFFD
-70000-7FFFD
-80000-8FFFD
-90000-9FFFD
-A0000-AFFFD
-B0000-BFFFD
-C0000-CFFFD
-D0000-DFFFD
-E0000
-E0002-E001F
-E0080-EFFFD
------ End Unassigned Table -----
+++ /dev/null
-INTERNET-DRAFT Adam M. Costello
-draft-ietf-idn-punycode-03.txt 2002-Oct-08
-Expires 2003-Apr-08
-
- Punycode: A Bootstring encoding of Unicode for IDNA
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note
- that other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet-Drafts as
- reference material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Distribution of this document is unlimited.
-
-Abstract
-
- Punycode is a simple and efficient transfer encoding syntax designed
- for use with Internationalized Domain Names in Applications [IDNA].
- It uniquely and reversibly transforms a Unicode string [UNICODE]
- into an ASCII string [ASCII]. ASCII characters in the Unicode
- string are represented literally, and non-ASCII characters are
- represented by ASCII characters that are allowed in host name labels
- (letters, digits, and hyphens). This document defines a general
- algorithm called Bootstring that allows a string of basic code
- points to uniquely represent any string of code points drawn from
- a larger set. Punycode is an instance of Bootstring that uses
- particular parameter values specified by this document, appropriate
- for IDNA.
-\f
-Contents
-
- 1. Introduction
- 1.1 Features
- 1.2 Interaction of protocol parts
- 2. Terminology
- 3. Bootstring description
- 3.1 Basic code point segregation
- 3.2 Insertion unsort coding
- 3.3 Generalized variable-length integers
- 3.4 Bias adaptation
- 4. Bootstring parameters
- 5. Parameter values for Punycode
- 6. Bootstring algorithms
- 6.1 Bias adaptation function
- 6.2 Decoding procedure
- 6.3 Encoding procedure
- 6.4 Overflow handling
- 7. Punycode examples
- 7.1 Sample strings
- 7.2 Decoding traces
- 7.3 Encoding traces
- 8. Security considerations
- 9. References (non-normative)
- A. Author contact information
- B. Mixed-case annotation
- C. Disclaimer and license
- D. Punycode sample implementation
-
-1. Introduction
-
- [IDNA] describes an architecture for supporting internationalized
- domain names. Labels containing non-ASCII characters can be
- represented by ACE labels, which begin with a special ACE prefix and
- contain only ASCII characters. The remainder of the label after the
- prefix is a Punycode encoding of a Unicode string satisfying certain
- constraints. For the details of the prefix and constraints, see
- [IDNA] and [NAMEPREP].
-
- Punycode is an instance of a more general algorithm called
- Bootstring, which allows strings composed from a small set of
- "basic" code points to uniquely represent any string of code points
- drawn from a larger set. Punycode is Bootstring with particular
- parameter values appropriate for IDNA.
-
-1.1 Features
-
- Bootstring has been designed to have the following features:
-
- * Completeness: Every extended string (sequence of arbitrary code
- points) can be represented by a basic string (sequence of basic
- code points). Restrictions on what strings are allowed, and on
- length, can be imposed by higher layers.
-
- * Uniqueness: There is at most one basic string that represents a
- given extended string.
-\f
- * Reversibility: Any extended string mapped to a basic string can
- be recovered from that basic string.
-
- * Efficient encoding: The ratio of basic string length to
- extended string length is small. This is important in the
- context of domain names because RFC 1034 [RFC1034] restricts the
- length of a domain label to 63 characters.
-
- * Simplicity: The encoding and decoding algorithms are reasonably
- simple to implement. The goals of efficiency and simplicity are
- at odds; Bootstring aims at a good balance between them.
-
- * Readability: Basic code points appearing in the extended string
- are represented as themselves in the basic string (although the
- main purpose is to improve efficiency, not readability).
-
- Punycode can also support an additional feature that is not used
- by the ToASCII and ToUnicode operations of [IDNA]. When extended
- strings are case-folded prior to encoding, the basic string can
- use mixed case to tell how to convert the folded string into a
- mixed-case string. See appendix B "Mixed-case annotation".
-
-1.2 Interaction of protocol parts
-
- Punycode is used by the IDNA protocol [IDNA] for converting domain
- labels into ASCII; it is not designed for any other purpose. It is
- explicitly not designed for processing arbitrary free text.
-
-2. Terminology
-
- 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 RFC 2119 [RFC2119].
-
- A code point is an integral value associated with a character in a
- coded character set.
-
- As in the Unicode Standard [UNICODE], Unicode code points are
- denoted by "U+" followed by four to six hexadecimal digits, while a
- range of code points is denoted by two hexadecimal numbers separated
- by "..", with no prefixes.
-
- The operators div and mod perform integer division; (x div y) is the
- quotient of x divided by y, discarding the remainder, and (x mod y)
- is the remainder, so (x div y) * y + (x mod y) == x. Bootstring
- uses these operators only with nonnegative operands, so the quotient
- and remainder are always nonnegative.
-
- The break statement jumps out of the innermost loop (as in C).
-
- An overflow is an attempt to compute a value that exceeds the
- maximum value of an integer variable.
-\f
-3. Bootstring description
-
- Bootstring represents an arbitrary sequence of code points (the
- "extended string") as a sequence of basic code points (the "basic
- string"). This section describes the representation. Section 6
- "Bootstring algorithms" presents the algorithms as pseudocode.
- Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
- algorithms for sample inputs.
-
- The following sections describe the four techniques used in
- Bootstring. "Basic code point segregation" is a very simple
- and efficient encoding for basic code points occurring in the
- extended string: they are simply copied all at once. "Insertion
- unsort coding" encodes the non-basic code points as deltas, and
- processes the code points in numerical order rather than in order of
- appearance, which typically results in smaller deltas. The deltas
- are represented as "generalized variable-length integers", which use
- basic code points to represent nonnegative integers. The parameters
- of this integer representation are dynamically adjusted using "bias
- adaptation", to improve efficiency when consecutive deltas have
- similar magnitudes.
-
-3.1 Basic code point segregation
-
- All basic code points appearing in the extended string are
- represented literally at the beginning of the basic string, in their
- original order, followed by a delimiter if (and only if) the number
- of basic code points is nonzero. The delimiter is a particular
- basic code point, which never appears in the remainder of the basic
- string. The decoder can therefore find the end of the literal
- portion (if there is one) by scanning for the last delimiter.
-
-3.2 Insertion unsort coding
-
- The remainder of the basic string (after the last delimiter if there
- is one) represents a sequence of nonnegative integral deltas as
- generalized variable-length integers, described in section 3.3. The
- meaning of the deltas is best understood in terms of the decoder.
-
- The decoder builds the extended string incrementally. Initially,
- the extended string is a copy of the literal portion of the basic
- string (excluding the last delimiter). The decoder inserts
- non-basic code points, one for each delta, into the extended string,
- ultimately arriving at the final decoded string.
-
- At the heart of this process is a state machine with two state
- variables: an index i and a counter n. The index i refers to
- a position in the extended string; it ranges from 0 (the first
- position) to the current length of the extended string (which refers
- to a potential position beyond the current end). If the current
- state is <n,i>, the next state is <n,i+1> if i is less than the
- length of the extended string, or <n+1,0> if i equals the length of
- the extended string. In other words, each state change causes i to
- increment, wrapping around to zero if necessary, and n counts the
- number of wrap-arounds.
-\f
- Notice that the state always advances monotonically (there is no
- way for the decoder to return to an earlier state). At each state,
- an insertion is either performed or not performed. At most one
- insertion is performed in a given state. An insertion inserts the
- value of n at position i in the extended string. The deltas are
- a run-length encoding of this sequence of events: they are the
- lengths of the runs of non-insertion states preceeding the insertion
- states. Hence, for each delta, the decoder performs delta state
- changes, then an insertion, and then one more state change. (An
- implementation need not perform each state change individually, but
- can instead use division and remainder calculations to compute the
- next insertion state directly.) It is an error if the inserted code
- point is a basic code point (because basic code points were supposed
- to be segregated as described in section 3.1).
-
- The encoder's main task is to derive the sequence of deltas that
- will cause the decoder to construct the desired string. It can do
- this by repeatedly scanning the extended string for the next code
- point that the decoder would need to insert, and counting the number
- of state changes the decoder would need to perform, mindful of the
- fact that the decoder's extended string will include only those
- code points that have already been inserted. Section 6.3 "Encoding
- procedure" gives a precise algorithm.
-
-3.3 Generalized variable-length integers
-
- In a conventional integer representation the base is the number of
- distinct symbols for digits, whose values are 0 through base-1. Let
- digit_0 denote the least significant digit, digit_1 the next least
- significant, and so on. The value represented is the sum over j of
- digit_j * w(j), where w(j) = base^j is the weight (scale factor)
- for position j. For example, in the base 8 integer 437, the digits
- are 7, 3, and 4, and the weights are 1, 8, and 64, so the value is
- 7 + 3*8 + 4*64 = 287. This representation has two disadvantages:
- First, there are multiple encodings of each value (because there
- can be extra zeros in the most significant positions), which is
- inconvenient when unique encodings are needed. Second, the integer
- is not self-delimiting, so if multiple integers are concatenated the
- boundaries between them are lost.
-
- The generalized variable-length representation solves these two
- problems. The digit values are still 0 through base-1, but now
- the integer is self-delimiting by means of thresholds t(j), each
- of which is in the range 0 through base-1. Exactly one digit, the
- most significant, satisfies digit_j < t(j). Therefore, if several
- integers are concatenated, it is easy to separate them, starting
- with the first if they are little-endian (least significant digit
- first), or starting with the last if they are big-endian (most
- significant digit first). As before, the value is the sum over j of
- digit_j * w(j), but the weights are different:
-
- w(0) = 1
- w(j) = w(j-1) * (base - t(j-1)) for j > 0
-\f
- For example, consider the little-endian sequence of base 8 digits
- 734251... Suppose the thresholds are 2, 3, 5, 5, 5, 5... This
- implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5)
- = 90, 90*(8-5) = 270, and so on. 7 is not less than 2, and 3 is
- not less than 3, but 4 is less than 5, so 4 is the last digit. The
- value of 734 is 7*1 + 3*6 + 4*30 = 145. The next integer is 251,
- with value 2*1 + 5*6 + 1*30 = 62. Decoding this representation
- is very similar to decoding a conventional integer: Start with a
- current value of N = 0 and a weight w = 1. Fetch the next digit d
- and increase N by d * w. If d is less than the current threshold
- (t) then stop, otherwise increase w by a factor of (base - t),
- update t for the next position, and repeat.
-
- Encoding this representation is similar to encoding a conventional
- integer: If N < t then output one digit for N and stop, otherwise
- output the digit for t + ((N - t) mod (base - t)), then replace N
- with (N - t) div (base - t), update t for the next position, and
- repeat.
-
- For any particular set of values of t(j), there is exactly one
- generalized variable-length representation of each nonnegative
- integral value.
-
- Bootstring uses little-endian ordering so that the deltas can be
- separated starting with the first. The t(j) values are defined in
- terms of the constants base, tmin, and tmax, and a state variable
- called bias:
-
- t(j) = base * (j + 1) - bias,
- clamped to the range tmin through tmax
-
- The clamping means that if the formula yields a value less than tmin
- or greater than tmax, then t(j) = tmin or tmax, respectively. (In
- the pseudocode in section 6 "Bootstring algorithms", the expression
- base * (j + 1) is denoted by k for performance reasons.) These
- t(j) values cause the representation to favor integers within a
- particular range determined by the bias.
-
-3.4 Bias adaptation
-
- After each delta is encoded or decoded, bias is set for the next
- delta as follows:
-
- 1. Delta is scaled in order to avoid overflow in the next step:
-
- let delta = delta div 2
-
- But when this is the very first delta, the divisor is not 2, but
- instead a constant called damp. This compensates for the fact
- that the second delta is usually much smaller than the first.
-
- 2. Delta is increased to compensate for the fact that the next
- delta will be inserting into a longer string:
-\f
- let delta = delta + (delta div numpoints)
-
- numpoints is the total number of code points encoded/decoded so
- far (including the one corresponding to this delta itself, and
- including the basic code points).
-
- 3. Delta is repeatedly divided until it falls within a threshold,
- to predict the minimum number of digits needed to represent the
- next delta:
-
- while delta > ((base - tmin) * tmax) div 2
- do let delta = delta div (base - tmin)
-
- 4. The bias is set:
-
- let bias =
- (base * the number of divisions performed in step 3) +
- (((base - tmin + 1) * delta) div (delta + skew))
-
- The motivation for this procedure is that the current delta provides
- a hint about the likely size of the next delta, and so t(j) is
- set to tmax for the more significant digits starting with the one
- expected to be last, tmin for the less significant digits up through
- the one expected to be third-last, and somewhere between tmin and
- tmax for the digit expected to be second-last (balancing the hope of
- the expected-last digit being unnecessary against the danger of it
- being insufficient).
-
-4. Bootstring parameters
-
- Given a set of basic code points, one needs to be designated as
- the delimiter. The base cannot be greater than the number of
- distinguishable basic code points remaining. The digit-values in
- the range 0 through base-1 need to be associated with distinct
- non-delimiter basic code points. In some cases multiple code points
- need to have the same digit-value; for example, uppercase and
- lowercase versions of the same letter need to be equivalent if basic
- strings are case-insensitive.
-
- The initial value of n cannot be greater than the minimum non-basic
- code point that could appear in extended strings.
-
- The remaining five parameters (tmin, tmax, skew, damp, and the
- initial value of bias) need to satisfy the following constraints:
-
- 0 <= tmin <= tmax <= base-1
- skew >= 1
- damp >= 2
- initial_bias mod base <= base - tmin
-
- Provided the constraints are satisfied, these five parameters affect
- efficiency but not correctness. They are best chosen empirically.
-
- If support for mixed-case annotation is desired (see appendix B),
- make sure that the code points corresponding to 0 through tmax-1 all
- have both uppercase and lowercase forms.
-\f
-5. Parameter values for Punycode
-
- Punycode uses the following Bootstring parameter values:
-
- base = 36
- tmin = 1
- tmax = 26
- skew = 38
- damp = 700
- initial_bias = 72
- initial_n = 128 = 0x80
-
- Although the only restriction Punycode imposes on the input integers
- is that they be nonnegative, these parameters are especially
- designed to work well with Unicode [UNICODE] code points, which
- are integers in the range 0..10FFFF (but not D800..DFFF, which are
- reserved for use by the UTF-16 encoding of Unicode). The basic code
- points are the ASCII [ASCII] code points (0..7F), of which U+002D
- (-) is the delimiter, and some of the others have digit-values as
- follows:
-
- code points digit-values
- ------------ ----------------------
- 41..5A (A-Z) = 0 to 25, respectively
- 61..7A (a-z) = 0 to 25, respectively
- 30..39 (0-9) = 26 to 35, respectively
-
- Using hyphen-minus as the delimiter implies that the encoded string
- can end with a hyphen-minus only if the Unicode string consists
- entirely of basic code points, but IDNA forbids such strings from
- being encoded. The encoded string can begin with a hyphen-minus,
- but IDNA prepends a prefix. Therefore IDNA using Punycode conforms
- to the RFC 952 rule that host name labels neither begin nor end with
- a hyphen-minus [RFC952].
-
- A decoder MUST recognize the letters in both uppercase and lowercase
- forms (including mixtures of both forms). An encoder SHOULD output
- only uppercase forms or only lowercase forms, unless it uses
- mixed-case annotation (see appendix B).
-
- Presumably most users will not manually write or type encoded
- strings (as opposed to cutting and pasting them), but those who do
- will need to be alert to the potential visual ambiguity between the
- following sets of characters:
-
- G 6
- I l 1
- O 0
- S 5
- U V
- Z 2
-
- Such ambiguities are usually resolved by context, but in a Punycode
- encoded string there is no context apparent to humans.
-\f
-6. Bootstring algorithms
-
- Some parts of the pseudocode can be omitted if the parameters
- satisfy certain conditions (for which Punycode qualifies). These
- parts are enclosed in {braces}, and notes immediately following the
- pseudocode explain the conditions under which they can be omitted.
-
- Formally, code points are integers, and hence the pseudocode assumes
- that arithmetic operations can be performed directly on code points.
- In some programming languages, explicit conversion between code
- points and integers might be necessary.
-
-6.1 Bias adaptation function
-
- function adapt(delta,numpoints,firsttime):
- if firsttime then let delta = delta div damp
- else let delta = delta div 2
- let delta = delta + (delta div numpoints)
- let k = 0
- while delta > ((base - tmin) * tmax) div 2 do begin
- let delta = delta div (base - tmin)
- let k = k + base
- end
- return k + (((base - tmin + 1) * delta) div (delta + skew))
-
- It does not matter whether the modifications to delta and k
- inside adapt() affect variables of the same name inside the
- encoding/decoding procedures, because after calling adapt() the
- caller does not read those variables before overwriting them.
-\f
-6.2 Decoding procedure
-
- let n = initial_n
- let i = 0
- let bias = initial_bias
- let output = an empty string indexed from 0
- consume all code points before the last delimiter (if there is one)
- and copy them to output, fail on any non-basic code point
- if more than zero code points were consumed then consume one more
- (which will be the last delimiter)
- while the input is not exhausted do begin
- let oldi = i
- let w = 1
- for k = base to infinity in steps of base do begin
- consume a code point, or fail if there was none to consume
- let digit = the code point's digit-value, fail if it has none
- let i = i + digit * w, fail on overflow
- let t = tmin if k <= bias {+ tmin}, or
- tmax if k >= bias + tmax, or k - bias otherwise
- if digit < t then break
- let w = w * (base - t), fail on overflow
- end
- let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
- let n = n + i div (length(output) + 1), fail on overflow
- let i = i mod (length(output) + 1)
- {if n is a basic code point then fail}
- insert n into output at position i
- increment i
- end
-
- The full statement enclosed in braces (checking whether n is a basic
- code point) can be omitted if initial_n exceeds all basic code
- points (which is true for Punycode), because n is never less than
- initial_n.
-
- In the assignment of t, where t is clamped to the range tmin through
- tmax, "+ tmin" can always be omitted. This makes the clamping
- calculation incorrect when bias < k < bias + tmin, but that cannot
- happen because of the way bias is computed and because of the
- constraints on the parameters.
-
- Because the decoder state can only advance monotonically, and there
- is only one representation of any delta, there is therefore only
- one encoded string that can represent a given sequence of integers.
- The only error conditions are invalid code points, unexpected
- end-of-input, overflow, and basic code points encoded using deltas
- instead of appearing literally. If the decoder fails on these
- errors as shown above, then it cannot produce the same output for
- two distinct inputs. Without this property it would have been
- necessary to re-encode the output and verify that it matches the
- input in order to guarantee the uniqueness of the encoding.
-\f
-6.3 Encoding procedure
-
- let n = initial_n
- let delta = 0
- let bias = initial_bias
- let h = b = the number of basic code points in the input
- copy them to the output in order, followed by a delimiter if b > 0
- {if the input contains a non-basic code point < n then fail}
- while h < length(input) do begin
- let m = the minimum {non-basic} code point >= n in the input
- let delta = delta + (m - n) * (h + 1), fail on overflow
- let n = m
- for each code point c in the input (in order) do begin
- if c < n {or c is basic} then increment delta, fail on overflow
- if c == n then begin
- let q = delta
- for k = base to infinity in steps of base do begin
- let t = tmin if k <= bias {+ tmin}, or
- tmax if k >= bias + tmax, or k - bias otherwise
- if q < t then break
- output the code point for digit t + ((q - t) mod (base - t))
- let q = (q - t) div (base - t)
- end
- output the code point for digit q
- let bias = adapt(delta, h + 1, test h equals b?)
- let delta = 0
- increment h
- end
- end
- increment delta and n
- end
-
- The full statement enclosed in braces (checking whether the input
- contains a non-basic code point less than n) can be omitted if all
- code points less than initial_n are basic code points (which is true
- for Punycode if code points are unsigned).
-
- The brace-enclosed conditions "non-basic" and "or c is basic" can be
- omitted if initial_n exceeds all basic code points (which is true
- for Punycode), because the code point being tested is never less
- than initial_n.
-
- In the assignment of t, where t is clamped to the range tmin through
- tmax, "+ tmin" can always be omitted. This makes the clamping
- calculation incorrect when bias < k < bias + tmin, but that cannot
- happen because of the way bias is computed and because of the
- constraints on the parameters.
-
- The checks for overflow are necessary to avoid producing invalid
- output when the input contains very large values or is very long.
-
- The increment of delta at the bottom of the outer loop cannot
- overflow because delta < length(input) before the increment, and
- length(input) is already assumed to be representable. The increment
- of n could overflow, but only if h == length(input), in which case
- the procedure is finished anyway.
-\f
-6.4 Overflow handling
-
- For IDNA, 26-bit unsigned integers are sufficient to handle all
- valid IDNA labels without overflow, because any string that
- needed a 27-bit delta would have to exceed either the code point
- limit (0..10FFFF) or the label length limit (63 characters).
- However, overflow handling is necessary because the inputs are not
- necessarily valid IDNA labels.
-
- If the programming language does not provide overflow detection,
- the following technique can be used. Suppose A, B, and C are
- representable nonnegative integers and C is nonzero. Then A + B
- overflows if and only if B > maxint - A, and A + (B * C) overflows
- if and only if B > (maxint - A) div C, where maxint is the greatest
- integer for which maxint + 1 cannot be represented. Refer to
- appendix D "Punycode sample implementation" for demonstrations of
- this technique in the C language.
-
- The decoding and encoding algorithms shown in sections 6.2 and
- 6.3 handle overflow by detecting it whenever it happens. Another
- approach is to enforce limits on the inputs that prevent overflow
- from happening. For example, if the encoder were to verify that
- no input code points exceed M and that the input length does not
- exceed L, then no delta could ever exceed (M - initial_n) * (L + 1),
- and hence no overflow could occur if integer variables were capable
- of representing values that large. This prevention approach would
- impose more restrictions on the input than the detection approach
- does, but might be considered simpler in some programming languages.
-
- In theory, the decoder could use an analogous approach, limiting the
- number of digits in a variable-length integer (that is, limiting the
- number of iterations in the innermost loop). However, the number
- of digits that suffice to represent a given delta can sometimes
- represent much larger deltas (because of the adaptation), and hence
- this approach would probably need integers wider than 32 bits.
-
- Yet another approach for the decoder is to allow overflow to occur,
- but to check the final output string by re-encoding it and comparing
- to the decoder input. If and only if they do not match (using a
- case-insensitive ASCII comparison) overflow has occurred. This
- delayed-detection approach would not impose any more restrictions on
- the input than the immediate-detection approach does, and might be
- considered simpler in some programming languages.
-
- In fact, if the decoder is used only inside the IDNA ToUnicode
- operation [IDNA], then it need not check for overflow at all,
- because ToUnicode performs a higher level re-encoding and
- comparison, and a mismatch has the same consequence as if the
- Punycode decoder had failed.
-
-7. Punycode examples
-
-7.1 Sample strings
-
- In the Punycode encodings below, the ACE prefix is not shown.
- Backslashes show where line breaks have been inserted in strings too
- long for one line.
-\f
- The first several examples are all translations of the sentence "Why
- can't they just speak in <language>?" (courtesy of Michael Kaplan's
- "provincial" page [PROVINCIAL]). Word breaks and punctuation have
- been removed, as is often done in domain names.
-
- (A) Arabic (Egyptian):
- u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
- u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
- Punycode: egbpdaj6bu4bxfgehfvwxn
-
- (B) Chinese (simplified):
- u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
- Punycode: ihqwcrb4cv8a8dqg056pqjye
-
- (C) Chinese (traditional):
- u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
- Punycode: ihqwctvzc91f659drss3x8bo0yb
-
- (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
- U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
- u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
- u+0065 u+0073 u+006B u+0079
- Punycode: Proprostnemluvesky-uyb24dma41a
-
- (E) Hebrew:
- u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
- u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
- u+05D1 u+05E8 u+05D9 u+05EA
- Punycode: 4dbcagdahymbxekheh6e0a7fei0b
-
- (F) Hindi (Devanagari):
- u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
- u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
- u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
- u+0939 u+0948 u+0902
- Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
-
- (G) Japanese (kanji and hiragana):
- u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
- u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
- Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
-
- (H) Korean (Hangul syllables):
- u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
- u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
- u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
- Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
- psd879ccm6fea98c
-
- (I) Russian (Cyrillic):
- U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
- u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
- u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
- u+0438
- Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
-\f
- (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
- U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
- u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
- u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
- u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
- u+0061 u+00F1 u+006F u+006C
- Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
-
- (K) Vietnamese:
- T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
- <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
- U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
- u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
- u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
- U+0056 u+0069 u+1EC7 u+0074
- Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
-
- The next several examples are all names of Japanese music artists,
- song titles, and TV programs, just because the author happens to
- have them handy (but Japanese is useful for providing examples
- of single-row text, two-row text, ideographic text, and various
- mixtures thereof).
-
- (L) 3<nen>B<gumi><kinpachi><sensei>
- u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
- Punycode: 3B-ww4c5e180e575a65lsy2b
-
- (M) <amuro><namie>-with-SUPER-MONKEYS
- u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
- u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
- U+004F U+004E U+004B U+0045 U+0059 U+0053
- Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
-
- (N) Hello-Another-Way-<sorezore><no><basho>
- U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
- u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
- u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
- Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
-
- (O) <hitotsu><yane><no><shita>2
- u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
- Punycode: 2-u9tlzr9756bt3uc0v
-
- (P) Maji<de>Koi<suru>5<byou><mae>
- U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
- u+308B u+0035 u+79D2 u+524D
- Punycode: MajiKoi5-783gue6qz075azm5e
-
- (Q) <pafii>de<runba>
- u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
- Punycode: de-jg4avhby1noc0d
-
- (R) <sono><supiido><de>
- u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
- Punycode: d9juau41awczczp
-\f
- The last example is an ASCII string that breaks the existing rules
- for host name labels. (It is not a realistic example for IDNA,
- because IDNA never encodes pure ASCII labels.)
-
- (S) -> $1.00 <-
- u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
- u+003C u+002D
- Punycode: -> $1.00 <--
-
-7.2 Decoding traces
-
- In the following traces, the evolving state of the decoder is
- shown as a sequence of hexadecimal values, representing the code
- points in the extended string. An asterisk appears just after the
- most recently inserted code point, indicating both n (the value
- preceeding the asterisk) and i (the position of the value just after
- the asterisk). Other numerical values are decimal.
-
- Decoding trace of example B from section 7.1:
-
- n is 128, i is 0, bias is 72
- input is "ihqwcrb4cv8a8dqg056pqjye"
- there is no delimiter, so extended string starts empty
- delta "ihq" decodes to 19853
- bias becomes 21
- 4E0D *
- delta "wc" decodes to 64
- bias becomes 20
- 4E0D 4E2D *
- delta "rb" decodes to 37
- bias becomes 13
- 4E3A * 4E0D 4E2D
- delta "4c" decodes to 56
- bias becomes 17
- 4E3A 4E48 * 4E0D 4E2D
- delta "v8a" decodes to 599
- bias becomes 32
- 4E3A 4EC0 * 4E48 4E0D 4E2D
- delta "8d" decodes to 130
- bias becomes 23
- 4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
- delta "qg" decodes to 154
- bias becomes 25
- 4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
- delta "056p" decodes to 46301
- bias becomes 84
- 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
- delta "qjye" decodes to 88531
- bias becomes 90
- 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
-\f
- Decoding trace of example L from section 7.1:
-
- n is 128, i is 0, bias is 72
- input is "3B-ww4c5e180e575a65lsy2b"
- literal portion is "3B-", so extended string starts as:
- 0033 0042
- delta "ww4c" decodes to 62042
- bias becomes 27
- 0033 0042 5148 *
- delta "5e" decodes to 139
- bias becomes 24
- 0033 0042 516B * 5148
- delta "180e" decodes to 16683
- bias becomes 67
- 0033 5E74 * 0042 516B 5148
- delta "575a" decodes to 34821
- bias becomes 82
- 0033 5E74 0042 516B 5148 751F *
- delta "65l" decodes to 14592
- bias becomes 67
- 0033 5E74 0042 7D44 * 516B 5148 751F
- delta "sy2b" decodes to 42088
- bias becomes 84
- 0033 5E74 0042 7D44 91D1 * 516B 5148 751F
-
-7.3 Encoding traces
-
- In the following traces, code point values are hexadecimal, while
- other numerical values are decimal.
-\f
- Encoding trace of example B from section 7.1:
-
- bias is 72
- input is:
- 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
- there are no basic code points, so no literal portion
- next code point to insert is 4E0D
- needed delta is 19853, encodes as "ihq"
- bias becomes 21
- next code point to insert is 4E2D
- needed delta is 64, encodes as "wc"
- bias becomes 20
- next code point to insert is 4E3A
- needed delta is 37, encodes as "rb"
- bias becomes 13
- next code point to insert is 4E48
- needed delta is 56, encodes as "4c"
- bias becomes 17
- next code point to insert is 4EC0
- needed delta is 599, encodes as "v8a"
- bias becomes 32
- next code point to insert is 4ED6
- needed delta is 130, encodes as "8d"
- bias becomes 23
- next code point to insert is 4EEC
- needed delta is 154, encodes as "qg"
- bias becomes 25
- next code point to insert is 6587
- needed delta is 46301, encodes as "056p"
- bias becomes 84
- next code point to insert is 8BF4
- needed delta is 88531, encodes as "qjye"
- bias becomes 90
- output is "ihqwcrb4cv8a8dqg056pqjye"
-\f
- Encoding trace of example L from section 7.1:
-
- bias is 72
- input is:
- 0033 5E74 0042 7D44 91D1 516B 5148 751F
- basic code points (0033, 0042) are copied to literal portion: "3B-"
- next code point to insert is 5148
- needed delta is 62042, encodes as "ww4c"
- bias becomes 27
- next code point to insert is 516B
- needed delta is 139, encodes as "5e"
- bias becomes 24
- next code point to insert is 5E74
- needed delta is 16683, encodes as "180e"
- bias becomes 67
- next code point to insert is 751F
- needed delta is 34821, encodes as "575a"
- bias becomes 82
- next code point to insert is 7D44
- needed delta is 14592, encodes as "65l"
- bias becomes 67
- next code point to insert is 91D1
- needed delta is 42088, encodes as "sy2b"
- bias becomes 84
- output is "3B-ww4c5e180e575a65lsy2b"
-
-8. Security considerations
-
- Users expect each domain name in DNS to be controlled by a single
- authority. If a Unicode string intended for use as a domain label
- could map to multiple ACE labels, then an internationalized domain
- name could map to multiple ASCII domain names, each controlled by
- a different authority, some of which could be spoofs that hijack
- service requests intended for another. Therefore Punycode is
- designed so that each Unicode string has a unique encoding.
-
- However, there can still be multiple Unicode representations of the
- "same" text, for various definitions of "same". This problem is
- addressed to some extent by the Unicode standard under the topic of
- canonicalization, and this work is leveraged for domain names by
- Nameprep [NAMEPREP].
-
-9. References (non-normative)
-
- [ASCII] Vint Cerf, "ASCII format for Network Interchange",
- 1969-Oct-16, RFC 20.
-
- [IDNA] Patrik Faltstrom, Paul Hoffman, Adam M. Costello,
- "Internationalizing Domain Names In Applications (IDNA)",
- draft-ietf-idn-idna.
-
- [NAMEPREP] Paul Hoffman, Marc Blanchet, "Nameprep: A
- Stringprep Profile for Internationalized Domain Names",
- draft-ietf-idn-nameprep.
-
- [PROVINCIAL] Michael Kaplan, "The 'anyone can be provincial!' page",
- http://www.trigeminal.com/samples/provincial.html.
-\f
- [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host
- Table Specification", 1985-Oct, RFC 952.
-
- [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
- 1987-Nov, RFC 1034.
-
- [UNICODE] The Unicode Consortium, "The Unicode Standard",
- http://www.unicode.org/unicode/standard/standard.html.
-
-A. Author contact information
-
- Adam M. Costello
- University of California, Berkeley
- http://www.nicemice.net/amc/
-
-B. Mixed-case annotation
-
- In order to use Punycode to represent case-insensitive strings,
- higher layers need to case-fold the strings prior to Punycode
- encoding. The encoded string can use mixed case as an annotation
- telling how to convert the folded string into a mixed-case string
- for display purposes. Note, however, that mixed-case annotation
- is not used by the ToASCII and ToUnicode operations specified in
- [IDNA], and therefore implementors of IDNA can disregard this
- appendix.
-
- Basic code points can use mixed case directly, because the decoder
- copies them verbatim, leaving lowercase code points lowercase, and
- leaving uppercase code points uppercase. Each non-basic code point
- is represented by a delta, which is represented by a sequence of
- basic code points, the last of which provides the annotation. If it
- is uppercase, it is a suggestion to map the non-basic code point to
- uppercase (if possible); if it is lowercase, it is a suggestion to
- map the non-basic code point to lowercase (if possible).
-
- These annotations do not alter the code points returned by decoders;
- the annotations are returned separately, for the caller to use or
- ignore. Encoders can accept annotations in addition to code points,
- but the annotations do not alter the output, except to influence the
- uppercase/lowercase form of ASCII letters.
-
- Punycode encoders and decoders need not support these annotations,
- and higher layers need not use them.
-
-C. Disclaimer and license
-
- Regarding this entire document or any portion of it (including
- the pseudocode and C code), the author makes no guarantees and
- is not responsible for any damage resulting from its use. The
- author grants irrevocable permission to anyone to use, modify,
- and distribute it in any way that does not diminish the rights
- of anyone else to use, modify, and distribute it, provided that
- redistributed derivative works do not contain misleading author or
- version information. Derivative works need not be licensed under
- similar terms.
-
-
-D. Punycode sample implementation
-\f
-/*
-punycode.c from draft-ietf-idn-punycode-03
-http://www.nicemice.net/idn/
-Adam M. Costello
-http://www.nicemice.net/amc/
-
-This is ANSI C code (C89) implementing
-Punycode (draft-ietf-idn-punycode-03).
-
-*/
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum punycode_status {
- punycode_success,
- punycode_bad_input, /* Input is invalid. */
- punycode_big_output, /* Output would exceed the space provided. */
- punycode_overflow /* Input needs wider integers to process. */
-};
-
-#if UINT_MAX >= (1 << 26) - 1
-typedef unsigned int punycode_uint;
-#else
-typedef unsigned long punycode_uint;
-#endif
-
-enum punycode_status punycode_encode(
- punycode_uint input_length,
- const punycode_uint input[],
- const unsigned char case_flags[],
- punycode_uint *output_length,
- char output[] );
-\f
- /* punycode_encode() converts Unicode to Punycode. The input */
- /* is represented as an array of Unicode code points (not code */
- /* units; surrogate pairs are not allowed), and the output */
- /* will be represented as an array of ASCII code points. The */
- /* output string is *not* null-terminated; it will contain */
- /* zeros if and only if the input contains zeros. (Of course */
- /* the caller can leave room for a terminator and add one if */
- /* needed.) The input_length is the number of code points in */
- /* the input. The output_length is an in/out argument: the */
- /* caller passes in the maximum number of code points that it */
- /* can receive, and on successful return it will contain the */
- /* number of code points actually output. The case_flags array */
- /* holds input_length boolean values, where nonzero suggests that */
- /* the corresponding Unicode character be forced to uppercase */
- /* after being decoded (if possible), and zero suggests that */
- /* it be forced to lowercase (if possible). ASCII code points */
- /* are encoded literally, except that ASCII letters are forced */
- /* to uppercase or lowercase according to the corresponding */
- /* uppercase flags. If case_flags is a null pointer then ASCII */
- /* letters are left as they are, and other code points are */
- /* treated as if their uppercase flags were zero. The return */
- /* value can be any of the punycode_status values defined above */
- /* except punycode_bad_input; if not punycode_success, then */
- /* output_size and output might contain garbage. */
-
-enum punycode_status punycode_decode(
- punycode_uint input_length,
- const char input[],
- punycode_uint *output_length,
- punycode_uint output[],
- unsigned char case_flags[] );
-
- /* punycode_decode() converts Punycode to Unicode. The input is */
- /* represented as an array of ASCII code points, and the output */
- /* will be represented as an array of Unicode code points. The */
- /* input_length is the number of code points in the input. The */
- /* output_length is an in/out argument: the caller passes in */
- /* the maximum number of code points that it can receive, and */
- /* on successful return it will contain the actual number of */
- /* code points output. The case_flags array needs room for at */
- /* least output_length values, or it can be a null pointer if the */
- /* case information is not needed. A nonzero flag suggests that */
- /* the corresponding Unicode character be forced to uppercase */
- /* by the caller (if possible), while zero suggests that it be */
- /* forced to lowercase (if possible). ASCII code points are */
- /* output already in the proper case, but their flags will be set */
- /* appropriately so that applying the flags would be harmless. */
- /* The return value can be any of the punycode_status values */
- /* defined above; if not punycode_success, then output_length, */
- /* output, and case_flags might contain garbage. On success, the */
- /* decoder will never need to write an output_length greater than */
- /* input_length, because of how the encoding is defined. */
-\f
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-/*** Bootstring parameters for Punycode ***/
-
-enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
- initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
-
-/* basic(cp) tests whether cp is a basic code point: */
-#define basic(cp) ((punycode_uint)(cp) < 0x80)
-
-/* delim(cp) tests whether cp is a delimiter: */
-#define delim(cp) ((cp) == delimiter)
-
-/* decode_digit(cp) returns the numeric value of a basic code */
-/* point (for use in representing integers) in the range 0 to */
-/* base-1, or base if cp is does not represent a value. */
-
-static punycode_uint decode_digit(punycode_uint cp)
-{
- return cp - 48 < 10 ? cp - 22 : cp - 65 < 26 ? cp - 65 :
- cp - 97 < 26 ? cp - 97 : base;
-}
-
-/* encode_digit(d,flag) returns the basic code point whose value */
-/* (when used for representing integers) is d, which needs to be in */
-/* the range 0 to base-1. The lowercase form is used unless flag is */
-/* nonzero, in which case the uppercase form is used. The behavior */
-/* is undefined if flag is nonzero and digit d has no uppercase form. */
-
-static char encode_digit(punycode_uint d, int flag)
-{
- return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
- /* 0..25 map to ASCII a..z or A..Z */
- /* 26..35 map to ASCII 0..9 */
-}
-
-/* flagged(bcp) tests whether a basic code point is flagged */
-/* (uppercase). The behavior is undefined if bcp is not a */
-/* basic code point. */
-
-#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
-
-/* encode_basic(bcp,flag) forces a basic code point to lowercase */
-/* if flag is zero, uppercase if flag is nonzero, and returns */
-/* the resulting code point. The code point is unchanged if it */
-/* is caseless. The behavior is undefined if bcp is not a basic */
-/* code point. */
-
-static char encode_basic(punycode_uint bcp, int flag)
-{
- bcp -= (bcp - 97 < 26) << 5;
- return bcp + ((!flag && (bcp - 65 < 26)) << 5);
-}
-\f
-/*** Platform-specific constants ***/
-
-/* maxint is the maximum value of a punycode_uint variable: */
-static const punycode_uint maxint = -1;
-/* Because maxint is unsigned, -1 becomes the maximum value. */
-
-/*** Bias adaptation function ***/
-
-static punycode_uint adapt(
- punycode_uint delta, punycode_uint numpoints, int firsttime )
-{
- punycode_uint k;
-
- delta = firsttime ? delta / damp : delta >> 1;
- /* delta >> 1 is a faster way of doing delta / 2 */
- delta += delta / numpoints;
-
- for (k = 0; delta > ((base - tmin) * tmax) / 2; k += base) {
- delta /= base - tmin;
- }
-
- return k + (base - tmin + 1) * delta / (delta + skew);
-}
-
-/*** Main encode function ***/
-
-enum punycode_status punycode_encode(
- punycode_uint input_length,
- const punycode_uint input[],
- const unsigned char case_flags[],
- punycode_uint *output_length,
- char output[] )
-{
- punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
-
- /* Initialize the state: */
-
- n = initial_n;
- delta = out = 0;
- max_out = *output_length;
- bias = initial_bias;
-
- /* Handle the basic code points: */
-
- for (j = 0; j < input_length; ++j) {
- if (basic(input[j])) {
- if (max_out - out < 2) return punycode_big_output;
- output[out++] =
- case_flags ? encode_basic(input[j], case_flags[j]) : input[j];
- }
- /* else if (input[j] < n) return punycode_bad_input; */
- /* (not needed for Punycode with unsigned code points) */
- }
-\f
- h = b = out;
-
- /* h is the number of code points that have been handled, b is the */
- /* number of basic code points, and out is the number of characters */
- /* that have been output. */
-
- if (b > 0) output[out++] = delimiter;
-
- /* Main encoding loop: */
-
- while (h < input_length) {
- /* All non-basic code points < n have been */
- /* handled already. Find the next larger one: */
-
- for (m = maxint, j = 0; j < input_length; ++j) {
- /* if (basic(input[j])) continue; */
- /* (not needed for Punycode) */
- if (input[j] >= n && input[j] < m) m = input[j];
- }
-
- /* Increase delta enough to advance the decoder's */
- /* <n,i> state to <m,0>, but guard against overflow: */
-
- if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
- delta += (m - n) * (h + 1);
- n = m;
-
- for (j = 0; j < input_length; ++j) {
- /* Punycode does not need to check whether input[j] is basic: */
- if (input[j] < n /* || basic(input[j]) */ ) {
- if (++delta == 0) return punycode_overflow;
- }
-
- if (input[j] == n) {
- /* Represent delta as a generalized variable-length integer: */
-
- for (q = delta, k = base; ; k += base) {
- if (out >= max_out) return punycode_big_output;
- t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */
- k >= bias + tmax ? tmax : k - bias;
- if (q < t) break;
- output[out++] = encode_digit(t + (q - t) % (base - t), 0);
- q = (q - t) / (base - t);
- }
-
- output[out++] = encode_digit(q, case_flags && case_flags[j]);
- bias = adapt(delta, h + 1, h == b);
- delta = 0;
- ++h;
- }
- }
-
- ++delta, ++n;
- }
-
- *output_length = out;
- return punycode_success;
-}
-\f
-/*** Main decode function ***/
-
-enum punycode_status punycode_decode(
- punycode_uint input_length,
- const char input[],
- punycode_uint *output_length,
- punycode_uint output[],
- unsigned char case_flags[] )
-{
- punycode_uint n, out, i, max_out, bias,
- b, j, in, oldi, w, k, digit, t;
-
- /* Initialize the state: */
-
- n = initial_n;
- out = i = 0;
- max_out = *output_length;
- bias = initial_bias;
-
- /* Handle the basic code points: Let b be the number of input code */
- /* points before the last delimiter, or 0 if there is none, then */
- /* copy the first b code points to the output. */
-
- for (b = j = 0; j < input_length; ++j) if (delim(input[j])) b = j;
- if (b > max_out) return punycode_big_output;
-
- for (j = 0; j < b; ++j) {
- if (case_flags) case_flags[out] = flagged(input[j]);
- if (!basic(input[j])) return punycode_bad_input;
- output[out++] = input[j];
- }
-
- /* Main decoding loop: Start just after the last delimiter if any */
- /* basic code points were copied; start at the beginning otherwise. */
-
- for (in = b > 0 ? b + 1 : 0; in < input_length; ++out) {
-
- /* in is the index of the next character to be consumed, and */
- /* out is the number of code points in the output array. */
-
- /* Decode a generalized variable-length integer into delta, */
- /* which gets added to i. The overflow checking is easier */
- /* if we increase i as we go, then subtract off its starting */
- /* value at the end to obtain delta. */
-
- for (oldi = i, w = 1, k = base; ; k += base) {
- if (in >= input_length) return punycode_bad_input;
- digit = decode_digit(input[in++]);
- if (digit >= base) return punycode_bad_input;
- if (digit > (maxint - i) / w) return punycode_overflow;
- i += digit * w;
- t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */
- k >= bias + tmax ? tmax : k - bias;
- if (digit < t) break;
- if (w > maxint / (base - t)) return punycode_overflow;
- w *= (base - t);
- }
-\f
- bias = adapt(i - oldi, out + 1, oldi == 0);
-
- /* i was supposed to wrap around from out+1 to 0, */
- /* incrementing n each time, so we'll fix that now: */
-
- if (i / (out + 1) > maxint - n) return punycode_overflow;
- n += i / (out + 1);
- i %= (out + 1);
-
- /* Insert n at position i of the output: */
-
- /* not needed for Punycode: */
- /* if (decode_digit(n) <= base) return punycode_invalid_input; */
- if (out >= max_out) return punycode_big_output;
-
- if (case_flags) {
- memmove(case_flags + i + 1, case_flags + i, out - i);
- /* Case of last character determines uppercase flag: */
- case_flags[i] = flagged(input[in - 1]);
- }
-
- memmove(output + i + 1, output + i, (out - i) * sizeof *output);
- output[i++] = n;
- }
-
- *output_length = out;
- return punycode_success;
-}
-
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a */
-/* command-line option. */
-
-enum {
- unicode_max_length = 256,
- ace_max_length = 256
-};
-\f
-static void usage(char **argv)
-{
- fprintf(stderr,
- "\n"
- "%s -e reads code points and writes a Punycode string.\n"
- "%s -d reads a Punycode string and writes code points.\n"
- "\n"
- "Input and output are plain text in the native character set.\n"
- "Code points are in the form u+hex separated by whitespace.\n"
- "Although the specification allows Punycode strings to contain\n"
- "any characters from the ASCII repertoire, this test code\n"
- "supports only the printable characters, and needs the Punycode\n"
- "string to be followed by a newline.\n"
- "The case of the u in u+hex is the force-to-uppercase flag.\n"
- , argv[0], argv[0]);
- exit(EXIT_FAILURE);
-}
-
-
-static void fail(const char *msg)
-{
- fputs(msg,stderr);
- exit(EXIT_FAILURE);
-}
-
-static const char too_big[] =
- "input or output is too large, recompile with larger limits\n";
-static const char invalid_input[] = "invalid input\n";
-static const char overflow[] = "arithmetic overflow\n";
-static const char io_error[] = "I/O error\n";
-
-
-/* The following string is used to convert printable */
-/* characters between ASCII and the native charset: */
-
-static const char print_ascii[] =
- "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
- "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
- " !\"#$%&'()*+,-./"
- "0123456789:;<=>?"
- "@ABCDEFGHIJKLMNO"
- "PQRSTUVWXYZ[\\]^_"
- "`abcdefghijklmno"
- "pqrstuvwxyz{|}~\n";
-
-
-int main(int argc, char **argv)
-{
- enum punycode_status status;
- int r;
- unsigned int input_length, output_length, j;
- unsigned char case_flags[unicode_max_length];
-
- if (argc != 2) usage(argv);
- if (argv[1][0] != '-') usage(argv);
- if (argv[1][2] != 0) usage(argv);
-\f
- if (argv[1][1] == 'e') {
- punycode_uint input[unicode_max_length];
- unsigned long codept;
- char output[ace_max_length+1], uplus[3];
- int c;
-
- /* Read the input code points: */
-
- input_length = 0;
-
- for (;;) {
- r = scanf("%2s%lx", uplus, &codept);
- if (ferror(stdin)) fail(io_error);
- if (r == EOF || r == 0) break;
-
- if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
- fail(invalid_input);
- }
-
- if (input_length == unicode_max_length) fail(too_big);
-
- if (uplus[0] == 'u') case_flags[input_length] = 0;
- else if (uplus[0] == 'U') case_flags[input_length] = 1;
- else fail(invalid_input);
-
- input[input_length++] = codept;
- }
-
- /* Encode: */
-
- output_length = ace_max_length;
- status = punycode_encode(input_length, input, case_flags,
- &output_length, output);
- if (status == punycode_bad_input) fail(invalid_input);
- if (status == punycode_big_output) fail(too_big);
- if (status == punycode_overflow) fail(overflow);
- assert(status == punycode_success);
-
- /* Convert to native charset and output: */
-
- for (j = 0; j < output_length; ++j) {
- c = output[j];
- assert(c >= 0 && c <= 127);
- if (print_ascii[c] == 0) fail(invalid_input);
- output[j] = print_ascii[c];
- }
-
- output[j] = 0;
- r = puts(output);
- if (r == EOF) fail(io_error);
- return EXIT_SUCCESS;
- }
-
- if (argv[1][1] == 'd') {
- char input[ace_max_length+2], *p, *pp;
- punycode_uint output[unicode_max_length];
-\f
- /* Read the Punycode input string and convert to ASCII: */
-
- fgets(input, ace_max_length+2, stdin);
- if (ferror(stdin)) fail(io_error);
- if (feof(stdin)) fail(invalid_input);
- input_length = strlen(input) - 1;
- if (input[input_length] != '\n') fail(too_big);
- input[input_length] = 0;
-
- for (p = input; *p != 0; ++p) {
- pp = strchr(print_ascii, *p);
- if (pp == 0) fail(invalid_input);
- *p = pp - print_ascii;
- }
-
- /* Decode: */
-
- output_length = unicode_max_length;
- status = punycode_decode(input_length, input, &output_length,
- output, case_flags);
- if (status == punycode_bad_input) fail(invalid_input);
- if (status == punycode_big_output) fail(too_big);
- if (status == punycode_overflow) fail(overflow);
- assert(status == punycode_success);
-
- /* Output the result: */
-
- for (j = 0; j < output_length; ++j) {
- r = printf("%s+%04lX\n",
- case_flags[j] ? "U" : "u",
- (unsigned long) output[j] );
- if (r < 0) fail(io_error);
- }
-
- return EXIT_SUCCESS;
- }
-
- usage(argv);
- return EXIT_SUCCESS; /* not reached, but quiets compiler warning */
-}
-
-
-
- INTERNET-DRAFT expires 2003-Apr-08
+++ /dev/null
-IETF IDN Working Group Editors Zita Wenzel, James Seng
-Internet Draft draft-ietf-idn-requirements-09.txt
-21 November 2001 Expires 21 May 2002
-
- Requirements of Internationalized Domain Names
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC 2026 [8].
-
-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 made obsolete 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.
-
-Intended Scope
-
-The intended scope of this document is to explore requirements for the
-internationalization of domain names on the Internet. It is not
-intended to document user requirements. It is recommended that
-solutions not necessarily be within the DNS itself, but could be a layer
-interjected between the application and the DNS. Proposals SHOULD
-fulfill most, if not all, of the requirements. This document MAY be
-updated based on actual trials.
-
-Abstract
-
-This document describes the requirement for encoding international
-characters into DNS names and records. This document is guidance for
-developing protocols for internationalized domain names.
-
-1. Introduction
-
-At present, the encoding of Internet domain names is restricted to a
-subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many
-other text based protocols on the Internet have already been at least
-partially internationalized. It is important for domain names to be
-similarly internationalized or for an equivalent solution to be found.
-This document assumes that the most effective solution involves putting
-non-ASCII names inside some parts of the overall DNS system although
-this assumption may not be the consensus of the IETF community.
-However, several sections of this document, including "Definitions and
-Conventions" should be useful in any case. A reasonable familiarity
-with DNS terminology is assumed in this document.
-
-This document is being discussed on the "idn" mailing list. To join the
-list, send a message to <majordomo@ops.ietf.org> with the words
-"subscribe idn" in the body of the message. Archives of the mailing
-list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
-
-1.1 Definitions and Conventions
-
-A language is a way that humans interact. In computerized 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 through automatic font change.
-
-Character: A character is a member of a set of elements used for
-organization, control, or representation of textual data.
-
-Graphic character: 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 character set. This character set is also
-known as the UCS (ISO 10646) [19]. 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.
-
-Unicode Technical Report #17 [24] defines a character encoding
-model in several levels (much of the text below is quoted from
-Unicode Technical Report #17).
-
-[N.B. Sections 1-6 below to be unpacked and and reworded to be
-independent of the Unicode Technical Report #17.]
-
-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 9 repertoire, the JIS X 0208 repertoire,
- the UCS repertoire (of a particular version).
-
-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.
-
-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.
-
-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.
-
- 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.) Examples: ASCII, Latin-15, Shift-JIS,
- UTF-16BE, UTF-16LE, UTF-8.
-
-5. The mapping from an abstract character repertoire (ACR) to a
- serialized 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.
-
- 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 an 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 RFC 2278 [12]. 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
-
-The Domain Name System is defined by RFC 1034 [4] and RFC 1035 [5], with
-clarifications, extensions and modifications given in RFC 1123 [6],
-RFC 1996 [7], RFC 2181 [10], and others. Of special importance here are the
-security extensions described in RFC 2535 [14] and related RFCs.
-
-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
-certain that the set of terms used in this document are well-defined and
-non-ambiguous, the definitions are given here.
-
-Master server: A master server for a zone holds the main copy of that
-zone. This copy is sometimes stored in a zone file. A slave server for
-a zone holds a complete copy of the records for that zone. Slave
-servers MAY be either authorized by the zone owner (secondary servers)
-or unauthorized (sometimes called "stealth secondaries"). Master and
-authorized slave servers are listed in the NS records for the zone,
-and are termed "authoritative" servers. In many contexts outside this
-document, the term "primary" is used interchangeably with "master" and
-"secondary" is used interchangeably with "slave".
-
-Caching server: A caching server holds temporary copies of DNS
-records; it uses records to answer queries about domain names. Further
-explanation of these terms can be found in RFC 1034 [4] and RFC 1996
-[7].
-
-DNS names can be represented in multiple forms, with different
-properties for internationalization. The most important ones are:
-
-- Domain name: The binary representation of a name used internally in
- the DNS protocol. This consists of a series of components of 1-63
- octets, with an overall length limited to 255 octets (including the
- length fields).
-
-- Master file format domain name: This is a representation of the name
- as a sequence of characters in some character sets; the common
- convention (derived from RFC 1035 [5] section 5.1) is to represent the
- octets of the name as ASCII characters where the octet is in the set
- corresponding to the ASCII values for [a-z,A-Z,0-9,-], using an escape
- mechanism (\x or \NNN) where not, and separating the components of the
- name by the dot character (".").
-
-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
-RFC 1034 [4] Section 3.5 and RFC 1123 [6]. 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, which defines its
-own rules. 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"
-
-Hostname:
-
-In the DNS protocols, a name is referred to as a sequence of octets.
-However, when discussing requirements for internationalized domain
-names, what we are looking for are ways to represent characters that
-are meaningful for humans.
-
-Internationalized Domain Name:
-
-In this document, this representation is referred to as a
-"hostname". While this term has been used for many different purposes
-over the years, it is used here in the sense of sequence of characters
-(not octets) representing a domain name conforming to the limited
-hostname syntax specified in RFC 952 [3]. This document attempts to
-define the requirements for an "Internationalized Domain Name"
-(IDN). IDN is defined as a sequence of characters that can be used in
-the context of functions where a hostname is used today, but contains
-one or more characters that are outside the set of characters
-specified as legal characters for host names RFC 1123 [6].
-
-1.4 A multilayer model of the DNS function
-
-The DNS can be seen as a multilayer function:
-
-- The bottom layer is where the packets are passed across the Internet
- in a DNS query and a DNS response. At this level, what matters is
- the format and meaning of bits and octets in a DNS packet.
-
-- 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 server often called "named.cache"). It is at this level
- that the statement "the DNS has a single root" RFC 2826 [17] makes
- sense, but still, what is being transferred are octets, not
- characters.
-
-- Interfacing to the user is a service layer, often called "the resolver
- library". It is often embedded in the operating system or system
- libraries of the client machines. It is at the top of this layer that
- the API calls commonly known as "gethostbyname" and "gethostbyaddress"
- reside. These calls are modified to support IPv6 RFC 2553 [15]. A
- conceptually similar layer exists in authoritative DNS servers,
- comprising the parts that generate "meaningful" strings in DNS files.
- Due to the popularity of the "master file" format, this layer often
- exists only in the administrative routines of the service maintainers.
-
-- The user of this layer (resolver library) is the application programs
- that use the DNS, such as mailers, mail servers, Web clients, Web
- servers, Web caches, IRC clients, FTP clients, distributed file
- systems, distributed databases, and almost all other applications on
- TCP/IP.
-
-Graphically, one can illustrate it like this:
-
-+---------------+ +---------------------+
-| Application | | (Base data) |
-+---------------+ +---------------------+
- | Application service interface |
- | For ex. GethostbyXXXX interface | (no standard)
-+---------------+ +---------------------+
-| Resolver | | Auth DNS server |
-+---------------+ +---------------------+
- | <----- DNS service interface -----> |
-+------------------------------------------------------------------+
-| DNS service |
-| +-----------------------+ +--------------------+ |
-| | Forwarding DNS server | | Caching DNS server | |
-| +-----------------------+ +--------------------+ |
-| |
-| +-------------------------+ |
-| | Parent-zone DNS servers | |
-| +-------------------------+ |
-| |
-| +-------------------------+ |
-| | Root DNS servers | |
-| +-------------------------+ |
-| |
-+------------------------------------------------------------------+
-
-1.5 Service model of the DNS
-
-The Domain Name Service is used for multiple purposes, each of which is
-characterized by what it puts into the system (the query) and what it
-expects as a result (the reply).
-
-The most used ones in the current DNS are:
-
-- Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get
- back an IPv4 or IPv6 address.
-
-- Hostname-to-mail server service (MX): As above, but the expected
- return value is a hostname and a priority for SMTP servers.
-
-- Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in
- in-addr.arpa. or ip6.arpa form respectively) and get back a hostname.
-
-- Domain delegation service (NS). Enter a domain name and get back
- nameserver records (designated hosts which provide authoritive
- nameservice) for the domain.
-
-New services are being defined, either as entirely new services (IPv6 to
-hostname mapping using binary labels) or as embellishments to other
-services such as DNS Security (DNSSEC) [14], returning information
-about whether a given DNS service is performed securely or not).
-
-These services exist, conceptually, at the Application/Resolver
-interface, NOT at the DNS-service interface. This document attempts to
-set requirements for an equivalent of the "used services" given above,
-where "hostname" is replaced by "Internationalized Domain Name". This
-does not preclude the fact that IDN should work with any kind of DNS
-queries. IDN is a new service. Since existing protocols like SMTP or
-HTTP use the old service, it is a matter of great concern how the new
-and old services work together, and how other protocols can take
-advantage of the new service.
-
-2. General Requirements
-
-These requirements address two concerns: The service offered to the
-users (the application service), and the protocol extensions, if needed,
-added to support this service.
-
-In the requirements, we attempt to use the term "service" whenever a
-requirement concerns the service, and "protocol" whenever a requirement
-is believed to constrain the possible implementation.
-
-2.1 Compatibility and Interoperability
-
-[1] The DNS is essential to the entire Internet. Therefore, the service
-MUST NOT damage present DNS protocol interoperability. It MUST make the
-minimum number of changes to existing protocols on all layers of the
-stack. It MUST continue to allow any system anywhere that implements
-the IDN specification to resolve any internationalized domain name.
-
-[2] The service MUST preserve the basic concept and facilities of domain
-names as described in RFC 1034 [4]. It MUST maintain a single, global,
-universal, and consistent hierarchical namespace.
-
-[3] 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.
-
-[4] 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.
-
-[5] 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.
-
-[6] 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.
-
-[7] 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
-authoritative server. This applies fully for the cases when:
-
-- The caching server does not know about IDN
-- The caching server implements the whole specification
-- The caching server implements a valid subset of the specification
-
-[8] The service MAY modify the DNS protocol RFC 1035 [5] and other related
-work undertaken by the DNS Extensions (DNSEXT) [2] working group. However,
-these changes SHOULD be as small as possible and any changes SHOULD be
-coordinated with the DNSEXT working group.
-
-[9] The protocol supporting the service SHOULD be as simple as possible
-from the user's perspective. Ideally, users SHOULD NOT realize that IDN
-was added on to the existing DNS.
-
-[10] The best solution is one that maintains maximum feasible
-compatibility with current DNS standards as long as it meets the other
-requirements in this document.
-
-[11] The protocol should handle with care new revisions of the CCS.
-Undefined codepoints should not be allowed unless a new revision of
-the protocol can handle it. Protocol revisions should be tagged.
-
-2.2 Internationalization
-
-[12] Internationalized characters MUST be allowed to be represented and
-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.
-
-[13] 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 RFC 2277 [11].
-
-[14] The protocol MUST NOT reject any non-IDN characters (to be
-defined) in any DNS queries or responses.
-
-[15] The protocol SHOULD NOT invent a new CCS for the purpose of IDN
-only and SHOULD use an existing CES. The charset(s) chosen SHOULD also be
-non-ambiguous.
-
-[16] 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 Top-Level Domains (TLDs) can be
-internationalized.
-
-[17] The protocol also SHOULD NOT make any localized restrictions in the
-protocol. For example, an IDN implementation which only allows domain
-names to use a single local script would immediately restrict
-multinational organization.
-
-[18] While there are a wide range of devices that use the DNS and a wide
-range of characteristics of international scripts and methods of
-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.
-
-2.3 Canonicalization
-
-Matching rules are a complicated process for IDN. Canonicalization
-of characters MUST follow precise and predictable rules to ensure
-consistency. "Requirements for String Identity Matching and String
-Indexing" is RECOMMENDED as a guide on canonicalization.
-
-The DNS has to match a host name in a request with a host name held
-in one or more zones. It also needs to sort names into order. It is
-expected that some sort of canonicalization algorithm will be used as
-the first step of this process. This section discusses some of the
-properties which will be REQUIRED of that algorithm.
-
-[19] To achieve interoperability, canonicalization MUST be done at a
-single well-defined place in the DNS resolution process. The protocol
-MUST specify canonicalization; it MUST specify exactly where in the
-DNS that canonicalization happens and does not happen; it MUST specify
-how additions to ISO 10646 will affect the stability of the DNS and
-the amount of work done on the root DNS servers.
-
-[20] The canonicalization algorithm MAY specify operations for case,
-ligature, and punctuation folding.
-
-[21] In order to retain backward compatibility with the current DNS,
-the service MUST retain the case-insensitive comparison for US-ASCII
-as specified in RFC 1035 [5]. For example, Latin capital letter A
-(U+0041) MUST match Latin small letter a (U+0061). Unicode Technical
-Report #21 [25] describes some of the issues with case
-mapping. Case-insensitivity for non US-ASCII MUST be discussed in the
-protocol proposal.
-
-[22] Case folding MUST be locale independent. If it were
-locale-dependent, then different clients would get different results.
-For example, Latin capital letter I (U+0049) case folded to lower case
-in the Turkish context will become Latin small letter dotless i
-(U+0131). But in the English context, it will become Latin small
-letter i (U+0069).
-
-[23] If other canonicalization is done, it MUST be done before the
-domain name is resolved. Further, the canonicalization MUST be easily
-upgradable as new languages and writing systems are added.
-
-[24] Any conversion (case, ligature folding, punctuation folding, etc)
-from what the user enters into a client to what the client asks for
-resolution MUST be done identically on any request from any client.
-
-[25] If the charset can be normalized, then it SHOULD be normalized
-before it is used in IDN. Normalization SHOULD follow Unicode
-Technical Report #15 [23].
-
-[26] The protocol SHOULD avoid inventing a new normalization form
-provided a technically sufficient one is available.
-
-2.4 Operational Issues
-
-[27] Zone files SHOULD remain easily editable.
-
-[28] An IDN-capable resolver or server SHALL NOT generate more traffic
-than a non-IDN-capable resolver or server would when resolving an
-ASCII-only domain name. The amount of traffic generated when resolving
-an IDN SHALL be similar to that generated when resolving an ASCII-only
-name.
-
-[29] The service SHOULD NOT add new centralized administration for the
-DNS. A domain administrator SHOULD be able to create internationalized
-names as easily as adding current domain names.
-
-[30] The protocol MUST work with DNSSEC. The protocol MAY break
-language sort order.
-
-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
-internationalized host names to and from IP addresses MUST have the
-same characteristics as the mapping of today's host names.
-
-Specifying requirements for internationalized domain names does not
-itself raise any new security issues. However, any change to the DNS MAY
-affect the security of any protocol that relies on the DNS or on
-DNS names. A thorough evaluation of those protocols for security
-concerns will be needed when they are developed. In particular, IDNs
-MUST be compatible with DNSSEC and, if multiple charsets or
-representation forms are permitted, the implications of this name-spoof
-MUST be throughly understood.
-
-4. References
-
-[1] World Wide Web Consortium, "Requirements for string identity
-matching and String Indexing", http://www.w3.org/TR/WD-charreq, July
-1998.
-
-[2] Olafur Gudmundson, Randy Bush, "IETF DNS Extensions Working Group"
-(DNSEXT), namedroppers@ops.ietf.org.
-
-[3] K. Harrenstien, M.K. Stahl, E.J. Feinler, "DoD Internet Host Table
-Specification", RFC 952, October 1985.
-
-[4] P. Mockapetris, "Domain Names - Concepts and Facilities",
-RFC 1034, November 1987.
-
-[5] P. Mockapetris, "Domain Names - Implementation and
-Specification", RFC 1035, November 1987.
-
-[6] R. Braden, "Requirements for Internet Hosts -- Application and
-Support", RFC 1123, October 1989.
-
-[7] P. Vixie, "A Mechanism for Prompt Notification of Zone Changes
-(DNS NOTIFY)", RFC 1996, August 1996.
-
-[8] S. Bradner, "The Internet Standards Process -- Revision 3", RFC
-2026, October 1996.
-
-[9] S. Bradner, "Key words for use in RFCs to Indicate Requirement
-Levels", RFC 2119, March 1997.
-
-[10] R. Elz, R. Bush, "Clarifications to the DNS Specification",
-RFC 2181, July 1997.
-
-[11] H. Alvestrand, "IETF Policy on Character Sets and Languages", RFC
-2277, January 1998.
-
-[12] N. Freed and J. Postel, "IANA Charset Registration Procedures",
-RFC 2278, January 1998.
-
-[13] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
-2279, January 1998.
-
-[14] D. Eastlake, "Domain Name System Security Extensions", RFC 2535,
-March 1999.
-
-[15] R. Gilligan et al, "Basic Socket Interface Extensions for IPv6",
-RFC 2553, March 1999.
-
-[16] L. Daigle et al, "A Tangled Web: Issues of I18N, Domain Names,
-and the Other Internet protocols", RFC 2825, May 2000.
-
-[17] Internet Architecture Board, "IAB Technical Comment on the Unique DNS
-Root", RFC 2826, May 2000.
-
-[18] P. Hoffman, "Comparison of Internationalized Domain Name
-Proposals", draft-ietf-idn-compare-00.txt, June 2000.
-
-[19] 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.
-
-[20] The Unicode Consortium, "The Unicode Standard". Described at
-http://www.unicode.org/unicode/standard/versions/.
-
-[21] 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.
-
-[22] Coded Character Set -- 7-bit American Standard Code for
-Information Interchange, ANSI X3.4-1986; also: ISO/IEC 646 (IRV).
-
-[23] M. Davis and M. Duerst, Unicode Consortium, "Unicode
-Normalization Forms", Unicode Standard Annex #15,
-http://www.unicode.org/unicode/reports/tr15/, 2000-08-31.
-
-[24] K. Whistler and M. Davis, Unicode Consortium, "Character Encoding
-Model", Unicode Technical Report #17,
-http://www.unicode.org/unicode/reports/tr17/, 2000-08-31.
-
-[25] M. Davis, Unicode Consortium, "Case Mappings", Unicode Technical
-Report #21, http://www.unicode.org/unicode/reports/tr21/, 2000-09-12.
-
-
-5. Editors' Contact
-
-Zita Wenzel, Ph.D.
-Information Sciences Institute
-University of Southern California
-4676 Admiralty Way
-Marina del Rey, CA
-90292 USA
-Tel: +1 310 448 8462
-Fax: +1 310 823 6714
-zita@isi.edu
-
-James Seng
-i-DNS.net International Pte Ltd.
-8 Temesek Boulevand
-#24-02 Suntec Tower 3
-Singapore 038988
-Tel: +65 248 6208
-Fax: +65 248 6198
-Email: jseng@pobox.org.sg
-
-6. Acknowledgements
-
-The editors gratefully acknowledge the contributions of:
-
-Harald Tveit Alvestrand <Harald@Alvestrand.no>
-Mark Andrews <Mark.Andrews@nominum.com>
-RJ Atkinson <request not to have email>
-Alan Barret <apb@cequrux.com>
-Marc Blanchet <blanchet@mailviagenie.qc.ca>
-Randy Bush <randy@psg.com>
-Andrew Draper <ADRAPER@altera.com>
-Martin Duerst <duerst@w3.org>
-Patrik Faltstrom <paf@swip.net>
-Ned Freed <ned.freed@innosoft.com>
-Olafur Gudmundsson <ogud@ogud.com>
-Paul Hoffman <phoffman@imc.org>
-Simon Josefsson <jas+idn@pdc.kth.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>
-Bill Manning <bmanning@ISI.EDU>
-Dan Oscarsson <Dan.Oscarsson@trab.se>
-J. William Semich <bill@mail.nic.nu>
-Yoshiro Yoneda <yone@nic.ad.jp>
+++ /dev/null
-Internet Draft Dan Oscarsson
-draft-ietf-idn-udns-03.txt Telia ProSoft
-Updates: RFC 2181, 1035, 1034, 2535 19 August 2001
-Expires: 19 February 2002
-
- Using the Universal Character Set in the Domain Name System (UDNS)
-
-Status of this memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
-Abstract
-
- Since the Domain Name System (DNS) [RFC1035] was created there have
- been a desire to use other characters than ASCII in domain names.
- Lately this desire have grown very strong and several groups have
- started to experiment with non-ASCII names. This document defines
- how the Universal Character Set (UCS) [ISO10646] is to be used in
- DNS. It includes both a transition scheme for older software
- supporting non-ASCII handling in applications only, as well as how to
- use UCS in labels and having more than 63 octets in a label.
-
-
-1. Introduction
-
- 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.
-
- To avoid several different implementations of non-ASCII names in DNS
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 1]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
- that do not work together, and to avoid breaking the current ASCII
- only DNS, there is an immediate need to standardise how DNS shall
- handle non-ASCII names.
-
- While the DNS protocol allow any octet in character data, so far the
- octets are only defined for the ASCII code points. Octets outside the
- ASCII range have no defined interpretation. This document defines how
- all octets are to be used in character data allowing a standardised
- way to use non-ASCII in DNS.
-
- The specification here conforms to the IDN requirements [IDNREQ].
-
-1.1 Terminology
-
- 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].
-
- IDN: Internationalised Domain Name, here used to mean a domain name
- containing non-ASCII characters.
-
- ACE: ASCII Compatible Encoding. Used to encode IDNs in a way
- compatible with the ASCII host name syntax.
-
-1.2 Previous versions of this document
-
- This version contains just minor corrections to the 4:th version.
-
- The third version of this document included a way to return both
- ASCII and non-ASCII versions of a name. As this could not be
- guaranteed to work it has been removed.
-
- 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.
-
- The first version of this document was available as draft-oscarsson-
- i18ndns-00.txt.
-
-
-2. The DNS Protocol
-
- The DNS protocol is used when communicating between DNS servers and
- other DNS servers or DNS clients. User interface issues like the
- format of zone files or how to enter or display domain names are not
- part of the protocol.
-
- The update of the protocol defined here can be used immediately as it
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 2]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
- is fully compatible with the DNS of today.
-
- For a long time there will be software understanding UCS in DNS and
- 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 aware DNS server
-
-
-2.1 Fundamentals
-
-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.
- Character data is used in labels and in text fields in the RDATA part
- of a RR.
-
- 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.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. 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.
-
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 3]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
- 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.
-
- 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.
-
- 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].
-
- 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].
-
-2.1.3 Backward Compatibility Encoding (BCE)
-
- 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.
-
- 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].
-
- The reason that the BCF form of the label is used is to support
- solutions where only applications know about non-ASCII labels. By
- using BCF the server need not know about UCS and can just do binary
- matching so it can be handled in old servers. Though due to the fact
- that BCF destroys information contained in the original form of a
- label it is impossible to return the original form to a client using
- BCE.
-
-2.1.4 Long names
-
- The current DNS protocol limits a label to 63 octets. As UTF-8 take
- more than one octet for some characters, an UTF-8 name cannot have 63
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 4]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
- characters in a label like an ASCII name can. For example a name
- using Hangul would have a maximum of 21 characters.
-
- The limits imposed by RFC 1035 is 63 octets per label and 255 octets
- for the full name. The 255 limit is not a protocol limit but one to
- simplify implementations.
-
- To support longer names a long label type is defined using [RFC2671]
- as extended label 0b000011 (the label type will be assigned by IANA
- and may not be the number used here).
-
- 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- |0 1 0 0 0 0 1 1| length | label data ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- length: length of label in octets
- label data: the label
-
- The long label MUST be handled by all software following this
- specification. Also, they MUST support a UDP packet size of up to
- 1280 bytes.
-
- 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
- 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.2 Rules for matching of domain names in UDNS aware 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:
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 5]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
- - only servers handling authorative data must implement form-
- insensitive matching of names. And they need only implement the
- subset needed for the subset of characters of UCS they support in
- 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
- 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
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 6]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
- A non-UDNS aware client will send ASCII or whatever is sent from an
- application. It can be BCE which will for the client just be ASCII
- text.
-
-2.3.4 UDNS aware server
-
- An UDNS aware server MUST handle all in this document and follow:
- - 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. 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 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.
-
- It is recommended that protocols updated to handle i18n do this by
- encoding character data in the same standard format as defined for
- DNS in this document (UCS normalised form C). The use of encoding it
- in ASCII or by tagged character sets should be avoided.
-
- DNS do not only have domain names in them, for example e-mail
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 7]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
- addresses are also included. So an e-mail address would be expected
- to be changed to include non-ASCII both before and after the @-sign.
-
- Software need to be updated to follow the user interface
- recommendations given above, so that a human will see the characters
- in their local character set, if possible.
-
-4. Security Considerations
-
- As always with data, if software does not check for data that can be
- 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.
-
-5. References
-
- [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] P. Mockapetris, "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997, RFC 2119.
-
- [RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
- RFC 2279, January 1998.
-
- [RFC2535] D. Eastlake, "Domain Name System Security Extensions".
- RFC 2535, March 1999.
-
- [RFC2671] P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [ISO10646] ISO/IEC 10646-1:2000. International Standard --
- Information technology -- Universal Multiple-Octet Coded
- Character Set (UCS)
-
- [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
-
- [UTR15] M. Davis and M. Duerst, "Unicode Normalization Forms",
- Unicode Technical Report #15, Nov 1999,
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 8]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
- http://www.unicode.org/unicode/reports/tr15/.
-
- [UTR21] M. Davis, "Case Mappings", Unicode Technical Report #21,
- Dec 1999, http://www.unicode.org/unicode/reports/tr21/.
-
- [UDATA] The Unicode Character Database,
- ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt.
- The database is described in
- ftp://ftp.unicode.org/Public/UNIDATA/
- UnicodeCharacterDatabase.html.
-
- [IDNREQ] James Seng, "Requirements of Internationalized Domain
- Names", draft-ietf-idn-requirement.
-
- [IANADNS] Donald Eastlake, Eric Brunner, Bill Manning, "Domain Name
- System (DNS) IANA Considerations",draft-ietf-dnsext-iana-dns.
-
- [IDNE] Marc Blanchet,Paul Hoffman, "Internationalized domain
- names using EDNS (IDNE)", draft-ietf-idn-idne.
-
- [CHNORM] M. Duerst, M. Davis, "Character Normalization in IETF
- Protocols", draft-duerst-i18n-norm.
-
- [IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
- Proposals", draft-ietf-idn-compare.
-
- [NAMEPREP] Paul Hoffman, "Comparison of Internationalized Domain Name
- Proposals", draft-ietf-idn-compare.
-
- [SACE] Dan Oscarsson, "Simple ASCII Compatible Encoding", draft-
- ietf-idn-sace.
-
- [RACE] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
- for IDN", draft-ietf-idn-race.
-
-6. Acknowledgements
-
- Paul Hoffman giving many comments in our e-mail discussions.
-
- Ideas from drafts by Paul Hoffman, Stuart Kwan, James Gilroy and Kent
- Karlsson.
-
- Magnus Gustavsson, Mark Davis, Kent Karlsson and Andrew Draper for
- comments on my draft.
-
- Discussions and comments by the members of the IDN working group.
-
-
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 9]
-\f
-Internet Draft Universal DNS 19 August 2001
-
-
-Author's Address
-
- Dan Oscarsson
- Telia ProSoft AB
- Box 85
- 201 20 Malmo
- Sweden
-
- E-mail: Dan.Oscarsson@trab.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dan Oscarsson Expires: 19 February 2002 [Page 10]
-\f
+++ /dev/null
-
-
-
-
-Network Working Group M. Duerst
-Internet-Draft W3C
-Expires: May 4, 2003 November 3, 2002
-
-
- Internationalized Domain Names in URIs
- draft-ietf-idn-uri-03
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on May 4, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document proposes to upgrade the definition of URIs (RFC 2396)
- [RFC2396] to work consistently with internationalized domain names.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 1]
-Internet-Draft IDNs in URIs November 2002
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. URI syntax changes . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Security considerations . . . . . . . . . . . . . . . . . . . 5
- 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
- 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03 . 5
- 5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02 . 5
- 5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01 . 5
- References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 2]
-Internet-Draft IDNs in URIs November 2002
-
-
-1. Introduction
-
- Internet domain names serve to identify hosts and services on the
- Internet in a convenient way. The IETF IDN working group [IDNWG] has
- been working on extending the character repertoire usable in domain
- names beyond a subset of US-ASCII.
-
- One of the most important places where domain names appear are
- Uniform Resource Identifiers (URIs, [RFC2396], as modified by
- [RFC2732]). However, in the current definition of the generic URI
- syntax, the restrictions on domain names are 'hard-coded'. In
- Section 2, this document relaxes these restrictions by updating the
- syntax, and defines how internationalized domain names are encoded in
- URIs.
-
- The syntax in this document has been chosen to further increase the
- uniformity of URI syntax, which is a very important principle of
- URIs.
-
- In practice, escaped domain names should be used as rarely as
- possible. Wherever possible, the actual characters in
- Internationalized Domain Names should be preserved as long as
- possible by using IRIs [IRI] rather than URIs, and only converting to
- URIs and then to ACE-encoded [IDNA] domain names (or ideally directly
- to ACE-encoding without even using URIs) when resolving the IRI.
- Also, this document does not exclude the use of ACE encoding directly
- in an URI domain name part. ACE encoding may be used directly in an
- URI domain name part if this is considered necessary for
- interoperability.
-
- Please note that even with the definition of URIs in [RFC2396], some
- URIs can already contain host names with escaped characters. For
- example, mailto:example@w%33.org is legal per [RFC2396] because the
- mailto: URI scheme does not follow the generic syntax of [RFC2396].
-
-2. URI syntax changes
-
- The syntax of URIs [RFC2396] currently contains the following rules
- relevant to domain names:
-
- hostname = *( domainlabel "." ) toplabel [ "." ]
- domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
- toplabel = alpha | alpha *( alphanum | "-" ) alphanum
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 3]
-Internet-Draft IDNs in URIs November 2002
-
-
- The later two rules are changed as follows:
-
- domainlabel = anchar | anchar *( anchar | "-" ) anchar
- toplabel = achar | achar *( anchar | "-" ) anchar
-
- and the following rules are added:
-
- anchar = alphanum | escaped
- achar = alpha | escaped
-
- Characters outside the repertoire (alphanum) are encoded by first
- encoding the characters in UTF-8 [RFC 2279], resulting in a sequence
- of octets, and then escaping these octets according to the rules
- defined in [RFC2396].
-
- Using UTF-8 assures that this encoding interoperates with IRIs [IRI].
- It is also aligned with the recommendations in [RFC2277] and
- [RFC2718], and is consistent with the URN syntax [RFC2141] as well as
- recent URL scheme definitions that define encodings of non-ASCII
- characters based on UTF-8 (e.g., IMAP URLs [RFC2192] and POP URLs
- [RFC2384]).
-
- The above syntax rules permit for domain names that are neither
- permitted as US-ASCII only domain names nor as internationalized
- domain names. However, such domain names should never be used, and
- will never be resolved because no such domains will be registered.
- For US-ASCII only domain names, the syntax rules in [RFC2396] are
- relevant. For example, http://www.w%33.org is legal, because the
- corresponding 'w3' is a legal 'domainlabel' according to [RFC2396].
- However, http://%2a.example.org is illegal because the corresponding
- '*' is not a legal 'domainlabel' according to [RFC2396].
-
- For domain names containing non-ASCII characters, the legal domain
- names are those for which the ToASCII operation ([IDNA], [Nameprep];
- using the unescaped UTF-8 values as input), with the flags
- "UseSTD3ASCIIRules" and "AllowUnassigned" set, is successful. The
- URI resolver MUST apply any steps required as part of domain name
- resolution by [IDNA], in particular the ToASCII operation, with the
- above-mentioned flags set. URIs where the ToASCII operation results
- in an error should be treated as unresolvable.
-
- For domain names containing non-ASCII characters, the Nameprep
- specification ([Nameprep]) defines some mappings, which mainly
- include normalization to NFKC and folding to lower case. When
- encoding an internationalized domain name in an URI, these mappings
- SHOULD NOT be applied. It should be assumed that the domain name is
- already normalized as far as appropriate.
-
-
-
-
-Duerst Expires May 4, 2003 [Page 4]
-Internet-Draft IDNs in URIs November 2002
-
-
- For consistency in comparison operations and for interoperability
- with older software, the following should be noted: 1) US-ASCII
- characters in domain names should not be escaped. 2) Because of the
- principle of syntax uniformity for URIs, it is always more prudent to
- take into account the possibility that US-ASCII characters are
- escaped.
-
-3. Security considerations
-
- The security considerations of [RFC2396] and those applying to
- internationalized domain names apply. There may be an increased
- potential to smuggle escaped US-ASCII-based domain names across
- firewalls, although because of the uniform syntax principle for URIs,
- such a potential is already existing.
-
-4. Acknowledgements
-
- Erik Nordmark
-
-5. Change Log
-
-5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03
-
- Clarified expectations on name checking.
-
-5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02
-
- Moved change log to back
-
- Changed to only change URIs; IRI syntax updated directly in IRI
- draft.
-
- Removed syntax restriction on %hh in the US-ASCII part, but made
- clear that restrictions to domain names apply.
-
- Made clear that escaped domain names in URIs should only be an
- intermediate representation.
-
- Gave example of mailto: as already allowing escaped host names.
-
- Corrected some typos.
-
-5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01
-
- Changed requirement for URI/IRI resolvers from MUST to SHOULD
-
- Changed IRI syntax slightly (ichar -> idchar, based on changes in
- [IRI])
-
-
-
-Duerst Expires May 4, 2003 [Page 5]
-Internet-Draft IDNs in URIs November 2002
-
-
- Various wording changes
-
-References
-
- [IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)",
- draft-ietf-idn-idna-14.txt (work in progress), October
- 2002, <http://www.ietf.org/internet-drafts/draft-ietf-
- idn-idna-14.txt>.
-
- [IDNWG] "IETF Internationalized Domain Name (idn) Working Group".
-
- [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
- Identifiers (IRI)", draft-duerst-iri-02.txt (work in
- progress), November 2002, <http://www.ietf.org/internet-
- drafts/draft-duerst-iri-02.txt>.
-
- [ISO10646] International Organization for Standardization,
- "Information Technology - Universal Multiple-Octet Coded
- Character Set (UCS) - Part 1: Architecture and Basic
- Multilingual Plane", ISO Standard 10646-1, October 2000.
-
- [Nameprep] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
- Profile for Internationalized Domain Names", draft-ietf-
- idn-nameprep-11.txt (work in progress), June 2002,
- <http://www.ietf.org/internet-drafts/draft-ietf-idn-
- nameprep-11.txt>.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
-
- [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
-
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
- Languages", BCP 18, RFC 2277, January 1998.
-
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
- [RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
-
- [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- [RFC2640] Curtin, B., "Internationalization of the File Transfer
-
-
-
-Duerst Expires May 4, 2003 [Page 6]
-Internet-Draft IDNs in URIs November 2002
-
-
- Protocol", RFC 2640, July 1999.
-
- [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
- "Guidelines for new URL Schemes", RFC 2718, November
- 1999.
-
- [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
- Literal IPv6 Addresses in URL's", RFC 2732, December
- 1999.
-
-
-Author's Address
-
- Martin Duerst
- World Wide Web Consortium
- 200 Technology Square
- Cambridge, MA 02139
- U.S.A.
-
- Phone: +1 617 253 5509
- Fax: +1 617 258 5999
- EMail: duerst@w3.org
- URI: http://www.w3.org/People/D%C3%BCrst/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 7]
-Internet-Draft IDNs in URIs November 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 8]
+++ /dev/null
-IETF IDN Working Group Sung Jae Shim
-Internet Draft DualName, Inc.
-Document: draft-ietf-idn-vidn-01.txt 2 March 2001
-Expires: 2 September 2001
-
-
-
- Virtually Internationalized Domain Names (VIDN)
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task Force
-(IETF), its areas, and its working groups. Note that other groups may also
-distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months and may be
-updated, replaced, or obsoleted by other documents at any time. It is
-inappropriate to use Internet-Drafts as reference material or to cite them other
-than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-
-1. Abstract
-
-This document proposes a method that enables domain names to be used in both
-local and English scripts, as a directory-search solution at an upper layer
-above the DNS. The method first converts virtual domain names typed in local
-scripts into the corresponding domain names in English scripts that comply with
-the DNS, using the knowledge of transliteration between local and English
-scripts. Then, the method searches for and displays domain names in English
-scripts that are active on the Internet so that the user can choose any of them.
-The conversion takes place automatically and transparently in the user's
-applications before DNS queries are sent, and so, the method does not make any
-change to the DNS nor require separate name servers.
-
-
-2. Conventions and definitions used in this document
-
-The key words "REQUIRED" and "MAY" in this document are to be interpreted as
-described in RFC-2119 [1].
-
-A "host" is a computer or device attached to the Internet. A "user host" is a
-computer or device with which a user is connected to the Internet, and a "user"
-is a person who uses a user host. A "server host" is a computer or device that
-provides services to user hosts.
-
-An "entity" is an organization or individual that has a domain name registered
-with the DNS.
-
-A "local language" is a language other than English language that a user prefers
-to use in a local context. "Local scripts" are scripts of a local language and
-"English scripts" are scripts of English language.
-
-A "virtual domain name" is a domain name in local scripts, and it is not
-registered with the DNS but used for the convenience of users. An "English
-domain name" is a domain name in English scripts. A "domain name" refers to an
-English domain name that complies with the DNS, unless specified otherwise.
-
-A "coded portion" is a pre-coded portion of a domain name (e.g., generic codes
-including 'com', 'edu', 'gov', 'int', 'mil', 'net', 'org', and country codes
-such as 'kr', 'jp', 'cn', and so on). An "entity-defined portion" is a portion
-of a domain name, which is defined by the entity that holds the domain name
-(e.g., host name, organization name, server name, and so on).
-
-The method proposed in this document is called "virtually internationalized
-domain names (VIDN)," as it enables domain names in English scripts to be used
-virtually in local scripts.
-
-A number of Korean-language characters are used in the original of this document
-for examples, which is available from the author upon request. The software used
-for Internet-Drafts does not allow using multilingual characters other than
-ASCII characters. Thus, this document may not display Korean-language characters
-properly, although it may be comprehensible without the examples using Korean-
-language characters. Also, when you open the original of this document, please
-select your view encoding type to Korean for Korean-language characters to be
-displayed properly.
-
-
-3. Introduction
-
-Domain names are valuable to Internet users as a main identifier of entities and
-resources on the Internet. The DNS allows using only English scripts in naming
-hosts or clusters of hosts on the Internet. More specifically, the DNS uses only
-the basic Latin alphabets (case-insensitive), the decimal digits (0-9) and the
-hyphen (-) in domain names. But there is a growing need for internationalized
-domain names in local scripts. Recognizing this need, various methods have been
-proposed to use local scripts in domain names. But to date, no method appears to
-meet all the requirements of internationalized domain names as described in
-Wenzel and Seng [2].
-
-A group of earlier methods tries to put internationalized domain names in local
-scripts inside some parts of the overall DNS, using special encoding schemes of
-Universal Character Set (UCS). But these methods put too much of a burden on the
-DNS, requiring a great deal of work for transition and update of the DNS
-components and the applications working with the DNS. Another group of earlier
-methods tries to build separate directory services for internationalized domain
-names or keywords in local scripts. But these methods also require complex
-implementation efforts, duplicating much of the work already done for the DNS.
-Both the groups of earlier methods require creating internationalized domain
-names or keywords in local scripts from scratch, which is a costly and lengthy
-process on the parts of the DNS and Internet users. Further, domain names or
-keywords created in local scripts are usable only by those who know the local
-scripts, and so, they may segregate the Internet into many groups of different
-sets of local scripts that are less universal than English scripts.
-
-VIDN intends to provide a more immediate and less costly solution to
-internationalized domain names than earlier methods. VIDN does not make any
-change to the DNS nor require creating additional domain names in local scripts.
-VIDN takes notice of the fact that many domain names currently used in regions
-where English scripts are not widely used have their entity-defined portions
-consisting of English scripts as transliterated from the respective local
-scripts. Using this knowledge of transliteration between local and English
-scripts, VIDN converts virtual domain names typed in local scripts into the
-corresponding domain names in English scripts that comply with the DNS. In this
-way, VIDN enables the same domain names to be used not only in English scripts
-as usual but also in local scripts, without creating additional domain names in
-local scripts.
-
-
-4. VIDN method
-
-4.1. Objectives
-
-Earlier methods of internationalized domain names try to create domain names or
-keywords in local scripts one way or another in addition to existing domain
-names in English scripts, and put them inside or outside the DNS, using special
-encoding schemes or lookup services. These methods require a lengthy and costly
-process of creating domain names in local scripts and updating the DNS
-components and applications. Even when they are successfully implemented, these
-methods have a risk of localizing the Internet by segregating it into groups of
-different sets of local scripts that are less universal than English scripts and
-so diminishing the international scope of the Internet. Further, these methods
-may cause more problems and disputes on copyrights, trademarks, and so on, in
-local contexts than those that we experience with current domain names in
-English scripts.
-
-VIDN intends to provide a solution to the problems of earlier methods of
-internationalized domain names. VIDN enables the same domain names to be used in
-both English scripts as usual and local scripts, and so, there is no need to
-create domain names in local scripts in addition to domain names in English
-scripts. VIDN works automatically and transparently in applications at user
-hosts before DNS requests are sent, and so, there is no need to make any change
-to the DNS or to have additional name servers. For these reasons as well as
-others, VIDN can be implemented more immediately with less cost than other
-methods of internationalized domain names.
-
-4.2. Description
-
-It is important to note that most domain names used in regions where English
-scripts are not widely used have their entity-defined portions consisting of
-English scripts as transliterated from local scripts. Of course, there are many
-domain names in those regions that do not follow this kind of transliteration
-between local and English scripts. In such case, new domain names in English
-scripts need to be created following this transliteration, but the number would
-be minimal, compared to the number of internationalized domain names in local
-scripts to be created and registered under other methods.
-
-The English scripts transliterated from local scripts do not have any meanings
-in English language, but their originals in local scripts before the
-transliteration have some meanings in the respective local language, usually
-indicating organization names, brand names, trademarks, and so on. VIDN enables
-to use these original local scripts as the entity-defined portions of virtual
-domain names in local scripts, by transliterating them into the corresponding
-entity-defined portions of actual domain names in English scripts. In this way,
-VIDN enables the same domain names in English scripts to be used virtually in
-local scripts without actually creating domain names in local scripts.
-
-As domain names in English scripts overlay IP addresses, so virtual domain names
-in local scripts do actual domain names in English scripts. The relationship
-between virtual domain names in local scripts and actual domain names in English
-scripts can be depicted as:
-
- +---------------------------------+
- | User |
- +---------------------------------+
- | |
- +----------------|-----------------------|------------------+
- | v (Transliteration) v |
- | +---------------------+ | +-----------------------+ |
- | | Virtual domain name | | | Actual domain name | |
- | | in local scripts |--+->| in English scripts | |
- | +---------------------+ +-----------------------+ |
- | User application | |
- +----------------------------------------|------------------+
- v
- DNS requests
-
-VIDN uses the phonemes of local and English scripts as a medium in
-transliterating the entity-defined portions of virtual domain names in local
-scripts into those of actual domain names in English scripts. This process of
-transliteration can be depicted as:
-
- Local scripts English scripts
-+----------------------------+ +-----------------------------+
-| Characters ----> Phonemes -----------> Phonemes ----> Characters |
-| | | | | | |
-| | | | | | |
-| (Inverse of transcription) | Match | (Transcription) |
-+----------------------------+ +-----------------------------+
- | ^
- | (Transliteration) |
- +------------------------------------+
-
-First, each entity-defined portion of a virtual domain name typed in local
-scripts is decomposed into individual characters or sets of characters so that
-each individual character or set of characters can represent an individual
-phoneme of the local language. This is the inverse of transcription of phonemes
-into characters. Second, each individual phoneme of the local language is
-matched with an equivalent phoneme of English language that has the same or most
-proximate sound. Third, each phoneme of English language is transcribed into the
-corresponding character or set of characters in English language. Finally, all
-the characters or sets of characters converted into English scripts are united
-to compose the corresponding entity-defined portion of an actual domain name in
-English scripts.
-
-For example, a word in Korean language, '\98\82' that means 'century' in English
-language, is transliterated into 'segi' in English scripts, and so, the entity
-whose name contains '\98\82' in Korean language may have an entity-defined portion
-of its domain name as 'segi' in English scripts. VIDN enables to use '\98\82' as
-an entity-defined portion of a virtual domain name in Korean scripts, which is
-converted into 'segi,' the corresponding entity-defined portion of an actual
-domain name in English scripts. In other words, the phonemes represented by the
-characters consisting of '\98\82' in Korean scripts have the same sounds as the
-phonemes represented by the characters consisting of 'segi' in English scripts.
-In the local context, '\98\82' in Korean scripts is clearly easier to remember and
-type and more intuitive and meaningful than 'segi' in English scripts.
-
-An entity-defined portion of a virtual domain name in Korean scripts, '¾\9e®ý', is
-transliterated into 'yahoo' in English scripts, since the phonemes represented
-by the characters consisting of '¾\9e®ý' in Korean scripts have the same sounds as
-the phonemes represented by the characters consisting of 'yahoo' in English
-scripts. That is, '¾\9e®ý' in Korean scripts is pronounced as the same as 'yahoo'
-in English scripts, and so, it is easy for Korean-speaking people to deduce '¾\9e
-®ý' in Korean scripts as the virtual equivalent of 'yahoo' in English scripts.
-VIDN enables to use virtual domain names in local scripts for domain names whose
-originals are in local scripts, e.g., '\98\82' in Korean scripts, as well as
-domain names whose originals are in English scripts, e.g., '¾\9e®ý' in Korean
-scripts. In this way, VIDN is able to make domain names truly international,
-allowing the same domain names to be used both in English and local scripts.
-
-The coded portions of domain names such as generic codes and country codes can
-also be transliterated from local scripts into English scripts, using their
-phonemes as a medium. For example, seven generic codes in English scripts, 'com',
-'edu', 'gov', 'int', 'mil', 'net', and 'org', can be transliterated from 'ýý', '
-Àí´\80', '\97\8d¦\8a', 'ÁðË«', ' Ï', 'þÚË«', 'ÀÁ\98Ú' in Korean scripts, respectively,
-which can be used as the corresponding generic codes of virtual domain names in
-Korean scripts. Based upon its meaning in English language, each coded portion
-of actual domain names also can be pre-assigned a virtual equivalent word or
-code in local scripts. For example, seven generic codes in English scripts,
-'com', 'edu', 'gov', 'int', 'mil', 'net', and 'org', can be pre-assigned '\98\82¾\95'
-(meaning 'commercial' in Korean language), 'ÌÏ\98þ' (meaning 'education' in Korean
-language), 'Âñ¦ð' (meaning 'government' in Korean language), '\98 ª' (meaning
-'international' in Korean language), '\98¦À\8b' (meaning 'military' in Korean
-language), 'þÚË«' (meaning 'network' in Korean language), and '³\9bÈ' (meaning
-'organization' in Korean language), respectively, which can be used as the
-corresponding generic codes of virtual domain names in Korean scripts.
-
-VIDN does not create such complexities as other conversion methods based upon
-semantics do, since it uses phonemes as a medium of transliteration between
-local and English scripts. Further, most languages have a small number of
-phonemes. For example, Korean language has nineteen consonant phonemes and
-twenty-one vowel phonemes, and English language has twenty-four consonant
-phonemes and twenty vowel phonemes. Each phoneme of Korean language can be
-matched with a phoneme of English language that has the same or proximate sound,
-and vice versa.
-
-Some characters or sets of characters may represent more than one phoneme. Some
-phonemes may be represented by more than one character or set of characters.
-Also, not every character or set of characters in local scripts may be neatly
-transliterated into only one character or set of characters in English scripts.
-In practice, people often transliterate the same local scripts differently into
-English scripts or vice versa. VIDN incorporates the provisions to deal with
-those variations that usually occur in particular situations as well as those
-variations that are caused by common usage or idiomatic expressions. More
-fundamentally, VIDN uses phonemes, which are very universal across different
-languages, as a medium of transliteration rather than following a certain set of
-transliteration rules that does not exist in many non-English-speaking countries
-nor is followed by many non-English-speaking people.
-
-One virtual domain name typed in local scripts may be converted into more than
-one possible domain name in English scripts. In such case, VIDN can search for
-and displays only those domain names in English scripts that are active on the
-Internet, so that the user can choose any of them. Further, VIDN can be used as
-a directory-search solution at an upper layer above the DNS. That is, the user
-can use VIDN to query a phoneme-based domain name request in local scripts,
-receive one or more corresponding domain names in English or ASCII-compatible
-scripts preferably, choose one based upon the results of that search, and make
-the final DNS request using any protocol or method to be chosen for
-internationalized domain names. In this regard of directory search, VIDN uses
-one-to-many map between virtual domain names in local scripts and actual domain
-names in English scripts.
-
-VIDN needs the one-to-many mapping and subsequent multiple DNS lookups only at
-the first query of each virtual domain name typed in local scripts at the user
-host. After the first query, the virtual domain name is set to the domain name
-in English scripts that has been chosen at the first query. Any subsequent
-queries with the same virtual domain name generate only one query with the
-selected domain name in English scripts. Once the use selects one possible
-domain name in English scripts from the list, VIDN remembers the user's
-selection and directs the user to the same domain name at his or her subsequent
-queries with that virtual domain name. In this way, VIDN can generate less
-traffic on the DNS, while providing faster, easier, and simpler navigation on
-the Internet to the user, using local scripts.
-
-Utilizing a coding scheme, VIDN is also capable of making each virtual domain
-name typed in local scripts correspond to exactly one actual domain name in
-English scripts. In this coding scheme, a unique code such as the Unicode or
-hexadecimal code represented by the virtual domain name, is pre-assigned to one
-of the corresponding domain names in English scripts and stored in the
-respective server host, so that both the user host and the server host can
-support and understand the code. Then, VIDN checks whether the code at each
-server host matches with the code generated at the user host. If one of the
-servers stores the code that matches with the code generated at the user host,
-the virtual domain name typed at the user host is recognized as corresponding
-only to the domain name of that server host, and the user host is connected to
-the server host. The domain names of the remaining server hosts that do not have
-the matching code are also displayed at the user host as alternative sites.
-
-Because a unique code is assigned to only one of the domain names in English
-scripts, it does not cause any domain name squatting problem beyond what we
-experience with current domain names in English scripts. Unique codes do not
-need to be stored in any specific format, that is, they can be embedded in HTML,
-XML, WML, and so on, so that the user host can interpret the retrieved code
-correctly. Likewise, unique codes do not require any specific intermediate
-transport protocol such as TCP/IP. The only requirement is that the protocol
-must be understood among all participating user hosts and server hosts. For
-security purpose, this coding scheme may use an encryption technique.
-
-For example, 'Â\9e¾Ô.ýý', a virtual domain name typed in Korean scripts, may
-result in four corresponding domain names in English scripts, including
-'jungang.com', 'joongang.com,' 'chungang.com', and 'choongang.com', since the
-phonemes represented by characters consisting of 'Â\9e¾Ô.ýý' in Korean scripts can
-have the same or almost the same sounds as the phonemes represented by
-characters consisting of 'jungang.com', 'joongang.com,' 'chungang.com', or
-'choongang.com' in English scripts. In this case, we assume that the server host
-with its domain name 'jungang.com' has the pre-assigned code that matches with
-the code generated when 'Â\9e¾Ô.ýý' in Korean scripts is entered in user
-applications. Then, the user host is connected to this server host, and the
-other server hosts may be listed to the user as alternative sites so that the
-user can try them.
-
-The process of this coding scheme that makes each virtual domain name in local
-scripts correspond to only one actual domain name in English scripts, can be
-depicted as:
-
- +---------------------------------+
- | User |
- +---------------------------------+
- | |
- +----------------|-----------------------|------------------+
- | v v |
- | +---------------------+ +-----------------------+ |
- | | Virtual domain name | | Potential domain names| |
- | | in a local language |---->| in English | |
- | | e.g., 'Â\9e¾Ô.ýý' | | e.g., 'jungang.com' | |
- | | (code: 297437)| | 'joongang.com' | |
- | | | | 'chungang.com' | |
- | | | | 'choongang.com' | |
- | +---------------------+ +-----------------------+ |
- | User application | |
- +----------------------------------------|------------------+
- ^ |
- | | Code check by VIDN
- Connection to | | +-- 'jungang.com'
- the server host | | | (code: 297437)
- 'jungang.com' | | |-- 'joongang.com'
- | |----+ (not active)
- | | |-- 'chungang.com'
- | | | (code: 381274)
- | DNS request and | +-- 'choongang.com'
- | response | (not active)
- +-----------------------+
-
-Since VIDN converts separately the entity-defined portions and the coded
-portions of a virtual domain name, it preserves the current syntax of domain
-names, that is, the hierarchical dotted notation, which Internet users are
-familiar with. Also, VIDN allows using a virtual domain name mixed with local
-and English scripts as the user wishes to, since the conversion takes place on
-each individual portion of the domain name and each individual character or set
-of characters of the portion.
-
-While VIDN preserves the hierarchical dotted notation of current domain names,
-the principles of VIDN are applicable to domain names in other possible
-notations such as those in a natural language (e.g., 'microsoft windows' rather
-than 'windows.microsoft.com'). Also, the principles of VIDN can be applied into
-other identifiers used on the Internet, such as user IDs of e-mail addresses,
-names of directories and folders, names of web pages and files, keywords used in
-search engines and directory services, and so on, allowing them to be used
-interchangeably in local and English scripts, without creating additional
-identifiers in local scripts. The conversion of VIDN can be done between any two
-sets of scripts interchangeably. Thus, even when the DNS accepts and registers
-domain names in other local scripts in addition to English, VIDN can allow using
-the same domain names in any two sets of scripts by converting virtual domain
-names in one set of scripts into actual domain names in another set of scripts.
-
-4.3. Development and implementation
-
-In a preferred arrangement, the development of VIDN for each set of local
-scripts may be administered by one or more local standard bodies in regions
-where the local scripts are widely used, for example, Korean Network Information
-Center for Korean scripts, Japan Network Information Center for Japanese scripts,
-and China, Hong Kong and Taiwan Network Information Centers for Chinese scripts,
-with consultation with experts on phonemics and linguistics of the respective
-local language and English language. Also, the unique codes for one-to-one
-mapping between virtual domain names in local scripts and actual domain names in
-English scripts can be administered by a central standard body like IANA.
-Alternatively, the unique codes for each set of local scripts may be
-administered by one or more local standard bodies in regions where the local
-scripts are widely used, as with the development of VIDN.
-
-VIDN is implemented in applications at the user host. That is, the conversion of
-virtual domain names in local scripts into the corresponding actual domain names
-in English scripts takes place at the user host before DNS requests are sent.
-Thus, neither a special encoding nor a separate lookup service is needed to
-implement VIDN. VIDN is also modularized with each module being used for
-conversion of virtual domain names in one set of local scripts into the
-corresponding actual domain names in English scripts. A user needs only the
-module for conversion of his or her preferred set of local scripts into English
-scripts. Alternatively, VIDN can be implemented at a central server host or a
-cluster of local server hosts. A central server can provide the conversion
-service for all sets of local scripts, or a cluster of local server hosts can
-share the conversion service. In the latter case, each local server host can
-provide the conversion service for one or more sets of local scripts used in a
-certain region.
-
-Because of its small size, VIDN can be easily embedded into applications
-software such as web browser, e-mail software, ftp system, and so on at the user
-host, or it can work as an add-on program to such software. In either case, the
-only requirement on the part of the user is to install VIDN or software
-embedding VIDN at the user host. Using virtual domain names in local scripts in
-accordance with the principles of VIDN is very intuitive to those who use the
-local scripts. The only requirement on the part of the entity whose server host
-provides Internet services to user hosts is to have an actual domain name in
-English scripts into which virtual domain names in local scripts are neatly
-transliterated in accordance with the principles of VIDN. Most entities in
-regions where English scripts are not widely used already have such domain names
-in English scripts. Finally, there is nothing to change on the part of the DNS,
-since VIDN uses the current DNS as it is.
-
-Taken together, the features of VIDN can meet all the requirement of
-internationalized domain names as described in Wenzel and Seng [2], with respect
-to compatibility and interoperability, internationalization, canonicalization,
-and operating issues. Given the fact that different methods toward
-internationalized domain names confuse users, as already observed in some
-regions where some of these methods have already been commercialized, e.g.,
-Korea, Japan and China, it is important to find and implement the most effective
-solution to internationalized domain names as soon as possible.
-
-4.4. Current status
-
-VIDN has been developed for Korean-English conversion as a web browser add-on
-program. The program contains all the features described in this document and is
-capable of listing all the domain names in English scripts that correspond to a
-virtual domain name typed in Korean scripts so that a user can choose any of
-them. The program can cover more than ninety percent of the sample. That is, the
-results of testing indicate that more than ninety percent of web sites in Korea
-can be accessed using virtual domain names in Korean scripts without creating
-additional domain names in Korean scripts. The remaining ten percent of domain
-names are mostly those that contain acronyms, abbreviations or initials. With
-improvement of its knowledge of transliteration, the program is expected to
-cover more domain names used in Korea.
-
-5. Security considerations
-
-Because VIDN uses the DNS as it is, it inherits the same security considerations
-as the DNS.
-
-6. Intellectual property considerations
-
-It is the intention of DualName, Inc. to submit the VIDN method and other
-elements of VIDN software to IETF for review, comment or standardization.
-
-DualName has applied for one or more patents on the technology related to
-virtual domain name software and virtual email software. If a standard is
-adopted by IETF and any patents are issued to DualName with claims that are
-necessary for practicing the standard, DualName is prepared to make available,
-upon written request, a non-exclusive license under fair, reasonable and non-
-discriminatory terms and condition, based on the principle of reciprocity,
-consistent with established practice.
-
-
-7. References
-
-1 Wenzel, Z. and Seng, J. (Editors), "Requirements of Internationalized Domain
-Names," draft-ietf-idn-requirements-03.txt, August 2000
-
-
-8. Author's address
-
-Sung Jae Shim
-DualName, Inc.
-3600 Wilshire Boulevard, Suite 1814
-Los Angeles, California 90010
-USA
-Email: shimsungjae@dualname.com
-
+++ /dev/null
-
-IPng Working Group Matt Crawford
-Internet Draft Fermilab
- Christian Huitema
- Susan Thomson
- Telcordia
- May 17, 2000
-
- DNS Extensions to Support IPv6 Address Aggregation and Renumbering
- <draft-ietf-ipngwg-dns-lookups-08.txt>
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. Internet-Drafts are
- working documents of the Internet Engineering Task Force (IETF), its
- areas, and its working groups. Note that other groups may also
- distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet- Drafts as
- reference material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-1. Abstract
-
- This document defines changes to the Domain Name System to support
- renumberable and aggregatable IPv6 addressing. The changes include
- a new resource record type to store an IPv6 address in a manner
- which expedites network renumbering and updated definitions of
- existing query types that return Internet addresses as part of
- additional section processing.
-
- For lookups keyed on IPv6 addresses (often called reverse lookups),
- this document defines a new zone structure which allows a zone to be
- used without modification for parallel copies of an address space
- (as for a multihomed provider or site) and across network
- renumbering events.
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 1]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-Status of this Memo ............................................... 1
-
-1. Abstract ...................................................... 1
-
-2. Introduction .................................................. 3
-
-3. Overview ...................................................... 4
- 3.1. Name-to-Address Lookup .................................. 4
- 3.2. Underlying Mechanisms for Reverse Lookups ............... 4
- 3.2.1. Delegation on Arbitrary Boundaries ................ 4
- 3.2.2. Reusable Zones .................................... 5
-
-4. Specifications ................................................ 6
- 4.1. The A6 Record Type ...................................... 6
- 4.1.1. Format ............................................ 6
- 4.1.2. Processing ........................................ 6
- 4.1.3. Textual Representation ............................ 7
- 4.1.4. Name Resolution Procedure ......................... 7
- 4.2. Zone Structure for Reverse Lookups ...................... 8
-
-5. Modifications to Existing Query Types ......................... 8
-
-6. Usage Illustrations ........................................... 9
- 6.1. A6 Record Chains ........................................ 9
- 6.1.1. Authoritative Data ................................ 10
- 6.1.2. Glue .............................................. 10
- 6.1.3. Variations ........................................ 12
- 6.2. Reverse Mapping Zones ................................... 13
- 6.2.1. The TLA level ..................................... 13
- 6.2.2. The ISP level ..................................... 14
- 6.2.3. The Site Level .................................... 14
- 6.3. Lookups ................................................. 14
- 6.4. Operational Note ........................................ 15
-
-7. Transition from RFC 1886 and Deployment Notes ................. 16
- 7.1. Transition from AAAA and Coexistence with A Records ..... 17
- 7.2. Transition from Nibble Labels to Binary Labels .......... 17
-
-8. Security Considerations ....................................... 18
-
-9. IANA Considerations ........................................... 18
-
-10. Acknowledgments .............................................. 18
-
-11. References ................................................... 19
-
-12. Authors' Addresses ........................................... 20
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 2]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-2. Introduction
-
- Maintenance of address information in the DNS is one of several
- obstacles which have prevented site and provider renumbering from
- being feasible in IP version 4. Arguments about the importance of
- network renumbering for the preservation of a stable routing system
- and for other purposes may be read in documents cited here as
- [RENUM]. To support the storage of IPv6 addresses without impeding
- renumbering we define the following extensions.
-
- o A new resource record type, "A6", is defined to map a domain
- name to an IPv6 address, with a provision for indirection for
- leading "prefix" bits.
-
- o Existing queries that perform additional section processing to
- locate IPv4 addresses are redefined to do that processing for
- both IPv4 and IPv6 addresses.
-
- o A new domain, IP6.ARPA, is defined to support lookups based on
- IPv6 address.
-
- o A new prefix-delegation method is defined, relying on new DNS
- features [BITLBL, DNAME].
-
- The changes are designed to be compatible with existing application
- programming interfaces. The existing support for IPv4 addresses is
- retained. Transition issues related to the coexistence of both IPv4
- and IPv6 addresses in DNS are discussed in [TRANS].
-
- This memo proposes a replacement for the specification in RFC 1886
- and a departure from current implementation practices. The changes
- are designed to facilitate network renumbering and multihoming.
- Domains employing the A6 record for IPv6 addresses can insert
- automatically-generated AAAA records in zone files to ease
- transition. It is expected that after a reasonable period, RFC 1886
- will become Historic.
-
- The next three major sections of this document are an overview of
- the facilities defined or employed by this specification, the
- specification itself, and examples of use.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [KWORD]. The key
- word "SUGGESTED" signifies a strength between MAY and SHOULD: it is
- believed that compliance with the suggestion has tangible benefits
- in most instances.
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 3]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-3. Overview
-
- This section provides an overview of the DNS facilities for storage
- of IPv6 addresses and for lookups based on IPv6 address, including
- those defined here and elsewhere.
-
-
-3.1. Name-to-Address Lookup
-
- IPv6 addresses are stored in one or more A6 resource records. A
- single A6 record may include a complete IPv6 address, or a
- contiguous portion of an address and information leading to one or
- more prefixes. Prefix information comprises a prefix length and a
- DNS name which is in turn the owner of one or more A6 records
- defining the prefix or prefixes which are needed to form one or more
- complete IPv6 addresses. When the prefix length is zero, no DNS
- name is present and all the leading bits of the address are
- significant. There may be multiples levels of indirection and the
- existence of multiple A6 records at any level multiplies the number
- of IPv6 addresses which are formed.
-
- An application looking up an IPv6 address will generally cause the
- DNS resolver to access several A6 records, and multiple IPv6
- addresses may be returned even if the queried name was the owner of
- only one A6 record. The authenticity of the returned address(es)
- cannot be directly verified by DNS Security [DNSSEC]. The A6
- records which contributed to the address(es) may of course be
- verified if signed.
-
- Implementers are reminded of the necessity to limit the amount of
- work a resolver will perform in response to a client request. This
- principle MUST be extended to also limit the generation of DNS
- requests in response to one name-to-address (or address-to-name)
- lookup request.
-
-
-3.2. Underlying Mechanisms for Reverse Lookups
-
- This section describes the new DNS features which this document
- exploits. This section is an overview, not a specification of those
- features. The reader is directed to the referenced documents for
- more details on each.
-
-
-3.2.1. Delegation on Arbitrary Boundaries
-
- This new scheme for reverse lookups relies on a new type of DNS
- label called the "bit-string label" [BITLBL]. This label compactly
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 4]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- represents an arbitrary string of bits which is treated as a
- hierarchical sequence of one-bit domain labels. Resource records
- can thereby be stored at arbitrary bit-boundaries.
-
- Examples in section 6 will employ the following textual
- representation for bit-string labels, which is a subset of the
- syntax defined in [BITLBL]. A base indicator "x" for hexadecimal
- and a sequence of hexadecimal digits is enclosed between "\[" and
- "]". The bits denoted by the digits represent a sequence of one-bit
- domain labels ordered from most to least significant. (This is the
- opposite of the order they would appear if listed one bit at a time,
- but it appears to be a convenient notation.) The digit string may
- be followed by a slash ("/") and a decimal count. If omitted, the
- implicit count is equal to four times the number of hexadecimal
- digits.
-
- Consecutive bit-string labels are equivalent (up to the limit
- imposed by the size of the bit count field) to a single bit-string
- label containing all the bits of the consecutive labels in the
- proper order. As an example, either of the following domain names
- could be used in a QCLASS=IN, QTYPE=PTR query to find the name of
- the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
-
- \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
-
- \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
-
-
-
-3.2.2. Reusable Zones
-
- DNS address space delegation is implemented not by zone cuts and NS
- records, but by a new analogue to the CNAME record, called the DNAME
- resource record [DNAME]. The DNAME record provides alternate naming
- to an entire subtree of the domain name space, rather than to a
- single node. It causes some suffix of a queried name to be
- substituted with a name from the DNAME record's RDATA.
-
- For example, a resolver or server providing recursion, while looking
- up a QNAME a.b.c.d.e.f may encounter a DNAME record
-
- d.e.f. DNAME w.xy.
-
- which will cause it to look for a.b.c.w.xy.
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 5]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-4. Specifications
-
-
-4.1. The A6 Record Type
-
- The A6 record type is specific to the IN (Internet) class and has
- type number 38 (decimal).
-
-
-4.1.1. Format
-
- The RDATA portion of the A6 record contains two or three fields.
-
- +-----------+------------------+-------------------+
- |Prefix len.| Address suffix | Prefix name |
- | (1 octet) | (0..16 octets) | (0..255 octets) |
- +-----------+------------------+-------------------+
-
-
- o A prefix length, encoded as an eight-bit unsigned integer with
- value between 0 and 128 inclusive.
-
- o An IPv6 address suffix, encoded in network order (high-order
- octet first). There MUST be exactly enough octets in this field
- to contain a number of bits equal to 128 minus prefix length,
- with 0 to 7 leading pad bits to make this field an integral
- number of octets. Pad bits, if present, MUST be set to zero
- when loading a zone file and ignored (other than for SIG
- [DNSSEC] verification) on reception.
-
- o The name of the prefix, encoded as a domain name. By the rules
- of [DNSIS], this name MUST NOT be compressed.
-
- The domain name component SHALL NOT be present if the prefix length
- is zero. The address suffix component SHALL NOT be present if the
- prefix length is 128.
-
- It is SUGGESTED that an A6 record intended for use as a prefix for
- other A6 records have all the insignificant trailing bits in its
- address suffix field set to zero.
-
-
-4.1.2. Processing
-
- A query with QTYPE=A6 causes type A6 and type NS additional section
- processing for the prefix names, if any, in the RDATA field of the
- A6 records in the answer section. This processing SHOULD be
- recursively applied to the prefix names of A6 records included as
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 6]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- additional data. When space in the reply packet is a limit,
- inclusion of additional A6 records takes priority over NS records.
-
- It is an error for a A6 record with prefix length L1 > 0 to refer to
- a domain name which owns a A6 record with a prefix length L2 > L1.
- If such a situation is encountered by a resolver, the A6 record with
- the offending (larger) prefix length MUST be ignored. Robustness
- precludes signaling an error if addresses can still be formed from
- valid A6 records, but it is SUGGESTED that zone maintainers from
- time to time check all the A6 records their zones reference.
-
-
-4.1.3. Textual Representation
-
- The textual representation of the RDATA portion of the A6 resource
- record in a zone file comprises two or three fields separated by
- whitespace.
-
- o A prefix length, represented as a decimal number between 0 and
- 128 inclusive,
-
- o the textual representation of an IPv6 address as defined in
- [AARCH] (although some leading and/or trailing bits may not be
- significant),
-
- o a domain name, if the prefix length is not zero.
-
- The domain name MUST be absent if the prefix length is zero. The
- IPv6 address MAY be be absent if the prefix length is 128. A number
- of leading address bits equal to the prefix length SHOULD be zero,
- either implicitly (through the :: notation) or explicitly, as
- specified in section 4.1.1.
-
-
-4.1.4. Name Resolution Procedure
-
- To obtain the IPv6 address or addresses which belong to a given
- name, a DNS client MUST obtain one or more complete chains of A6
- records, each chain beginning with a record owned by the given name
- and including a record owned by the prefix name in that record, and
- so on recursively, ending with an A6 record with a prefix length of
- zero. One IPv6 address is formed from one such chain by taking the
- value of each bit position from the earliest A6 record in the chain
- which validly covers that position, as indicated by the prefix
- length. The set of all IPv6 addresses for the given name comprises
- the addresses formed from all complete chains of A6 records
- beginning at that name, discarding records which have invalid prefix
- lengths as defined in section 4.1.2.
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 7]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- If some A6 queries fail and others succeed, a client might obtain a
- non-empty but incomplete set of IPv6 addresses for a host. In many
- situations this may be acceptable. The completeness of a set of A6
- records may always be determined by inspection.
-
-
-4.2. Zone Structure for Reverse Lookups
-
- Very little of the new scheme's data actually appears under
- IP6.ARPA; only the first level of delegation needs to be under that
- domain. More levels of delegation could be placed under IP6.ARPA if
- some top-level delegations were done via NS records instead of DNAME
- records, but this would incur some cost in renumbering ease at the
- level of TLAs [AGGR]. Therefore, it is declared here that all
- address space delegations SHOULD be done by the DNAME mechanism
- rather than NS.
-
- In addition, since uniformity in deployment will simplify
- maintenance of address delegations, it is SUGGESTED that address and
- prefix information be stored immediately below a DNS label "IP6".
- Stated another way, conformance with this suggestion would mean that
- "IP6" is the first label in the RDATA field of DNAME records which
- support IPv6 reverse lookups.
-
- When any "reserved" or "must be zero" bits are adjacent to a
- delegation boundary, the higher-level entity MUST retain those bits
- in its own control and delegate only the bits over which the lower-
- level entity has authority.
-
- To find the name of a node given its IPv6 address, a DNS client MUST
- perform a query with QCLASS=IN, QTYPE=PTR on the name formed from
- the 128 bit address as one or more bit-string labels [BITLBL],
- followed by the two standard labels "IP6.ARPA". If recursive
- service was not obtained from a server and the desired PTR record
- was not returned, the resolver MUST handle returned DNAME records as
- specified in [DNAME], and NS records as specified in [DNSCF], and
- iterate.
-
-
-5. Modifications to Existing Query Types
-
- All existing query types that perform type A additional section
- processing, i.e. the name server (NS), mail exchange (MX), and
- mailbox (MB) query types, and the experimental AFS data base (AFSDB)
- and route through (RT) types, must be redefined to perform type A,
- A6 and AAAA additional section processing, with type A having the
- highest priority for inclusion and type AAAA the lowest. This
- redefinition means that a name server may add any relevant IPv4 and
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 8]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- IPv6 address information available locally to the additional section
- of a response when processing any one of the above queries. The
- recursive inclusion of A6 records referenced by A6 records already
- included in the additional section is OPTIONAL.
-
-
-6. Usage Illustrations
-
- This section provides examples of use of the mechanisms defined in
- the previous section. All addresses and domains mentioned here are
- intended to be fictitious and for illustrative purposes only.
- Example delegations will be on 4-bit boundaries solely for
- readability; this specification is indifferent to bit alignment.
-
- Use of the IPv6 aggregatable address format [AGGR] is assumed in the
- examples.
-
-
-6.1. A6 Record Chains
-
- Let's take the example of a site X that is multi-homed to two
- "intermediate" providers A and B. The provider A is itself multi-
- homed to two "transit" providers, C and D. The provider B gets its
- transit service from a single provider, E. For simplicity suppose
- that C, D and E all belong to the same top-level aggregate (TLA)
- with identifier (including format prefix) '2345', and the TLA
- authority at ALPHA-TLA.ORG assigns to C, D and E respectively the
- next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28
- and 2345:000E::/32.
-
- C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
- prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
- B.
-
- A assigns to X the subscriber identification '11' and B assigns the
- subscriber identification '22'. As a result, the site X inherits
- three address prefixes:
-
- o 2345:00C1:CA11::/48 from A, for routes through C.
- o 2345:00D2:DA11::/48 from A, for routes through D.
- o 2345:000E:EB22::/48 from B, for routes through E.
-
- Let us suppose that N is a node in the site X, that it is assigned
- to subnet number 1 in this site, and that it uses the interface
- identifier '1234:5678:9ABC:DEF0'. In our configuration, this node
- will have three addresses:
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 9]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-
- o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
- o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
- o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-
-6.1.1. Authoritative Data
-
- We will assume that the site X is represented in the DNS by the
- domain name X.EXAMPLE, while A, B, C, D and E are represented by
- A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we
- assume a subdomain "IP6" that will hold the corresponding prefixes.
- The node N is identified by the domain name N.X.EXAMPLE. The
- following records would then appear in X's DNS.
-
- $ORIGIN X.EXAMPLE.
- N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
- SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
-
- And elsewhere there would appear
-
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
-
- SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
-
- A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
-
- A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
-
- B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
-
- C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
- D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
- E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
-
-
-6.1.2. Glue
-
- When, as is common, some or all DNS servers for X.EXAMPLE are within
- the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
- enough "glue" information to enable DNS clients to reach those
- nameservers. This is true in IPv6 just as in IPv4. However, the A6
- record affords the DNS administrator some choices. The glue could
- be any of
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 10]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
-
- o a (possibly smaller) set of records which collapse the structure
- of that minimal set,
-
- o or a set of A6 records with prefix length zero, giving the
- entire global addresses of the servers.
-
- The trade-off is ease of maintenance against robustness. The best
- and worst of both may be had together by implementing either the
- first or second option together with the third. To illustrate the
- glue options, suppose that X.EXAMPLE is served by two nameservers
- NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
- ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
- Then the top-level zone EXAMPLE would include one (or more) of the
- following sets of A6 records as glue.
-
- $ORIGIN EXAMPLE. ; first option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
- NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
- SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
- SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
- IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
-
-
- $ORIGIN EXAMPLE. ; second option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
- A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
- NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
- A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
-
-
- $ORIGIN EXAMPLE. ; third option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
- A6 0 2345:00D2:DA11:1:1:11:111:1111
- A6 0 2345:000E:EB22:1:1:11:111:1111
- NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
- A6 0 2345:00D2:DA11:2:2:22:222:2222
- A6 0 2345:000E:EB22:2:2:22:222:2222
-
- The first and second glue options are robust against renumbering of
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 11]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
- those providers' own DNS is unreachable. The glue records of the
- third option are robust against DNS failures elsewhere than the
- zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
- address space is renumbered.
-
- If the EXAMPLE zone includes redundant glue, for instance the union
- of the A6 records of the first and third options, then under normal
- circumstances duplicate IPv6 addresses will be derived by DNS
- clients. But if provider DNS fails, addresses will still be
- obtained from the zero-prefix-length records, while if the EXAMPLE
- zone lags behind a renumbering of X.EXAMPLE, half of the addresses
- obtained by DNS clients will still be up-to-date.
-
- The zero-prefix-length glue records can of course be automatically
- generated and/or checked in practice.
-
-6.1.3. Variations
-
- Several more-or-less arbitrary assumptions are reflected in the
- above structure. All of the following choices could have been made
- differently, according to someone's notion of convenience or an
- agreement between two parties.
-
- First, that site X has chosen to put subnet information in a
- separate A6 record rather than incorporate it into each node's
- A6 records.
-
- Second, that site X is referred to as "SUBSCRIBER-X" by both of
- its providers A and B.
-
- Third, that site X chose to indirect its provider information
- through A6 records at IP6.X.EXAMPLE containing no significant
- bits. An alternative would have been to replicate each subnet
- record for each provider.
-
- Fourth, B and E used a slightly different prefix naming
- convention between themselves than did A, C and D. Each
- hierarchical pair of network entities must arrange this naming
- between themselves.
-
- Fifth, that the upward prefix referral chain topped out at
- ALPHA-TLA.ORG. There could have been another level which
- assigned the TLA values and holds A6 records containing those
- bits.
-
- Finally, the above structure reflects an assumption that address
- fields assigned by a given entity are recorded only in A6 records
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 12]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- held by that entity. Those bits could be entered into A6 records in
- the lower-level entity's zone instead, thus:
-
- IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
- IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
-
- IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
- and so on.
-
-
- Or the higher-level entities could hold both sorts of A6 records
- (with different DNS owner names) and allow the lower-level entities
- to choose either mode of A6 chaining. But the general principle of
- avoiding data duplication suggests that the proper place to store
- assigned values is with the entity that assigned them.
-
- It is possible, but not necessarily recommended, for a zone
- maintainer to forego the renumbering support afforded by the
- chaining of A6 records and to record entire IPv6 addresses within
- one zone file.
-
-
-6.2. Reverse Mapping Zones
-
- Supposing that address space assignments in the TLAs with Format
- Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
- zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
- the IP6.ARPA zone would include
-
- $ORIGIN IP6.ARPA.
- \[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
- \[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
- \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
-
- Eight trailing zero bits have been included in each TLA ID to
- reflect the eight reserved bits in the current aggregatable global
- unicast addresses format [AGGR].
-
-
-6.2.1. The TLA level
-
- ALPHA-TLA's assignments to network providers C, D and E are
- reflected in the reverse data as follows.
-
- \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
- \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
- \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 13]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-6.2.2. The ISP level
-
- The providers A through E carry the following delegation information
- in their zone files.
-
- \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
- \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
- \[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
- \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
- \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
-
- Note that some domain names appear in the RDATA of more than one
- DNAME record. In those cases, one zone is being used to map
- multiple prefixes.
-
-
-6.2.3. The Site Level
-
- Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
- name translations. This domain is now referenced by two different
- DNAME records held by two different providers.
-
- $ORIGIN IP6.X.EXAMPLE.
- \[x0001/16] DNAME SUBNET-1
- \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
- and so on.
-
- SUBNET-1 need not have been named in a DNAME record; the subnet bits
- could have been joined with the interface identifier. But if
- subnets are treated alike in both the A6 records and in the reverse
- zone, it will always be possible to keep the forward and reverse
- definition data for each prefix in one zone.
-
-
-6.3. Lookups
-
- A DNS resolver looking for a hostname for the address
- 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
- DNAME records shown above and would form new queries. Assuming that
- it began the process knowing servers for IP6.ARPA, but that no
- server it consulted provided recursion and none had other useful
- additional information cached, the sequence of queried names and
- responses would be (all with QCLASS=IN, QTYPE=PTR):
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 14]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-
- To a server for IP6.ARPA:
- QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
-
- Answer:
- \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
-
- To a server for IP6.ALPHA-TLA.ORG:
- QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
-
- Answer:
- \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
-
- To a server for IP6.C.NET.:
- QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
-
- Answer:
- \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
-
- To a server for IP6.A.NET.:
- QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
-
- Answer:
- \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
-
- To a server for IP6.X.EXAMPLE.:
- QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
-
- Answer:
- \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
- \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
-
- All the DNAME (and NS) records acquired along the way can be cached
- to expedite resolution of addresses topologically near to this
- address. And if another global address of N.X.EXAMPLE were resolved
- within the TTL of the final PTR record, that record would not have
- to be fetched again.
-
-
-6.4. Operational Note
-
- In the illustrations in section 6.1, hierarchically adjacent
- entities, such as a network provider and a customer, must agree on a
- DNS name which will own the definition of the delegated prefix(es).
- One simple convention would be to use a bit-string label
- representing exactly the bits which are assigned to the lower-level
- entity by the higher. For example, "SUBSCRIBER-X" could be replaced
- by "\[x11/8]". This would place the A6 record(s) defining the
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 15]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- delegated prefix at exactly the same point in the DNS tree as the
- DNAME record associated with that delegation. The cost of this
- simplification is that the lower-level zone must update its upward-
- pointing A6 records when it is renumbered. This cost may be found
- quite acceptable in practice.
-
-
-7. Transition from RFC 1886 and Deployment Notes
-
- When prefixes have been "delegated upward" with A6 records, the
- number of DNS resource records required to establish a single IPv6
- address increases by some non-trivial factor. Those records will
- typically, but not necessarily, come from different DNS zones (which
- can independently suffer failures for all the usual reasons). When
- obtaining multiple IPv6 addresses together, this increase in RR
- count will be proportionally less -- and the total size of a DNS
- reply might even decrease -- if the addresses are topologically
- clustered. But the records could still easily exceed the space
- available in a UDP response which returns a large RRset [DNSCLAR] to
- an MX, NS, or SRV query, for example. The possibilities for overall
- degradation of performance and reliability of DNS lookups are
- numerous, and increase with the number of prefix delegations
- involved, especially when those delegations point to records in
- other zones.
-
- DNS Security [DNSSEC] addresses the trustworthiness of cached data,
- which is a problem intrinsic to DNS, but the cost of applying this
- to an IPv6 address is multiplied by a factor which may be greater
- than the number of prefix delegations involved if different
- signature chains must be verified for different A6 records. If a
- trusted centralized caching server (as in [TSIG], for example) is
- used, this cost might be amortized to acceptable levels. One new
- phenomenon is the possibility that IPv6 addresses may be formed from
- a A6 records from a combination of secure and unsecured zones.
-
- Until more deployment experience is gained with the A6 record, it is
- recommended that prefix delegations be limited to one or two levels.
- A reasonable phasing-in mechanism would be to start with no prefix
- delegations (all A6 records having prefix length 0) and then to move
- to the use of a single level of delegation within a single zone.
- (If the TTL of the "prefix" A6 records is kept to an appropriate
- duration the capability for rapid renumbering is not lost.) More
- aggressively flexible delegation could be introduced for a subset of
- hosts for experimentation.
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 16]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-7.1. Transition from AAAA and Coexistence with A Records
-
- Administrators of zones which contain A6 records can easily
- accommodate deployed resolvers which understand AAAA records but not
- A6 records. Such administrators can do automatic generation of AAAA
- records for all of a zone's names which own A6 records by a process
- which mimics the resolution of a hostname to an IPv6 address (see
- section 4.1.4). Attention must be paid to the TTL assigned to a
- generated AAAA record, which MUST be no more than the minimum of the
- TTLs of the A6 records that were used to form the IPv6 address in
- that record. For full robustness, those A6 records which were in
- different zones should be monitored for changes (in TTL or RDATA)
- even when there are no changes to zone for which AAAA records are
- being generated. If the zone is secure [DNSSEC], the generated AAAA
- records MUST be signed along with the rest of the zone data.
-
- A zone-specific heuristic MAY be used to avoid generation of AAAA
- records for A6 records which record prefixes, although such
- superfluous records would be relatively few in number and harmless.
- Examples of such heuristics include omitting A6 records with a
- prefix length less than the largest value found in the zone file, or
- records with an address suffix field with a certain number of
- trailing zero bits.
-
- On the client side, when looking up and IPv6 address, the order of
- A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA;
- AAAA, then A6; A6 only; or both in parallel. The default order (or
- only order, if not configurable) MUST be to try A6 first, then AAAA.
- If and when the AAAA becomes deprecated a new document will change
- the default.
-
- The guidelines and options for precedence between IPv4 and IPv6
- addresses are specified in [TRANS]. All mentions of AAAA records in
- that document are henceforth to be interpreted as meaning A6 and/or
- AAAA records in the order specified in the previous paragraph.
-
-
-7.2. Transition from Nibble Labels to Binary Labels
-
- Implementations conforming to RFC 1886 perform reverse lookups as
- follows:
-
- An IPv6 address is represented as a name in the IP6.INT domain
- by a sequence of nibbles separated by dots with the suffix
- ".IP6.INT". The sequence of nibbles is encoded in reverse order,
- i.e. the low-order nibble is encoded first, followed by the next
- low-order nibble and so on. Each nibble is represented by a
- hexadecimal digit. For example, a name for the address
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 17]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in
- section 6.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
- 8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
-
- Implementations conforming to this specification will perform a
- lookup of a binary label in IP6.ARPA as specified in Section 3.2.
- It is RECOMMENDED that for a transition period implementations first
- lookup the binary label in IP6.ARPA and if this fails try to lookup
- the 'nibble' label in IP6.INT.
-
-
-8. Security Considerations
-
- The signing authority [DNSSEC] for the A6 records which determine an
- IPv6 address is distributed among several entities, reflecting the
- delegation path of the address space which that address occupies.
- DNS Security is fully applicable to bit-string labels and DNAME
- records. And just as in IPv4, verification of name-to-address
- mappings is logically independent of verification of address-to-name
- mappings.
-
- With or without DNSSEC, the incomplete but non-empty address set
- scenario of section 4.1.4 could be caused by selective interference
- with DNS lookups. If in some situation this would be more harmful
- than complete DNS failure, it might be mitigated on the client side
- by refusing to act on an incomplete set, or on the server side by
- listing all addresses in A6 records with prefix length 0.
-
-
-9. IANA Considerations
-
- The A6 resource record has been assigned a Type value of 38.
-
-
-10. Acknowledgments
-
- The authors would like to thank the following persons for valuable
- discussions and reviews: Mark Andrews, Rob Austein, Jim Bound,
- Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis
- Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob
- Hinden, Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
- Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
-
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 18]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-11. References
-
-
- [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable
- Global Unicast Address Format". RFC 2374, July 1998.
-
- [BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
- RFC 2673, August 1999.
-
- [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
- August 1999.
-
- [DNSCLAR] Elz, R and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [DNSIS] Mockapetris, P. V., "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
- [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
- Security Extensions", RFC 2535, March 1999.
-
- [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels," RFC 2119.
-
- [RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
- 1900, February 1996.
-
- Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
- Why would I want it and what is it anyway?", RFC 2071, January
- 1997.
-
- Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
- Behaviour Today", RFC 2101, February 1997.
-
- [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
- IPv6 Hosts and Routers", RFC 1933, April 1996.
-
- [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
- Wellington, "Secret Key Transaction Authentication for DNS
-
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 19]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- (TSIG)", work in progress.
-
-12. Authors' Addresses
-
- Matt Crawford Christian Huitema Susan Thomson
- Fermilab Telcordia Telcordia
- MS 368 MCC 1J236B MCC 1C259B
- PO Box 500 445 South Street 445 South Street
- Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960
- USA USA USA
-
- +1 630 840-3461 +1 201 829-4266 +1 201 829-4514
- crawdad@fnal.gov huitema@research.telcordia.com
- set@research.telcordia.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 20]
-
+++ /dev/null
-INTERNET DRAFT Editors: James SENG
-draft-jseng-idn-admin-03.txt John C KLENSIN, Wendy RICKARD
-16 June 2003 Authors: K. KONISHI
-Expires December 2003 K. HUANG, H. QIAN, Y. KO
-
- Internationalized Domain Names Registration and Administration
- Guideline for Chinese, Japanese, and Korean
-
-Status of This Memo
-
-This document is an Internet Draft and is in full conformance
-with all provisions of Section 10 of RFC2026 except that the
-right to produce derivative works is not granted.
-
- 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 rendered obsolete by
- other documents at any time. It is inappropriate to use Internet
- Drafts as reference material or to cite them other than as
- "works in progress."
-
- The list of current Internet Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
-Achieving internationalized access to domain names raises many complex
-issues. These are associated not only with basic protocol design--such
-as how names are represented on the network, compared, and converted to
-appropriate forms--but also with issues and options for deployment,
-transition, registration, and administration.
-
-The IETF Internationalized Domain Name (IDN) Working Group focused its
-efforts on the development of a standards-track specification for access
-to domain names in a range of scripts that is broader in scope than the
-original ASCII. During its efforts, it became clear that the appearance
-of characters with similar appearances and/or interpretations created
-potential for confusion, as well as difficulties in deployment and
-transition, and that those issues could best be addressed
-administratively rather than through restrictions embedded in the
-protocols.
-
-This document is an effort of the Joint Engineering Team (JET), a group
-composed of members of CNNIC, TWNIC, KRNIC, and JPNIC as well as other
-individual experts. It offers guidelines for zone administrators --
-including but not limited to registry operators and registrars -- and
-information for all domain names holders on the administration of domain
-names that contain characters drawn from Chinese, Japanese, and Korean
-scripts. Other language groups are encouraged to develop their own
-guidelines as needed, based on these guidelines if that is helpful.
-
-Table of Contents
-
-1. Introduction
-
-2. Definitions, Context, and Notation
-2.1. Definitions and Context
-2.2. Notation for Ideographs and Other Non-ASCII CJK Characters
-
-3. Scope of the Administrative Guidelines
-3.1. Principles Underlying These Guidelines
-3.2. Registration of IDL
-3.2.1. Using the Language Variant Table
-3.2.2. IDL Package
-3.2.3. Procedure for Registering IDLs
-3.3. Deletion and Transfer of IDL and IDL Package
-3.4. Activation and Deactivation of IDL Variants
-3.4.1. Activation Algorithm
-3.4.2. Deactivation Algorithm
-3.5. Managing Changes in Language Associations
-3.6. Managing Changes to Language Variant Tables
-
-4. Examples of Guideline Use in Zones
-
-5. Syntax Description for the Language Variant Table
-5.1 ABNF Syntax
-5.2. Comments and Explanation of Syntax
-
-6. Security Considerations
-
-7. Index to Terminology
-
-8. Acknowledgments
-
-9. Authors’ Addresses
-
-10. Normative References
-
-11. Nonnormative References
-
-1. Introduction
-
-Domain names form the fundamental naming architecture of the Internet.
-Countless Internet protocols and applications rely on them, not just for
-stability and continuity, but also to avoid ambiguity. They were
-designed to be identifiers without any language context. However, as
-domain names have become visible to end users through Web URLs and
-e-mail addresses, the strings in domain-name labels are being
-increasingly interpreted as names, words, or phrases. It is likely that
-users will do the same with languages of differing character sets--such
-as Chinese, Japanese and Korean (CJK)--in which many words or concepts
-are represented using short sequences of characters.
-
-The introduction of what are called Internationalized Domain Names (IDN)
-amplifies both the difficulty of putting names into identifiers and the
-confusion that exists between scripts and languages. It also affects a
-number of Internet protocols and applications and creates additional
-layers of complexity in terms of technical administration and services.
-Given the added complications of using a much broader range of
-characters than the original small ASCII subset, precautions are
-necessary in the deployment of IDNs in order to minimize confusion and
-fraud.
-
-The IETF IDN Working Group [IDN-WG] addressed the problem of handling
-the encoding and decoding of Unicode strings into and out of Domain Name
-System (DNS) labels with the goal that its solution would not put the
-operational DNS at any risk. Its work resulted in one primary protocol
-and three supporting ones, respectively:
-
-1. Internationalizing Host Names in Applications [IDNA]
-2. Preparation of Internationalized Strings [STRINGPREP]
-3. A Stringprep Profile for Internationalized Domain Names [NAMEPREP]
-4. Punycode [PUNYCODE]
-
-IDNA--which calls on the others--normalizes and transforms strings that
-are intended to be used as IDNs. In combination, the four provide the
-minimum functions required for internationalization, such as performing
-case mappings, eliminating character differences that would cause severe
-problems, and specifying matching (equality). They also convert between
-the resulting Unicode code points and an ASCII-based form that is more
-suitable for storing in actual DNS labels. In this way, the IDNA
-transformations improve a user’s chances of getting to the correct IDN.
-
-Addressing the issues around differing character sets, a primary
-consideration and administrative challenge involves region-specific
-definitions, interpretations, and the semantics of strings to be used in
-IDNs. A Unicode string may have a specific meaning as a name, word, or
-phrase in a particular language but that meaning could vary depending on
-the country, region, culture, or other context in which the string is
-used. It might also have different interpretations in different
-languages that share some or all of the same characters. Therefore,
-individual zones and zone administrators may find it necessary to impose
-restrictions and procedures to reduce the likelihood of confusion--and
-instabilities of reference--within their own environments.
-
-Over the centuries, the evolution of CJK characters--and the differences
-in their use in different languages and even in different regions where
-the same language is spoken--has given rise to the idea of "variants",
-wherein one conceptual character can be identified with several
-different Code Points in character sets for computer use. This document
-provides a framework for handling such variants while minimizing the
-possibility of serious user confusion in the obtaining or use of domain
-names. However, the concept of variants is complex and may require many
-different layers of solution, this guideline offers only one of the
-solution components. It is not sufficient by itself to solve the whole
-problem, even with zone-specific tables as described below.
-
-Additionally, because of local language or writing-system differences,
-it is impossible to create universally accepted definitions for which
-potential variants are the same and which are not the same. It is even
-more difficult to define a technical algorithm to generate variants that
-are linguistically accurate--that is, that the variant forms produced
-make as much sense in the language as the originally specified forms.
-It is also possible that variants generated may have no meaning in the
-associated language or languages. The intention is not to generate
-meaningful "words" but to generate similar variants to be reserved. So
-even though the method described in this document may not always be
-linguistically accurate--or need to be--it increases the chances of
-getting the right variants while accepting the inherent limitations of
-the DNS and the complexities of human language.
-
-This document outlines a model for such conventions for zones in which
-labels that contain CJK characters are to be registered and a system for
-implementing that model. It provides a mechanism that allows each zone
-to define its own local rules for permitted characters and sequences and
-the handling of IDNs and their variants.
-
-2. Definitions, Context, and Notation
-
-2.1. Definitions and Context
-
-This document uses a number of special terms. In this section,
-definitions and explanations are grouped topically. Some readers may
-prefer to skip over this material, returning, perhaps via the index to
-terminology in section 7, when needed.
-
-2.1.1. IDN: The term "IDN" has a number of different uses: (a) as an
-abbreviation for "Internationalized Domain Name"; (b) as a fully
-qualified domain name that contains at least one label that contains
-characters not appearing in ASCII, specifically not in the subset of
-ASCII recommended for domain names (the so-called "hostname" or "LDH"
-subset, see RFC1035 [STD13]); (c) as a label of a domain name that
-contains at least one character beyond ASCII; (d) as a Unicode string to
-be processed by Nameprep; (e) as a string that is an output from
-Nameprep; (f) as a string that is the result of processing through both
-Nameprep and conversion into Punycode; (g) as the abbreviation of an IDN
-(more properly, IDL) Package, in the terminology of this document; (h)
-as the abbreviation of the IETF IDN Working Group; (g) as the
-abbreviation of the ICANN IDN Committee; and (h) as standing for other
-IDN activities in other companies/organizations.
-
-Because of the potential confusion, this document uses the term "IDN" as
-an abbreviation for Internationalized Domain Name and, specifically, in
-the second sense described in (b) above. It uses "IDL," defined
-immediately below, to refer to Internationalized Domain Labels.
-
-2.1.2. IDL: This document provides a guideline to be applied on a
-per-zone basis, one label at a time. Therefore, the term
-"Internationalized Domain Label" or "IDL" will be used instead of the
-more general term "IDN" or its equivalents. The processing
-specifications of this document may be applied, in some zones, to ASCII
-characters also, if those characters are specified as valid in a
-Language Variant Table (see below). Hence, in some zones, an IDL may
-contain or consist entirely of "LDH" characters.
-
-2.1.3. FQDN: A fully qualified domain name, one that explicitly
-contains all labels, including a Top-Level Domain (TLD) name. In this
-context, a TLD name is one whose label appears in a nameserver record in
-the root zone. The term "Domain Name Label" refers to any label of a
-FQDN.
-
-2.1.4. Registration: In this document, the term "registration" refers
-to the process by which a potential domain name holder requests that a
-label be placed in the DNS either as an individual name within a domain
-or as a subdomain delegation from another domain name holder. In the
-case of a successful registration, the label or delegation records are
-placed in the relevant zone file, or, more specifically, they are
-"activated" or made "active" and additional IDLs may be reserved as part
-of an "IDL Package" (see below). The guidelines presented here are
-recommended for all zones--at any hierarchy level--in which CJK
-characters are to appear and not just domains at the first or second
-level.
-
-2.1.5. RFC3066: A system, widely used in the Internet, for coding and
-representing names of languages. It is based on an International
-Organization for Standardization (ISO) standard for coding language
-names [ISO639], but expands it to provide additional precision.
-
-2.1.6. ISO/IEC 10646: The international standard universal
-multiple-octet coded character set ("UCS") [IS10646]. The Code Point
-definitions of this standard are identical to those of corresponding
-versions of the Unicode standard (see below). Consequently, the
-characters and their coding are often referred to as "Unicode
-characters."
-
-2.1.7. Unicode Character: The term "Unicode character" is used here in
-reference to characters chosen from the Unicode Standard Version 3.2
-[UNICODE] (and hence from ISO/IEC 10646). In this document, the
-characters are identified by their positions, or "Code Points." The
-notation U+12AB, for example, indicates the character at the position
-12AB (hexadecimal) in the Unicode 3.2 table. For characters in
-positions above FFFF—i.e., requiring more than sixteen bits to
-represent--a five to eight-character string is used, such as U+112AB for
-the character in position 12AB of plane 1.
-
-2.1.8. Unicode String: "Unicode string" refers to a string of Unicode
-characters. The Unicode string is identified by the sequence of the
-Unicode characters regardless of the encoding scheme.
-
-2.1.9. CJK Characters: CJK characters are characters commonly used in
-the Chinese, Japanese, or Korean languages, including but not limited to
-those defined in the Unicode Standard as ASCII (U+0020 to U+007F), Han
-ideographs (U+3400 to U+9FAF and U+20000 to U+2A6DF), Bopomofo (U+3100
-to U+312F and U+31A0 to U+31BF), Kana (U+3040 to U+30FF), Jamo (U+1100
-to 11FF and U+3130 to U+318F), Hangul (U+AC00 to U+D7AF and U+3130 to
-U+318F), and the respective compatibility forms. The particular
-characters that are permitted in a given zone are specified in the
-Language Variant Table(s) for that zone.
-
-2.1.10. Label String: A generic term referring to a string of
-characters that is a candidate for registration in the DNS or such a
-string, once registered. A label string may or may not be valid
-according to the rules of this specification and may even be invalid for
-IDNA use. The term "label", by itself, refers to a string that has been
-validated and may be formatted to appear in a DNS zone file.
-
-2.1.11. Language Variant Table: The key mechanisms of this
-specification utilize a three-column table, called a Language Variant
-Table, for each language permitted to be registered in the zone. Those
-columns are known, respectively, as "Valid Code Point", "Preferred
-Variant", and "Character Variant", which are defined separately below.
-The Language Variant Tables are critical to the success of the guideline
-described in this document. However, the principles to be used to
-generate the tables are not within the scope of this document and should
-be worked out by each registry separately (perhaps by adopting or
-adapting the work of some other registry). In this document, "Table"
-and "Variant Table" are used as short forms for Language Variant Table.
-
-2.1.12. Valid Code Point: In a Language Variant Table, the list of Code
-Points that is permitted for that language. Any other Code Points, or
-any string containing them, will be rejected by this specification. The
-Valid Code Point list appears as the first column of the Language
-Variant Table.
-
-2.1.13. Preferred Variant: In a Language Variant Table, a list of Code
-Points corresponding to each Valid Code Point and providing possible
-substitutions for it. These substitutions are "preferred" in the sense
-that the variant labels generated using them are normally registered in
-the zone file, or "activated." The Preferred Code Points appear in
-column 2 of the Language Variant Table. "Preferred Code Point" is used
-interchangeably with this term.
-
-2.1.14. Character Variant: In a Language Variant Table, a second list
-of Code Points corresponding to each Valid Code Point and providing
-possible substitutions for it. Unlike the Preferred Variants,
-substitutions based on Character Variants are normally reserved but not
-actually registered (or "activated"). Character Variants appear in
-column 3 of the Language Variant Table. The term "Code Point Variants"
-is used interchangeably with this term.
-
-2.1.15. Preferred Variant Label: A label generated by use of Preferred
-Variants (or Preferred Code Points).
-
-2.1.16. Character Variant Label: A label generated by use of Character
-Variants.
-
-2.1.17. Zone Variant: A Preferred or Character Variant Label that is
-actually to be entered (registered) into the DNS--that is, into the zone
-file for the relevant zone. Zone Variants are also referred to as Zone
-Variant Labels or Active (or Activated) Labels.
-
-2.1.18. IDL Package: A collection of IDLs as determined by these
-Guidelines. All labels in the package are "reserved", meaning they
-cannot be registered by anyone other than the holder of the Package.
-These reserved IDLs may be "activated", meaning they are actually
-entered into a zone file as a "Zone Variant". The IDL Package also
-contains identification of the language(s) associated with the
-registration process. The IDL and its variant labels form a single,
-atomic unit.
-
-2.2 Notation for Ideographs and Other Non-ASCII CJK Characters.
-
-For purposes of clarity, particularly in regard to examples, Han
-ideographs appear in several places in this document. However, they do
-not appear in the ASCII version of this document. For the convenience
-of readers of the ASCII version--and some readers not familiar with
-recognizing and distinguishing Chinese characters--most uses of these
-characters will be associated with both their Unicode Code Points and an
-"asterisk tag" with its corresponding Chinese Romanization [ISO7098],
-with the tone mark represented by a number from 1 to 4. Those tags have
-no meaning outside this document; they are a quick visual and reading
-reference to help facilitate the combinations and transformations of
-characters in the guideline and table excerpts.
-
-3. Scope of the Administrative Guidelines
-
-Zone administrators are responsible for the administration of the domain
-name labels under their control. A zone administrator might be
-responsible for a large zone, such as a top-level domain (TLD)--whether
-generic or country code--or a smaller one, such as a typical second- or
-third-level domain. A large zone is often more complex than its smaller
-counterpart. However, actual technical administrative tasks--such as
-addition, deletion, delegation, and transfer of zones between domain
-name holders--are similar for all zones.
-
-This document provides guidelines for the ways CJK characters should be
-handled within a zone, for how language issues should be considered and
-incorporated, and for how Domain Name Labels containing CJK characters
-should be administered (including registration, deletion, and transfer
-of labels). It does not provide any guidance for the handling of
-non-CKJ characters or languages in zones.
-
-Other IDN policies--such as the creation of new top-level domains
-(TLDs), the cost structure for registrations, and how the processes
-described here get allocated between registrar and registry if the zone
-makes that distinction--also are outside the scope of this document.
-
-Technical implementation issues are not discussed here either. For
-example, deciding which guidelines should be implemented as registry
-actions and which should be registrar actions is left to zone
-administrators, with the possibility that it will differ from zone to
-zone.
-
-3.1. Principles Underlying These Guidelines
-
-In many places, in the event of a dispute over rights to a name (or,
-more accurately, DNS label string), this document assumes "first-come,
-first-served" (FCFS) as a resolution policy even though FCFS is not
-listed below as one of the principles for this document. If policies
-are already in place governing priorities and "rights", one can use the
-guidelines here by replacing uses of FCFS in this document with policies
-specific to the zone. Some of the guidelines here may not be applicable
-to other policies for determining rights to labels. Still other
-alternatives--such as use of UDRP [WIPO-UDRP] or mutual exclusion--might
-have little impact on other aspects of these guidelines.
-
-(a) Although some Unicode strings may be pure identifiers made up of an
-assortment of characters from many languages and scripts, IDLs are
-likely to be "words" or "names" or "phrases" that have specific meaning
-in a language. While a zone administration might or might not require
-"meaning" as a registration criterion, meaning could prove to be a
-useful tool for avoiding user confusion.
-
- Each IDL to be registered should be associated administratively
- with one or more languages.
-
-Language associations should either be predetermined by the zone
-administrator and applied to the entire zone or be chosen by the
-registrants on a per-IDL basis. The latter may be necessary for some
-zones, but it will make administration more difficult and will increase
-the likelihood of conflicts in variant forms.
-
- A given zone might have multiple languages associated with it or
- it may have no language specified at all. Omitting specification
- of a language may provide additional opportunities for user
- confusion and is therefore NOT recommended.
-
-(b) Each language uses only a subset of Unicode characters. Therefore,
-if an IDL is associated with a language, it is not permitted to contain
-any Unicode character that is not within the valid subset for that
-language.
-
- Each IDL to be registered must be verified against the valid subset
- of Unicode for the language(s) associated with the IDL. That subset
- is specified by the list of characters appearing in the first column
- of the language and zone-specific tables as described later in this
- document.
-
-If the IDL fails this test for any of its associated languages, the IDL
-is not valid for registration.
-
-Note that this verification is not necessarily linguistically accurate,
-because some languages have special rules. For example, some languages
-impose restrictions on the order in which particular combinations of
-characters may appear. Characters that are valid for the language--and
-hence permitted by this specification--might still not form valid words
-or even strings in the language.
-
-(c) When an IDL is associated with a language, it may have Character
-Variants that depend on that language associated with it in addition to
-any Preferred Variants. These variants are potential sources of
-confusion with the Code Points in the original label string.
-Consequently, the labels generated from them should be unavailable to
-registrants of other names, words, or phrases.
-
- During registration, all labels generated from the Character
- Variants for the associated language(s) of the IDL should be
- reserved.
-
-IDL reservations of the type described here normally do not appear in
-the distributed DNS zone file. In other words, these reserved IDLs may
-not resolve. Domain name holders could request that these reserved IDLs
-be placed in the zone file and made active and resolvable.
-
-Zones will need to establish local policies about how they are to be
-made active. Specifically, many zones, especially at the top level,
-have prohibited or restricted the use of "CNAME"s--DNS
-aliases--especially CNAMEs that point to nameserver delegation records
-(NS records). And long-term use of long-term aliases for domain
-hierarchies, rather than single names ("DNAME records") are considered
-problematic because of the recursion they can introduce into DNS
-lookups.
-
-(d) When an IDL is a "name", "word", or "phrase", it will have Character
-Variants depending on the associated language. Furthermore, one or more
-of those Character Variants will be used more often than others for
-linguistic, political, or other reasons. These more commonly used
-variants are distinguished from ordinary Character Variants and are
-known as Preferred Variant(s) for the particular language.
-
- To increase the likelihood of correct and predictable resolution of
- the IDN by end users, all labels generated from the Preferred
- Variants for the associated language(s) should be resolvable.
-
-In other words, the Preferred Variant Labels should appear in the
-distributed DNS zone file.
-
-(e) IDLs associated with one or more languages may have a large number
-of Character Variant Labels or Preferred Variant Labels. Some of these
-labels may include combinations of characters that are meaningless or
-invalid linguistically. It may therefore be appropriate for a zone to
-adopt procedures that include only linguistically-acceptable labels in
-the IDL Package.
-
- A zone administrator may impose additional rules and other
- processing activities to limit the number of Character Variant
- Labels or Preferred Variant Labels that are actually reserved or
- registered.
-
-These additional rules and other processing activities are based on
-policies and/or procedures imposed on a per-zone basis and therefore are
-not within the scope of this document. Such policies or procedures
-might be used, for example, to restrict the number of Preferred Variant
-Labels actually reserved or to prevent certain words from being
-registered at all.
-
-(f) There are some Character Variant Labels and Preferred Variant Labels
-that are associated with each IDL. These labels are considered
-"equivalent" to each another. To avoid confusion, they all should be
-assigned to a single domain name holder.
-
- The IDL and its variant labels should be grouped together into a
- single atomic unit, known in this document as an "IDL Package".
-
-The IDL Package is created upon registration and is atomic: Transfer and
-deletion of an IDL is performed on the IDL Package as a whole. That is,
-an IDL within the IDL Package may not be transferred or deleted
-individually; any re-registration, transfers, or other actions that
-impact the IDL should also affect the other variants.
-
-The name-conflict resolution policy associated with this zone could
-result in a conflict with the principle of IDL Package atomicity. In
-such a case, the policy must be defined to make the precedence clear.
-
-3.2. Registration of IDL
-
-To conform to the principles described in 3.1, this document introduces
-two concepts: the Language Variant Table and the IDL Package. These are
-described in the next two subsections, followed by a description of the
-algorithm that is used to interpret the table and generate variant
-labels.
-
-3.2.1. Using the Language Variant Table
-
-For each zone that uses a given language, each language should have its
-own Language Variant Table. The table consists of a header section that
-identifies references and version information, followed by a section
-with one row for each Code Point that is valid for the language and
-three columns..
-
-a) The first column contains the subset of Unicode characters that is
-valid to be registered ("Valid Code Point"). This is used to verify the
-IDL to be registered (see 3.1b). As in the registration procedure
-described later, this column is used as an index to examine characters
-that appear in a proposed IDL to be processed. The collection of Valid
-Code Points in the table for a particular language can be thought of as
-defining the script for that language, although the normal definition of
-a script would not include, for example, ASCII characters with CJK ones.
-
-b) The second column contains the Preferred Variant(s) of the
-corresponding Unicode character in column one ("Valid Code Point").
-These variant characters are used to generate the Preferred Variant
-Labels for the IDL. Those labels should be resolvable (see 3.1d).
-Under normal circumstances, all of those Preferred Variant Labels will
-be activated in the relevant zone file so that they will resolve when
-the DNS is queried for them.
-
-c) The third column contains the Character Variant(s) for the
-corresponding Valid Code Point. These are used to generate the
-Character Variant Labels of the IDL, which are then to be reserved (see
-3.1c). Registration--or activation--of labels generated from Character
-Variants will normally be a registrant decision, subject to local
-policy.
-
-Each entry in a column consists of one or more Code Points, expressed as
-a numeric character number in the Unicode table and optionally followed
-by a parenthetical reference. The first column--or Valid Code Point--
-may have only one Code Point specified in a given row. The other
-columns may have more than one.
-
-Any row may be terminated with an optional comment, starting in "#".
-
-The formal syntax of the table and more-precise definitions of some of
-its organization appear in Section 5.
-
-The Language Variant Table should be provided by a relevant group,
-organization, or body. However, the question of who is relevant or has
-the authority to create this table and the rules that define it is
-beyond the scope of this document.
-
-3.2.2. IDL Package
-
-The IDL Package is created on successful registration and consists of:
-
-a) the IDL registered
-
-b) the language(s) associated with the IDL
-
-c) the reserved IDLs
-
-d) active IDLs--that is, "Zone Variant Labels" that are to appear in
- the DNS zone file
-
-3.2.3. Procedure for Registering IDLs
-
-An explanation follows each step.
-
-Step 1. IN <= IDL to be registered and
- {L} <= Set of languages associated with IN
-
-Start the process with the label string (prospective IDL) to be
-registered and the associated language(s) as input.
-
-Step 2. Generate the Nameprep-processed version of the IN, applying
- all mappings and canonicalization required by IDNA.
-
-The prospective IDL is processed by using Nameprep to apply the
-normalizations and exclusions globally required to use IDNA. If the
-Nameprep processing fails, then the IDL is invalid and the registration
-process must stop.
-
-Step 2.1. NP(IN) <= Nameprep processed IN
-Step 2.2. Check availability of NP(IN).
- If not available, route to conflict policy.
-
-The Nameprep-processed IDL is then checked against the contents of the
-zone file and previously created IDL Packages. If it is already
-registered or reserved, then a conflict exists that must be resolved by
-applying whatever policy is applicable for the zone. For example, if
-FCFS is used, the registration process terminates unless the conflict
-resolution policy provides another alternative.
-
-Step 3. Process each language.
- For each language (AL} in {L}
-
-Step 3 goes through all languages associated with the proposed IDL and
-checks each character (after Nameprep has been applied) for validity in
-each of them. It then applies the Preferred Variants (column 2 values)
-and the Character Variants (column 3 values) to generate candidate
-labels.
-
-Step 3.1. Check validity of NP(IN) in AL. If failed, stop processing.
-
-In step 3.1, IDL validation is done by checking that every Code Point in
-the Nameprep-processed IDL is a Code Point allowed by the "Valid Code
-Point" column of the Character Variant Table for the language. This is
-then repeated for any other languages (and hence, Language Variant
-Tables) specified in the registration. If one or more Code Points are
-not valid, the registration process terminates.
-
-Step 3.2. PV(IN,AL) <= Set of available Nameprep-processed Preferred
- Variants of NP(IN) in AL
-
-Step 3.2 generates the list of Preferred Variant Labels of the IDL by
-doing a combination (see Step 3.2A below) of all possible variants
-listed in the "Preferred Variant(s)" column for each Code Point in the
-Nameprep-processed IDL. The generated Preferred Variant Labels must be
-processed through Nameprep. If the Nameprep processing fails for any
-Preferred Variant Label (this is unlikely to occur if the Preferred
-Variants [Code Points] are processed through Nameprep before being
-placed in the table), then that variant label will be removed from the
-list. The remaining Preferred Variant Labels in the list are then
-checked to see whether they are already registered or reserved. If any
-are registered or reserved, then the conflict resolution policy will
-apply. In general, this will not prevent the originally requested IDL
-from being registered unless the policy prevents such registration. For
-example, if FCFS is applied, then the conflicting variants will be
-removed from the list, but the originally requested IDL and any
-remaining variants will be registered (see steps 5 and 8 below).
-
-Step 3.2A Generating variant labels from Variant Code Points.
-
-Steps 3.2 and 3.3 require that the Preferred Variants and Character
-Variants be combined with the original IDL to form sets of variant
-labels. Conceptually, one starts with the original, Nameprep-processed,
-IDL and examines each of its characters in turn. If a character is
-encountered for which there is a corresponding Preferred Variant or
-Character Variant, a new variant label is produced with the Variant Code
-Point substituted for the original one. If variant labels already exist
-as the result of the processing of characters that appeared earlier in
-the original IDL, then the substitutions are made in them as well,
-resulting in additional generated variant labels. This operation is
-repeated separately for the Preferred Variants (in Step 3.2) and
-Character Variants (in Step 3.3). Of course, equivalent results could
-be achieved by processing the original IDL’s characters in order,
-building the Preferred Variant Label set and Character Variant Label set
-in parallel.
-
-This process will sometimes generate a very large number of labels. For
-example, if only two of the characters in the original IDL are
-associated with Preferred Variants and if the first of those characters
-has three Preferred Variants and the second has two, one ends up with 12
-variant labels to be placed in the IDL Package and, normally, in the
-zone file. Repeating the process for Character Variants, if any exist,
-would further increase the number of labels. And if more than one
-language is specified for the original IDL, then repetition of the
-process for additional languages (see step 4, below) might further
-increase the size of the set.
-
-For illustrative purposes, the "combination" process could be achieved
-by a recursive function similar to the following pseudocode:
-
-Function Combination(Str)
- F <= first codepoint of Str
- SStr <= Substring of Str, without the first code point
- NSC <= {}
-
- If SStr is empty then
- For each V in (Variants of code point F)
- NSC = NSC set-union (the string with the code point V)
- End of Loop
- Else
- SubCom = Combination(SStr)
- For each V in (Variants of code point F)
- For each SC in SubCom
- NSC = NSC set-union (the string with the first code point V
- followed by the string SC)
- End of Loop
- End of Loop
- Endif
-
- Return NSC
-
-Step 3.3. CV(IN,AL) <= Set of available Nameprep-processed Character
- Variants of NP(IN) in AL
-
-This step generates the list of Character Variant Labels by doing a
-combination (see Step 3.2A above) of all the possible variants listed in
-the "Character Variant(s)" column for each Code Point in the
-Nameprep-processed original IDL. As with the Preferred Variant Labels,
-the generated Character Variant Labels must be processed by, and
-acceptable to, Nameprep. If the Nameprep processing fails for a
-Character Variant Label, then that variant label will be removed from
-the list. The remaining Character Variant Labels are then checked to be
-sure they are not registered or reserved. If one or more are, then the
-conflict resolution policy is applied. As with Preferred Variant
-Labels, a conflict that is resolved in favor of the earlier registrant
-does not, in general, prevent the IDL from being registered, nor the
-remaining variants from being reserved in step 6 below.
-
-Step 3.4. End of Loop
-
-Step 4. Let PVall be the set-union of all PV(IN,AL)
-
-Step 4 generates the Preferred Variants Label for all languages.
-In this step, and again in step 6 below, the zone administrator may
-impose additional rules and processing activities to restrict the number
-of Preferred (tentatively to be reserved and activated) and Character
-(tentatively to be reserved) Label Variants. These additional rules and
-processing activities are zone policy specific and therefore are not
-specified in this document.
-
-Step 5. {ZV} <= PVall set-union NP(IN)
-
-Step 5 generates the initial Zone Variants. The set includes all
-Preferred Variants for all languages and the original Nameprep-processed
-IDL. Unless excluded by further processing, these Zone Variants will be
-activated--that is, placed into the DNS zone. Note that the "set-union"
-operation will eliminate any duplicates.
-
-Step 6. Let CVall be the set-union of all CV(IN,AL), set-minus {ZV}
-
-Step 6 generates the Reserved Label Variants (the Character Variant
-Label set). These labels are normally reserved but not activated. The
-set includes all Character Variant Labels for all languages, but not the
-Zone Variants defined in the previous step. The set-union and set-minus
-operations eliminate any duplicates.
-
-Step 7. Create IDL Package for IN using IN, {L}, {ZV} and CVall
-
-In Step 7, the "IDL Package" is created using the original IDL, the
-associated language(s), the Zone Variant Labels, and the Reserved
-Variant Labels. If zone-specific additional processing or filtering is
-to be applied to eliminate linguistically inappropriate or other forms,
-it should be applied before the IDL Package is actually assembled.
-
-Step 8. Put {ZV} into zone file
-
-The activated IDLs are converted via ToASCII with UseSTD13ASCIIRules
-[IDNA] before being placed into the zone file. This conversion results
-in the IDLs being in the actual IDNA ("Punycode") form used in zone
-files, while the IDLs have been carried in Unicode form up to this
-point. If ToASCII fails for any of the activated IDLs, that IDL must
-not be placed into the zone file. If the IDL is a subdomain name, it
-will be delegated.
-
-3.3. Deletion and Transfer of IDL and IDL Package
-
-In traditional domain administration, every Domain Name Label is
-independent of all other Domain Name Labels. Registration, deletion,
-and transfer of labels is done on a per-label basis. However, with the
-guidelines discussed here, each IDL is associated with specific
-languages, with all label variants--both active (zone) and reserved--
-together in an IDL Package. This quite deliberately prohibits labels
-that contain sufficient mixtures of characters from different scripts
-to make them impossible as words in any given language. If a zone
-chooses to not impose that restriction--that is, to permit labels to
-be constructed by picking characters from several different languages
-and scripts--then the guidelines described here would be inappropriate.
-
-As stated earlier, the IDL package should be treated as a single atomic
-unit and all variants of the IDL should belong to a single domain-name
-holder. If the local policy related to the handling of disagreements
-requires a particular IDL to be transferred and deleted independently of
-the IDL Package, the conflict policy would take precedence. In such an
-event, the conflict policy should include a transfer or delete procedure
-that takes the nature of IDL Packages into consideration.
-
-When an IDL Package is deleted, all of the Zone and Reserved Label
-Variants again become available. The deletion of one IDL Package does
-not change any other IDL Packages.
-
-3.4. Activation and Deactivation of IDL variants
-
-Because there are active (registered) IDLs and inactive (reserved but
-not registered) IDLs within an IDL package, processes are required to
-activate or deactivate IDL variants within an IDL Package.
-
-3.4.1. Activation Algorithm
-
-Step 1. IN <= IDL to be activated and PA <= IDL Package
-
-Start with the IDL to be activated and the IDL Package of which it is a
-member.
-
-Step 2. NP(IN) <= Nameprep processed IN
-
-Process the IDL through Nameprep. This step should never cause a
-problem, or even a change, since all labels that become part of the IDL
-Package are processed through Nameprep in Step 3.2 or 3.3 of the
-Registration procedure (section 3.2.3).
-
-Step 3. If NP(IN) not in {RV} then stop
-
-Verify that the Nameprep-processed version of the IDL appears as a
-still-unactivated label in the IDL Package, i.e., in the list of
-Reserved Label Variants, {RV}. It might be a useful "sanity check" to
-also verify that it does not already appear in the zone file.
-
-Step 4. {RV} <= {RV} set-minus NP(IN) and {ZV} <= {ZV} set-union NP(IN)
-
-Within the IDL Package, remove the Nameprep-processed version of the IDL
-from the list of Reserved Label Variants and add it to the list of
-active (zone) label variants.
-
-Step 5. Put {ZV} into the zone file
-
-Actually register (activate) the Zone Variant Labels.
-
-
-3.4.2. Deactivation Algorithm
-
-Step 1. IN <= IDL to be deactivated and PA <= IDL Package
-
-As with activation, start with the IDL to be deactivated and the IDL
-Package of which it is a member.
-
-Step 2. NP(IN) <= Nameprep processed IN
-
-Get the Nameprep-processed version of the name (see discussion in the
-previous section).
-
-Step 3. If NP(IN) not in {ZV} then stop
-
-Verify that the Nameprep-processed version of the IDL appears as an
-activated (zone) label variant in the IDL Package. It might be a useful
-"sanity check" at this point to also verify that it actually appears in
-the zone file.
-
-Step 4. {RV} <= {RV} set-union NP(IN) and {ZV} <= {ZV} set-minus NP(IN)
-
-Within the IDL Package, remove the Nameprep-processed version of the IDL
-from the list of Active (Zone) Label Variants and add it to the list of
-Reserved (but inactive) Label Variants.
-
-Step 5. Put {ZV} into the zone file
-
-3.5. Managing Changes in Language Associations
-
-Since the IDL package is an atomic unit and the associated list of
-variants must not be changed after creation, this document does not
-include a mechanism for adding and deleting language associations within
-the IDL package. Instead, it recommends deleting the IDL package
-entirely, followed by a registration with the new set of languages.
-Zone administrators may find it desirable to devise procedures that
-prevent other parties from capturing the labels in the IDL Package
-during these operations.
-
-3.6. Managing Changes to the Language Variant Tables
-
-Language Variant Tables are subject to changes over time, and these
-changes may or may not be backward compatible. It is possible that
-updated Language Variant Tables may produce a different set of Preferred
-Variants and Reserved Variants.
-
-In order to preserve the atomicity of the IDL Package, when the Language
-Variant Table is changed, IDL Packages created using the previous
-version of the Language Variant Table must not be updated or affected.
-
-4. Examples of Guideline Use in Zones
-
-To provide a meaningful example, some Language Variant Tables must be
-defined. Assume, then, for the purpose of giving examples, that the
-following four Language Variant Tables are defined:
-
-Note: these tables are not a representation of the actual tables, and
-they do not contain sufficient entries to be used in any actual
-implementation.
-
-a) Language Variant Table for zh-cn and zh-sg
-
-Reference 1 CP936 (commonly known as GBK)
-Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt
-Reference 3 List of Simplified character Table (Simplified column)
-Reference 4 zSimpVariant in Unihan.txt
-Reference 5 variant that exists in GB2312, common simplified hanzi
-
-Version 1 20020701 # July 2002
-
-56E2(1);56E2(5);5718(2) # sphere, ball, circle; mass, lump
-5718(1);56E2(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump
-60F3(1);60F3(5); # think, speculate, plan, consider
-654E(1);6559(5);6559(2) # teach
-6559(1);6559(5);654E(2) # teach, class
-6DF8(1);6E05(5);6E05(2) # clear
-6E05(1);6E05(5);6DF8(2) # clear, pure, clean; peaceful
-771E(1);771F(5);771F(2) # real, actual, true, genuine
-771F(1);771F(5);771E(2) # real, actual, true, genuine
-8054(1);8054(3);806F(2) # connect, join; associate, ally
-806F(1);8054(3);8054(2),8068(2) # connect, join; associate, ally
-96C6(1);96C6(5); # assemble, collect together
-
-
-b) Language Variant Table for zh-tw
-
-Reference 1 CP950 (commonly known as BIG5)
-Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt
-Reference 3 List of Simplified Character Table (Traditional column)
-Reference 4 zTradVariant in Unihan.txt
-
-Version 1 20020701 # July 2002
-
-5718(1);5718(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump
-60F3(1);60F3(1); # think, speculate, plan, consider
-6559(1);6559(1);654E(2) # teach, class
-6E05(1);6E05(1);6DF8(2) # clear, pure, clean; peaceful
-771F(1);771F(1);771E(2) # real, actual, true, genuine
-806F(1);806F(3);8054(2),8068(2) # connect, join; associate, ally
-96C6(1);96C6(1); # assemble, collect together
-
-c) Language Variant Table for ja
-
-Reference 1 CP932 (commonly known as Shift-JIS)
-Reference 2 zVariant in Unihan.txt
-Reference 3 variant that exists in JIS X0208, commonly used Kanji
-
-Version 1 20020701 # July 2002
-
-5718(1);5718(3);56E3(2) # sphere, ball, circle; mass, lump
-60F3(1);60F3(3); # think, speculate, plan, consider
-654E(1);6559(3);6559(2) # teach
-6559(1);6559(3);654E(2) # teach, class
-6DF8(1);6E05(3);6E05(2) # clear
-6E05(1);6E05(3);6DF8(2) # clear, pure, clean; peaceful
-771E(1);771E(1);771F(2) # real, actual, true, genuine
-771F(1);771F(1);771E(2) # real, actual, true, genuine
-806F(1);806F(1);8068(2) # connect, join; associate, ally
-96C6(1);96C6(3); # assemble, collect together
-
-d) Language Variant Table for ko
-
-Reference 1 CP949 (commonly known as EUC-KR)
-Reference 2 zVariant and K-source in Unihan.txt
-
-Version 1 20020701 # July 2002
-
-5718(1);5718(1);56E3(2) # sphere, ball, circle; mass, lump
-60F3(1);60F3(1); # think, speculate, plan, consider
-654E(1);654E(1);6559(2) # teach
-6DF8(1);6DF8(1);6E05(2) # clear
-771E(1);771E(1);771F(2) # real, actual, true, genuine
-806F(1);806F(1);8068(2) # connect, join; associate, ally
-96C6(1);96C6(1); # assemble, collect together
-
-Example 1: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
- {L} = {zh-cn, zh-sg, zh-tw}
-
-NP(IN) = (U+6E05 U+771F U+6559)
-PV(IN,zh-cn) = (U+6E05 U+771F U+6559)
-PV(IN,zh-sg) = (U+6E05 U+771F U+6559)
-PV(IN,zh-tw) = (U+6E05 U+771F U+6559)
-{ZV} = (U+6E05 U+771F U+6559)}
-CVall = (U+6E05 U+771E U+6559),
- (U+6E05 U+771E U+654E),
- (U+6E05 U+771F U+654E),
- (U+6DF8 U+771E U+6559),
- (U+6DF8 U+771E U+654E),
- (U+6DF8 U+771F U+6559),
- (U+6DF8 U+771F U+654E)}
-
-Example 2: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
- {L} = {ja}
-
-NP(IN) = (U+6E05 U+771F U+6559)
-PV(IN,ja) = (U+6E05 U+771F U+6559)
-{ZV} = (U+6E05 U+771F U+6559)}
-CVall = (U+6E05 U+771E U+6559),
- (U+6E05 U+771E U+654E),
- (U+6E05 U+771F U+654E),
- (U+6DF8 U+771E U+6559),
- (U+6DF8 U+771E U+654E),
- (U+6DF8 U+771F U+6559),
- (U+6DF8 U+771F U+654E)}
-
-Example 3: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
- {L} = {zh-cn, zh-sg, zh-tw, ja, ko}
-
-NP(IN) = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
-Invalid registration because U+6E05 is invalid in L = ko
-
-Example 4: IDL = (U+806F U+60F3 U+96C6 U+5718)
- *lian2 xiang3 ji2 tuan2*
- {L} = {zh-cn, zh-sg, zh-tw}
-
-NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
-PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
-PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
-PV(IN,zh-tw) = (U+806F U+60F3 U+96C6 U+5718)
-{ZV} = (U+8054 U+60F3 U+96C6 U+56E2),
- (U+806F U+60F3 U+96C6 U+5718)}
-CVall = (U+8054 U+60F3 U+96C6 U+56E3),
- (U+8054 U+60F3 U+96C6 U+5718),
- (U+806F U+60F3 U+96C6 U+56E2),
- (U+806f U+60F3 U+96C6 U+56E3),
- (U+8068 U+60F3 U+96C6 U+56E2),
- (U+8068 U+60F3 U+96C6 U+56E3),
- (U+8068 U+60F3 U+96C6 U+5718)
-
-Example 5: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
- *lian2 xiang3 ji2 tuan2*
- {L} = {zh-cn, zh-sg}
-
-NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
-PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
-PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
-{ZV} = (U+8054 U+60F3 U+96C6 U+56E2)}
-CVall = (U+8054 U+60F3 U+96C6 U+56E3),
- (U+8054 U+60F3 U+96C6 U+5718),
- (U+806F U+60F3 U+96C6 U+56E2),
- (U+806f U+60F3 U+96C6 U+56E3),
- (U+806F U+60F3 U+96C6 U+5718),
- (U+8068 U+60F3 U+96C6 U+56E2),
- (U+8068 U+60F3 U+96C6 U+56E3),
- (U+8068 U+60F3 U+96C6 U+5718)}
-
-Example 6: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
- *lian2 xiang3 ji2 tuan2*
- {L} = {zh-cn, zh-sg, zh-tw}
-
-NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
-Invalid registration because U+8054 is invalid in L = zh-tw
-
-Example 7: IDL = (U+806F U+60F3 U+96C6 U+5718)
- *lian2 xiang3 ji2 tuan2*
- {L} = {ja,ko}
-
-NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
-PV(IN,ja) = (U+806F U+60F3 U+96C6 U+5718)
-PV(IN,ko) = (U+806F U+60F3 U+96C6 U+5718)
-{ZV} = (U+806F U+60F3 U+96C6 U+5718)}
-CVall = (U+806F U+60F3 U+96C6 U+56E3),
- (U+8068 U+60F3 U+96C6 U+5718),
- (U+8068 U+60F3 U+96C6 U+56E3)}
-
-5. Syntax Description for the Language Variant Table
-
-The formal syntax for the Language Variant Table is as follows, using
-the IETF "ABNF" metalanguage [ABNF]. Some comments on this syntax
-appear immediately after it.
-
-5.1 ABNF Syntax
-
-LanguageVariantTable = 1*ReferenceLine VersionLine 1*EntryLine
-ReferenceLine = "Reference" SP RefNo SP RefDesciption [ Comment ] CRLF
-RefNo = 1*DIGIT
-RefDesciption = *[VCHAR]
-VersionLine = "Version" SP VersionNo SP VersionDate [ Comment ] CRLF
-VersionNo = 1*DIGIT
-VersionDate = YYYYMMDD
-EntryLine = VariantEntry/Comment CRLF
-VariantEntry = ValidCodePoint ";"
- PreferredVariant ";" CharacterVariant [ Comment ]
-ValidCodePoint = CodePoint
-RefList = RefNo 0*( "," RefNo )
-PreferredVariant = CodePointSet 0*( "," CodePointSet )
-CharacterVariant = CodePointSet 0*( "," CodePointSet )
-CodePointSet = CodePoint 0*( SP CodePoint )
-CodePoint = 4*8DIGIT [ "(" Reflist ")" ]
-Comment = "#" *VCHAR
-
-YYYYMMDD is an integer, in alphabetic form, representing a date, where
-YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit
-day.
-
-5.2. Comments and Explanation of Syntax
-
-Any lines starting with, or portions of lines after, the hash
-symbol("#") are treated as comments. Comments have no significance in
-the processing of the tables; nor are there any syntax requirements
-between the hash symbol and the end of the line. Blank lines in the
-tables are ignored completely.
-
-Every language should have its own Language Variant Table provided by a
-relevant group, organization, or other body. That table will normally
-be based on some established standard or standards. The group that
-defines a Language Variant Table should document references to the
-appropriate standards at the beginning of the table, tagged with the
-word "Reference" followed by an integer (the reference number) followed
-by the description of the reference. For example:
-
-Reference 1 CP936 (commonly known as GBK)
-Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt
-Reference 3 List of Simplified Character Table (Simplified column)
-Reference 4 zSimpVariant in Unihan.txt
-Reference 5 Variant that exists in GB2312, common simplified Hanzi
-
-Each Language Variant Table must have a version number and its release
-date. This is tagged with the word "Version" followed by an integer
-then followed by the date in the format YYYYMMDD, where YYYY is the
-4-digit year, MM is the 2-digit month, and DD is the 2-digit day of the
-publication date of the table.
-
-Version 1 20020701 # July 2002 Version 1
-
-The table has three columns, separated by semicolons: "Valid Code
-Point"; "Preferred Variant(s)"; and "Character Variant(s)".
-
-The "Valid Code Point" is the subset of Unicode characters that are
-valid to be registered.
-
-There can be more than one Preferred Variant; hence there could be
-multiple entries in the "Preferred Variant(s)" column. If the
-"Preferred Variant(s)" column is empty, then there is no corresponding
-Preferred Variant; in other words, the Preferred Variant is null.
-Unless local policy dictates otherwise, the procedures above will result
-in only those labels that reflect the valid code point being activated
-(registered) into the zone file.
-
-The "Character Variant(s)" column contains all Character Variants of the
-Code Point. Since the Code Point is always a variant of itself, to
-avoid redundancy, the Code Point is assumed to be part of the "Character
-Variant(s)" and need not be repeated in the "Character Variant(s)"
-column.
-
-If the variant in the "Preferred Variant(s)" or the "Character
-Variant(s)" column is composed of a sequence of Code Points, then
-sequence of Code Points is listed separated by a space.
-
-If there are multiple variants in the "Preferred Variant(s)" or the
-"Character Variant(s)" column, then each variant is separated by a
-comma.
-
-Any Code Point listed in the "Preferred Variant(s)" column must be
-allowed by the rules for the relevant language to be registered.
-However, this is not a requirement for the entries in the "Character
-Variant(s)" column; it is possible that some of those entries may not be
-allowed to be registered.
-
-Every Code Point in the table should have a corresponding reference
-number (associated with the references) specified to justify the entry.
-The reference number is placed in parentheses after the Code Point. If
-there is more than one reference, then the numbers are placed within a
-single set of parentheses and separated by commas.
-
-6. Security Considerations
-
-As discussed in the Introduction, substantially-unrestricted use of
-international (non-ASCII) characters in domain name labels may cause
-user confusion and invite various types of attacks. In particular, in
-the case of CJK languages, an attacker has an opportunity to divert or
-confuse users as a result of different characters (or, more
-specifically, assigned code points) with identical or similar semantics.
-These Guidelines provide a partial remedy for those risks by supplying
-a framework for prohibiting inappropriate characters from being
-registered at all and for permitting "variant" characters to be grouped
-together and reserved, so that they can only be registered in the DNS by
-the same owner. However, the system it suggests is no better or worse
-than the per-zone and per-language tables whose format and use this
-document specifies. Specific tables, and any additional local
-processing, will reflect per-zone decisions about the balance between
-risk and flexibility of registrations. And, of course, errors in
-construction of those tables may significantly reduce the quality of
-protection provided.
-
-7. Index to Terminology
-
-As a convenience to the reader, this section lists all of the special
-terminology used in this document, with a pointer to the section in
-which it is defined.
-
-Activated Label 2.1.17
-Activation 2.1.4
-Active Label 2.1.17
-Character Variant 2.1.14
-Character Variant Label 2.1.16
-CJK Characters 2.1.9
-Code point 2.1.7
-Code Point Variant 2.1.14
-FQDN 2.1.3
-Hostname 2.1.1
-IDL 2.1.2
-IDL Package 2.1.18
-IDN 2.1.1
-Internationalized Domain Label 2.1.2
-ISO/IEC 10646 2.1.6
-Label String 2.1.10
-Language name codes 2.1.5
-Language Variant Table 2.1.11
-LDH Subset 2.1.1
-Preferred Code Point 2.1.13
-Preferred Variant 2.1.13
-Preferred Variant Label 2.1.15
-Registration 2.1.4
-Reserved 2.1.18
-RFC3066 2.1.5
-Table 2.1.11
-UCS 2.1.6
-Unicode Character 2.1.7
-Unicode String 2.1.8
-Valid Code Point 2.1.12
-Variant Table 2.1.11
-Zone Variant 2.1.17
-
-
-8. Acknowledgments
-
-The authors gratefully acknowledge the contributions of:
-
-- V. CHEN, N. HSU, H. HOTTA, S. TASHIRO, Y. YONEYA, and other Joint
-Engineering Team members at the JET meeting in Bangkok, Thailand.
-
-- Yves Arrouye, an observer at the JET meeting in Bangkok, for his
-contribution on the IDL Package.
-
-- Those who commented on, and made suggestions about, earlier versions,
-including Harald ALVESTRAND, Erin CHEN, Patrik FALTSTROM, Paul HOFFMAN,
-Soobok LEE, LEE Xiaodong, MAO Wei, Erik NORDMARK, and L.M. TSENG.
-
-9. Authors’ Addresses
-
-James SENG
-Infocomm Development Authority
-8 Temasek Boulevard
-#14-00 Suntec Tower Three
-Singapore 038988
-Phone: +65 9638-7085
-E-mail: jseng@pobox.org.sg
-
-Kazunori KONISHI
-JPNIC
-Kokusai-Kougyou-Kanda Bldg 6F
-2-3-4 Uchi-Kanda, Chiyoda-ku
-Tokyo 101-0047
-Japan
-Phone: +81 49-278-7313
-E-mail: konishi@jp.apan.net
-
-Kenny HUANG
-TWNIC
-3F, 16, Kang Hwa Street, Taipei
-Taiwan
-TEL : 886-2-2658-6510
-E-mail: huangk@alum.sinica.edu
-
-QIAN Hualin
-CNNIC
-No.6 Branch-box of No.349 Mailbox, Beijing 100080
-Peoples Republic of China
-E-mail: Hlqian@cnnic.net.cn
-
-KO YangWoo
-PeaceNet
-Yangchun P.O. Box 81 Seoul 158-600
-Korea
-E-mail: newcat@peacenet.or.kr
-
-John C KLENSIN
-1770 Massachusetts Avenue, No. 322
-Cambridge, MA 02140
-U.S.A.
-E-mail: Klensin+ietf@jck.com
-
-Wendy RICKARD
-The Rickard Group
-16 Seminary Ave
-Hopewell, NJ 08525
-USA
-E-mail: rickard@rickardgroup.com
-
-10. Normative References
-
-[ABNF] Augmented BNF for Syntax Specifications: ABNF, RFC 2234, D.
- Crocker and P. Overell, eds., November 1997.
-
-[STD13] Paul Mockapetris, "Domain names--concepts and facilities"
- (RFC 1034) and "Domain names--implementation and
- specification" (RFC 1035), STD 13, November 1987.
-
-
-[RFC3066] Tags for the Identification of Languages, RFC3066,
- Jan 2001, H. Alvestrand.
-
-[IDNA] Internationalizing Domain Names in Applications (IDNA),
- RFC 3490, March 2003, Patrik Faltstrom, Paul Hoffman,
- Adam M. Costello.
-
-[PUNYCODE] Punycode: A Bootstring encoding of Unicode for
- Internationalized Domain Names in Applications (IDNA),
- RFC 3492, March 2003, Adam M. Costello.
-
-[STRINGPREP]Preparation of Internationalized Strings ("stringprep"),
- RFC 3454, December 2002, P. Hoffman, M. Blanchet.
-
-[NAMEPREP] Nameprep: A Stringprep Profile for Internationalized
- Domain Names, RFC 3491, March 2003, P. Hoffman, M. Blanchet.
-
-[IS10646] A product of ISO/IEC JTC1/SC2/WG2, Work Item JTC1.02.18
- (ISO/IEC 10646). It is a multipart standard: Part 1,
- published as ISO/IEC 10646-1:2000(E), covers the
- Architecture and Basic Multilingual Plane, and Part 2,
- published as ISO/IEC 10646-2:2001(E), covers the
- supplementary (additional) planes.
-
-[UNIHAN] Unicode Han Database, Unicode Consortium
- ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt.
-
-[UNICODE] The Unicode Consortium, "The Unicode Standard--Version
- 3.0," ISBN 0-201-61633-5. Unicode Standard Annex #28
- (http://www.unicode.org/unicode/reports/tr28/) defines
- Version 3.2 of the Unicode Standard, which is definitive
- for IDNA and this document.
-
-[ISO7098] ISO 7098;1991 Information and documentation--Romanization
- of Chinese, ISO/TC46/SC2.
-
-11. Nonnormative References
-
-[IDN-WG] IETF Internationalized Domain Names Working Group,
- idn@ops.ietf.org, James Seng, Marc Blanchet.
- http://www.i-d-n.net/.
-
-[IESG-IDN] "IESG Statement on IDN", Internet Engineering Steering Group,
- IETF, 11 February 2003,
- http://www.ietf.org/IESG/STATEMENTS/IDNstatement.txt.
-
-[ISO639] "ISO 639:1988 (E/F)--Code for the representation of names
- of languages"--International Organization for
- Standardization, 1st edition, 1988-04-01.
+++ /dev/null
-INTERNET-DRAFT John C Klensin
-21 October 2002
-Expires April 2003
-
- National and Local Characters in DNS TLD Names
- draft-klensin-idn-tld-00.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance
- with all provisions of Section 10 of RFC2026 except that the
- right to produce derivative works is not granted.
-
- 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.
- 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.
-
-
-Abstract
-
- In the context of work on internationalizing the Domain Name System
- (DNS), there have been extensive discussions about "multilingual" or
- "internationalized" top level domain names (TLDs), especially for
- countries whose predominant language is not written in a Roman-based
- script. This document reviews some of the motivations for such
- domains and the constraints that the DNS imposes. It then suggests
- an alternative, local translation, that may solve a superset of the
- problem while avoiding protocol changes, serious deployment delays,
- and other difficulties.
-
-Table of Contents
-
-1 Introduction
-1.1 Background on the "Multilingual Name" Problem
-1.2 Domain Name System Constraints
-1.3 Internationalization and Localization
-2. Client-side solutions
-2.1 IDNA and the client
-2.2 Local translation tables for TLD names
-3. Advantages and disadvantages of local translation
-3.1 Every TLD in the local language and character set
-\f
-3.2 Unification of country code domains
-3.3 User understanding of local and global reference
-3.4 Limits on TLD propagation
-4. Security Considerations
-5. References
-6. Acknowledgements
-7. Author's Address
-
-
-1. Introduction
-
-1.1 Background on the "Multilingual Name" Problem
-
-People who share a language prefer to communicate in it, using whatever
-characters are normally used to write that language, rather than in some
-"foreign" one. There have been standards for using mutually-agreed
-characters and languages in electronic mail message bodies and selected
-headers since the introduction of MIME in 1992 [MIME] and the Web has
-permitted multilingual text since its inception. However, since domain
-names are exposed to users in email addresses and URLs, and
-corresponding arrangements in other protocols, demand rapidly arose to
-permit domain names in applications that used characters other than
-those of the very restrictive, ASCII-subset, "LDH" conventions [LDH].
-The effort to do this rapidly became known as "multilingual domain
-names", although that is a misnomer, since the DNS deals only with
-characters and identifier strings, and not, except by accident, what
-people usually think of as "names". And there has been little actual
-interest in what would actually be a "multilingual name" -- i.e., a name
-that contains components from more than one language -- but only the use
-of strings conforming to different languages in the context of the DNS.
-
-1.1.1 Approaches to the requirement
-
-If the requirement is seen, not as "modifying the DNS", but as
-"providing users with access to the DNS from a variety of languages and
-character sets", three sets of proposals have emerged in the IETF and
-elsewhere. They are:
-
- (1) Perform processing in client software that recodes a user-visible
- string into an ASCII-compatible form that can safely be passed
- through the DNS protocols and stored in the DNS. This is the
- approach used, for example, in the IETF's "IDNA" protocol [IDNA].
-
- (2) Modify the DNS to be more hospitable to non-ASCII names and
- strings. There have been a variety of proposals to do this in almost
- as many ways, some of which have been implemented on a proprietary
- basis by various vendors. None of them have gained acceptance in the
- IETF community, primarily because they would take a long time to
- deploy and would leave many problems unsolved.
-
- (3) Move the problem out of the DNS entirely, relying instead on a
- "directory" or "presentation" layer to handle internationalization.
- The rationale for this approach is discussed in [DNSROLE].
-
-This document proposes a fourth approach, applicable to the top level
-domains (TLDs) only (see section 1.2.1 for a discussion of the special
-issues that make TLDs problematic). That approach could be used as an
-alternate or supplement to the strategies summarized above.
-\f
-
-1.1.2 Writing the name of one's country in its own characters
-
-An early focus of the "multilingual domain name" efforts was expressed
-in statements such as "users in my country, in which ASCII is rarely
-used, should be able to write an entire domain name in their own
-character set. In particular, since all top-level domain names, at
-present, follow the LDH rules, the somewhat more restrictive naming
-rules discussed in [STD3], and the coding conventions specified in
-[RFC1591], all fully-qualified DNS names were effectively required to
-contain at least one ASCII label (the TLD name), and that was considered
-inappropriate. One should, instead, be able to write the name of the
-ccTLD for China in Chinese, the name of the ccTLD for Saudi Arabia in
-Arabic, and so on.
-
-1.1.3 Countries with multiple languages and countries with multiple
- names
-
->From a user interface standpoint, writing ccTLD names in local
-characters is a problem. As discussed in section 1.2.2, the DNS itself
-does not easily permit a domain to be referred to by more than one name
-(or spelling or translation of a name). Countries with more than one
-official language would require that the country name be represented in
-each of those languages. And, just as it is important that a user in
-China be able to represent the name of the Chinese ccTLD in Chinese
-characters, she should be able to access a Chinese-language site in
-France using Chinese characters, requiring that she be able to write the
-name of the French ccTLD in those characters rather than in a form based
-on a Roman character set.
-
-
-1.2 Domain Name System Constraints
-
-1.2.1 Administrative hierarchy
-
-The domain name system is designed around the idea of an "administrative
-hierarchy", with the entity responsible for a given node of the
-hierarchy responsible for policies applicable to its subhierarchies (Cf.
-[STD13]). The model works quite well for the domain and subdomains of a
-particular enterprise, where the hierarchy can be organized to match the
-organizational structure, there are established ways to set policies and
-there is, at least presumably, shared assumptions about overall goals
-and objectives among all registrants in the domain. It is more
-problematic when a domain is shared by unrelated entities which lack
-common policy assumptions. It is difficult to reach agreement on rules
-that should apply to all of them. That situation always prevails for
-the labels registered in a TLD (second-level names) except in those TLDs
-for which the second level is structural (e.g., the .CO, .AC, .GOV
-conventions in many ccTLD) in which case, it exists for the labels
-within that structural level.
-
-TLDs may, but need not, have consistent registration policies for those
-second (or third) level names. Countries (or ccTLD administrators) have
-often adopted rules about what entities may register in those ccTLDs,
-and the forms the names may take. RFC 1591 outlined registration norms
-for most of the gTLDs, even though those norms have been largely ignored
-in recent years. And some recent "sponsored" domains are based on quite
-specific rules about appropriate registrations. Homogeneous
-\f
-registration rules for the root are, by contrast, impossible: almost by
-definition, the subdomains registered in it are diverse and no single
-policy applying to all root subdomains (TLDs) is feasible.
-
-1.2.2 Aliases
-
-In an environment different from the DNS, a rational way to permit
-assigning local-language names to a country code (or other) domain would
-be to set up an alias for the name, or to use some sort of "see instead"
-reference. But the DNS does not have quite the right facilities for
-either. Instead, it supports a "CNAME" record, whose label can refer
-onto to a particular label and not to a subtree. For example, if A.B.C
-is a fully-qualified name, then a CNAME reference from X to A would make
-X.B.C appear to have the same values as A.B.C. However, a CNAME
-reference from Y to C would not make A.B.Y referenceable (or even
-defined) at all. A second record type, DNAME [RFC2672], can provide an
-alias for a portion of the tree. But it is problematic technically, and
-its use is strongly discouraged except for transition uses from one
-domain to another.
-
-
-1.3 Internationalization and Localization
-
-It has often been observed that while many people talk about
-"internationalization" (a term we typically use for making something
-globally accessible while incorporating a broad-range "universal"
-character set and conventions appropriate to all languages), they often really
-mean, and want, "localization" (making things work well in a particular
-locality, or well, but potentially differently, for a broad range of
-localities). Anything that actually involves the DNS must be global and
-hence internationalized since the DNS cannot meaningfully support
-different responses based, e.g., on the location of the user making a
-query. While the DNS cannot support localization internally, many of
-the features discussed earlier in this section are much more easily
-thought about in local terms --whether localized to a geographical area,
-users of a language, or using some other criteria -- than in global ones.
-
-2. Client-side solutions
-
-Traditionally, the IETF has avoided becoming involved in standardization
-for actions that take place strictly on individual hosts on the network,
-assuming that it should confine itself to behavior that is observable
-"on the wire", i.e., in protocols between network hosts. Exceptions to
-this general principle have been made when different clients were
-required to utilize data or interpret values in compatible ways to
-preserve interoperability: the standards for email and web body formats,
-and IDNA itself, are examples of these exceptions. Regardless of what
-is required to be standardized, it is almost never required, and often
-unwise, that a user interface, by default, present on-the-wire formats
-to the user. However, in most cases when the presentation format and
-the wire format differ, the client program must take precautions that
-the wire format can be reconstructed from user input, or to keep the
-wire format, while hidden, bound to the presentation mechanism so that
-it can be reconstructed. And, while it is rarely a goal in itself, it
-is often necessary that the user be at least vaguely aware that the wire
-("real") format is different from the presentation one and that the wire
-format be available for debugging.
-
-\f
-2.1 IDNA and the client
-
-As mentioned above, IDNA itself is entirely a client-side protocol. It
-works by providing labels to the DNS in a special format (so-called
-"ACE"). When labels in that format are encountered, they are
-transformed, by the client, back into internationalized (normally
-Unicode) characters. In the context of this document, the important
-obvservation about IDNA is that any application program that supports it
-is already doing considerable transformation work on the client; it is
-not simply presenting the on-the-wire formats to the user.
-
-
-2.2 Local translation tables for TLD names
-
-We suggest that, in addition to maintaining the code and tables required
-to support IDNA, clients may want to maintain a table that contains a
-list of TLDs and that maps between them and locally-desirable names.
-For ccTLDs, these might be the names (or locally-standard abbreviations)
-by which the relevant countries are known locally (whether in ASCII
-characters or others). With some care on the part of the application
-designer (e.g., to ensure that local forms do not conflict with the
-actual TLD names), a particular TLD name input from the user could be
-either in local or standard form without special tagging or problems.
-When DNS names are received by these client programs, the TLD labels
-would be mapped to local form before IDNA is applied to the rest of the
-name; when names are received from users, local TLD names would be
-mapped to the global ones before being passed into IDNA or for other DNS
-processing.
-
-
-3. Advantages and disadvantages of local translation
-
-3.1 Every TLD in the local language and character set
-
-The notion of a top-level domain whose name matches, e.g., the name that
-is used for a country in that country or the name of a language in that
-language as, as mentioned above, immediately appealing. But most of the
-reasons for it argue equally strongly for other TLDs being accessible
-from that language. A user in Korea who can access the national ccTLD
-in the Korean language and character set has every reason to expect that
-both generic top level domains and and domains associated with other
-countries would be similarly accessible, especially if the second-level
-domains bear Korean names. A user in Spain or Portugal, or in Latin
-America, would presumably have similar expectations, but would expect to
-use Spanish names, not Korean ones.
-
-That level of local optimization is not realistic --some would argue not
-possible-- with the DNS since it would ultimately require that every top
-level domain be replicated for each of the world's languages. That
-replication process would involve not just the top level domain itself:
-in principle, all of its subtrees would need to be completely replicated
-as well (or at least all of the subtrees for which a the language
-associated with the a given replicant was relevant). The administrative
-hierarchy characteristics of the DNS (see section 1.2.1) turn the
-replication process into an administrative nightmare: every
-administrator of a second-level domain in the world would be forced to
-maintain dozens, probably hundreds, of similar zone files for the the
-replicates of the domain. Even if only the zones relevant to a
-\f
-particular country or language were replicated, the administrative and
-tracking problems to bind these to the appropriate top-level domain and
-keep all of the replicas synchronized would be extremely difficulty at
-best. And many administrators of third- and fourth-level domains, and
-beyond, would be faced with similar problems.
-
-By contrast, dealing with the names of TLDs as a localization problem,
-using local translation, is fairly simple. Each function represented by
-a TLD -- a country, generic registrations, or purpose-specific
-registrations -- could be represented in the local language and
-character set as needed. And, for countries with many languages, or
-users living, working, or visiting countries where their language was
-not dominant, "local" could be defined in terms of the needs or wishes
-of each particular user.
-
-3.2 Unification of country code domains
-
-It follows from some of the comments above that, while there appears to
-be some immediate appeal from having (at least) two domains for each
-country, one using the ISO 3166-1 code and another one using a name
-based on the national name in the national language, such a situation
-would create considerable problems for registrants in the multiple
-domains. For registrants maintaining enterprise or organizational
-subdomains, ease of administration in a single family of zone files will
-usually make a registration in a single top-level domain preferable to
-replicated sets of them, at least as long as their functional
-requirements (such a local-language access) are met by the unified
-structure.
-
-Of course, having replicated domains might be popular with registries
-and registrars, since replication would almost inevitably increase the
-total number of domains to be registered.
-
-3.3 User understanding of local and global references
-
-While the IDNA tables (actually Nameprep and Stringprep -- see the IDNA
-specification) must be identical globally for IDNA to work reliably, the
-tables for mapping between local names and TLD names could be locally
-determined, and differ from one locale to another, as long as users
-understood that international interchange of names required using the
-standard forms. That understanding could be assisted by software. It
-is likely that, at least for the foreseeable future, DNS names being
-passed among users in different countries, or using different languages,
-will be forced to be in ACE form to guarantee compatibility in any
-event, so the marginal knowledge or effort needed to put TLD names into
-standard form and transmit them that way would be very small.
-
-3.4 Limits on TLD propagation
-
-The concept of using local translation does have one side-effect, which
-some portions of the Internet community might consider undesirable.
-The size and complexity of translation tables, and maintaining those
-tables, will be, to a considerable extent, a function of the number of
-top-level domains, the frequency with which new domains are added, and
-the number of domains that are added at a time. A country or other
-locale that wished to maintain a few set of translations (i.e., so that
-every TLD had a representation in the local language) would presumably
-find setting up a table for the current collection of a few hundred
-\f
-domains to be a task that would take some days. If the number of TLDs
-was relatively stable, with a relatively small number being added at
-infrequent intervals, the updates could probably be dealt with on an ad
-hoc basis. But, if large numbers of domains were added frequently, or
-if the total number of TLDs became very large, maintaining the table
-might require dedicated staff. Worse, updating the tables stored on
-client machines might require update and synchronization protocols and
-all of the related complexities.
-
-4. Security Considerations
-
-IDNA provides a client-based mechanism for presenting Unicode names in
-applications while passing only ASCII-based names on the wire. As such,
-it constitutes a major step along the path of introducing a client-based
-presentation layer into the Internet. Client-based presentation layer
-transformations introduce risks from variant tables that can change
-meaning without external protection. For example, if a mapping table
-normally maps A onto C and that table is altered by an attacker so that
-A maps onto D instead, much mischief can be committed. On the other
-hand, these are not the usual sort of network attacks: they may be
-thought of as falling into the "users can always cause harm to
-themselves" category. The local translation model outlined here does
-not significantly increase the risks over those associated with IDNA,
-but may provide some new avenues for exploiting them.
-
-Both this approach and IDNA rely on having updated programs present
-information to the user in a very different form than the one in which
-it is transmitted on the wire. Unless the internal (wire) form is
-always used in interchange, there are possibilities for ambiguity and
-confusion about references.
-
-5. References
-
-[DNSROLE] Klensin, J.C., "Role of the Domain Name System", work in
- progress (draft-klensin-dns-role-04.txt).
-
-[IDNA] Faltstorm, F., P. Hoffman, A. M. Costello, "Internationalizing
- Domain Names in Applications (IDNA)", work in progress
- (draft-ietf-idn-idna-13.txt)
-
-[LDH] STD13 and comments
-
-[MIME] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
- Extensions): Mechanisms for Specifying and Describing the Format of
- Internet Message Bodies", RFC 1341, June 1992. Updated and replaced
- by Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message Bodies",
- RFC2045, November 1996. Also, Moore, K., "Representation of
- Non-ASCII Text in Internet Message Headers", RFC 1342, June 1992.
- Updated and replaced by Moore, K., "MIME (Multipurpose Internet
- Mail Extensions) Part Three: Message Header Extensions for
- Non-ASCII Text", RFC 2047, November 1996.
-
-[RFC1591] Postel, J., "Domain Name System Structure and Delegation",
- RFC1591, March 1994.
-
-[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
- August 1999.
-\f
-
-[STD3] Braden, R., Ed., "Requirements for Internet Hosts - Application and
- Support", RFC1123, October 1989.
-
-[STD13] Mockapetris, P.V., 1034 "Domain names - concepts and
- facilities", RFC 1034, and "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
-6. Acknowledgements
-
-This document was inspired by a number of conversations in ICANN, IETF,
-MINC, and private contexts about the future evolution and
-internationalization of top level domains. Discussions within, and
-about, the ICANN IDN Committee have been particularly helpful, although
-several of the members of that committee may be surprised about where
-those discussions led.
-
-7. Author's Address
-
-John C Klensin
-1770 Massachusetts Ave, #322
-Cambridge, MA 02140 USA
-email: john+ietf@jck.com
-\f
projects / thirdparty / bind9.git / commitdiff
