From d38cad0addd6e4fd7bfdb7823c02eb87affb5175 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 10 Mar 2004 00:39:48 +0000 Subject: [PATCH] remove expired/drafts --- doc/draft/draft-hall-dm-idns-00.txt | 2739 ------- doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt | 767 -- doc/draft/draft-ietf-dnsext-apl-rr-02.txt | 394 - ...draft-ietf-dnsext-delegation-signer-15.txt | 992 --- doc/draft/draft-ietf-idn-aceid-02.txt | 219 - doc/draft/draft-ietf-idn-cjk-01.txt | 454 -- doc/draft/draft-ietf-idn-dude-02.txt | 864 --- doc/draft/draft-ietf-idn-idna-07.txt | 612 -- doc/draft/draft-ietf-idn-idne-02.txt | 426 -- doc/draft/draft-ietf-idn-iptr-02.txt | 540 -- doc/draft/draft-ietf-idn-jpchar-01.txt | 6735 ----------------- doc/draft/draft-ietf-idn-nameprep-08.txt | 2281 ------ doc/draft/draft-ietf-idn-punycode-03.txt | 1495 ---- doc/draft/draft-ietf-idn-requirements-09.txt | 655 -- doc/draft/draft-ietf-idn-udns-03.txt | 557 -- doc/draft/draft-ietf-idn-uri-03.txt | 442 -- doc/draft/draft-ietf-idn-vidn-01.txt | 505 -- .../draft-ietf-ipngwg-dns-lookups-08.txt | 1119 --- doc/draft/draft-jseng-idn-admin-03.txt | 1335 ---- doc/draft/draft-klensin-idn-tld-00.txt | 437 -- 20 files changed, 23568 deletions(-) delete mode 100644 doc/draft/draft-hall-dm-idns-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-apl-rr-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-15.txt delete mode 100644 doc/draft/draft-ietf-idn-aceid-02.txt delete mode 100644 doc/draft/draft-ietf-idn-cjk-01.txt delete mode 100644 doc/draft/draft-ietf-idn-dude-02.txt delete mode 100644 doc/draft/draft-ietf-idn-idna-07.txt delete mode 100644 doc/draft/draft-ietf-idn-idne-02.txt delete mode 100644 doc/draft/draft-ietf-idn-iptr-02.txt delete mode 100644 doc/draft/draft-ietf-idn-jpchar-01.txt delete mode 100644 doc/draft/draft-ietf-idn-nameprep-08.txt delete mode 100644 doc/draft/draft-ietf-idn-punycode-03.txt delete mode 100644 doc/draft/draft-ietf-idn-requirements-09.txt delete mode 100644 doc/draft/draft-ietf-idn-udns-03.txt delete mode 100644 doc/draft/draft-ietf-idn-uri-03.txt delete mode 100644 doc/draft/draft-ietf-idn-vidn-01.txt delete mode 100644 doc/draft/draft-ietf-ipngwg-dns-lookups-08.txt delete mode 100644 doc/draft/draft-jseng-idn-admin-03.txt delete mode 100644 doc/draft/draft-klensin-idn-tld-00.txt diff --git a/doc/draft/draft-hall-dm-idns-00.txt b/doc/draft/draft-hall-dm-idns-00.txt deleted file mode 100644 index d3bc4b4e0d..0000000000 --- a/doc/draft/draft-hall-dm-idns-00.txt +++ /dev/null @@ -1,2739 +0,0 @@ - - - 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. - - - - 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] - 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] , "AMC-ACE-Z version - 0.3.1" - - [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) “ The ISO/IEC 10646 character - set repertoire, as represented by the Unicode 3.1 - specification. - - ACE (ASCII-Compatible Encoding) “ 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) “ 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] - 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] - 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] - 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] - 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 “ 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] - 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 “ 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 - ") 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 “ 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] - 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 “ 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] - 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] - 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] - 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] - 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] - INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001 - - - zone, with the resource record data value of - "host..example.com." (where 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] - 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] - 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] - 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] - 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] - 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] - 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 , 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] - 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] - 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] - 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] - 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] - 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] - 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 , 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] - 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]. Characters which - are prohibited by MUST NOT appear in any label - of any internationalized host identifier. - - b. Labels MUST be normalized through 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 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 (U+0041 U+0301 U+0042) would be - normalized and lowercased to (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] - 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] - 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] - 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] - 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 “ The extended label identifier. - - 0b000011 “ The EDNS/UTF-8 extended label type identifier. - - Length “ The number of octets in the label data, or the off- - set to the length octet of another EDNS/UTF-8 label. - - Label data “ 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 - (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 (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] - 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] - 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 - (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 - - 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] - 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] - 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] - 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] - 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] - 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] - 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] - 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 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] - 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] - 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] - 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] - 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] - 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] - 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] - 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] - 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] - 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] - 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 .example.com. domain name has - two associated MX resource records, one of which points to the UCS - domain name of mail..example.com, while the other points to - - Hall I-D Expires: May 2002 [page 51] - INTERNET-DRAFT draft-hall-dm-idns-00.txt November 2001 - - - the ACE encoded domain name of mail..example.net. (where the - "" 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 .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 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] - 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] - 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] , "AMC-ACE-Z version - 0.3.1" - - [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] - 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] diff --git a/doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt b/doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt deleted file mode 100644 index 9c634c094e..0000000000 --- a/doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt +++ /dev/null @@ -1,767 +0,0 @@ - - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - diff --git a/doc/draft/draft-ietf-dnsext-apl-rr-02.txt b/doc/draft/draft-ietf-dnsext-apl-rr-02.txt deleted file mode 100644 index 1a75b65f01..0000000000 --- a/doc/draft/draft-ietf-dnsext-apl-rr-02.txt +++ /dev/null @@ -1,394 +0,0 @@ - - - - - - -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 - . - -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] - -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 () 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] - -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: - - IN APL {[!]afi:address/prefix}* - - The data consists of zero or more strings of the address family - indicator , immediately followed by a colon ":", an address, - - - -Koch Expires September 2001 [Page 3] - -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 is the decimal numeric value of that particular address - family. - -5.1. Textual Representation of IPv4 Addresses - - An IPv4 address in the
part of an is in dotted - quad notation, just as in an A RR. The has values from the - interval 0..32 (decimal). - -5.2. Textual Representation of IPv6 Addresses - - The representation of an IPv6 address in the
part of an - follows [RFC2373], section 2.2. Legal values for - 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 in a single APL RR are - allowed and MUST NOT be merged by a DNS server or resolver. - MUST be kept in order and MUST NOT be rearranged or aggregated. - - A single APL RR may contain belonging to different address - families. The maximum number of 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] - -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 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] - -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] - -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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Koch Expires September 2001 [Page 7] diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-15.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-15.txt deleted file mode 100644 index 2164a10a71..0000000000 --- a/doc/draft/draft-ietf-dnsext-delegation-signer-15.txt +++ /dev/null @@ -1,992 +0,0 @@ - - - - - - - DNSEXT Working Group Olafur Gudmundsson - INTERNET-DRAFT June 2003 - - - 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] - -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] - -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] - -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] - -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] - -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] - -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 (, DS, ), 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 , 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 - '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] - -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] - -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] - -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] - -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] - -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] - -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] - -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 - example. NS ns.example. - example. KEY - 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 - 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 - secure.example. NS ns1.secure.example. - secure.example. KEY - secure.example. KEY - secure.example. NXT - secure.example. SIG(KEY) - secure.example. SIG(SOA) - secure.example. SIG(NS) - secure.example. SIG(NXT) - - 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] - -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 - ) - 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] - -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] - -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 - - - 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] - -INTERNET-DRAFT Delegation Signer Record June 2003 - - - - - - - - - - - - - - - - - Gudmundsson Expires January 2004 [Page 1] diff --git a/doc/draft/draft-ietf-idn-aceid-02.txt b/doc/draft/draft-ietf-idn-aceid-02.txt deleted file mode 100644 index 896781021f..0000000000 --- a/doc/draft/draft-ietf-idn-aceid-02.txt +++ /dev/null @@ -1,219 +0,0 @@ - -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 diff --git a/doc/draft/draft-ietf-idn-cjk-01.txt b/doc/draft/draft-ietf-idn-cjk-01.txt deleted file mode 100644 index 3344ab160c..0000000000 --- a/doc/draft/draft-ietf-idn-cjk-01.txt +++ /dev/null @@ -1,454 +0,0 @@ -Ź©ŔInternet Draft James SENG - 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 …ńł…Ĺć {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 ‚Çô 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 -Jiang Mingliang -Dongman Lee -Karlsson Kent - -Author(s) - -James SENG Äč†îŻ…«Ĺ -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 ‰©â…雷˘ä -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‚ÇÖ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 ‚Çô - 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 diff --git a/doc/draft/draft-ietf-idn-dude-02.txt b/doc/draft/draft-ietf-idn-dude-02.txt deleted file mode 100644 index 3af28936c4..0000000000 --- a/doc/draft/draft-ietf-idn-dude-02.txt +++ /dev/null @@ -1,864 +0,0 @@ -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 - -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. - - 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). - - 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 - - (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) 3b (Latin, kanji) - u+0033 u+5E74 u+0062 u+7D44 u+91D1 u+516B u+5148 u+751F - DUDE: xdx8whx8tgz7ug863f6s5kuduwxh - - (O) -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) majikoi5 (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) de (Latin, katakana) - u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0 - DUDE: vs5bezgxrvs3ibvs2qtiud - - (R) (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. - - 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 - Brian W. Spolarich - WALID, Inc. - State Technology Park - 2245 S. State St. - Ann Arbor, MI 48104 - +1 734 822 2020 - - Adam M. Costello - 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: - - -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. - - 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 */ -/******************************************/ - -/* This is ANSI C code (C89) implementing */ -/* DUDE (draft-ietf-idn-dude-02). */ - - -/************************************************************/ -/* Public interface (would normally go in its own .h file): */ - -#include - -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[] ); - - /* 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[] ); - - /* 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 - -/* 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. */ - -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. */ - - 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; - - 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 -#include -#include -#include - -/* 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_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); - - 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; - - /* 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 diff --git a/doc/draft/draft-ietf-idn-idna-07.txt b/doc/draft/draft-ietf-idn-idna-07.txt deleted file mode 100644 index e4f2a3ff43..0000000000 --- a/doc/draft/draft-ietf-idn-idna-07.txt +++ /dev/null @@ -1,612 +0,0 @@ -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 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, -. - -[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, -. - - -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 diff --git a/doc/draft/draft-ietf-idn-idne-02.txt b/doc/draft/draft-ietf-idn-idne-02.txt deleted file mode 100644 index c645528cd2..0000000000 --- a/doc/draft/draft-ietf-idn-idne-02.txt +++ /dev/null @@ -1,426 +0,0 @@ -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 , which is U+00C9. The -decomposition and downcasing specified in [NAMEPREP] changes the second -character to , 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 ). - -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 -. - - -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 - diff --git a/doc/draft/draft-ietf-idn-iptr-02.txt b/doc/draft/draft-ietf-idn-iptr-02.txt deleted file mode 100644 index b96f37cedb..0000000000 --- a/doc/draft/draft-ietf-idn-iptr-02.txt +++ /dev/null @@ -1,540 +0,0 @@ - - - - - - -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] - - diff --git a/doc/draft/draft-ietf-idn-jpchar-01.txt b/doc/draft/draft-ietf-idn-jpchar-01.txt deleted file mode 100644 index 1c87cc3d91..0000000000 --- a/doc/draft/draft-ietf-idn-jpchar-01.txt +++ /dev/null @@ -1,6735 +0,0 @@ -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 diff --git a/doc/draft/draft-ietf-idn-nameprep-08.txt b/doc/draft/draft-ietf-idn-nameprep-08.txt deleted file mode 100644 index ee022d57c2..0000000000 --- a/doc/draft/draft-ietf-idn-nameprep-08.txt +++ /dev/null @@ -1,2281 +0,0 @@ -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 "bc" would not match -"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, . - -[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 -. - -[UAX15] Mark Davis and Martin Duerst. Unicode Standard Annex #15: -Unicode Normalization Forms, Version 3.1.0. -. - -[UTR21] Mark Davis. Case Mappings. Unicode Technical Report;21. -. - - -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 ----- diff --git a/doc/draft/draft-ietf-idn-punycode-03.txt b/doc/draft/draft-ietf-idn-punycode-03.txt deleted file mode 100644 index 9240e60cf7..0000000000 --- a/doc/draft/draft-ietf-idn-punycode-03.txt +++ /dev/null @@ -1,1495 +0,0 @@ -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. - -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. - - * 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. - -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 , the next state is if i is less than the - length of the extended string, or 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. - - 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 - - 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: - - 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. - -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. - -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. - -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. - -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. - -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. - - The first several examples are all translations of the sentence "Why - can't they just speak in ?" (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: Proprostnemluvesky - 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 - - (J) Spanish: PorqunopuedensimplementehablarenEspaol - 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: - Tisaohkhngthch\ - nitingVit - 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) 3B - u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F - Punycode: 3B-ww4c5e180e575a65lsy2b - - (M) -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- - 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) 2 - u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032 - Punycode: 2-u9tlzr9756bt3uc0v - - (P) MajiKoi5 - 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) de - u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0 - Punycode: de-jg4avhby1noc0d - - (R) - u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067 - Punycode: d9juau41awczczp - - 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 - - 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. - - 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" - - 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. - - [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 - -/* -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 - -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[] ); - - /* 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. */ - -/**********************************************************/ -/* Implementation (would normally go in its own .c file): */ - -#include - -/*** 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); -} - -/*** 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) */ - } - - 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 */ - /* state to , 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; -} - -/*** 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); - } - - 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 -#include -#include -#include - -/* 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 -}; - -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); - - 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]; - - /* 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 diff --git a/doc/draft/draft-ietf-idn-requirements-09.txt b/doc/draft/draft-ietf-idn-requirements-09.txt deleted file mode 100644 index ad6e18d494..0000000000 --- a/doc/draft/draft-ietf-idn-requirements-09.txt +++ /dev/null @@ -1,655 +0,0 @@ -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 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 -Mark Andrews -RJ Atkinson -Alan Barret -Marc Blanchet -Randy Bush -Andrew Draper -Martin Duerst -Patrik Faltstrom -Ned Freed -Olafur Gudmundsson -Paul Hoffman -Simon Josefsson -Kent Karlsson -John Klensin -Tan Juay Kwang -Dongman Lee -Bill Manning -Dan Oscarsson -J. William Semich -Yoshiro Yoneda diff --git a/doc/draft/draft-ietf-idn-udns-03.txt b/doc/draft/draft-ietf-idn-udns-03.txt deleted file mode 100644 index a86887c1c9..0000000000 --- a/doc/draft/draft-ietf-idn-udns-03.txt +++ /dev/null @@ -1,557 +0,0 @@ -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/draft/draft-ietf-idn-uri-03.txt b/doc/draft/draft-ietf-idn-uri-03.txt deleted file mode 100644 index 2d44967a6c..0000000000 --- a/doc/draft/draft-ietf-idn-uri-03.txt +++ /dev/null @@ -1,442 +0,0 @@ - - - - -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, . - - [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, . - - [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, - . - - [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] diff --git a/doc/draft/draft-ietf-idn-vidn-01.txt b/doc/draft/draft-ietf-idn-vidn-01.txt deleted file mode 100644 index fbab57dfc6..0000000000 --- a/doc/draft/draft-ietf-idn-vidn-01.txt +++ /dev/null @@ -1,505 +0,0 @@ -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, '­­‚' that means 'century' in English -language, is transliterated into 'segi' in English scripts, and so, the entity -whose name contains '­­‚' in Korean language may have an entity-defined portion -of its domain name as 'segi' in English scripts. VIDN enables to use '­­‚' 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 '­­‚' in Korean scripts have the same sounds as the -phonemes represented by the characters consisting of 'segi' in English scripts. -In the local context, '­­‚' 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, 'ľž®ý', is -transliterated into 'yahoo' in English scripts, since the phonemes represented -by the characters consisting of 'ľž®ý' in Korean scripts have the same sounds as -the phonemes represented by the characters consisting of 'yahoo' in English -scripts. That is, 'ľž®ý' in Korean scripts is pronounced as the same as 'yahoo' -in English scripts, and so, it is easy for Korean-speaking people to deduce 'ľž -®ý' 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., '­­‚' in Korean scripts, as well as -domain names whose originals are in English scripts, e.g., 'ľž®ý' 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 'ýý', ' -Ŕí´€', '—Ť¦Š', 'ÁđË«', ' Ď', 'ţÚË«', 'ŔÁÚ' 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 '‚ľ•' -(meaning 'commercial' in Korean language), 'ĚĎţ' (meaning 'education' in Korean -language), 'Âń¦đ' (meaning 'government' in Korean language), ' ÂŞ' (meaning -'international' in Korean language), '¦Ŕ‹' (meaning 'military' in Korean -language), 'ţÚË«' (meaning 'network' in Korean language), and 'ł›Č­' (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, 'žľÔ.ýý', 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 'žľÔ.ýý' 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 'žľÔ.ýý' 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., 'žľÔ.ýý' | | 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 - diff --git a/doc/draft/draft-ietf-ipngwg-dns-lookups-08.txt b/doc/draft/draft-ietf-ipngwg-dns-lookups-08.txt deleted file mode 100644 index 8733d075c1..0000000000 --- a/doc/draft/draft-ietf-ipngwg-dns-lookups-08.txt +++ /dev/null @@ -1,1119 +0,0 @@ - -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 - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/draft/draft-jseng-idn-admin-03.txt b/doc/draft/draft-jseng-idn-admin-03.txt deleted file mode 100644 index 24e66a2fdb..0000000000 --- a/doc/draft/draft-jseng-idn-admin-03.txt +++ /dev/null @@ -1,1335 +0,0 @@ -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. diff --git a/doc/draft/draft-klensin-idn-tld-00.txt b/doc/draft/draft-klensin-idn-tld-00.txt deleted file mode 100644 index cbe2e15b31..0000000000 --- a/doc/draft/draft-klensin-idn-tld-00.txt +++ /dev/null @@ -1,437 +0,0 @@ -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 - -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. - - -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 - -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. - - -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 - -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 - -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. - - -[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 -