From 5bca09d7c1674a85eb4fe686a608c754f18967b4 Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Fri, 27 Apr 2001 17:54:21 +0000 Subject: [PATCH] updated drafts --- doc/draft/draft-costanzo-dns-gl-03.txt | 657 ------- doc/draft/draft-costanzo-dns-gl-04.txt | 19 + ... => draft-ietf-dnsext-dnssec-okbit-02.txt} | 84 +- ...> draft-ietf-dnsext-dnssec-roadmap-03.txt} | 172 +- doc/draft/draft-ietf-dnsext-ixfr-01.txt | 558 ------ doc/draft/draft-ietf-dnsext-ixfr-02.txt | 19 + doc/draft/draft-ietf-enum-e164s2-np-00.txt | 1596 ----------------- doc/draft/draft-ietf-enum-e164s2-np-01.txt | 19 + doc/draft/draft-ietf-enum-rqmts-01.txt | 342 ---- doc/draft/draft-ietf-enum-rqmts-02.txt | 19 + ...n-cjk-00.txt => draft-ietf-idn-cjk-01.txt} | 90 +- doc/draft/draft-ietf-idn-compare-01.txt | 687 ------- doc/draft/draft-ietf-idn-compare-02.txt | 19 + doc/draft/draft-ietf-idn-dude-00.txt | 596 ------ doc/draft/draft-ietf-idn-dude-01.txt | 898 ++++++++++ doc/draft/draft-ietf-idn-icu-00.txt | 514 ------ doc/draft/draft-ietf-idn-icu-01.txt | 19 + ...idne-01.txt => draft-ietf-idn-idne-02.txt} | 103 +- doc/draft/draft-ietf-idn-idnra-00.txt | 334 ---- doc/draft/draft-ietf-idn-idnra-01.txt | 20 + doc/draft/draft-ietf-idn-sace-00.txt | 276 --- doc/draft/draft-ietf-idn-sace-01.txt | 19 + doc/draft/draft-ietf-idn-vidn-00.txt | 537 ------ doc/draft/draft-ietf-idn-vidn-01.txt | 505 ++++++ ...ft-ietf-ipngwg-default-addr-select-03.txt} | 388 ++-- ...aft-whr-dnsext-secure-online-update-00.txt | 580 ------ ...aft-whr-dnsext-secure-online-update-01.txt | 19 + 27 files changed, 2007 insertions(+), 7082 deletions(-) delete mode 100644 doc/draft/draft-costanzo-dns-gl-03.txt create mode 100644 doc/draft/draft-costanzo-dns-gl-04.txt rename doc/draft/{draft-ietf-dnsext-dnssec-okbit-01.txt => draft-ietf-dnsext-dnssec-okbit-02.txt} (81%) rename doc/draft/{draft-ietf-dnsext-dnssec-roadmap-02.txt => draft-ietf-dnsext-dnssec-roadmap-03.txt} (89%) delete mode 100644 doc/draft/draft-ietf-dnsext-ixfr-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-ixfr-02.txt delete mode 100644 doc/draft/draft-ietf-enum-e164s2-np-00.txt create mode 100644 doc/draft/draft-ietf-enum-e164s2-np-01.txt delete mode 100644 doc/draft/draft-ietf-enum-rqmts-01.txt create mode 100644 doc/draft/draft-ietf-enum-rqmts-02.txt rename doc/draft/{draft-ietf-idn-cjk-00.txt => draft-ietf-idn-cjk-01.txt} (93%) delete mode 100644 doc/draft/draft-ietf-idn-compare-01.txt create mode 100644 doc/draft/draft-ietf-idn-compare-02.txt delete mode 100644 doc/draft/draft-ietf-idn-dude-00.txt create mode 100644 doc/draft/draft-ietf-idn-dude-01.txt delete mode 100644 doc/draft/draft-ietf-idn-icu-00.txt create mode 100644 doc/draft/draft-ietf-idn-icu-01.txt rename doc/draft/{draft-ietf-idn-idne-01.txt => draft-ietf-idn-idne-02.txt} (84%) delete mode 100644 doc/draft/draft-ietf-idn-idnra-00.txt create mode 100644 doc/draft/draft-ietf-idn-idnra-01.txt delete mode 100644 doc/draft/draft-ietf-idn-sace-00.txt create mode 100644 doc/draft/draft-ietf-idn-sace-01.txt delete mode 100644 doc/draft/draft-ietf-idn-vidn-00.txt create mode 100644 doc/draft/draft-ietf-idn-vidn-01.txt rename doc/draft/{draft-ietf-ipngwg-default-addr-select-02.txt => draft-ietf-ipngwg-default-addr-select-03.txt} (81%) delete mode 100644 doc/draft/draft-whr-dnsext-secure-online-update-00.txt create mode 100644 doc/draft/draft-whr-dnsext-secure-online-update-01.txt diff --git a/doc/draft/draft-costanzo-dns-gl-03.txt b/doc/draft/draft-costanzo-dns-gl-03.txt deleted file mode 100644 index b080a88999..0000000000 --- a/doc/draft/draft-costanzo-dns-gl-03.txt +++ /dev/null @@ -1,657 +0,0 @@ -INTERNET-DRAFT A. Costanzo -draft-costanzo-dns-gl-03.txt AKC Computer Services Corp. -Expires: December 2000 June 2000 - - - - Definition of the DNS GL Resource Record - used to encode Geographic Locations - - - - - - 1. 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. - - -To learn the current status of any Internet-Draft, please check the -"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow -Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), -munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast, or ftp.isi.edu -(US West Coast). - -Distribution of this memo is unlimited. - - -2. Abstract - -This document defines the format of a new Experimental Resource Record (RR) -namely GL for the Domain Naming System (DNS), and reserves a corresponding -DNS type mnemonic and numerical code XX (decimal). This definition deals -with associating geographical host location mappings to host names within -a domain. - - -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. - - - -Costanzo [Page 1] - -EXPIRES IN SIX MONTHS June 2000 - -3. Introduction - - The ideal way to manage and maintain a database of information, such as - geographical location of Internet hosts, is to delegate responsibility - to local domain administrators. - - This document resolves the problem of relating host information within - the DNS to geographical locations. This definition has been designed to - be easy for the person who administrates DNS for a domain. The author - hopes that the lack of requiring longitude, latitude and elevation - information and merely being able to enter address information, as you - would address a postal letter, will mean broad acceptance and use of the - GL resource record. - - The availability of geographical location information will immediately be - able to benefit applications in network management, which would enhance - and supplement various network tools which currently exist. - - The Domain Name System is ideally suited to provide geographic location - information. The information we desire to make available globally needs - to be maintained and updated locally (perfect for DNS). - - Although several other attempts by various authors have attempted to - created resource records that would allow location information on host to - be stored and distributed, none, to the authors knowledge, have either - gained acceptance on a wide scale or made allowance for location information - that is not within the confines of the planet Earth. - -4. The GL format - - GL has the following format: - - GL - - -4.1 Rdata Format - - Rdata has the following format: - - - - The format of the RDATA field is two varying length strings separated by - a space character. The first, the hierarchical locator, then an address - string. Each is quoted (like all strings) only when it has spaces in it, - which will never be true for the first string, and almost always for the - second. - - - - - - - - -Costanzo [Page 2] - -EXPIRES IN SIX MONTHS June 2000 - - -4.1.1 The Hierarchical Locator - -The Hierarchical Locator contains the following components (each separated -by a period "."): - - Astronomical Location - (Required) - A coded field defining the heavenly body within - the known Universe, where the machine resides. The most common - entry, "S3" is the planet Earth and is the only currently - defined location. - - Man-made devices (Space Stations, Rockets, Probes, etc.) not residing - on planet Earth may have Astronimical Locations defined as well. - - New locations MUST be registered with the Internet Assigned Numbers - Authority (IANA). Refer to section 6 for additional information. - - Country Code - (Required) - - The country code specifies the country the host computer resides - in. The code is a two character fixed length string and may only - be included within the Astronimical Location 'S3'. These codes - are defined in document ISO 3166-1 and are listed in Appendix A - for easy reference. - - Postal Zone - (Optional) - - This rdata component supplies the postal code (Zip Code) for the - location the host computer resides. For countries that have a - multi-segmented postal coding system, the segments should be - separated by period(s) ".". - - This field may be omitted only if the country in which the host - machine resides does not use a postal coding system. - - When all three Hierarchical Locator components exist for an DNS - entry, the position being defined is considered to be a "precise - position". - - - 4.2 The Quoted String - - This string should be entered as you would enter an address on - a postal letter within the country specified by the Hierarchical - Locator. The country code information should not be included within - the quoted string. This string is always required and must be - present in the RDATA field. - - The quoted string may be used for both visual reference of the - physical address as well as by a software application to help - determine a more precise location of the host machine (if the - Hierarchical Locator lacks sufficient precision). - - - -Costanzo [Page 3] - -EXPIRES IN SIX MONTHS June 2000 - - - The only instance in which any application should attempt to - interpret the quoted string is in a case where the country - code defines a country that does not use, or has not implemented - a postal code system. - - No software or application should attempt to override a precise - position defined by the Hierarchical Locator with information - defined within the quoted string data. - - - 5. Example(s) - - Example 1 (with a postal zone defined): - - donuts A 192.188.192.1 - GL S3.US.45420.1910 "1425 Arbor Avenue, Dayton OH" - - Example 2 (no postal zone): - - lorinda A 129.122.1.1 - GL S3.SR "Marthastrasse 64, Shawproject, Uitvlug, Parimaribo" - - Example 3 - -; Authoritative data for akc.net. -; -; note in this example: -; uspring, diana and martha (even though the complete postal code was -; not entered) are precisely defined -; -; lorinda, resides in the country of SURINAME, which has not implemented -; a postal coding system. -; -; THIS IS ONLY AN EXAMPLE -; -@ IN SOA forme.akc.net. postmaster.akc.net. - ( - 99071100 ; Serial (yymmddnn) - 10800 ; Refresh (3 hours) - 3600 ; Retry (1 hour) - 3600000 ; Expire (1000 hours) - 86400 ; Minimum (24 hours) - ) - - IN NS ns.akc.net. - -uspring IN A 192.188.192.2 - IN MX 5 mail - IN HINFO Vax VMS - IN GL S3.US.45420.1910 "1425 Arbor Avenue, Dayton OH" -ftp IN CNAME uspring - - - -Costanzo [Page 4] - -EXPIRES IN SIX MONTHS June 2000 - - - -diana IN A 192.188.192.3 - IN MX 5 mail - IN HINFO Vax VMS - IN GL S3.US.07204.1367 "808 Chestnut Street, Roselle -Park, NJ" -www IN CNAME diana - -martha IN A 192.188.192.4 - IN MX 5 mail - IN HINFO Vax VMS - IN GL S3.US.07204 "815 Chestnut Willis Place, Roselle -Park, NJ" - -lorinda IN A 129.122.1.1 - IN GL S3.SR "Marthastrasse 64, Shawproject, Uitvlug, -Parimaribo" - - -6. Registering New Astronomical Location(s) - - New Astronomical Locations (ALs) MUST be registered with the Internet - Assigned Numbers Authority (IANA). IANA acts as a central registry for - these values. IANA may reject or modify the Astronomical Location - registration request if it does not meet the criteria as specified in - section 4.1.1. - - Registration requests should be sent via electronic mail to IANA as - follows: - - To: IANA@iana.org - Subject: Registration of a new Astronomical Location - - The mail message must specify the proposed AL. Documentation defining - the AL and its proposed purpose must be included. The documentation must - either reference an external non-Internet standards document or an existing - or soon to be RFC. If applicable, the documentation should contain a - draft version of the future RFC. The draft must be submitted as a - RFC according to the normal procedure within a reasonable amount of - time after the AL registration has been approved. - - IANA will not register a new Astronmical Location until an actual - computer requiring GL data in the DNS resides or will soon reside on a - heavenly body other than Earth. - - - - - - - - - - -Costanzo [Page 5] - -EXPIRES IN SIX MONTHS May 2000 - - - -7. Notes To Implementors: - -7.1 Defining New Astronimical Locations - - The astronomical location 'S3' is intended to be Sol-Three (i.e. the Earth). - The Earth is the 3rd large planet in the solar system. The Sun would be S0 - (not that we'd have a computer there), but a solar observatory in orbit might - be S0-001. Our moon would be S3-1. Other letters and such for catalogued - objects. Additionally, the ISS and Mir space stations could use S3-001 (Mir), - S3-002 (ISS) now, if they get connected on IP. - - This document only defines 'S3' however the authors strongly suggest that the - above nomenclature be followed. - - -7.2 Other possible uses for GL - - The use of postal codes also is exactly what is needed for credit card address - authentication. Sites could (quietly) compare GL info provided on entries from - ISPs to what someone enters for additional verification purposes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Costanzo [Page 6] - -EXPIRES IN SIX MONTHS June 2000 - - -8. Appendix A: ISO 3166-1 Country Codes - - The ISO country codes are merely listed here for easy reference and may - become out-of-date in this document. Any changes in the ISO specification - supercede this appendix and the ISO specification must be followed. - - -AFGHANISTAN AF -ALBANIA AL -ALGERIA DZ -AMERICAN SAMOA AS -ANDORRA AD -ANGOLA AO -ANGUILLA AI -ANTARCTICA AQ -ANTIGUA AND BARBUDA AG -ARGENTINA AR -ARMENIA AM -ARUBA AW -AUSTRALIA AU -AUSTRIA AT -AZERBAIJAN AZ -BAHAMAS BS -BAHRAIN BH -BANGLADESH BD -BARBADOS BB -BELARUS BY -BELGIUM BE -BELIZE BZ -BENIN BJ -BERMUDA BM -BHUTAN BT -BOLIVIA BO -BOSNIA AND HERZEGOWINA BA -BOTSWANA BW -BOUVET ISLAND BV -BRAZIL BR -BRITISH INDIAN OCEAN TERRITORY IO -BRUNEI DARUSSALAM BN -BULGARIA BG -BURKINA FASO BF -BURUNDI BI -CAMBODIA KH -CAMEROON CM -CANADA CA -CAPE VERDE CV -CAYMAN ISLANDS KY -CENTRAL AFRICAN REPUBLIC CF -CHAD TD -CHILE CL -CHINA CN -CHRISTMAS ISLAND CX - - -Costanzo [Page 7] - -EXPIRES IN SIX MONTHS June 2000 - -COCOS (KEELING) ISLANDS CC -COLOMBIA CO -COMOROS KM -CONGO CG -COOK ISLANDS CK -COSTA RICA CR -COTE D'IVOIRE CI -CROATIA HR -CUBA CU -CYPRUS CY -CZECH REPUBLIC CZ -DENMARK DK -DJIBOUTI DJ -DOMINICA DM -DOMINICAN REPUBLIC DO -EAST TIMOR TP -ECUADOR EC -EGYPT EG -EL SALVADOR SV -EQUATORIAL GUINEA GQ -ERITREA ER -ESTONIA EE -ETHIOPIA ET -FALKLAND ISLANDS (MALVINAS) FK -FAROE ISLANDS FO -FIJI FJ -FINLAND FI -FRANCE FR -FRANCE, METROPOLITAN FX -FRENCH GUIANA GF -FRENCH POLYNESIA PF -FRENCH SOUTHERN TERRITORIES TF -GABON GA -GAMBIA GM -GEORGIA GE -GERMANY DE -GHANA GH -GIBRALTAR GI -GREECE GR -GREENLAND GL -GRENADA GD -GUADELOUPE GP -GUAM GU -GUATEMALA GT -GUINEA GN -GUINEA-BISSAU GW -GUYANA GY -HAITI HT -HEARD AND MC DONALD ISLANDS HM -HONDURAS HN -HONG KONG HK -HUNGARY HU - - -Costanzo [Page 8] - -EXPIRES IN SIX MONTHS June 2000 - - -ICELAND IS -INDIA IN -INDONESIA ID -IRAN (ISLAMIC REPUBLIC OF) IR -IRAQ IQ -IRELAND IE -ISRAEL IL -ITALY IT -JAMAICA JM -JAPAN JP -JORDAN JO -KAZAKHSTAN KZ -KENYA KE -KIRIBATI KI -KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF KP -KOREA, REPUBLIC OF KR -KUWAIT KW -KYRGYZSTAN KG -LAO PEOPLE'S DEMOCRATIC REPUBLIC LA -LATVIA LV -LEBANON LB -LESOTHO LS -LIBERIA LR -LIBYAN ARAB JAMAHIRIYA LY -LIECHTENSTEIN LI -LITHUANIA LT -LUXEMBOURG LU -MACAU MO -MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF MK -MADAGASCAR MG -MALAWI MW -MALAYSIA MY -MALDIVES MV -MALI ML -MALTA MT -MARSHALL ISLANDS MH -MARTINIQUE MQ -MAURITANIA MR -MAURITIUS MU -MAYOTTE YT -MEXICO MX -MICRONESIA (FEDERATED STATES OF) FM -MOLDOVA, REPUBLIC OF MD -MONACO MC -MONGOLIA MN -MONTSERRAT MS -MOROCCO MA -MOZAMBIQUE MZ -MYANMAR MM -NAMIBIA NA -NAURU NR -NEPAL NP -NETHERLANDS NL -NETHERLANDS ANTILLES AN -NEW CALEDONIA NC - - -Costanzo [Page 9] - -EXPIRES IN SIX MONTHS June 2000 - -NEW ZEALAND NZ -NICARAGUA NI -NIGER NE -NIGERIA NG -NIUE NU -NORFOLK ISLAND NF -NORTHERN MARIANA ISLANDS MP -NORWAY NO -OMAN OM -PAKISTAN PK -PALAU PW -PANAMA PA -PAPUA NEW GUINEA PG -PARAGUAY PY -PERU PE -PHILIPPINES PH -PITCAIRN PN -POLAND PL -PORTUGAL PT -PUERTO RICO PR -QATAR QA -REUNION RE -ROMANIA RO -RUSSIAN FEDERATION RU -RWANDA RW -ST. HELENA SH -SAINT KITTS AND NEVIS KN -SAINT LUCIA LC -ST. PIERRE AND MIQUELON PM -SAINT VINCENT AND THE GRENADINES VC -SAMOA WS -SAN MARINO SM -SAO TOME AND PRINCIPE ST -SAUDI ARABIA SA -SENEGAL SN -SEYCHELLES SC -SIERRA LEONE SL -SINGAPORE SG -SLOVAKIA SK -SLOVENIA SI -SOLOMON ISLANDS SB -SOMALIA SO -SOUTH AFRICA ZA -SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS GS -SPAIN ES -SRI LANKA LK -SUDAN SD -SURINAME SR -SVALBARD AND JAN MAYEN ISLANDS SJ -SWAZILAND SZ -SWEDEN SE -SWITZERLAND CH -SYRIAN ARAB REPUBLIC SY - - -Costanzo [Page 10] - -EXPIRES IN SIX MONTHS June 2000 - -TAIWAN, PROVINCE OF CHINA TW -TAJIKISTAN TJ -TANZANIA, UNITED REPUBLIC OF TZ -THAILAND TH -TOGO TG -TOKELAU TK -TONGA TO -TRINIDAD AND TOBAGO TT -TUNISIA TN -TURKEY TR -TURKMENISTAN TM -TURKS AND CAICOS ISLANDS TC -TUVALU TV -UGANDA UG -UKRAINE UA -UNITED ARAB EMIRATES AE -UNITED KINGDOM GB -UNITED STATES US -UNITED STATES MINOR OUTLYING ISLANDS UM -URUGUAY UY -UZBEKISTAN UZ -VANUATU VU -VATICAN CITY STATE (HOLY SEE) VA -VENEZUELA VE -VIET NAM VN -VIRGIN ISLANDS (BRITISH) VG -VIRGIN ISLANDS (U.S.) VI -WALLIS AND FUTUNA ISLANDS WF -WESTERN SAHARA EH -YEMEN YE -YUGOSLAVIA YU -ZAIRE ZR -ZAMBIA ZM -ZIMBABWE ZW - - -9. Acknowledgments - - The author would like to thank - -James Sears - for his continual editing effort -Robert Ullmann - for his input - -and the members of the namedroppers mailing list for both their support and -criticism of this document. - -10. Author's Address - -Al Costanzo -AKC Computer Services Corp. - P.O. Box 4031, Roselle Park, NJ 07204-0531 - www.AKC.com -Phone: +1 908 298 9000 -Email: AL@AKC.COM - -Costanzo [Page 11] \ No newline at end of file diff --git a/doc/draft/draft-costanzo-dns-gl-04.txt b/doc/draft/draft-costanzo-dns-gl-04.txt new file mode 100644 index 0000000000..02c5312b2b --- /dev/null +++ b/doc/draft/draft-costanzo-dns-gl-04.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +A. Costanzo: al@akc.com + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-okbit-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-okbit-02.txt similarity index 81% rename from doc/draft/draft-ietf-dnsext-dnssec-okbit-01.txt rename to doc/draft/draft-ietf-dnsext-dnssec-okbit-02.txt index f84a21ce74..5904cc8937 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-okbit-01.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-okbit-02.txt @@ -5,8 +5,8 @@ INTERNET-DRAFT David Conrad -draft-ietf-dnsext-dnssec-okbit-01.txt Nominum Inc. - November, 2000 +draft-ietf-dnsext-dnssec-okbit-02.txt Nominum Inc. + May, 2001 Indicating Resolver Support of DNSSEC @@ -55,9 +55,9 @@ Abstract -Expires May, 2001 [Page 1] +Expires October, 2001 [Page 1] -draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000 +draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001 This document discusses a method to avoid these negative impacts, @@ -74,15 +74,15 @@ draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000 2. Rationale - As DNSSEC is deployed, the vast majority of queries will be from - resolvers that are not DNSSEC aware and thus do not understand or - support the DNSSEC security RRs. When a query from such a resolver - is received for a DNSSEC signed zone, the DNSSEC specification - indicates the nameserver must respond with the appropriate DNSSEC - security RRs. As DNS UDP datagrams are limited to 512 bytes - [RFC1035], responses including DNSSEC security RRs have a high - probability of resulting in a truncated response being returned and - the resolver retrying the query using TCP. + Initially, as DNSSEC is deployed, the vast majority of queries will + be from resolvers that are not DNSSEC aware and thus do not + understand or support the DNSSEC security RRs. When a query from + such a resolver is received for a DNSSEC signed zone, the DNSSEC + specification indicates the nameserver must respond with the + appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to + 512 bytes [RFC1035], responses including DNSSEC security RRs have a + high probability of resulting in a truncated response being returned + and the resolver retrying the query using TCP. TCP DNS queries result in significant overhead due to connection setup and teardown. Operationally, the impact of these TCP queries @@ -111,9 +111,9 @@ draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000 -Expires May, 2001 [Page 2] +Expires October, 2001 [Page 2] -draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000 +draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001 non-compliant caching or forwarding servers inappropriately copy data @@ -167,9 +167,9 @@ draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000 -Expires May, 2001 [Page 3] +Expires October, 2001 [Page 3] -draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000 +draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001 DNSSEC security RRs and SHOULD retry the query without the EDNS0 in @@ -182,16 +182,28 @@ Security Considerations that zone as the response may be forged or a non-forged response of an altered (DO bit cleared) query. -IANA Considerations +IANA considerations: - Allocation of the most significant bit of the Z field in the EDNS0 - OPT meta-RR is required. + EDNS0[RFC2761] defines 16 bits as extened flags in the OPT record, + these bits are encoded into the TTL field of the OPT record (RFC2761 + section 4.6). + + This document reserves one of these bits as the OK bit. It is + requested that the left most bit be allocated. Thus the USE of the + OPT record TTL field would look like + + +0 (MSB) +1 (LSB) + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 0: | EXTENDED-RCODE | VERSION | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 2: |DO| Z | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Acknowledgements This document is based on a rough draft by Bob Halley with input from Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush, - Rob Austein, and Steve Bellovin. + Rob Austein, Steve Bellovin, and Erik Nordmark. References @@ -208,6 +220,14 @@ References 2535, March 1999. [RFC2671] Vixie, P., Extension Mechanisms for DNS (EDNS0)", RFC 2671, + + + +Expires October, 2001 [Page 4] + +draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001 + + August 1999 Author's Address @@ -220,14 +240,6 @@ Author's Address Phone: +1 650 779 6003 - - - -Expires May, 2001 [Page 4] - -draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000 - - Email: david.conrad@nominum.com @@ -267,17 +279,5 @@ Full Copyright Statement - - - - - - - - - - - - -Expires May, 2001 [Page 5] +Expires October, 2001 [Page 5] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt similarity index 89% rename from doc/draft/draft-ietf-dnsext-dnssec-roadmap-02.txt rename to doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt index a94c4f434f..9f35184a65 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-02.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt @@ -6,7 +6,7 @@ DNEXT Working Group S. Rose Internet Draft NIST -Expires: August 2001 February 2001 +Expires: November 2001 April 2001 Category: Informational @@ -14,7 +14,7 @@ Category: Informational DNS Security Document Roadmap ------------------------------ - + Status of this Document @@ -61,7 +61,7 @@ Rose [Page 1] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 overview of what to find in which document and author @@ -120,7 +120,7 @@ Rose [Page 2] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 1. Introduction @@ -180,7 +180,7 @@ Rose [Page 3] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 possible that some documents fall into more than one of these @@ -207,11 +207,12 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 | [RFC2538, | | [RFC2535, | | [SSH-DNS] | | RFC2931, | | RFC3007, | +-------------+ | NO] | | RFC3008, | - +------------+ | CLARIFY, | + +------------+ | RFC3090, | | SIZE ] | | OKBIT, | | ADBIT, | - | OPTIN ] | + | OPTIN, | + | PARSIG ] | +-----------+ | | @@ -233,14 +234,13 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 - Rose [Page 4] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 The "DNSSEC protocol" document set refers to the document that makes @@ -258,8 +258,9 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 lines of RFC/Internet Draft author guidelines). Also, the portions of the specification to be modified SHOULD be synopsized in the new document for the benefit of the reader. The "DNSSEC protocol" set - includes the documents [RFC2535], [RFC3007], [RFC3008], [CLARIFY], - [SIZE], [OKBIT], [ADBIT] and their derivative documents. + includes the documents [RFC2535], [RFC3007], [RFC3008], [RFC3090], + [SIZE], [OKBIT], [ADBIT], [OPTIN], [PARSIG] and their derivative + documents. The "New Security RRs" set refers to the group of documents that seek to add additional Resource Records to the set of base DNS Record @@ -289,8 +290,7 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 vidual user public keys (PGP, e-mail, etc.) Some documents in this group may fall beyond the DNSEXT WG scope, but they are included because of their use of the security extensions. The documents in - this group should not propose any changes to the DNS protocol to sup- - port other protocols; only how existing DNS security records and + this group should not propose any changes to the DNS protocol to @@ -300,9 +300,10 @@ Rose [Page 5] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 + support other protocols; only how existing DNS security records and transactions can be used to support other protocols. One such docu- ment is [SSH-DNS] which deals with storing SSH keys in the DNS using the security records. @@ -318,8 +319,8 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 two Internet Drafts that fall under this category: the report on the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover [ROLLOVER]. These documents were submitted through the DNSOP Working - Group, however the main concern of thesee documents is the implemen- - tation and limitations of the DNS security extensions, hence their + Group, however the main concern of these documents is the implementa- + tion and limitations of the DNS security extensions, hence their interest to the DNS security community. The CAIRN draft deals with the implementation of a secure DNS, and the draft on key rollover deals with updating DNS keys in a secure fashion. Authors of docu- @@ -345,12 +346,11 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 col to add security should follow common guidelines as to minimum required content and structure. It is the purpose of this document roadmap to establish criteria for content that any new DNS security - protocol specifications document SHOULD contain. This criteria + protocol specifications document SHOULD contain. These criteria SHOULD be interpreted as a minimum set of information required/needed in a document, any additional information regarding the specific extension should also be included in the document. These criteria are not officially part of the IETF guidelines regarding RFC/Internet - Drafts, but should be considered as guidance to promote uniformity to @@ -360,9 +360,10 @@ Rose [Page 6] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 + Drafts, but should be considered as guidance to promote uniformity to Working Group documents. Since the addition of security to the DNS protocol is now considered @@ -409,8 +410,7 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 In addition, authors are encouraged to include any necessary descrip- tion of the algorithm itself, as well as any know/suspected weaknesses as an appendix to the document. This is for reference - only, as the goals of the DNSEXT working group is to propose exten- - sions to the DNS protocol, not cryptographic research. + only, as the goals of the DNSEXT working group is to propose @@ -420,7 +420,10 @@ Rose [Page 7] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 + + + extensions to the DNS protocol, not cryptographic research. 4.3 Refinement of Security Procedures @@ -468,9 +471,6 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 6. Acknowledgements In addition to the RFCs mentioned in this document, there are also - numerous Internet drafts that fall in one or more of the categories - of DNS Security documents mentioned above. Depending on where (and - if) these documents are on the IETF standards track, the reader may @@ -480,41 +480,44 @@ Rose [Page 8] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 + numerous Internet drafts that fall in one or more of the categories + of DNS Security documents mentioned above. Depending on where (and + if) these documents are on the IETF standards track, the reader may not be able to access these documents through the RFC repositories. - For that reason, the version of the Internet drafts that were refer- - enced in this document are given below: + All of these documents are "Work in Progress" and are subject to + change, therefore a version number is not supplied for the current + revision. * SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". - * CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone - Status" - * AUTH: B. Wellington. "Domain Name System Security (DNSSEC) - Signing Authority" + dnsind-sigalgopt-NN.txt> * CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa- - tion in the CAIRN Testbed". + tion in the CAIRN Testbed". * UPDATE: B. Wellington. "Secure Domain Name System (DNS) Dynamic - Update". + Update". * SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver - message size requirements". + message size requirements". * GSS-TSIG: S. Kwan, P. Garg, J. Gilroy, and L. Esibov. "GSS - Algorithm for TSIG (GSS-TSIG)". + Algorithm for TSIG (GSS-TSIG)". * NO: S. A. Josefsson. "Authenticating Denial of Existence in DNS - with Minimum Disclosure". + with Minimum Disclosure". * OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC". - + * RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the - Domain Name System (DNS)" + Domain Name System (DNS)" * ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS) - Security Key Rollover" . + Security Key Rollover" . * ADBIT: B. Wellington. "Redefinition of DNS AD bit" + ietf-dnsext-ad-is-secure-NN.txt> * OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" + kosters-dnsext-dnssec-opt-in-NN.txt> * SSH-DNS: W. Griffin. "Storing SSH Host Keys in DNS" + griffin-ssh-host-keys-in-dns-NN.txt> + * PARSIG: R. Geiben, T. Lindgreen. "Parent's SIG Over Child's + KEY" + 7. References @@ -528,9 +531,6 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 (DNS)", RFC 2536, March 1999. [RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update", - RFC 2137, April 1997. - - [RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain @@ -540,9 +540,12 @@ Rose [Page 9] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 + RFC 2137, April 1997. + + [RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. [RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the @@ -554,6 +557,9 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 [RFC2931] D. Eastlake "DNS Request and Transaction Signatures (SIG(0))" RFC 2931, September 2000. + [RFC3090] E. Lewis "DNS Security Extensions Clarification on Zone + Status" RFC 3090, March 2001. + [RFC1591] J. Postal, "Domain Name System Structure and Delegation", RFC 1591, March 1994. @@ -588,19 +594,46 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001 -Expiration and File Name: - - This draft, titled expires June 2001 - - - Rose [Page 10] -INTERNET-DRAFT DNS Security Document Roadmap February 2001 +INTERNET-DRAFT DNS Security Document Roadmap April 2001 + + +Expiration and File Name: + + This draft, titled expires November + + + + + + + + + + + + + + + + + + + + + + + + + + + 2001 + Full Copyright Statement @@ -618,6 +651,18 @@ Full Copyright Statement Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as + + + +Rose [Page 11] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap April 2001 + + required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be @@ -654,6 +699,21 @@ Full Copyright Statement -Rose [Page 11] + + + + + + + + + + + + + + + +Rose [Page 12] diff --git a/doc/draft/draft-ietf-dnsext-ixfr-01.txt b/doc/draft/draft-ietf-dnsext-ixfr-01.txt deleted file mode 100644 index d9373cbe43..0000000000 --- a/doc/draft/draft-ietf-dnsext-ixfr-01.txt +++ /dev/null @@ -1,558 +0,0 @@ - -INTERNET DRAFT M. Ohta -draft-ietf-dnsext-ixfr-01.txt Tokyo Institute of Technology - June 2000 - - Incremental Zone Transfer in DNS - -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. - - Copyright (C) The Internet Society (March/5/2000). All Rights - Reserved. - -Abstract - - This document proposes extensions to the DNS protocols to provide an - incremental zone transfer (IXFR) mechanism. - -1. Introduction - - For rapid propagation of changes to a DNS database [STD13], it is - necessary to reduce latency by actively notifying servers of the - change. This is accomplished by the NOTIFY extension of the DNS - [NOTIFY]. - - The current full zone transfer mechanism (AXFR) is not an efficient - means to propagate changes to a small part of a zone, as it transfers - the entire zone file. - - Incremental transfer (IXFR) as proposed is a more efficient - mechanism, as it transfers only the changed portion(s) of a zone. - - - -M. Ohta Expires on December 5, 2000 [Page 1] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - - In this document, a secondary name server which requests IXFR is - called an IXFR client and a primary or secondary name server which - responds to the request is called an IXFR server. - - The current AXFR specification in [STD13] is very terse, and in - practice it does not contain sufficient information to construct - interoperable implementations. This memo assumes AXFR protocol used - in existing interoperable implementations. - -2. Brief Description of the Protocol - - If an IXFR client, which likely has an older version of a zone, - thinks it needs new information about the zone (typically through SOA - refresh timeout or the NOTIFY mechanism), it sends an IXFR message - containing the SOA serial number of its, presumably outdated, copy of - the zone. - - An IXFR server should keep record of the newest version of the zone - and the differences between that copy and several older versions. - When an IXFR request with an older version number is received, the - IXFR server needs to send only the differences required to make that - version current. Alternatively, the server may choose to transfer - the entire zone just as in a normal full zone transfer. - - When a zone has been updated, it should be saved in stable storage - before the new version is used to respond to IXFR (or AXFR) queries. - Otherwise, if the server crashes, data which is no longer available - may have been distributed to secondary servers, which can cause - persistent database inconsistencies. - - If an IXFR query with the same or newer version number than that of - the server is received, it is replied to with a single SOA record of - the server's current version, just as a SOA query before TCP AXFR. - - Transport of a query may be by either UDP or TCP. If an IXFR query - is via UDP, the IXFR server may attempt to reply using UDP if the - entire response can be contained in a single UDP packet. If the UDP - reply does not fit, the query is responded to with a single SOA - record of the server's current version to inform the client that a - TCP query should be initiated. - - Thus, a client should first make an IXFR query using UDP. If the - query type or other part of the query is not recognized by the - server, an AXFR (preceded by a UDP SOA query) should be tried, - ensuring backward compatibility. If the query response is a single - packet with the entire new zone, or if the server does not have a - newer version than the client, everything is done. Otherwise, a TCP - IXFR query should be tried. - - - -M. Ohta Expires on December 5, 2000 [Page 2] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - - To ensure integrity, servers should use UDP checksums for all UDP - responses. A cautious client which receives a UDP packet with a - checksum value of zero should ignore the result and try a TCP IXFR - instead. - - The query type value of IXFR assigned by IANA is 251. - -3. Query Format - - The IXFR query packet format is the same as that of a normal DNS - query, but with the query type being IXFR and the authority section - containing the SOA record of client's version of the zone. - -4. Response Format - - If incremental zone transfer is not available, the entire zone is - returned. The first and the last RR of the response is the SOA - record of the zone. I.e. the behavior is the same as an AXFR - response except the query type is IXFR. - - If incremental zone transfer is available, one or more difference - sequences is returned. The list of difference sequences is preceded - and followed by a copy of the server's current version of the SOA. - - Each difference sequence represents one update to the zone (one SOA - serial change) consisting of deleted RRs and added RRs. The first RR - of the deleted RRs is the older SOA RR and the first RR of the added - RRs is the newer SOA RR. - - Modification of an RR is performed first by removing the original RR - and then adding the modified one. - - Each individual difference sequence must leave the zone in a - consistent state with contents identical to those visible in the - master at the time identified by the new SOA serial number. During a - transfer, the slave server may save the zone data to stable storage - and use it in responding to queries after applying one or more - complete difference sequences even if they do not yet form a complete - incremental transfer. - - A difference sequence which indicates the removal of a non-existent - RR is an indication of an error that the IXFR client is out-of-sync - with the IXFR server. The IXFR SHOULD be aborted, and an AXFR - requested from the same server. A difference sequence which - indicates the addition of a seemingly duplicate (though a node may - have multiple TXT RR's with duplicate content) or conflicting RR may - just be a malformed zone. In any case the IXFR should be aborted and - AXFR performed. - - - -M. Ohta Expires on December 5, 2000 [Page 3] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - - The sequences of differential information are ordered oldest first - newest last. Thus, the differential sequences are the history of - changes made since the version known by the IXFR client up to the - server's current version. - - RR sets (RRs of the same RR types) in the incremental transfer - messages may be partial. For example, if a single RR of multiple RRs - of the same RR type changes, only the changed RR needs to be - transferred. - - An IXFR client, should only replace an older version with a newer - version after all the differences have been successfully processed. - - An incremental response is different from that of a non-incremental - response in that it begins with two SOA RRs, the server's current SOA - followed by the SOA of the client's version which is about to be - replaced. - - A slave receiving an IXFR response needs to classify it as one of the - following four cases: - - UDP-overflow An indication that the transfer will not fit in a - UDP packet and should be retried over TCP - - up-to-date An indication that the serial number of the - request is current and no transfer is necessary - - incremental An incremental transfer - - nonincremental A full zone transfer - - Performing this classification requires some care. For example, - UDP-overflow responses differ from UDP up-to-date responses only in - the value of the SOA serial number. Also, to distinguish between a - nonincremental and an incremental transfer, the slave needs to - receive the first two response RRs and check whether the second one - is a SOA. If the master chose to transmit each RR in a separate TCP - message, this involves waiting for a second TCP response message. On - the other hand, in the case of an up-to-date response, the slave must - not wait for a second TCP message as doing so would cause it to hang - waiting for a message the master will never send. Therefore, the - slave must examine the first message and eliminate the possibility - that it is a TCP up-to-date response before it attempts to receive a - second message. - - Slaves must not attempt to classify a response based on incidental - information such as the presence or absence of a question section, - the QTYPE field of a possible question section, or the number of - - - -M. Ohta Expires on December 5, 2000 [Page 4] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - - response RRs in a TCP response message. - - An example algorithm for classifying IXFR responses appears in - Appendix A. - -5. Purging Strategy - - An IXFR server can not be required to hold all previous versions - forever and may delete them anytime. In general, there is a trade- - off between the size of storage space and the possibility of using - IXFR. - - Information about older versions should be purged if the total length - of an IXFR response would be longer than that of an AXFR response. - Given that the purpose of IXFR is to reduce AXFR overhead, this - strategy is quite reasonable. The strategy assures that the amount - of storage required is at most twice that of the current zone - information. - - Information older than the SOA expire period should also be purged. - -6. Optional Condensation of Multiple Versions - - An IXFR server may optionally condense multiple difference sequences - into a single difference sequence, thus, dropping information on - intermediate versions. - - This may be beneficial if a lot of versions, not all of which are - useful, are generated. For example, if multiple ftp servers share a - single DNS name and the IP address associated with the name is - changed once a minute to balance load between the ftp servers, it is - not so important to keep track of all the history of changes. - - But, this feature may not be so useful if an IXFR client has access - to two IXFR servers: A and B, with inconsistent condensation results. - The current version of the IXFR client, received from server A, may - be unknown to server B. In such a case, server B can not provide - incremental data from the unknown version and a full zone transfer is - necessary. - - Condensation is completely optional. Clients can't detect from the - response whether the server has condensed the reply or not. - - For interoperability, IXFR servers, including those without the - condensation feature, should not flag an error even if it receives a - client's IXFR request with a version number known not to exist (which - means that the server has versions with version numbers newer and - older than, but not equal to, the version number) and should, - - - -M. Ohta Expires on December 5, 2000 [Page 5] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - - instead, attempt to perform a full zone transfer by replying with a - single SOA record of the server's current version (UDP case) or with - a full zone content (UDP or TCP case). - -7. Example - - Given the following three generations of data with the current serial - number of 3, - - example.domain. IN SOA ns.example.domain. rt.example.domain. ( - 1 600 600 3600000 604800) - IN NS ns.example.domain. - ns.example.domain. IN A 10.0.0.1 - ftp.example.domain. IN A 10.0.1.1 - - ftp.example.domain. is removed and www.example.domain. is added. - - example.domain. IN SOA ns.example.domain. rt.example.domain. ( - 2 600 600 3600000 604800) - IN NS ns.example.domain. - ns.example.domain. IN A 10.0.0.1 - www.example.domain. IN A 10.0.1.2 - IN A 10.0.2.1 - - One of the IP addresses of www.example.domain. is changed. - - example.domain. IN SOA ns.example.domain. rt.example.domain. ( - 3 600 600 3600000 604800) - IN NS ns.example.domain. - ns.example.domain. IN A 10.0.0.1 - www.example.domain. IN A 10.0.3.1 - IN A 10.0.2.1 - - The following IXFR query - - +---------------------------------------------------+ - Header | OPCODE=SQUERY | - +---------------------------------------------------+ - Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | | - +---------------------------------------------------+ - Authority | example.domain. IN SOA serial=1 | - +---------------------------------------------------+ - Additional | | - +---------------------------------------------------+ - - could be replied to with the following full zone transfer message: - - - -M. Ohta Expires on December 5, 2000 [Page 6] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | example.domain. IN SOA serial=3 | - | example.domain. IN NS NS.JAIN.AD.JP. | - | ns.example.domain. IN A 10.0.0.1 | - | www.example.domain. IN A 10.0.3.1 | - | www.example.domain. IN A 10.0.2.1 | - | example.domain. IN SOA serial=3 | - +---------------------------------------------------+ - Authority | | - +---------------------------------------------------+ - Additional | | - +---------------------------------------------------+ - - or with the following incremental message: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | example.domain. IN SOA serial=3 | - | example.domain. IN SOA serial=1 | - | ftp.example.domain. IN A 10.0.1.1 | - | example.domain. IN SOA serial=2 | - | www.example.domain. IN A 10.0.1.2 | - | www.example.domain. IN A 10.0.2.1 | - | example.domain. IN SOA serial=2 | - | www.example.domain. IN A 10.0.1.2 | - | example.domain. IN SOA serial=3 | - | www.example.domain. IN A 10.0.3.1 | - | example.domain. IN SOA serial=3 | - +---------------------------------------------------+ - Authority | | - +---------------------------------------------------+ - Additional | | - +---------------------------------------------------+ - - or with the following condensed incremental message: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - - - -M. Ohta Expires on December 5, 2000 [Page 7] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - - Answer | example.domain. IN SOA serial=3 | - | example.domain. IN SOA serial=1 | - | ftp.example.domain. IN A 10.0.1.1 | - | example.domain. IN SOA serial=3 | - | www.example.domain. IN A 10.0.3.1 | - | www.example.domain. IN A 10.0.2.1 | - | example.domain. IN SOA serial=3 | - +---------------------------------------------------+ - Authority | | - +---------------------------------------------------+ - Additional | | - +---------------------------------------------------+ - - or, if UDP packet overflow occurs, with the following message: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | example.domain. IN SOA serial=3 | - +---------------------------------------------------+ - Authority | | - +---------------------------------------------------+ - Additional | | - +---------------------------------------------------+ - -8. Acknowledgements - - The original idea of IXFR was conceived by Anant Kumar, Steve Hotz - and Jon Postel. - - For the refinement of the protocol and documentation, many people - have contributed including, but not limited to, Anant Kumar, Robert - Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz, Andreas - Gustafsson, Josh Littlefield, Olafur Gudmundsson, William King and - the members of the IETF DNSEXT working group. - -9. References - - [NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC1996, August 1996. - - [STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035), - November 1987. - -10. Appendix A Appendix A. Pseudocode for response classification - - - - -M. Ohta Expires on December 5, 2000 [Page 8] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - - The following pseudocode outlines one possible algorithm for - classifying IXFR responses. - - receive the first response message; - extract the first response RR, always an SOA; - if (the serial number of this SOA RR is less - than or equal to that of the request) { - the response is an up-to-date response; - } else { - if (the response message was received by UDP and - contains no more RRs after the initial SOA) { - the response is a UDP-overflow response; - } else { - extract the second response RR, waiting for a second TCP - response message if necessary; - if (this second RR is an SOA) { - the response is an incremental transfer; - } else { - the response is a nonincremental transfer; - } - } - } - -11. Security Considerations - - Though DNS is related to several security problems, no attempt is - made to fix them in this document. - - This document is believed to introduce no additional security - problems to the current DNS protocol. - -12. Author's Address - - Masataka Ohta - Computer Center, Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN - - Phone: +81-3-5734-3299, Fax: +81-3-5734-3415 - EMail: mohta@necom830.hpcl.titech.ac.jp - - Comments should be directed to DNSEXT WG . - - - - - - - - - - -M. Ohta Expires on December 5, 2000 [Page 9] - -INTERNET DRAFT Incremental Zone Transfer in DNS June 2000 - - -13. Full Copyright Statement - - "Copyright (C) The Internet Society (March/5/2000). All Rights - Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - -M. Ohta Expires on December 5, 2000 [Page 10] - diff --git a/doc/draft/draft-ietf-dnsext-ixfr-02.txt b/doc/draft/draft-ietf-dnsext-ixfr-02.txt new file mode 100644 index 0000000000..987a73d4c9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ixfr-02.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +M. Ohta: mohta@necom830.hpcl.titech.ac.jp + + diff --git a/doc/draft/draft-ietf-enum-e164s2-np-00.txt b/doc/draft/draft-ietf-enum-e164s2-np-00.txt deleted file mode 100644 index 136872b6e3..0000000000 --- a/doc/draft/draft-ietf-enum-e164s2-np-00.txt +++ /dev/null @@ -1,1596 +0,0 @@ - -ENUM Working Group A. Gallant -Internet Draft Comsat Corporation -Expires: January 6, 2001 July 7, 2000 - - - The Number Portability Supplement to ITU-T Recommendation E.164 - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [1]. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. Internet-Drafts are draft documents valid for a maximum of - six months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - -1. Abstract - - This document contains a text version of the Number Portability - Supplement (11/98) to ITU-T Recommendation E.164 (The international - public telecommunication numbering plan, 05/97) [2]. That - Supplement [3] defined terminology for number portability within an - E.164 numbering scheme; identified formats, call flows, - architectures, and routing approaches for some methods; and gave - examples of some processes needed to implement number portability. - - A January 2000 workshop on IP-Telecomms interworking (focused on - numbering, naming, addressing, and routing) identified issues to be - addressed by the IETF and/or the ITU [4]. This Supplement was noted - as a document related to a joint IETF/ITU issue on E.164 number - portability. A text version was posted on the ITU's web site in - March 2000 and notified to the itu+ietf and enum mailing lists. - - This Internet Draft is being submitted to support work of the ENUM - (Telephone Number Mapping) Working Group on impacts of local number - portability on a DNS-based architecture and protocols for mapping a - telephone number to a set of attributes (e.g., URLs) [5]. - - - -Gallant Expires January 6, 2001 1 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - -2. Convention used in this document - - "e164s2" below flags the section numbering from the ITU original. - - -3. Table of Contents - - Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 - 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 2. Convention Used in this Document . . . . . . . . . . . . . . . 2 - 3. Table of Contents . . . . . . . . . . . . . . . . . . . . . . 2 - 4. Text Version of the Number Portability Supplement . . . . . . 3 - (e164s2) 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 - (e164s2) 2 References . . . . . . . . . . . . . . . . . . . . . . 3 - (e164s2) 3 Definitions and abbreviations . . . . . . . . . . . . 3 - (e164s2) 4 E.164 number structures . . . . . . . . . . . . . . . 6 - (e164s2) 4.1 International public telecommunication number for - geographic areas . . . . . . . . . . . . . . . . . . 7 - (e164s2) 4.2 International public telecommunication number for - global services . . . . . . . . . . . . . . . . . . 7 - (e164s2) 4.3 International public telecommunication number for - networks . . . . . . . . . . . . . . . . . . . . . . 8 - (e164s2) 5 Number portability types . . . . . . . . . . . . . . . 8 - (e164s2) 6 Generic implementation of number portability . . . . . 11 - (e164s2) 7 Entities addressed by routing . . . . . . . . . . . . 12 - (e164s2) 8 Number portability mechanisms . . . . . . . . . . . . 13 - (e164s2) 8.1 Assumptions . . . . . . . . . . . . . . . . . . . . 13 - (e164s2) 8.2 General description . . . . . . . . . . . . . . . . 13 - (e164s2) 9 Types of addresses and numbers _ within networks and - across network boundaries . . . . . . . . . . . . . . 18 - (e164s2) 9.1 Concatenated address . . . . . . . . . . . . . . . . 19 - (e164s2) 9.2 Separated addresses . . . . . . . . . . . . . . . . 21 - (e164s2) 9.3 RN only . . . . . . . . . . . . . . . . . . . . . . 22 - (e164s2) 9.4 Only DN (normally across network boundaries) . . . . 22 - (e164s2) 10 Combinations of addressing types, addressed entities - and mechanisms: general signalling requirements . . . 23 - (e164s2) 11 Examples of locations of number portability - database(s) within networks . . . . . . . . . . . . . 24 - (e164s2) 12 Administrative processes . . . . . . . . . . . . . . 25 - 5. Front Matter from the ITU-T Published Version . . . . . . . . 26 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 - 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 28 - 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . 28 - - - - - - - - -Gallant Expires January 6, 2001 2 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - -4. Text Version of the Number Portability Supplement - - This section contains the text of the Rec. E.164 Supplement on - Number Portability. It also contains text versions of all figures - and tables. The front matter of the ITU-T published version is - found in Section 6 of this document. - - -------------------------------------------------------------------- - SUPPLEMENT 2 to Recommendation E.164 (The international - public telecommunication numbering plan) - - Number Portability - (Geneva, 1998) - - (e164s2) 1 Scope - - This Supplement defines standard terminology for a common - understanding of the different aspects of number portability within - an E.164 numbering scheme. It identifies numbering and addressing - formats, call flows, network architectures and routing approaches - that will provide alternative methods of implementation. It also - proposes some examples of the administrative and operational - processes required for the successful implementation of number - portability. - - (e164s2) 2 References - - - ITU-T Recommendation E.164 (1997), The international public - telecommunication numbering plan. - - (e164s2) 3 Definitions and abbreviations - - (e164s2) 3.1 Definitions - - The following definitions and terms used in this Supplement are to - be used within the context of number portability. - - (e164s2) 3.1.1 address (taken from E.164): A string or combination - of decimal digits, symbols and additional information which - identifies the specific termination point(s) of a connection in a - public network(s) or, where applicable, in interconnected private - network(s). - - (e164s2) 3.1.2 directory number: See end user's number. - - (e164s2) 3.1.3 donor network/exchange: The initial - network/exchange where a number was located before ever being - ported. - - (e164s2) 3.1.4 donor service provider: The service provider from - whom the number was initially ported. - - -Gallant Expires January 6, 2001 3 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - - (e164s2) 3.1.5 end user's number: The E.164 number used by the - calling party to establish a call to the end user. This number is - also used for presentation services like Calling Line Identification - (CLI) and Connected Line Identification Presentation (COLP). - - The end user's number is equivalent to a directory number. - - (e164s2) 3.1.6 Geographic Number (GN): An E.164 number which - corresponds to a discrete geographic area. - - (e164s2) 3.1.7 location portability: The ability of an end user to - retain the same E.164 international public telecommunication number - when moving from one location to another. - - (e164s2) 3.1.8 network operator: An entity that operates a network - in order to route calls. - - (e164s2) 3.1.9 Non-Geographic Number (NGN): An E.164 number which - has no geographic significance. - - (e164s2) 3.1.10 numbering plan: A numbering plan specifies the - format and structure of the numbers used within that plan. It - typically consists of decimal digits segmented into groups in order - to identify specific elements used for identification, routing and - charging capabilities, e.g. within E.164 to identify countries, - national destinations and subscribers. - - A numbering plan does not include prefixes, suffixes and additional - information required to complete a call. - - The national numbering plan is the national implementation of the - E.164 numbering plan. - - (e164s2) 3.1.11 originating network/exchange: The network/exchange - serving a calling end user. - - (e164s2) 3.1.12 portable number: An entire E.164 number identified - by an appropriate authority which is subject to number portability. - - (e164s2) 3.1.13 ported number: An end user's E.164 number that has - been subject to number portability. - - (e164s2) 3.1.14 recipient network/exchange: The network/exchange - where a number is located after being ported. [Footnote: The - recipient exchange may consist of a central processor and both co- - located and remote concentrator units. The routing number may - identify either this whole ensemble or a specific concentrator (in - which case the ensemble may use several different routing numbers).] - - - - -Gallant Expires January 6, 2001 4 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - (e164s2) 3.1.15 recipient service provider: The service provider to - whom the number is ported. - - (e164s2) 3.1.16 routing number: A number that is derived and used - by the network to route the call towards a ported number. - - Four types of entities can be indicated by routing numbers as - follows: - - - Recipient network: The routing number identifies the network - where the customer is now located. Therefore the routing process - will need additional information (i.e. DN) to be completed. - - - Recipient exchange: The routing number identifies the exchange - where the customer is now located. Therefore the routing process - within the recipient exchange will need additional information (i.e. - DN) to be completed. - - - Point of interconnection: The routing number identifies an - interface to the next network in the routing process. Therefore the - routing process will need additional information (i.e. DN) to be - completed. - - - Network termination point: The routing number identifies the - subscriber/access line/service. The ported customer identified by - the RN is unique. Therefore the routing process in terms of number - portability can be completed without any additional information. - - (e164s2) 3.1.17 serving network(s)/exchange(s): The - network(s)/exchange(s) that determines the status of a number in an - environment capable of supporting number portability and, if - necessary, obtains the routing information for ported numbers. The - functionality to provide these capabilities may reside in either the - originating, donor, recipient or transit network/exchange or in some - combination. - - (e164s2) 3.1.18 service number: A non-geographic E.164 number - allocated to a specific category of services. - - (e164s2) 3.1.19 service portability: The ability of an end user to - retain the same E.164 international public telecommunication number - when changing from one type of service to another. - - (e164s2) 3.1.20 service provider: An entity that offers services to - users involving the use of network resources. - - (e164s2) 3.1.21 service provider portability: The ability of an end - user to retain the same E.164 international public telecommunication - number when changing from one service provider to another. - - - - -Gallant Expires January 6, 2001 5 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - (e164s2) 3.1.22 service provider portability for geographic - numbers: The ability of an end user to retain the same geographic - E.164 international public telecommunication number when changing - from one service provider to another without changing their location - and without changing the nature of the service offered. - - (e164s2) 3.1.23 service provider portability for non-geographic - numbers: The ability of an end user to retain the same non- - geographic E.164 international public telecommunications number when - changing from one service provider to another without changing the - nature of the service offered. - - (e164s2) 3.1.24 transit network(s)/exchange(s): A network/exchange - between two networks. - - (e164s2) 3.2 Abbreviations - - CCBS Completion of Calls to Busy Subscriber - DDI Direct-Dialling-In - DN Directory Number - GNP Geographic Number Portability - IN Intelligent Network - MSN Multiple Subscriber Number - NGNP Non-Geographic Number Portability - RN Routing Number - SP Service Provider - - (e164s2) 4 E.164 number structures - - This clause identifies three different structures for the - international public telecommunication number: - - - international public telecommunication number for geographic - areas; - - international public telecommunication number for global - services; - - international public telecommunication number for networks. - - - - - - - - - - - - - - - - -Gallant Expires January 6, 2001 6 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - (e164s2) 4.1 International public telecommunication number for - geographic areas - - +-------------+ +-----------------+ +---------------------+ - | CC | | NDC | | SN | - +-------------+ +-----------------+ +---------------------+ - | | | | - |1 to 3 digits| | Max (15-n) digits | - | | | | - | |<-----National (significant) number----->| - | | - |<---------------------Max 15 digits--------------------->| - | | - |<--------International public telecommunication--------->| - | number for geographic areas | - - CC Country Code for geographic areas - NDC National Destination Code (optional) - SN Subscriber Number - n Number of digits in the country code - - NOTE - National and international prefixes are not part of - the international public telecommunication number for - geographic areas. - - Figure 1 - International public telecommunication - number structure for geographic areas - - (e164s2) 4.2 International public telecommunication number - for global services - - +-------------+ +-----------------------------------------+ - | CC | | GSN | - +-------------+ +-----------------------------------------+ - | | | | - | 3 digits | |<-------------Max 12 digits------------->| - | | | | - |<---------------------Max 15 digits--------------------->| - | | - |<--------International public telecommunication--------->| - | number for global services | - - CC Country Code for global services - GSN Global Subscriber Number - - NOTE - National and international prefixes are not - considered to be part of the international public - telecommunication number for global services. - - Figure 2 - International public telecommunication - number structure for global services - - -Gallant Expires January 6, 2001 7 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - - (e164s2) 4.3 International public telecommunication number for - networks - - +-------------+ +-----------------+ +---------------------+ - | CC | | IC | | SN | - +-------------+ +-----------------+ +---------------------+ - | | | | | | - | 3 digits | | 1 to 4 digits | | Max (12-x) digits | - | | | | - | |<-------------Max 12 digits------------->| - | | - |<---------------------Max 15 digits--------------------->| - | | - |<--------International public telecommunication--------->| - | number for networks | - - CC Country Code for networks - IC Identification Code - SN Subscriber Number - x Number of digits in Identification Code (IC) - - NOTE - National and international prefixes are not part of - the international public telecommunication number for - networks. - - Figure 3 - International public telecommunication - number structure for networks - - (e164s2) 5 Number portability types - - An E.164 number is classified into the following three types - of country codes: - - 1) beginning with CC for geographic areas; - 2) beginning with CC for global services; and - 3) beginning with CC for networks. - - The following tables provide an overview of the applicability of - each type of portability, when considered against the three number - types. - - - - - - - - - - - - -Gallant Expires January 6, 2001 8 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - Table 1 - Service provider portability - - +---------------------------------------------------------+ - | Scope | | | - |-----------| | | - |CC type | Between CC domains | Within CC domains | - | (Note 1) | | | - |-----------+-----------+----------+-----------+----------| - |Geographic |Porting |Standards |Porting |Standards | - | |not |not |applicable |not | - | |applicable |required | |required | - | | | | | (Note 4) | - |-----------+-----------+----------+-----------+----------| - |Global |Porting |Standards |Porting |Standards | - |Services |not |not |applicable |not | - | |applicable |required | |required | - | | | | | (Note 2) | - |-----------+-----------+----------+-----------+----------| - |Network |Porting |Standards |Network |Network | - | (Note 3) |not |not |operator |operator | - | |applicable |required |matter |matter | - +---------------------------------------------------------+ - - - Table 2 - Service portability - - +---------------------------------------------------------+ - | Scope | | | - |-----------| | | - |CC type | Between CC domains | Within CC domains | - | (Note 1) | | | - |-----------+-----------+----------+-----------+----------| - |Geographic |Porting |Standards |Porting |Standards | - | |not |not |applicable |not | - | |applicable |required | |required | - | | | | | (Note 4) | - |-----------+-----------+----------+-----------+----------| - |Global |Porting |Standards |Porting |Standards | - |Services |not |not |not |not | - | |applicable |required |applicable |required | - |-----------+-----------+----------+-----------+----------| - |Network |Porting |Standards |Network |Network | - | (Note 3) |not |not |operator |operator | - | |applicable |required |matter |matter | - +---------------------------------------------------------+ - - - - - - - - -Gallant Expires January 6, 2001 9 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - Table 3 - Location portability - - +---------------------------------------------------------+ - | Scope | | | - |-----------| | | - |CC type | Between CC domains | Within CC domains | - | (Note 1) | | | - |-----------+-----------+----------+-----------+----------| - |Geographic |Porting |Standards |Porting |Standards | - | |not |not |applicable |not | - | |applicable |required | |required | - | | | | | (Note 4) | - |-----------+-----------+----------+-----------+----------| - |Global |Porting |Standards |Porting |Standards | - |Services |not |not |applicable |not | - | |applicable |required | (Note 5) |required | - |-----------+-----------+----------+-----------+----------| - |Network |Porting |Standards |Network |Network | - | (Note 3) |not |not |operator |operator | - | |applicable |required |matter |matter | - +---------------------------------------------------------+ - - - Notes to Tables 1, 2 and 3: - - NOTE 1 - Portability not supported between CC types. - - NOTE 2 - Requires international agreement(s) and infrastructure to - support number portability (e.g. UIFN). - - NOTE 3 - Includes the CC + IC digits required to uniquely identify - the network. - - NOTE 4 - International standardization not required but could be of - use. - - NOTE 5 - These resources are "non-geographic" therefore location - portability is inherent. - - NOTE 6 - For purposes of Tables 1, 2 and 3, "Standards" means ITU-T - Recommendations. - - - - - - - - - - - - -Gallant Expires January 6, 2001 10 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - (e164s2) 6 Generic implementation of number portability - - The following general routing scheme is assumed as the routing model - for calls routed to a ported customer. - - - incoming call - | - 1st step of the | - routing process, | - based on dialled digits | - | - +---------------------------+ +--------------------+ - | Serving Network | | | Transit Network | - | v | | (optional) | - | +-+ | | | - | | | |-------------------+ | - | Serving Exchange +-+ | | | | - +---------------------------+ +---------------|----+ - | - 2nd step of the | - routing process, | - based on routing number | - v - +---------------------------+ - | Recipient Network | | - | v | - | +-+ | - | | | | - | Recipient Exchange +-+ | - +---------------------------+ - | - | - +---+ - customer with | | - ported number | | - +---+ - - NOTE - The serving network may be the originating network - and/or the donor or a transit network. - - Figure 4 - Conceptual framework for incoming calls - - - NOTE 1 - The caller sets up the call by dialling the end user's - number which in this case is a ported number. The end user's number - is enough to initiate the routing process. Furthermore, number - portability, by definition, implies that the callers should continue - to dial the same end user's number and nothing more to set up a call - to a ported customer. - - - -Gallant Expires January 6, 2001 11 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - NOTE 2 - The routing process is split into two consecutive main - steps: - - a) Normal routing based on end user's number towards a serving - exchange: - - As a 1st step in the routing process, the originating network routes - the call up to a serving exchange clearly identified by the analysis - of a certain number of leading digits of the end user's number. - - b) Routing to customer's interface based on routing number(s) - obtained by this serving exchange: - - It should be noted that this step might be subdivided into sub-steps - (e.g. the serving exchange could provide information to route to a - database - within the recipient network or accessed by the recipient - network - which provides subsequent routing information identifying - the recipient exchange, information used for a subsequent sub- step - in the routing process). - - NOTE 3 - If only the recipient network is identified, then it is the - responsibility of the recipient network to terminate the call at the - recipient exchange. - - NOTE 4 - The internal routing process in the recipient exchange - shall unambiguously determine the called customer's interface and - complete the call taking into account the supplementary services - activated. - - NOTE 5 - If a number is ported subsequently from service provider - No. 1 to service provider No. 2, then to service provider No. 3, - etc. this will change the routing number but not the routing - principles. - - (e164s2) 7 Entities addressed by routing - - Entities which need to be addressed by a Routing Number (RN) in one - or more routing solutions are identified in this clause. - - According to the structure of the routing number, one or a - combination of several of the following entities should be - addressable: - - - A recipient network: In this option, the routing number - identifies the network where the customer is now located. Therefore - the routing process will need additional information (i.e. DN) to be - completed. - - - - - - -Gallant Expires January 6, 2001 12 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - - A Point of Interconnection (POI): In this option, the routing - number identifies an interface to the next network in the routing - process. Therefore the routing process will need additional - information (i.e. DN) to be completed. - - - Recipient exchange: In this option, the routing number - identifies the exchange where the customer is now located. Therefore - the routing process within the recipient exchange will need an - additional information (i.e. DN) to be completed. - - - Network Termination Point (NTP): In this option, the routing - number identifies the subscriber/access line/service. The ported - customer identified by the RN is unique. Therefore the routing - process, in terms of number portability, can be completed without - any additional information. - - (e164s2) 8 Number portability mechanisms - - (e164s2) 8.1 Assumptions - - The following document internal assumptions that have been made: - - a) that Calling Line Identification (CLI) is required to be - transported, with display information, unchanged to recipient - network; - - b) that Connected Line Identification (COLI) is required to be - transported, with display information, unchanged to originating - network; - - c) that initial routing arrangements have been defined and - implemented prior to the introduction of routing based on a routing - number; - - d) that number portability is not allowed to influence the carrier - selection function; - - e) that an NP solution shall not influence functions in PBXs. - - (e164s2) 8.2 General description - - (e164s2) 8.2.1 Call rerouted from donor network by use of onward - routing principles - - The first step/solution discussed for number portability is often - that the donor network maintains the portability information, i.e. - the complete address to both recipient network and exchange, for - ported-out numbers and reroutes incoming calls to ported-out numbers - onward towards the recipient network according to onward routing - principles outlined in Figure 5. - - - -Gallant Expires January 6, 2001 13 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - - Originating Transit Donor - Network Network(s)(A) Network - +-------+ +-------+ +-------+ - | | IAM | | IAM | +--+| - +-->| |------>| |------>| |DB||..... - | | | | | | +--+| . - | +-------+ +-------+ +-------+ . - | | | . - Calling a1)IAM | |b)IAM . - Subscriber +---------+ | . - | | Called - | | Subscriber - v v ^ - +-------+ +-------+ | - | |a2)IAM | | | - | |------>| |----+ - | | | | - +-------+ +-------+ - Transit Recipient - Network(s)(B) Network - - Figure 5 - Call rerouting to recipient network by - onward routing principles from donor network - - - In Figure 5, the donor network receives an incoming call. It then - detects that the called number has been ported-out to another - network and makes a DB query to retrieve a routing number. It - thereafter reroutes the call onward towards the recipient network - using retrieved routing information. - - Please note that the transit network(s) are optional, i.e. direct - interconnections connections between originating network and donor - network might exist and the same also between donor network and - recipient network. Note also that the transit network(s) A and B can - be the same depending on network structure and call case. - - (e164s2) 8.2.2 Call rerouted by dropback principles from donor - network - - One possible enhancement of the previously described onward routing - solution, is that the donor network initiates the rerouting of the - call towards the recipient network according to "dropback" - principles outlined in Figure 6. Also, in this scenario, only the - donor network maintains NP information, i.e. the complete address to - both recipient network and exchange, for ported-out numbers. - - - - - - -Gallant Expires January 6, 2001 14 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - Originating Transit Donor - Network Network(s)(A) Network - +-------+ +-------+ +-------+ - | | IAM | | IAM | +--+| - +-->| |------>| |......>| |DB||..... - | | | | |<......| +--+| . - | +-------+ +-------+ Dropb.+-------+ . - | | | . - Calling a1)IAM| | b)IAM . - Subscriber | +---------+ . - | | Called - | | Subscriber - ----> v v ^ - Lasting +-------+ +-------+ | - relation | |a2)IAM | | | - ....> | |------>| |----+ - Temporary | | | | - relation +-------+ +-------+ - Transit Recipient - Network(s)(B) Network - - Figure 6 - Dropback with rerouting information and - onward rerouting performed by a transit network - - - The option b) is valid when direct interconnection exists between - transit network A and recipient network. - - A further evolution is that the dropback indication is sent back to - the originating network. This is mainly of interest if the - originating network has direct interconnections to other networks - than the transit network used in the call attempt to the donor - network. - - The dropback indication is also passed through to the originating - network if either the transit network A has no "dropback" capability - or determines that the preceding network has "dropback" capability. - The originating network, at reception of the release, reroutes the - call towards recipient network. - - Please note that the transit networks are optional (i.e. direct - connections between originating network and donor network might - exist) but might exist [case a1) and a2)] between the onward routing - (transit or originating) network and recipient network. - - When carrier selection is valid for the call, the originating - network reuses the carrier selection information after reception of - dropback indication. It could be debated if a selected carrier (e.g. - TN A) is allowed/recommended to transport the dropback to - originating network, but it has no option if it has no redirect on - "dropback" capability. - - -Gallant Expires January 6, 2001 15 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - - (e164s2) 8.2.3 Call rerouting initiated by "Query on Release - (QoR)" principles from donor network - - A similar case as the previously described "dropback" principle is - when the preceding network to donor initiates NP actions, i.e. an NP - DB query, at reception of a release message. This case is often - referred to as "Query on Release (QoR)". - - In Figure 7, the donor network receives an incoming call. It then - detects that the called number has been ported out to another - network. It then determines that one of the preceding networks has - QoR capability by looking at received signalling information. It - thereafter releases the call with a special indication telling that - called number is ported out. The transit network then traps the - release, determines that preceding network has no QoR capability, - makes an NP database query and reroutes the call onward towards the - recipient network. In this scenario the transit network has access - to an NP DB with the complete address to the recipient network, at - least for ported-out numbers. - - Options a1) and a2), in Figure 7, are valid when transit network A - either has no direct interconnection to recipient network or when - overflow traffic is placed via transit network B. - - - Originating Transit Donor - Network Network(s)(A) Network - +-------+ +-------+ +-------+ - | | IAM | +--+| IAM | | - +-->| |------>| |DB||......>| |..... - | | | | +--+|<......| | . - | +-------+ +-------+ REL +-------+ . - | | | . - Calling a1)IAM| | b)IAM . - Subscriber | +---------+ . - | | Called - | | Subscriber - ----> v v ^ - Lasting +-------+ +-------+ | - relation | |a2)IAM | | | - ....> | |------>| |----+ - Temporary | | | | - relation +-------+ +-------+ - Transit Recipient - Network(s)(B) Network - - Figure 7 - Query on Release by transit network - - - - - -Gallant Expires January 6, 2001 16 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - The option b), in Figure 7, is valid when direct interconnection - exists between transit network A and recipient network. - - Please note in this case that the DB query might take place also in - the originating network, i.e. that the DB could also exist in the - originating network. - - That is what may occur if either the transit network A has no QoR - query capability or determines that the preceding network has QoR - capability. It therefore lets the release pass through to - originating network. The originating network, at reception of the - release, queries its NP database and reroutes the call towards - recipient network. In this scenario the originating network has - access to an NP DB with the complete address to both recipient - network and exchange, at least for ported-out numbers. - - Sending back the release message to the originating network is also - of interest if the originating network has direct connections to - networks other than the transit network currently used. - - When carrier selection is valid for the call, the originating - network reuses the carrier selection information after querying NP - DB. It could be debated if a selected carrier is allowed/recommended - to transport the release message to originating network, but it has - no option if it has no redirect on QoR capability. - - (e164s2) 8.2.4 Routing initiated by "All call query" principles - - In the scenario shown in Figure 8, the originating network has - access to an NP DB with the complete address to the recipient - exchange, at least for ported-out numbers. This implies that only - one NP DB look-up needs to be performed to complete the call. - - Note however, that more than one DB look-up may be required if there - is not sufficient information to route to the recipient exchange. - - - - - - - - - - - - - - - - - - -Gallant Expires January 6, 2001 17 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - Originating Transit Donor - Network Network Network - +-------+ +-------+ +-------+ - | +--+|a1)IAM | | | | - +-->| |DB||------>| | | |..... - | | +--+| | | | | . - | +-------+ +-------+ +-------+ . - | | | . - Calling | | a2)IAM . - Subscriber +---------+ +---------+ . - | | Called - | | Subscriber - ----> | v ^ - Lasting | b)IAM +-------+ | - relation +------------->| | | - ....> | |----+ - Temporary | | - relation +-------+ - Recipient - Network - - Figure 8 - All call query by originating network - - - As can be seen in Figure 8, the donor network is not involved in the - call set-up at all, however optionally the transit network [see - cases a1) and a2) above] might be transiting the call to the - recipient network. - - Alternatively, a transit network, rather than the originating - network, could perform the NP DB look-up. - - (e164s2) 9 Types of addresses and numbers - within networks - and across network boundaries - - With service provider portability it may no longer be possible to - use an end user's number, dialled by the calling party, to route the - call to the customer. If a customer changes service provider, a - Routing Number (RN) is needed to be able to route the call. The - routing information may have one of the following: - - - concatenated address (see 9.1); - - separated address (see 9.2); - - RN only, i.e. a plain network address, suppressed E.164 number - (see 9.3); - - DN only, i.e. a plain E.164 number (see 9.4). - - - - - - - -Gallant Expires January 6, 2001 18 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - (e164s2) 9.1 Concatenated address - - (e164s2) 9.1.1 Description - - In this type of address, two numbers are concatenated in the same - signalling field (the called party number) which is used to route - the call (Figure 9). - - +-----------------------+-----------------------+ - | RN | DN | - +-----------------------+-----------------------+ - - Figure 9 - Showing a concatenated address - - - RN is a routing number prefixed for a routing purpose. The length of - RN may vary from country to country. - - If some non-ported numbers have DN leading digits identical to the - RN, this may imply a signalling field exists which indicates - "Routing information for a ported number"; otherwise, the routing - would be ambiguous. - - The RN could take one of the following values: - - Case 1: RN represents the first digits of a number block usually - handled by the addressed entity to which the call has to be routed. - In this case, specific information carried by the signalling - protocol is needed to indicate that it is a call to a ported number. - - Case 2: One or more of the first digits of the RN are digits not - used as first digits in the national numbering plan used to indicate - that the call is to a ported number. The value of the digits could - be between 0 and 9 (spare in the national numbering plan). The rest - of the RN identifies the addressed entity to which the call has to - be routed and is used for this purpose. - - Case 3: This case is similar to case 2, but the first (or first - two) digit(s) of the RN field is (are) one of the hexadecimal values - nationally spare in the Signalling System No. 7. RN is used to route - the call to the addressed entity. - - (e164s2) 9.1.2 Brief analysis - - Case 1 - - Pros: - - This solution does not waste any numbering resource since the RN - value is formed by the first digits of the number block usually - handled by the addressed entity. - - -Gallant Expires January 6, 2001 19 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - - This solution does not need a specific addressing scheme (for - identifying the addressed exchange) and can be accommodated in the - existing signalling. - - Cons: - - This solution requires the use of a specific identifier to qualify - the routing number as an address used for a ported call which - requires special treatment. The routing mechanisms in exchanges have - to be adapted to be able to provide this special treatment. As there - is a constraint on the maximum length of the complete concatenated - address, the numbering space available for RN may be insufficient; - limitations can be present on the maximum numbers of digits being - supported by the signalling system and the exchanges in the - different networks involved. - - Case 2 - - Pros: - - As for case 1, this solution can also be accommodated in the - existing signalling. In opposition to case 1, this solution does not - require any additional information to qualify the call as a ported - call since one of the first digits of the routing number is - dedicated to ported calls. - - Cons: - - This solution makes use of a part of the national numbering scheme. - To be able to handle the prefix, routing mechanisms in the exchanges - will have to be changed. As there is a constraint on the maximum - length of the complete concatenated address, the numbering space - available for RN may be insufficient. - - Case 3 - - Pros: - - This solution does not waste any resource from the national - numbering plan since the first digit(s) is (are) hexadecimal. - [Footnote: That is, one of the 6 values A, B, C, D, E or F.] The - advantages are similar to those already mentioned for case 2. - - - - - - - - - - -Gallant Expires January 6, 2001 20 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - Cons: - - The drawbacks are similar to those already mentioned for case 2. - However, since this solution makes use of hexadecimal character(s), - it requires changes (e.g. in signalling systems, switches and - support systems). Although the solution does not require any - resources from the national numbering plan, it does take up - numbering resources (it uses a spare value from the Signalling - System No. 7). - - (e164s2) 9.2 Separated addresses - - (e164s2) 9.2.1 Description - - In this address type, the routing number and the directory number - are carried in two different fields in the signalling messages - (Figure 10). The address identifying the destination of the ported - call, routing number, is used to route the call. The DN is carried - transparently in a separate signalling parameter and is only used at - the called side to complete the call. - - +-----------------------+ - | RN | - +-----------------------+ - +-----------------------+ - | DN | - +-----------------------+ - - Figure 10 - Showing a separated address - - - (e164s2) 9.2.2 Brief analysis - - Pros: - - The routing number can either be an E.164 number or a non- E.164 - number. In either case the routing number should be in the same - format as the national numbering plan. Since the called number and - routing number are carried in separate signalling parameters, the - possibility for mis-routing is minimized. If non-E.164 numbers are - used, all numbers from the national numbering plan can be used as - routing numbers. If E.164 numbers are used, numbers within the - national numbering plans must be identified and assigned only for - routing purposes. As opposed to prefix solutions, no special - treatment of routing numbers need to be provided by the routing - mechanisms of the exchange. - - - - - - - -Gallant Expires January 6, 2001 21 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - Cons: - - Such a separated address solution requires, by definition, that - signalling systems used are able to carry both RN and DN in separate - signalling parameters. - - (e164s2) 9.3 RN only - - (e164s2) 9.3.1 Description - - In this case the routing number is the only information being sent - between exchanges/networks (Figure 11). The directory number, E.164 - number, is not sent between exchanges but is translated into a - routing number. The routing number must point out the access line to - which the called party is connected as no other method is available. - - +-----------------------+ - | RN | - +-----------------------+ - - Figure 11 - Showing a routing number only - - - (e164s2) 9.3.2 Brief analysis - - Pros: - - The advantages of this addressing method are that it is - internationally available today because the RNs are E.164 numbers - and that it does not require any changes in the signalling systems. - - Cons: - - To be able to provide information regarding the DN, in services like - COLP, a second query in the recipient exchange (or in the last - transit exchange) is needed. This solution can waste numbering - resources (depending on the solution). - - (e164s2) 9.4 Only DN (normally across network boundaries) - - (e164s2) 9.4.1 Description - - In this case the directory number is the only information that is - being sent between networks. - - +-----------------------+ - | DN | - +-----------------------+ - - Figure 12 - Showing a directory number only - - - -Gallant Expires January 6, 2001 22 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - - (e164s2) 9.4.2 Brief analysis - - Pros: - - It is not mandatory to introduce RN transfer between networks, i.e. - this solution does not affect existing network interfaces. It allows - different addressing options of different operators to work - together. Operators will have to transport routing information with - ported calls inside their networks, regardless of which number - portability solution is chosen. There are multiple options to - transport this routing information. Separation or concatenation of - routing information and directory number is the main characteristic. - - Internal routing is not dependent on information given by other - networks (no network interdependence). - - Cons: - - Use of this addressing method requires the use of "all call query - all networks" architecture at the network interface. - - (e164s2) 10 Combinations of addressing types, addressed - entities and mechanisms: general signalling requirements - - The previous clauses above have identified that there are three - components that must be determined in any implementation of service - provider number portability: - - 1) the entity addressed by the routing number; - 2) the method of transporting the routing number; - 3) the architecture used to determine the routing number. - - Addressed entity: Assuming a routing number is utilized (see below), - there are four possible entities that can be identified by the - routing number: - - 1) network termination point; - 2) recipient exchange; - 3) recipient network; - 4) point of interconnection. - - Transport of routing number: There are four transport methods - described: - - 1) concatenated; - 2) separated; - 3) no routing number used; - 4) routing number only. - - - - -Gallant Expires January 6, 2001 23 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - Architectures: There are four architectures described: - - 1) onward routing; - 2) dropback; - 3) query on release; - 4) all call query. - - With the exception of the "No routing number used/routing number - only" transport mechanisms, the three components are independent of - one another, allowing a multitude of theoretically possible - solutions by combining the components. For example, an - implementation could consist of: - - - Routing number identifies the recipient exchange, is transported - concatenated with dialled digits and is derived using an onward - routing architecture. - - Or, an alternate implementation could be: - - - Routing number identifies the recipient network, is transported - in a separate field to the dialled digits and is derived using an - all call query architecture. - - The various combinations provide flexibility of implementation to - take into account economical and technical parameters of each - individual situation. For this reason this Supplement does not - recommend one solution over another. - - (e164s2) 11 Examples of locations of number portability - database(s) within networks - - (e164s2) 11.1 General description - - Depending on the evolutionary level in a particular network, the NP - database will be located in different places of the network or - possibly even external to the network. The following principles of - NP data storing have been identified, described and evaluated: - - a) exchange-based (distributed) solutions; - b) exchange external (centralized) solutions. - - The following options for NP data query places have been identified, - described and evaluated: - - 1) originating local exchange; - 2) gateway exchange(s); - 3) transit or gateway exchange(s); - 4) donor local exchange(s). - - - - - -Gallant Expires January 6, 2001 24 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - Regardless of data storing place, the exchange/network can act - according to different NP principles, e.g. onward routing the call, - dropping back the rerouting information or even acting as a database - and responding a query with rerouting information. - - (e164s2) 12 Administrative processes - - In establishing number portability, processes that underpin its - introduction and management are a key requirement. The following - list provides top level guidance on specific areas of activity and - the steps that need to be covered. - - Process activity Steps to be covered - - Service Initial contact between operators - establishment Planning stage - Implementation planning - Network implementation and testing - - Service Introduction of a new switch - maintenance Introduction of a new numbering block - Number change - New routing number - - Service Request - ordering Validation - Scheduling - Contingency plans - Hours - Subsequent portability - Change of account name - Reasons for rejection - Installation - Cancellation - - Fault and repair - handling - - Directory number Directory entries - information Operator assistance - Emergency service - Number plan administration - Law enforcement agencies - - Billing - -------------------------------------------------------------------- - - - - - - - -Gallant Expires January 6, 2001 25 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - 5. Front Matter from the ITU-T Published Version - - This section contains sections from the front matter of the ITU-T - published version of Supplement 2 to Rec. E.164, including the - Source, the Foreword, the note on "ROA," the text on intellectual - property rights, and the copyright notice. They are provided here - for information and reference. The text here was valid at the time - of publication, but there may have been revisions since then. - - - 5.1 Source (from the ITU-T published version) - - Supplement 2 to ITU-T Recommendation E.164 was prepared by ITU-T - Study Group 2 (1997-2000) and was approved under the WTSC Resolution - No. 5 procedure on the 9th of November 1998. - - - 5.2 FOREWORD (from the ITU-T published version) - - ITU (International Telecommunication Union) is the United Nations - Specialized Agency in the field of telecommunications. The ITU - Telecommunication Standardization Sector (ITU-T) is a permanent - organ of the ITU. The ITU-T is responsible for studying technical, - operating and tariff questions and issuing Recommendations on them - with a view to standardizing telecommunications on a worldwide - basis. - - The World Telecommunication Standardization Conference (WTSC), which - meets every four years, establishes the topics for study by the - ITU-T Study Groups which, in their turn, produce Recommendations on - these topics. - - The approval of Recommendations by the Members of the ITU-T is - covered by the procedure laid down in WTSC Resolution No. 1. - - In some areas of information technology which fall within ITU-T's - purview, the necessary standards are prepared on a collaborative - basis with ISO and IEC. - - - 5.3 NOTE (from the ITU-T published version) - - In this Recommendation the term "recognized operating agency" (ROA) - includes any individual, company, corporation or governmental - organization that operates a public correspondence service. The - terms "Administration," "ROA" and "public correspondence" are - defined in the "Constitution of the ITU (Geneva, 1992). - - - - - - -Gallant Expires January 6, 2001 26 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - - 5.4 INTELLECTUAL PROPERTY RIGHTS (from the ITU-T published version) - - The ITU draws attention to the possibility that the practice or - implementation of this Recommendation may involve the use of a - claimed Intellectual Property Right. The ITU takes no position - concerning the evidence, validity or applicability of claimed - Intellectual Property Rights, whether asserted by ITU members or - others outside of the Recommendation development process. - - As of the date of approval of this Recommendation, the ITU had not - received notice of intellectual property, protected by patents, - which may be required to implement this Recommendation. However, - implementors are cautioned that this may not represent the latest - information and are therefore strongly urged to consult the TSB - patent database. - - - 5.5 Copyright Notice (from E.164 Supp. 2, ITU-T published version) - - (c) ITU 1999 - - All rights reserved. No part of this publication may be reproduced - or utilized in any form or by any means, electronic or mechanical, - including photocopying and microfilm, without permission in writing - from the ITU. - - -6. Security Considerations - - None. - - -7. References - - 1 Bradner, S., "The Internet Standards Process -- Revision 3", - BCP 9, RFC 2026, October 1996. - - 2 ITU-T Recommendation E.164 (05/97), "The international public - telecommunication numbering plan". - - 3 Supplement 2 (11/98) to ITU-T Recommendation E.164 (05/97), - "Supplement 2: Number Portability". - - 4 "Report of the IP-Telecoms Interworking Workshop (Numbering, - Naming, Addressing and Routing), ITU, Geneva 25-27 January 2000", - http://www.itu.int/ITU-T/ip-telecoms/ip-telecoms.htm, last - modified 2000-03-20. - - 5 "Telephone Number Mapping (enum)", last modified 03-Jul-00, - http://www.ietf.org/html.charters/enum-charter.html. - - - -Gallant Expires January 6, 2001 27 -Internet-Draft Number Portability (E.164 Supp. 2) July 7, 2000 - - -8. Acknowledgments - - I would like to thank the ITU TSB (Telecommunication Standardization - Bureau), and Mr. John Tar in particular, for helping to make the - text of Supplement 2 to E.164 freely available on the ITU web site. - - -9. Author's Address - - Andrew Gallant - Comsat Corporation - 6560 Rock Spring Drive - Bethesda, MD 20817 USA - Phone: +1 301 214 3264 - Fax: +1 301 214 7226 - Email: andrew.gallant@comsat.com - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation 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. - - - - - - - - -Gallant Expires January 6, 2001 28 - diff --git a/doc/draft/draft-ietf-enum-e164s2-np-01.txt b/doc/draft/draft-ietf-enum-e164s2-np-01.txt new file mode 100644 index 0000000000..3cda4774c1 --- /dev/null +++ b/doc/draft/draft-ietf-enum-e164s2-np-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +A. Gallant: andrew.gallant@comsat.com + + diff --git a/doc/draft/draft-ietf-enum-rqmts-01.txt b/doc/draft/draft-ietf-enum-rqmts-01.txt deleted file mode 100644 index ad453c4f21..0000000000 --- a/doc/draft/draft-ietf-enum-rqmts-01.txt +++ /dev/null @@ -1,342 +0,0 @@ - -Telephone Number Mapping A. Brown -Internet Draft Nortel Networks -Document: June 2000 -Category: Informational - - - ENUM Requirements - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [1]. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. Internet-Drafts are draft documents valid for a maximum of - six months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet- Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -1. Abstract - - This paper defines the requirements for a DNS-based architecture and - protocols for mapping a telephone number to a set of attributes - (e.g., URLs) that can be used to contact a resource associated with - that number. There are many possible protocols that can be - considered for a telephone number mapping service. The purpose of - this document is to focus discussion on a DNS-based solution. The - intention is to enumerate the expectations of such a solution and to - clarify the scope. - -2. 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 RFC-2119 [2]. - -3. Requirements - -3.1 Endpoint Address Lookup - - The system SHALL provide a service for the retrieval of service - specific endpoint addresses (e.g., email address, IP address, SIP - address, URL, etc.) or the retrieval of the addresses of servers, if - available, which may contain this endpoint information. - - - ENUM Requirements June 2000 - - -3.2 Capabilities Retrieval/Negotiation - - The retrieval or negotiation of capabilities is beyond the scope of - the system. - -3.3 Retrieval of Additional Information and Capabilities - - The retrieval of additional, application-specific information (e.g., - spoken name for verification purposes) is beyond the scope of the - system. The system MUST provide a service for the retrieval of - protocol and service information if available. - - The system SHOULD provide access to capabilities relevant to the - telephone number in question. The retrieval or negotiation of - capabilities will depend on the outcome of the rescap work or work - done in other groups. - -3.4 Qualification of the Request - - The system is not required to enable the qualification of a request - by a user, for the purposes of filtering for reducing returned - information or for traffic reduction. - -3.5 Provisioning - - The architecture and protocol MAY support at least the existing - administrative model as the current E.164 telephone number - delegation system. The protocol SHOULD also provide the ability to - support corporate numbering plan or competitive directory service - providers under separate root domains. It SHOULD NOT require an - additional centralized administrator beyond that required for the - existing telephone number system. - - The distribution of telephone numbers is a national affair by ITU - treaty and different telephone number distribution schemes may - require different delegation models. How nations choose to - administer the ENUM space within their borders is a national issue. - In any case, the subscriber or enterprise is the ultimate authority - for service provisioning. - - Further, it must be possible for the authority to which a telephone - number has been delegated to redirect the query to a different - entity that provides service-specific information for that number. - -3.6 Propagation of Changes - - Propagation of Changes If multiple copies of the data are - distributed in different areas, their update should be incorporated - almost simultaneously depending on the application of DNS to - services. - - - - - ENUM Requirements June 2000 - - - When a numbering plan change is made in a country or network, the - update of relevant E.164 number data in DNS needs to be coordinated - with the change. - -3.7 Response Timeout - - The system SHALL have a defined timeout mechanism. - -3.8 Global Number Portability - - The system MUST support existing local number portability - mechanisms, where applicable. It is RECOMMENDED that the system not - be designed in such as way as to impede future global number - portability. - -3.9 Scalability - - The system MUST scale to handle quantities of telephone numbers and - queries comparable to current and expected future PSTN usage. - - It must be possible to operate the system based on telephone number - blocks defined at the digit boundaries as well as explicit per- - number configuration. - -3.10 Query Performance - - It SHOULD be possible to administer the ENUM service using the - selected protocols and structures such that the current user - expectations for latency in telecommunications services can be met. - In particular, it SHOULD be possible to operate the system in such a - manner that an ENUM query for a service-specific record can be - satisfied within one second 95% of the time and that within two - seconds, the query can be satisfied 99% of the time. - -3.11 Other PSTN Numbering Services - - E.164 numbers, short codes, service codes and prefixes are - categorized in dialing plans. A prefix is an indicator consisting - of one or more digits that allows the selection of different types - of number formats, networks and/or services. Prefixes are not part - of the number and are part of a dialing plan. The uses and the - formats of prefixes are a national matter. Short codes, e.g. - emergency, or service codes may be used based on the national - numbering plan. Those codes are not universal and typically valid - only within a numbering domain identified with the same country code - or country code + network identification code. - - PSTN type numbering services such as Emergency 911, directory - assistance 411, and other carrier codes for services accessible via - non-E164 (or subset) telephone number service access codes are - outside the scope of ENUM. - -3.12 Privacy - - ENUM Requirements June 2000 - - - - The system MUST allow the owner of the telephone number to control - the information which prospective callers may receive. - -3.13 Competition - - The solution MUST permit competing service providers to offer - telecommunications service for a given number. Competing - telecommunications services MUST be enabled where the ENUM entry is - administered by the single entity to which the number is delegated. - Who that single entity is, is beyond the scope of ENUM. - -3.14 Authorization of Requests and Responses - - The system SHALL enable the authorization of requests and responses. - -3.15 Privacy and Integrity of Requests and Responses - - The system SHALL enable the privacy and integrity of requests and - responses. - -3.16 Call Routing - - The system is not required to provide a service for routing calls or - locating gateways to a specific service. - -3.17 Service Logic - - The system is not responsible for employing service logic for the - intelligent retrieval of information. - -3.18 E.164 Numbers - - The system is not responsible for returning information on private - numbering plans and non-E.164 numbers. The system is responsible - for returning information on 1-800 and other legitimate E.164 - numbers. - -3.19 Application Specific Use of ENUM - - The ENUM service MUST be application agnostic. It is expected that - various other IETF work groups will develop ENUM specific usage - profiles for their specific application. ENUM will not mandate the - use of any specific DNS Resource Record for any particular - application. - -4. Security Considerations - - This document specifies several security requirements including - privacy of information, and authorization, privacy and integrity or - requests and responses. - - - - ENUM Requirements June 2000 - - - The system will be designed to retrieve information required to - initiate an Internet telephony session. Each of these session types - will have their own security threats, which should be addressed in - the groups responsible for those services. - -5. References - - - 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997 - -6. Acknowledgements - - This document is based on discussions from the ENUM working group. - -7. Author's Addresses - - Anne Brown - Nortel Networks - P.O. Box 3511, Station C - K1Y 4H7 - Phone: +1 613 765 5274 - Email: arbrown@nortelnetworks.com - -8. Changes From draft-enum-rqmts-00.txt - - Based on WG discussions and input documents from the SG2 workshop, - the following changes have been made since the previous version of - this draft: - - 3.1 Endpoint Address Lookup - Major - URLs are not the only response - 3.3 Retrieval of Additional Information and Capabilities - Renamed from "Retrieval of Additional Information" - Minor - Added paragraph on capabilities - 3.5 Provisioning - Major - New text involving change of ENUM scope - 3.6 Propagation of Changes - New section - Major - New section based on nnar-e164-dns-iw-info.txt - 3.9 Scalability - Renumbered from 3.8 - Major - New paragraph on handling of both blocks and - individual telephone numbers. - 3.10 Query Performance - Renumbered from 3.9 - Major - Upgraded to support PSTN performance - expectations - 3.11 Other PSTN Numbering Services - Renumbered from 3.10 - - ENUM Requirements June 2000 - - - Renamed from "Other PSTN Services" - Minor - Changes for clarification based on WG - discussions and nnar-e164-dns-iw-info.txt - - 3.13 Competition - Renumbered from 3.12 - Major - Telephone number MUST be able to be - administered by a single entity - - 3.19 Application Specific Use of ENUM - New Section - Major - For clarification - -Full Copyright Statement - - "Copyright (C) The Internet Society (date). 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 implmentation 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-enum-rqmts-02.txt b/doc/draft/draft-ietf-enum-rqmts-02.txt new file mode 100644 index 0000000000..a47840ab90 --- /dev/null +++ b/doc/draft/draft-ietf-enum-rqmts-02.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +A. Brown: arbrown@nortel.ca + + diff --git a/doc/draft/draft-ietf-idn-cjk-00.txt b/doc/draft/draft-ietf-idn-cjk-01.txt similarity index 93% rename from doc/draft/draft-ietf-idn-cjk-00.txt rename to doc/draft/draft-ietf-idn-cjk-01.txt index d979e3d88d..3344ab160c 100644 --- a/doc/draft/draft-ietf-idn-cjk-00.txt +++ b/doc/draft/draft-ietf-idn-cjk-01.txt @@ -1,7 +1,7 @@ -Internet Draft James SENG - Yoshiro YONEYA -12th Sep 2000 Kenny HUANG -Expires 12 Mar 2001 KIM Kyongsok +Internet Draft James SENG + Yoshiro YONEYA +11th Apr 2001 Kenny HUANG +Expires 11 Oct 2001 KIM Kyongsok Han Ideograph (CJK) for Internationalized Domain Names @@ -54,11 +54,6 @@ 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 - - Expires 12th March 2001 [Page 1] - -Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 - 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 @@ -113,11 +108,6 @@ points in Unicode. 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" - - Expires 12th March 2001 [Page 2] - -Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 - {U+5C71} still bears some resembles to 3 peaks of a hill. Not all ideographs are pictograph. There are other classifications such @@ -172,11 +162,6 @@ 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 - - Expires 12th March 2001 [Page 3] - -Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 - (U+982D U+9AEE). It will also match TC {U+982D U+9AEE} that does not have any meaning in Chinese. @@ -231,11 +216,6 @@ 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 - - Expires 12th March 2001 [Page 4] - -Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 - 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, @@ -290,11 +270,6 @@ Hence, Han folding here is not recommended. 4. Vietnamese While Vietnamese also adopted Chinese ideographs ('chu han') and created - - Expires 12th March 2001 [Page 5] - -Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 - 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'. @@ -349,11 +324,6 @@ or removing radical from standard ideographs. 7. Mechanism - - Expires 12th March 2001 [Page 6] - -Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 - The implicit proposal in this document is that CJKV ideographs may or may not be "folded" for the purposes of comparison of domain names. @@ -405,14 +375,6 @@ If conservative safety is really required, then are made on x-axis characters, but the license of that domain name can pick which y or z variants they wish to use.. - - - - - Expires 12th March 2001 [Page 7] - -Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 - Acknowledgement The editor gratefully acknowledge the contributions of: @@ -424,7 +386,7 @@ Karlsson Kent Author(s) -James SENG +James SENG  i-DNS.net International Pte Ltd. 8 Temasek Boulevard Suntec Tower 3 #24-02 @@ -439,7 +401,7 @@ Shinagawa IntercityBldg., B-13F Email: yone@po.ntts.co.jp Tel: +81-3-5782-7291 -Kenny HUANG +Kenny HUANG 雷 Geotempo International Ltd; TWNIC 3F, No 16 Kang Hwa Street, Nei Hu Taipei 114, Taiwan @@ -468,11 +430,6 @@ References [KANJIDIC] Sanseidos Unicode Kanji Information Dictionary ISBN 4-385-13690-4 - Expires 12th March 2001 [Page 8] - -Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 - - [UNICHART] Unicode chart http://charts.unicode.org/ [ZONGBIAO] Simplified Characters Standard Chart 2nd Edition, 1986 @@ -494,37 +451,4 @@ Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001 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] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Expires 12th March 2001 [Page 9] + National University Press. 1999. [in Hangeul] \ No newline at end of file diff --git a/doc/draft/draft-ietf-idn-compare-01.txt b/doc/draft/draft-ietf-idn-compare-01.txt deleted file mode 100644 index 22df4611e0..0000000000 --- a/doc/draft/draft-ietf-idn-compare-01.txt +++ /dev/null @@ -1,687 +0,0 @@ -Internet Draft Paul Hoffman -draft-ietf-idn-compare-01.txt IMC & VPNC -July 11, 2000 -Expires in six months - -Comparison of Internationalized Domain Name Proposals - -Status of this memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC 2026. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material -or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - -Abstract - -The IDN Working Group is working on proposals for internationalized -domain names that might become a standard in the IETF. Before a single -full proposal can be made, competing proposals must be compared on a -wide range of requirements and desired features. This document compares -the many parts of a comprehensive protocol that have been proposed. It -is the companion document to "Requirements of Internationalized Domain -Names" [IDN-REQ], which lays out the requirements for the -internationalized domain name protocol. - - -1. Introduction - -As the IDN Working Group has discussed the requirements for IDN, -suggestions have been made for various candidate protocols that might -meet the requirements. These proposals have been somewhat helpful in -bringing up real-world needs for the requirements. - -It became clear no single proposal had wide agreement from the working -group. In fact, the authors of various proposals found themselves taking -some features from other proposals as they revised their drafts. At the -same time, working group participants were making suggestions for -incremental changes that might affect more than one proposal. - -Because of this mixing and matching, it was decided that this IDN -comparisons document should compare features that might end up in the -final protocol, not full protocol suggestions themselves. The features -that had been discussed in the working group were divided by function, -and appear in this document in separate sections. For each function, -there are multiple suggestions for protocol elements that might meet the -requirements that are described in [IDN-REQ]. - -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 Format of this document - -Each section covers one feature that has been discussed as being part of -the final IDN solution. Within each section, alternate proposals are -listed with the major perceived pros and cons of the proposal. Also, -each proposal is given a label to make discussion of this document (and -of the proposals themselves) easier. - -References to the numbered requirements in [IDN-REQ] are from version --02 of that document. These numbers are expected to change and the -requirements document evolves. In this draft, the requirements are show -as "[#n-02]", where "n" is the requirement number from draft -02 of -[IDN-REQ]. This document only lists where particular proposals don't -meet particular requirmenents from [IDN-REQ], not the ones that they -fulfill. - -Note that this document is supposed to reflect the discussion of all -proposed alternatives, not just the ones that fully match the -requirements in [IDN-REQ]. It will serve as a summary of the discussion -in the IDN WG for readers in the future who may want to know why certain -alternatives were not chosen for the eventual protocol. - -The proposal drafts covered in this document are: - -[DUERST] Character Normalization in IETF Protocols, -draft-duerst-i18n-norm-03 - -[IDNE] Internationalized domain names using EDNS (IDNE), -draft-ietf-idn-idne-01 - -[KWAN] Using the UTF-8 Character Set in the Domain Name System, -draft-skwan-utf8-dns-03 - -[RACE] RACE: Row-based ASCII Compatible Encoding for IDN, -draft-ietf-idn-race-00 - -[SENG] UTF-5, a transformation format of Unicode and ISO 10646, -draft-jseng-utf5-01 - -[UDNS] Using the Universal Character Set in the Domain Name System -(UDNS), draft-ietf-idn-udns-00 - - -2. Architecture - -One of the biggest questions raised early in the IDN discussion was what -the format of internationalized name parts would be on the wire, that -is, between the user's computer and the DNS resolvers. It was agreed -that the DNS protocols certainly allow non-ASCII octets in domain name -parts and resource records, but there was also acknowledgement that many -protocols that rely on the DNS could not handle non-ASCII names due to -the design of the protocol. Section 3.1 of this document describes the -proposed encodings for the non-ASCII name parts. - -Because of requirement [#2-02], there were proposals for -ASCII-compatible encodings (ACEs) of non-ASCII characters. Different -ACEs were proposed (and are discussed in Section 4 of this document), -but they all have the same goal: to allow non-ASCII characters to be -represented in host names that conform to RFC 1034 [RFC1034]. - -2.1 arch-1: Just send binary - -[KWAN] proposes beginning to send characters outside the range allowed -in RFC 1034. - -Pro: Easiest to describe. Only changes host name syntax, not any of the -related DNS protocols. - -Con: Doesn't work with many exiting protocols that relies on DNS. -Violates requirement [#9-02]. - -2.2 arch-2: Send binary or ACE - -[UDNS] (and, later, [IDNE]) proposes using both binary and ACE formats -on the wire. - -Pro: Allows protocols that can handle binary name parts to use them -directly, while allowing protocols that cannot use binary name parts to -also handle names without conversion. Allows domain names in free text -to be displayed in binary even in systems that require ACE-formatted -names on the wire. - -Con: Requires all software that uses domain names to handle both -formats. Requires processing time for conversion of ACE formats into the -format must likely used internally to the software. - -2.3 arch-3: Just send ACE - -[RACE] and [SENG] propose that host naming rules remain the same and -that all internationalize domain names be sent in ACE format. - -Pro: No changes at all to current DNS protocols. - -Con: Requires all software to recognize ACE domain names and convert -them to human-readable for display. This is true not only in domain -names used on the wire but also domain names used in free text. - - -3. Names in binary - -Both arch-1 and arch-2 include domain name parts that are represented on -the wire in a binary format. This section describes some of the features -of such names. - -3.1 bin-1: Format - -There are many different charsets and encodings for the scripts of the -world. The WG has discussed which binary encoding should be used on the -wire. - -3.1.1 bin-1.1: UTF-8 - -The IETF policy on character sets [RFC2277] states that UTF-8 [RFC2279] -is the preferred charset for IETF protocols. UTF-8 encodes all -characters in the ISO 10646 repertoire. - -Pro: Well-supported in other IETF protocols. Compact for most scripts. -Wide implementation in programming languages. US-ASCII characters have -the same encoding in UTF-8 as they do in US-ASCII. Because it is based -on ISO 10646, expansion of the repertoire comes from respected -international standards bodies. - -Con: Asian scripts require three octets per character. - -3.1.2 bin-1.2: Labelled charsets - -Mailing list discussion mentioned using multiple charsets for the binary -representation. Each name part would be labelled with the charset used. - -Pro: Allows users to specify names in the charsets they are most -familiar with. - -Con: All resolvers would have to know all charsets. Thus, the number of -charsets would probably have to be limited and never expand. Mapping of -characters between charsets would have to be exact and not change over -time. - -3.2 bin-2: Distinguishing binary from current format - -Software built for current domain names might give unexpected results -when dealing with non-ASCII characters in domain names. For example, it -was reported on the mailing list that some software crashes when a -non-ASCII domain name is returned for in-addr.arpa requests. Thus, there -may be a need for IDN to prevent software that is not binary-aware from -receiving domain names with binary parts. This would only apply to an -IDN that used arch-2, not arch-1. - -3.2.1 bin-2.1: Don't mark binary - -[KWAN] does not specify any way of changing requests to prevent binary -name parts from being transmitted. - -Pro: No changes to current DNS requests and responses. - -Con: Likely to cause disruption in software that is not binary-aware. -Likely to cause systems to misread names and possibly (and incorrectly) -convert them to ASCII names by stripping off the high bit in octets; -this in turn would lead to security problems due to mistaken identities. -Returning binary host names to DNS queries is known to break some -current software. - -3.2.2 bin-2.2: Mark binary with IN bit - -[UDNS] describes using a bit from the header of DNS queries to mark the -query as possibly containing a binary name part and indicating that the -response to the query can contain binary name parts. - -Pro: This bit is currently unused and must be set to zero, so current -software won't use it accidentally. No changes to any other part of the -query or RRs. - -Con: It's the last unused bit in the header and DNS folks have indicated -that they are very hesitant to give it up. - -3.2.3 bin-2.3: Mark binary with new QTYPEs - -[UDNS] using new QTYPEs to mark the query as possibly containing a -binary name part and indicating that the response to the query can -contain binary name parts. QTYPEs are two octets long, and no QTYPEs to -date use more than the lower eight bits, so one of the bits from the -upper octet could be used to indicate binary names. - -Pro: These bits are currently unused and must be set to zero, so current -software won't use them accidentally. No changes to any other part of -the query or RRs. Uses a bit that isn't as prized as the IN bit. - -Con: Software must pay more attention to the QTYPEs than it might have -previously. - -3.2.4 bin-2.4: Mark binary with EDNS - -[IDNE] uses EDNS [RFC2671] to mark the query and response as containing -a binary name part. - -Pro: There is little use of EDNS at this point, so it is very unlikely -to have bad interactions with old software. EDNS allows longer name -parts, and allows additional information (such as IDN version number) -in each name part. - -Con: There is little use of EDNS and this might make implementation -harder. - - -4. Names in ASCII-compatible encoding (ACE) - -Both arch-2 and arch-3 include domain name parts that are represented on -the wire in an ASCII-compatible encoding (ACE). This section describes -some of the features of such names. - -4.1 ace-1: Format - -A variety of proposals for the format of ACE have been proposed. Each -proposal has different features, such as how many characters can be -encoded within the 63 octet limit for each name part. The length -descriptions in this section assume that there is no distinguishing of -ACE from current names; this is not a likely outcome of the WG work. - -The descriptions of lengths is based on script block names from -[BLOCK-NAMES]. - -4.1.1 ace-1.1: UTF-5 - -[SENG] Describes UTF-5, which is a fairly direct encoding of ISO 10646 -characters using a system similar to UTF-8. Characters from Basic Latin -and Latin-1 Supplement take 2 octets; Latin Extended-A through Tibetan -take 3 octets; Myanmar through the end of BMP take 4 octets; non-BMP -characters take 5 octets. This means that names using all characters -in the Myanmar through the end of BMP are limited to 15 characters. - -Pro: Extremely simple. - -Con: Poor compression, particularly for Asian scripts. - -4.1.2 ace-1.2: RACE - -[RACE] describes RACE, which is a two-step algorithm that first -compresses the name part, then converts the compressed string into and -ACE. Name parts in all scripts other than Han, Yi, Hangul syllables, -Ethiopic, and non-BMP take up ceil(1.6*(n+1)) octets; name parts in -those scripts and any name that mixes characters from different rows in -ISO 10646 take up ceil(3.2*(n+1)) octets. This means that names using -Han, Yi, Hangul syllables, or Ethiopic, are limited to 18 characters. -(Note: this document used to be called CIDNUC.) - -Pro: Best compression for most scripts, and similar compression for the -scripts where it is not the best. - -Con: More complicated than UTF-5. Not well optimized for names that have -mixed scripts, such as non-Latin names that use hyphen or ASCII digits. - -4.1.3 ace-1.3: Hex of UTF-8 - -An early draft described "hex of UTF-8", which is a straight-forward -hexadecimal encoding of UTF-8. Characters in Basic Latin (other than -non-US-ASCII and hyphen) take 3 octets; Latin Extended-A through Tibetan -take 5 octets; Myanmar through end of BMP take 7 octets; non-BMP -characters take 9 octets. This means that names using all characters -in the Myanmar through the end of BMP are limited to 9 characters. - -Pros: Very simple to describe. - -Cons: Very poor compression for all scripts. - -4.1.4 ace-1.5: SACE - -A message on the mailing list pointed to code for SACE, an ASCII -encoding that purports to compact to about the same size as UTF-8. - -Pros: Similar compression to UTF-8. - -Cons: No description of how the algorithm works. - -4.2 ace-2: Distinguishing ACE from current names - -Software that finds ACE name parts in free text probably should -display the name part using the actual characters, not the ACE -equivalent. Thus, software must be able to identify which ASCII name -parts are ACE and which are non-ACE ASCII parts (such as current names). -This would only apply to an IDN proposal that used arch-2, not arch-3. - -4.2.1 ace-2.1: Currently legal names - -Name parts that are currently legal in RFC 1034 can be tagged to -indicate the part is encoded with ACE. - -4.2.1.1 ace-2.1.1: Add hopefully-unique legal tag - -[RACE] proposes adding a hopefully-unique legal tag to the beginning -of the name. The proposal would also work with such a tag at the end of -the name part, but it is easier for most people to recognize at the -beginning of name parts. - -Pros: Easy for software (and humans) to recognize. - -Cons: There is no way to prevent people from beginning non-ACE names -with the tag. Unless the tag is very unlikely to appear in any name in -any human language, non-ACE names that begin with the tag will display -oddly or be rejected by some systems. - -4.2.1.2 ace-2.1.2: Add a checksum - -Off-list discussion has mentioned the possibility of creating a checksum -mechanism where the checksum would be added to the beginning (or end) of -ACE name parts. - -4.2.2 ace-2.2: Currently illegal names - -Instead of creating names that are currently legal, another proposal is -to create names that use the current ASCII characters but are illegal. - -4.2.2.1 ace-2.2.1: Add trailing hyphen - -An earlier draft described using a trailing hyphen as a signifier of an -ACE name. - -Pros: It is surmised that most current software does not reject names -that are illegal in this fashion. Thus, there would be little disruption -to current systems. This mechanism takes up fewer characters than any -proposed in ace-2.1. - -Cons: Some current software is will probably break with this mechanism. -It goes against some current protocols that match the rules in RFC 1034. - -5. Prohibited characters - -There was a short but active discussion on the mailing list about which -characters from the ISO 10646 character set should never appear in host -names. To date, there are no Internet Drafts on the subject. This -section summarizes some of the suggestions. - -5.1 prohib-1: Identical and near-identical characters - -Some characters are visually identical or incredibly similar to other -characters, thus making it impossible to accurately enter host names -that are seen in print. - -5.2 prohib-2: Separators - -Horizontal and vertical spacing characters would make it unclear where a -host name begins and ends. Also, allowing periods and period-like -characters as characters within a name part would also cause similar -confusion. - -5.3 prohib-3: Non-displaying and non-spacing characters - -There are many characters that cannot be seen in the ISO 10646 character -set. These include control characters, non-breaking spaces, formatting -characters, and tagging characters. These characters would certainly -cause confusion if allowed in host names. - -5.4 prohib-4: Private use characters - -Private use characters from ISO 10646 inherently have no specified -visual form (and in fact can be used for non-displaying characters). -Thus, there could be no visual interoperability for characters in the -private use areas. - -5.5 prohib-5: Punctuation - -Some punctuation characters are disallowed in URLs because they are used -in URL syntax. - -5.6 prohib-6: Symbols - -Some mailing list discussion stated that characters that do not normally -appear in human or company names should not be allowed in host names. -This includes symbols and non-name punctuation. - - -6. Canonicalization - -The working group has a spirited discussion on the need for -canonicalization. [IDN-REQ] describes many requirements for when and what -type of canonicalization might be performed. - -6.1 canon-1: Type of canonicalization - -The Unicode Consortium's recommendations and definitions of -canonicalization [UTR-15] describes many forms of canonicalization that -can be performed on character strings. [DUERST] covers much of the same -ground but makes more focused requirements for canonicalization on the -Internet. - -6.1.1 canon-1.1: Normalization Form C - -[DUERST] recommends Normalization Form C, as described in [UTR-15], for -use on the Internet. This form is a canonical decomposition, followed by -canonical composition. - -6.1.2 canon-1.2: Normalization Form KC - -Discussion on the mailing list recommended Normalization Form KC. This -form is a compatibility decomposition, followed by canonical -composition. Compatibility decomposition makes characters that have -compatibility equivalence the same after decomposing. - -6.2 canon-2: Other canonicalization - -Host names may have special canonicalization needs that can be added to -those given in canon-1. - -6.2.1 canon-2.1: Case folding in ASCII - -RFC 1034 specifies that there is no difference between host names that -have the same letters but the letters have different case. Thus, the -name part "example" is considered the same as "Example" and "EXamPLe". -Neither uppercase nor lowercase is specified as being canonical. - -6.2.2 canon-2.2: Case folding in non-ASCII - -Discussion on the mailing list has raised the issue of whether or not -non-ASCII Latin characters should have the same case-folding rules as -ASCII. Such rules would match the expectations of native speakers of -some languages, but would go counter to the expectations of native -speakers of other languages. - -6.2.3 canon-2.3: Han folding - -Discussion on the mailing list has raised the issue of equivalences in -some languages use of Han characters. For example, in Chinese, there are -many traditional characters that have equivalent simplified characters. -Similarly, there are some Han ideographs for which there are multiple -representations in ISO 10646. There are no well-established rules for -such folding, and some of the proposed folding would be locale-specific. - -6.3 canon-3: Location of canonicalization - -Canonicalization can be performed in any system in the DNS. Because it -is not a trivial operation and can require large tables, the location of -where canonicalization is performed is important. - -6.3.1 canon-3.1: Canonicalize only in the application - -Early canonicalization is a cleaner architecture design. Spending the -cycles on the end systems puts less burden on resolvers or servers in -the DNS service. When IDN is first adopted, the applications need to be -updated anyway to handle the new format for the names. It is easier for -people to upgrade their applications than their resolvers if they need a -new IDN feature. - -6.3.2 canon-3.2: Canonicalize only in the resolver - -Updating a single resolver provides new service to large number of -applications and (possibly) users. It is easier to find canonicalization -bugs in resolvers than in applications because the resolver has -predictable programmatic interfaces. IDN will probably be revised often -as new characters are added to ISO 10646, so updating smaller number of -resolvers is better than revising more applications. When an end user -has a problem with resolving an IDN name, it is much easier to test if -the problem is in the resolver than in the user's application. - -6.3.3 canon-3.3: Canonicalize in the DNS service - -Canonicalization should happen as late as possible so that changes in -the canonicalization algorithm don't orphan all applications and -resolvers. Some canonicalization discards information and so should be -delayed as long as possible. Canonicalization is practically free, -computationally (although it involves some large tables). Because adding -IDN to the DNS will happen over time, canonicalizing at the server will -minimize the number of things that need to be changed, and simplify and -centralize the process of change. - - -7. Transitions - -Early in the working group discussion, there was active debate about how -the transition from the current host name rules to IDN would be handled. -Given requirement [#1-02], this transition is quite important to -deciding which proposals might be feasible. - -7.1 trans-1: Always do current plus new architecture - -In this proposal, IDN will be used at the same time as the current DNS -forever. That is, IDN will be in addition to the current DNS. - -7.2 trans-2: Transition period - -In this proposal, IDN will be used at the same time as the current DNS -for a specified period of time, after which only IDN will exist. That -is, IDN will replace the current DNS. - - -8. Root server considerations - -DNS root servers receive all requests for top-level domains that are not -in the local DNS cache. They are critical to the Internet. Care must be -taken to ensure that root servers will not be affected by new mechanisms -introduced. - -Any IDN proposal that includes a binary encoding will have an impact on -the root servers. The binary requests will affect the root servers -because the current root server software is designed to handle current -host names. Further, the root zone files which contain ccTLDs and gTLDs -would have to support binary domain names and possibly binary host names -for NS records. Because all the root servers are equivalent, they would -have to be synchronized to support the binary domain names at the same -time. - -Proposals that only use ACE and use tagging with currently-legal names -would, by definition, not affect the root servers. - - -9. Security considerations - -All security considerations listed in [IDN-REQ] apply to this document. -Further, all security considerations listed in each of the IDN proposals -must be considered when comparing the proposals. - -Some proposals described in this document may create new security -considerations. However, these considerations will have to be addressed -in the eventual protocol document. All the proposals described here are -still incomplete and security considerations may be added to them as -they are revised. All the proposals listed in this document use the ISO -10646 character set, so the proposals inherit any security -characteristics of that character set. - -Many protocols and applications rely on domain names to identify the -parties involved in a network transaction. For example, a user who -connects to a web site by entering or selecting a URL expects that their -software will select the web site named in the URL. The uniqueness of -domain names are crucial to ensure identification of Internet entities. - -To make round-trip translation between local charsets and ISO 10646, the -ISO 10646 specification has assigned multiple code points to individual -glyphs. Moreover, some glyphs might look similar to some users, but look -clearly different by other users. This means that it would be simple for -an attacker to mimic a domain name by using similar-looking but -different glyphs and guessing that some users will not see the -difference in their user interface. - -Some IDN protocols may have denial of service attacks, such as by using -non-identified chars, exception characters, or under-specified behavior -in using some special characters. - - -10. IANA considerations - -This document does not create any new IANA registries. However, it is -possible that a character property registry may need to be set up when -the IDN protocol is created in order to list prohibited characters -(section 5) and canonicalization mappings (section 6). - - -11. Acknowledgements - -James Seng and Marc Blanchet gave many helpful suggestions on the -pre-release versions of this document. - - -12. References - -[BLOCK-NAMES] Unicode Consortium, -. - -[DUERST] Character Normalization in IETF Protocols, -draft-duerst-i18n-norm-03 - -[IDN-REQ] Requirements of Internationalized Domain Names, -draft-ietf-idn-requirements-02 - -[IDNE] Internationalized domain names using EDNS (IDNE), -draft-ietf-idn-idne-01 - -[KWAN] Using the UTF-8 Character Set in the Domain Name System, -draft-skwan-utf8-dns-03 - -[RACE] RACE: Row-based ASCII Compatible Encoding for IDN, -draft-ietf-idn-race-00 - -[RFC2277] IETF Policy on Character Sets and Languages, RFC 2277 - -[RFC2279] UTF-8, a transformation format of ISO 10646, RFC 2279 - -[RFC2671] Extension Mechanisms for DNS (EDNS0), RFC 2671 - -[SENG] UTF-5, a transformation format of Unicode and ISO 10646, -draft-jseng-utf5-01 - -[UDNS] Using the Universal Character Set in the Domain Name System -(UDNS), draft-ietf-idn-udns-00 - -[UTR15] Unicode Normalization Forms, Unicode Technical Report #15 - - -A. Differences Between -00 and -01 Drafts - -Throughout: Changed references from [HOFFMAN] to [RACE]. - -Throughout: Changed references from [OSCARSSON] to [UDNS]. - -Throughout: Added [IDNE]. - -Removed section 1.2. - -3.2.3: Updated to mention [UDNS]. - -3.2.4: Updated with [IDNE], changed "EDNS0" to "EDNS", and reworded. - -4.1.2: Added Ethiopic to the list of scripts that require two octets per -character. - -4.1.3: Removed reference to [OSCARSSON] because that is no longer in the -[UDNS] draft. - -4.2.2.1: Removed reference to [OSCARSSON] because that is no longer in -the [UDNS] draft. - -6.1.1: Reworded first sentence. - -6.3: Added entire section and subsections. - -8: Fixed typo in first sentence. - - -B. Author Contact - -Paul Hoffman -IMC & VPNC -127 Segre Place -Santa Cruz, CA 95060 -phoffman@imc.org or paul.hoffman@vpnc.org diff --git a/doc/draft/draft-ietf-idn-compare-02.txt b/doc/draft/draft-ietf-idn-compare-02.txt new file mode 100644 index 0000000000..f9dac5815d --- /dev/null +++ b/doc/draft/draft-ietf-idn-compare-02.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +P. Hoffman: phoffman@imc.org + + diff --git a/doc/draft/draft-ietf-idn-dude-00.txt b/doc/draft/draft-ietf-idn-dude-00.txt deleted file mode 100644 index 86e05d4635..0000000000 --- a/doc/draft/draft-ietf-idn-dude-00.txt +++ /dev/null @@ -1,596 +0,0 @@ -Internet Engineering Task Force (IETF) Mark Welter -INTERNET-DRAFT Brian W. Spolarich -draft-ietf-idn-dude-00.txt WALID, Inc. -November 16, 2000 Expires May 16, 2001 - - - DUDE: Differential Unicode Domain Encoding - - -Status of this memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other -groups may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference -material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -The distribution of this document is unlimited. - -Copyright (c) The Internet Society (2000). All Rights Reserved. - -Abstract - -This document describes a tranformation method for representing -Unicode character codepoints in host name parts in a fashion that is -completely compatible with the current Domain Name System. It provides -for very efficient representation of typical Unicode sequences as -host name parts, while preserving simplicity. It is proposed as a -potential candidate for an ASCII-Compatible Encoding (ACE) for supporting -the deployment of an internationalized Domain Name System. - - -Table of Contents - -1. Introduction -1.1 Terminology -2. Hostname Part Transformation -2.1 Post-Converted Name Prefix -2.2 Radix Selection -2.3 Hostname Prepartion -2.4 Definitions -2.5 DUDE Encoding -2.5.1 Extended Variable Length Hex Encoding -2.5.2 DUDE Compression Algorithm -2.5.3 Forward Transformation Algorithm -2.6 DUDE Decoding -2.6.1 Extended Variable Length Hex Decoding -2.6.2 DUDE Decompression Algorithm -2.6.3 Reverse Transformation Algorithm -3. Examples -3.1 'www.walid.com' (in Arabic) -4. DUDE Extensions -4.1 Extended DUDE Encoding -4.1.1 Modified Extended Variable Length Hex Encoding -4.1.2 Extended Compression Algorithm -4.1.3 Extended Forward Transformation Algorithm -4.2 Extended DUDE Decoding -4.2.1 Modified Extended Variable Length Hex Decoding -4.2.2 Extended Decompression Algorithm -4.2.3 Extended Reverse Transformation Algorithm -5. Security Considerations -6. References - - -1. Introduction - -DUDE describes an encoding scheme of the ISO/IEC 10646 [ISO10646] -character set (whose character code assignments are synchronized -with Unicode [UNICODE3]), and the procedures for using this scheme -to transform host name parts containing Unicode character sequences -into sequences that are compatible with the current DNS protocol -[STD13]. As such, it satisfies the definition of a 'charset' as -defined in [IDNREQ]. - -1.1 Terminology - -The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and -"MAY" in this document are to be interpreted as described in RFC 2119 -[RFC2119]. - -Hexadecimal values are shown preceded with an "0x". For example, -"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are -shown preceded with an "0b". For example, a nine-bit value might be -shown as "0b101101111". - -Examples in this document use the notation from the Unicode Standard -[UNICODE3] as well as the ISO 10646 names. For example, the letter "a" -may be represented as either "U+0061" or "LATIN SMALL LETTER A". - -DUDE converts strings with internationalized characters into -strings of US-ASCII that are acceptable as host name parts in current -DNS host naming usage. The former are called "pre-converted" and the -latter are called "post-converted". This specification defines both -a forward and reverse transformation algorithm. - - -2. Hostname Part Transformation - -According to [STD13], hostname parts must start and end with a letter -or digit, and contain only letters, digits, and the hyphen character -("-"). This, of course, excludes most characters used by non-English -speakers, characters, as well as many other characters in the ASCII -character repertoire. Further, domain name parts must be 63 octets or -shorter in length. - -2.1 Post-Converted Name Prefix - -This document defines the string 'dq--' as a prefix to identify -DUDE-encoded sequences. For the purposes of comparison in the IDN -Working Group activities, the 'dq--' prefix should be used solely to -identify DUDE sequences. However, should this document proceed beyond -draft status the prefix should be changed to whatever prefix, if any, -is the final consensus of the IDN working group. - -Note that the prepending of a fixed identifier sequence is only one -mechanism for differentiating ASCII character encoded international -domain names from 'ordinary' domain names. One method, as proposed in -[IDNRACE], is to include a character prefix or suffix that does not -appear in any name in any zone file. A second method is to insert a -domain component which pushes off any international names one or more -levels deeper into the DNS hierarchy. There are trade-offs between -these two methods which are independent of the Unicode to ASCII -transcoding method finally chosen. We do not address the international -vs. 'ordinary' name differention issue in this paper. - -2.2 Radix Selection - -There are many proposed methods for representing Unicode characters -within the allowed target character set, which can be split into groups -on the basis of the underlying radix. We have chosen a method with -radix 16 because both UTF-16 and ASCII are represented by even multiples -of four bits. This allows a Unicode character to be encoded as a -whole number of ASCII characters, and permits easier manipulation of -the resulting encoded data by humans. - -2.3 Hostname Prepartion - -The hostname part is assumed to have at least one character disallowed -by [STD13], and that is has been processed for logically equivalent -character mapping, filtering of disallowed characters (if any), and -compatibility composition/decomposition before presentation to the DUDE -conversion algorithm. - -While it is possible to invent a transcoding mechanism that relies -on certain Unicode characters being deemed illegal within domain names -and hence available to the transcoding mechanism for improving encoding -efficiency, we feel that such a proposal would complicate matters -excessively. We also believe that Unicode name preprocessing for -both name resolution and name registration should be considered as -separate, independent issues, which we will address in a separate -document. - -2.4 Definitions - -For clarity: - - 'integer' is an unsigned binary quantity; - 'byte' is an 8-bit integer quantity; - 'nibble' is a 4-bit integer quantity. - -2.5 DUDE Encoding - -The idea behind this scheme is to provide compression by encoding the -contiguous least significant nibbles of a character that differ from the -preceding character. Using a variant of the variable length hex encoding -desribed in [IDNDUERST] and elsewhere, by encoding leading zero nibbles -this technique allows recovery of the differential length. The encoding -is, with some practice, easy to perform manually. - -There are two extensions to this basic idea: one enables encoding the -preferred case for each charcter (for reverse DNS resolution) and -another improves the worse case behaviour related to surrogates. The -basic algorithms will be formally described first and then the extended -algorithms will be described. - -2.5.1 Extended Variable Length Hex Encoding - -The variable length hex encoding algorithm was introduced by Duerst in -[IDNDUERST]. It encodes an integer value in a slight modification of -traditional hexadecimal notation, the difference being that the most -significant digit is represented with an alternate set of "digits" -- -- 'g through 'v' are used to represent 0 through 15. The result is a -variable length encoding which can efficiently represent integers of -arbitrary length. - -This specification extends the variable length hex encoding algorithm -to support the compression scheme defined below by potentially not -supressing leading zero nibbles. - -The extended variable length nibble encoding of an integer, C, -to length N, is defined as follows: - - 1. Start with I, the Nth least significant nibble from the least - significant nibble of C; - - 2. Emit the Ith character of the sequence [ghijklmnopqrstuv]; - - 3. Continue from the most to least significant, encoding each - remaining nibble J by emitting the Jth character of the - sequence [0123456789abcdef]. - -2.5.2 DUDE Compression Algorithm - - 1. Let PREV = 0; - - 2. If there are no more characters in the input, terminate successfully; - - 4. Let C be the next character in the input; - - 5. If C != '-' , then go to step 5; - - 6. Consume the input character, emit '-', and go to step 2; - - 7. Let D be the result of PREV exclusive ORed with C; - - 8. Find the least positive value N such that - D bitwise ANDed with M is zero - where M = the bitwise complement of (16**N) - 1; - - 9. Let V be C ANDed with the bitwise complement of M; - - 10. Variable length hex encode V to length N and emit the result; - - 11. Let PREV = C and go to step 2. - - -2.5.3 Forward Transformation Algorithm - -The DUDE transformation algorithm accepts a string in UTF-16 -[ISO10646] format as input. The encoding algorithm is as follows: - - 1. Break the hostname string into dot-separated hostname parts. - For each hostname part which contains one or more characters - disallowed by [STD13], perform steps 2 and 3 below; - - 2. Compress the hostname part using the method described in section - 2.5.2 above, and encode using the encoding described in section - 2.5.1; - - 3. Prepend the post-converted name prefix 'dq--' (see section 2.1 - above) to the resulting string. - - -2.6 DUDE Decoding - -2.6.1 Extended Variable Length Hex Decoding - - Decoding extended variable length hex encoded strings is identical -to the standard variable length hex encoding, and is defined as -follows: - - 1. Let CL be the lower case of the first input character, - - If CL is not in set [ghijklmnopqrstuv], - return error, - else - consume the input character; - - 2. Let R = CL - 'g', - Let N = 1; - - 3. If no more input characters exist, go to step 9. - - 4. Let CL be the lower case of the next input character; - - 5. If CL is not in the set [0123456789abcdef], go to Step 9; - - 6. Consume the next input character, - Let N = N + 1; - Let R = R * 16; - - 7. If N is in set [0123456789], - then let R = R + (N - '0') - else let R = R + (N - 'a') + 10; - - 8. Go to step 3; - - 9. Let MASK be the bitwise complement of (16**N) - 1; - - 10. Return decoded result R as well as MASK. - -2.6.2 DUDE Decompression Algorithm - - 1. Let PREV = 0; - - 2. If there are no more input characters then terminate successfully; - - 3. Let C be the next input character; - - 4. If C == '-', append '-' to the result string, consume the character, - and go to step 2, - - 5. Let VPART, MASK be the next variable length hex decoded - value and mask; - - 6. If VPART > 0xFFFF then return error status, - - 7. Let CU = ( PREV bitwise-AND MASK) + VPART, - Let PREV = CU; - - 8. Append the UTF-16 character CU to the result string; - - 9. Go to step 2. - - -2.6.3 Reverse Transformation Algorithm - - 1. Break the string into dot-separated components and apply Steps - 2 through 4 to each component; - - 2. Remove the post converted name prefix 'dq--' (see Section 2.1); - - 3. Decompress the component using the decompression algorithm - described above; - - 4. Concatenate the decoded segments with dot separators and return. - -3. Examples - -The examples below illustrate the encoding algorithm and provide -comparisons to alternate encoding schemes. UTF-5 sequences are -prefixed with '----', as no ACE prefix was defined for that encoding. - -3.1 'www.walid.com' (in Arabic): - - UTF-16: U+0645 U+0648 U+0642 U+0639 . U+0648 U+0644 U+064A U+062F . - U+0634 U+0631 U+0643 U+0629 - - DUDE: dq--m45oij9.dq--m48kqif.dq--m34hk3i9 - - UTF-6: wq--ymk5k8k2j9.wq--ymk8k4kaif.wq--ymj4j1k3i9 - - UTF-5: ----m45m48m42m39.----m48m44m4am2f.----m34m31m43m29 - - RACE: bq--azcuqqrz.bq--azeeisrp.bq--ay2dcqzj - - LACE: bq--aqdekscche.bq--aqdeqrckf5.bq--aqddimkdfe - - (more examples to come) - -4. DUDE Extensions - -The first extension to the DUDE concept recognizes that the first -character emitted by the variable length hex encoding algorithm is -always alphabetic. We encode the case (if any) of the original Unicode -character in the case of the initial "hex" character. Because the DNS -performs case-insensitive comparisons, mixed case international domain -names behave in exactly the same way as traditional domain names. -In particular, this enables reverse lookups to return names in the -preferred case. - -The second extension regards the treatment of Unicode surrogate -characters. If surrogates are not expanded, two 16-bit surrogates are -needed to represent a single codepoint in the range of 0x10000 -through 0x10FFFF. This cuts the worse case limits in half for most -proposals. We will assume that our input and output Unicode are in -UTF-32 format -- that is, any surrogates are expanded to their UCS-4 -equivalents. If the input codes all fall under 0x10000, then the -extended method will emit the same length string as the basic method. -One final modification takes note of the fact that the only only -codepoints forcing the use of six hex digits is for those with a "10" -as the fifth and sixth digits. We will encode the fifth digit using -a seventeenth digit as a special case to avoid this extra expansion. - -4.1 Extended DUDE Encoding - -4.1.1 Modified Extended Variable Length Hex Encoding - -The modified extended variable length hex encoding of an integer C to -length N with case U is performed as follows: - - 1. If C > 0x10FFFF return error status; - - 2. If N < 6 go to step 5; (this is true for characters from - the first 16 Planes) - - 3. If U is 'Uppercase' then emit 'W' - else emit 'w'; (special case for the 17th Plane) - - 4. go to step 7; - - 5. Let I be the Nth nibble from the right of C; - - 6. If U is 'Uppercase' - then emit the Ith character of sequence [GHIJKLMNOPQRSTUV], - else emit the Ith character of sequence [ghijklmnopqrstuv]; - - 7. Let N = N - 1; - - 8. Continue from N to 1, encoding each remaining nibble, J, by - emitting the Jth character of sequence [0123456789abcdef]. - - -4.1.2 Extended Compression Algorithm - - 1. Let PREV = 0; - - 2. If there are no more characters in the input, terminate successfully; - - 4. Let U be the case of the next character in the input; - Let C be the lowercase value of the next input character; - - 5. If C != '-' , then go to step 7; - - 6. Consume the input character, emit '-', and go to step 2; - - 7. Let D be the result of PREV exclusive ORed with C; - - 8. Find the least positive value N such that - D bitwise ANDed with M is zero - where M = the bitwise complement of (16**N) - 1; - - 9. Let V = C ANDed with the bitwise complement of M; - - 10. Emit the modified variable length hex encoding of V to length - N with case U; - - 11. Let PREV = C and go to step 2. - -4.1.3 Extended Forward Transformation Algorithm - -The overall extended encoding algorithm is as follows: - - 1. Break the hostname string into dot-separated hostname parts. - For each hostname part, perform steps 2 and 3 below; - - 2. Compress the component using the method described in section - 4.1.2 above, and encode using the encoding described in section - 4.1.1; - - 3. Prepend the post-converted name prefix 'dq--' (see section 2.1 - above) to the resulting string. - -4.2 Extended DUDE Decoding - -4.2.1 Modified Extended Variable Length Hex Decoding - - 1. Let U be the case of the next input character, - Let C0 be the lower case of the next input character; - - 2. If C0 is not in set [ghijklmnopqrstuw] then return error status, - else, consume the input character; - - 3. Let R = C0 - 'g' - Let N = 1; - - 4. If no more input characters exist then go to step 8; - - 5. Let CL be the lower case of the next input character, - If CL is not in set [0123456789abcdef] then go to step 8; - - 6. Consume the next input character, - Let N = N + 1, - Let R = R * 16, - If CL is in set [0-9] - then let R = R + (CL - '0') - else let R = R + (CL - 'a') + 10; - - 7. Go to step 4; - - 8. If R < 0x100000 then go to step 10; - - 9. Let N = N + 1, - If (N > 6) or (C0 != 'w') - then return error status; - - 10. Let MASK be the bitwise complement of (16**N) - 1. Return - result R, MASK, and U. - -4.2.2 Extended Decompression Algorithm - - 1. Let PREV = 0; - - 2. If there are no more input characters then terminate successfully; - - 3. Let C be the next input character; - - 4. If C == '-', append '-' to the result - string, consume the character, and go to step 2; - - 5. Let VPART, MASK, and U be the result of the modified extended - variable length decoded value; - - 6. Let CU = (PREV 'bitwise AND' MASK) + VPART, - Let PREV = CU; - - 7. If U == 'Uppercase' then let CU = the corresponding upper case value - of CU; - - 8. Append CU to the result string and go to step 2. - -4.2.3 Extended Reverse Transformation Algorithm - - 1. Break the string into dot-separated components and apply Steps - 2 through 4 to each component; - - 2. Remove the post converted name prefix 'dq--' (see Section 2.1); - - 3. Decompress the component using the extended decompression - algorithm described in section 4.2.2 above; - - 4. Concatenate the decoded segments with dot separators and return. - -Note that DUDE decoding will return error for input strings which do -not comply with RFC1035. - -5. Security Considerations - -Much of the security of the Internet relies on the DNS and any -change to the characteristics of the DNS may change the security of -much of the Internet. Therefore DUDE makes no changes to the DNS itself. - -DUDE is designed so that distinct Unicode sequences map to distinct -domain name sequences (modulo the Unicode and DNS equivalence rules). -Therefore use of DUDE with DNS will not negatively affect security. - - -6. References - -[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name -Proposals", draft-ietf-idn-compare; - -[IDNRACE] Paul Hoffman, "RACE: Row-Based ASCII Compatible Encoding for -IDN", draft-ietf-idn-race; - -[IDNREQ] James Seng, "Requirements of Internationalized Domain Names", -draft-ietf-idn-requirement; - -[IDNNAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of -Internationalized Host Names", draft-ietf-idn-nameprep; - -[IDNDUERST] M. Duerst, "Internationalization of Domain Names", -draft-duerst-dns-i18n; - -[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information -technology -- Universal Multiple-Octet Coded Character Set (UCS) -- -Part 1: Architecture and Basic Multilingual Plane. Five amendments and -a technical corrigendum have been published up to now. UTF-16 is -described in Annex Q, published as Amendment 1. 17 other amendments are -currently at various stages of standardization; - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", March 1997, RFC 2119; - -[STD13] Paul Mockapetris, "Domain names - implementation and -specification", November 1987, STD 13 (RFC 1035); - -[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version -3.0", ISBN 0-201-61633-5. Described at -. - - -A. Acknowledgements - -The structure (and some of the structural text) of this document is -intentionally borrowed from the LACE IDN draft (draft-ietf-idn-lace-00) -by Mark Davis and Paul Hoffman. - -B. IANA Considerations - -There are no IANA considerations in this document. - - -C. Author Contact Information - -Mark Welter -Brian W. Spolarich -WALID, Inc. -State Technology Park -2245 S. State St. -Ann Arbor, MI 48104 -+1-734-822-2020 - -mwelter@walid.com -briansp@walid.com ------BEGIN PGP SIGNATURE----- -Version: GnuPG v1.0.1 (GNU/Linux) -Comment: For info see http://www.gnupg.org - -iD8DBQE6FZ/D/DkPcNgtD/0RAoswAKCUGBTSFJv96+Z+YnA8m47qrnheAgCeLQ6C -1+knyHluauC+66esCtPVoKU= -=hbT+ ------END PGP SIGNATURE----- - diff --git a/doc/draft/draft-ietf-idn-dude-01.txt b/doc/draft/draft-ietf-idn-dude-01.txt new file mode 100644 index 0000000000..d1b83c223f --- /dev/null +++ b/doc/draft/draft-ietf-idn-dude-01.txt @@ -0,0 +1,898 @@ +Internet Engineering Task Force (IETF) Mark Welter +INTERNET-DRAFT Brian W. Spolarich +draft-ietf-idn-dude-01.txt WALID, Inc. +March 02, 2001 Expires September 02, 2001 + + + DUDE: Differential Unicode Domain Encoding + + +Status of this memo + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other +groups may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +The distribution of this document is unlimited. + +Copyright (c) The Internet Society (2000). All Rights Reserved. + +Abstract + +This document describes a tranformation method for representing +Unicode character codepoints in host name parts in a fashion that is +completely compatible with the current Domain Name System. It provides +for very efficient representation of typical Unicode sequences as +host name parts, while preserving simplicity. It is proposed as a +potential candidate for an ASCII-Compatible Encoding (ACE) for supporting +the deployment of an internationalized Domain Name System. + + +Table of Contents + +1. Introduction +1.1 Terminology +2. Hostname Part Transformation +2.1 Post-Converted Name Prefix +2.2 Radix Selection +2.3 Hostname Prepartion +2.4 Definitions +2.5 DUDE Encoding +2.5.1 Extended Variable Length Hex Encoding +2.5.2 DUDE Compression Algorithm +2.5.3 Forward Transformation Algorithm +2.6 DUDE Decoding +2.6.1 Extended Variable Length Hex Decoding +2.6.2 DUDE Decompression Algorithm +2.6.3 Reverse Transformation Algorithm +3. Examples +4. Optional Case Preservation +5. Security Considerations +6. References + + +1. Introduction + +DUDE describes an encoding scheme of the ISO/IEC 10646 [ISO10646] +character set (whose character code assignments are synchronized +with Unicode [UNICODE3]), and the procedures for using this scheme +to transform host name parts containing Unicode character sequences +into sequences that are compatible with the current DNS protocol +[STD13]. As such, it satisfies the definition of a 'charset' as +defined in [IDNREQ]. + +1.1 Terminology + +The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and +"MAY" in this document are to be interpreted as described in RFC 2119 +[RFC2119]. + +Hexadecimal values are shown preceded with an "0x". For example, +"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are +shown preceded with an "0b". For example, a nine-bit value might be +shown as "0b101101111". + +Examples in this document use the notation from the Unicode Standard +[UNICODE3] as well as the ISO 10646 names. For example, the letter "a" +may be represented as either "U+0061" or "LATIN SMALL LETTER A". + +DUDE converts strings with internationalized characters into +strings of US-ASCII that are acceptable as host name parts in current +DNS host naming usage. The former are called "pre-converted" and the +latter are called "post-converted". This specification defines both +a forward and reverse transformation algorithm. + + +2. Hostname Part Transformation + +According to [STD13], hostname parts must start and end with a letter +or digit, and contain only letters, digits, and the hyphen character +("-"). This, of course, excludes most characters used by non-English +speakers, characters, as well as many other characters in the ASCII +character repertoire. Further, domain name parts must be 63 octets or +shorter in length. + +2.1 Post-Converted Name Prefix + +This document defines the string 'dq--' as a prefix to identify +DUDE-encoded sequences. For the purposes of comparison in the IDN +Working Group activities, the 'dq--' prefix should be used solely to +identify DUDE sequences. However, should this document proceed beyond +draft status the prefix should be changed to whatever prefix, if any, +is the final consensus of the IDN working group. + +Note that the prepending of a fixed identifier sequence is only one +mechanism for differentiating ASCII character encoded international +domain names from 'ordinary' domain names. One method, as proposed in +[IDNRACE], is to include a character prefix or suffix that does not +appear in any name in any zone file. A second method is to insert a +domain component which pushes off any international names one or more +levels deeper into the DNS hierarchy. There are trade-offs between +these two methods which are independent of the Unicode to ASCII +transcoding method finally chosen. We do not address the international +vs. 'ordinary' name differention issue in this paper. + +2.2 Radix Selection + +There are many proposed methods for representing Unicode characters +within the allowed target character set, which can be split into groups +on the basis of the underlying radix. We have chosen a method with +radix 16 because both UTF-32 and ASCII are represented by even multiples +of four bits. This allows a Unicode character to be encoded as a +whole number of ASCII characters, and permits easier manipulation of +the resulting encoded data by humans. + +2.3 Hostname Preparation + +The hostname part is assumed to have at least one character disallowed +by [STD13], and that is has been processed for logically equivalent +character mapping, filtering of disallowed characters (if any), and +compatibility composition/decomposition before presentation to the DUDE +conversion algorithm. + +While it is possible to invent a transcoding mechanism that relies +on certain Unicode characters being deemed illegal within domain names +and hence available to the transcoding mechanism for improving encoding +efficiency, we feel that such a proposal would complicate matters +excessively. + +2.4 Definitions + +For clarity: + + 'integer' is an unsigned binary quantity; + 'byte' is an 8-bit integer quantity; + 'nibble' is a 4-bit integer quantity. + +2.5 DUDE Encoding + +The idea behind this scheme is to provide compression by encoding the +contiguous least significant nibbles of a character that differ from the +preceding character. Using a variant of the variable length hex encoding +desribed in [IDNDUERST] and elsewhere, by encoding leading zero nibbles +this technique allows recovery of the differential length. The encoding +is, with some practice, easy to perform manually. + +2.5.1 Extended Variable Length Hex Encoding + +The variable length hex encoding algorithm was introduced by Duerst in +[IDNDUERST]. It encodes an integer value in a slight modification of +traditional hexadecimal notation, the difference being that the most +significant digit is represented with an alternate set of "digits" +- -- 'g through 'v' are used to represent 0 through 15. The result is a +variable length encoding which can efficiently represent integers of +arbitrary length. + +This specification extends the variable length hex encoding algorithm +to support the compression scheme defined below by potentially not +supressing leading zero nibbles. + +The extended variable length nibble encoding of an integer, C, +to length N, is defined as follows: + + 1. Start with I, the Nth least significant nibble from the least + significant nibble of C; + + 2. Emit the Ith character of the sequence [ghijklmnopqrstuv]; + + 3. Continue from the most to least significant, encoding each + remaining nibble J by emitting the Jth character of the + sequence [0123456789abcdef]. + +2.5.2 DUDE Compression Algorithm + + 1. Let PREV = 0; + + 2. If there are no more characters in the input, terminate successfully; + + 4. Let C be the next character in the input; + + 5. If C != '-' , then go to step 7; + + 6. Consume the input character, emit '-', and go to step 2; + + 7. Let D be the result of PREV exclusive ORed with C; + + 8. Find the least positive value N such that + D bitwise ANDed with M is zero + where M = the bitwise complement of (16**N) - 1; + + 9. Let V be C ANDed with the bitwise complement of M; + + 10. Variable length hex encode V to length N and emit the result; + + 11. Let PREV = C and go to step 2. + + +2.5.3 Forward Transformation Algorithm + +The DUDE transformation algorithm accepts a string in UTF-32 +[UNICODE3] format as input. It is assumed that prior nameprep +processing has disallowed the private use code points in +0X100000 throuh 0X10FFFF, so that we are left with the task of +encoding 20 bit integers. The encoding algorithm is as follows: + + 1. Break the hostname string into dot-separated hostname parts. + For each hostname part which contains one or more characters + disallowed by [STD13], perform steps 2 and 3 below; + + 2. Compress the hostname part using the method described in section + 2.5.2 above, and encode using the encoding described in section + 2.5.1; + + 3. Prepend the post-converted name prefix 'dq--' (see section 2.1 + above) to the resulting string. + + +2.6 DUDE Decoding + +2.6.1 Extended Variable Length Hex Decoding + + Decoding extended variable length hex encoded strings is identical +to the standard variable length hex encoding, and is defined as +follows: + + 1. Let CL be the lower case of the first input character, + + If CL is not in set [ghijklmnopqrstuv], + return error, + else + consume the input character; + + 2. Let R = CL - 'g', + Let N = 1; + + 3. If no more input characters exist, go to step 9. + + 4. Let CL be the lower case of the next input character; + + 5. If CL is not in the set [0123456789abcdef], go to Step 9; + + 6. Consume the next input character, + Let N = N + 1; + Let R = R * 16; + + 7. If N is in set [0123456789], + then let R = R + (N - '0') + else let R = R + (N - 'a') + 10; + + 8. Go to step 3; + + 9. Let MASK be the bitwise complement of (16**N) - 1; + + 10. Return decoded result R as well as MASK. + +2.6.2 DUDE Decompression Algorithm + + 1. Let PREV = 0; + + 2. If there are no more input characters then terminate successfully; + + 3. Let C be the next input character; + + 4. If C == '-', append '-' to the result string, consume the character, + and go to step 2, + + 5. Let VPART, MASK be the next extended variable length hex decoded + value and mask; + + 6. If VPART > 0xFFFFF then return error status, + + 7. Let CU = ( PREV bitwise-AND MASK) + VPART, + Let PREV = CU; + + 8. Append the UTF-32 character CU to the result string; + + 9. Go to step 2. + + +2.6.3 Reverse Transformation Algorithm + + 1. Break the string into dot-separated components and apply Steps + 2 through 4 to each component; + + 2. Remove the post converted name prefix 'dq--' (see Section 2.1); + + 3. Decompress the component using the decompression algorithm + described above (which in turn invokes the decoding algorithm + also described above); + + 4. Concatenate the decoded segments with dot separators and return. + +3. Examples + +The examples below illustrate the encoding algorithm. Allowed RFC1035 +characters, including period [U+002E] and dash [U+002D] are shown as +literals in the UTF-16 version of the example. DUDE is compared to +LACE as proposed in [IDNLACE]. A comprehensive comparison of ACE +proposals is outside of the scope of this document. However we believe +that DUDE shows a good balance between efficiency (resulting in shorter +ACE sequences for typical names) and complexity. + + +3.1 'www.walid.com' [Arabic]: + + UTF-16: U+0645 U+0648 U+0642 U+0639 . U+0648 U+0644 U+064A U+062F . + U+0634 U+0631 U+0643 U+0629 + + DUDE: dq--m45oij9.dq--m48kqif.dq--m34hk3i9 + + LACE: bq--aqdekscche.bq--aqdeqrckf5.bq--aqddimkdfe + +3.2 'Abugazalah-Intellectual-Property.com' [Arabic]: + + UTF-16: U+0623 U+0628 U+0648 U+063A U+0632 U+0627 U+0644 U+0629 - + U+0644 U+0644 U+0645 U+0644 U+0643 U+064A U+0629 - U+0627 + U+0644 U+0641 U+0643 U+0631 U+064A U+0629 . U+0634 U+0631 + U+0643 U+0629 + + DUDE: dq--m23ok8jaii7k4i9-m44klkjqi9-m27k4hjj1kai9.dq--m34hk3i9 + + LACE: bq--badcgkcihizcorbjaeac2bygircekrcdjiuqcabna4dcorcbimyuuki. + bq--aqddimkdfe + +3.3 'King-Hussain.person.jr' [Arabic] + + UTF-16: U+0627 U+0644 U+0645 U+0644 U+0643 - U+062D U+0633 U+064A + U+0646 . U+0634 U+062E U+0635 . U+0627 U+0644 U+0623 U+0631 + U+062F U+0646 + + DUDE: dq--m27k4lkj-m2dj3kam.dq--m34iej5.dq--m27k4i3j1ifk6 + + LACE: bq--audcorcfirbqcabnaudegljtjjda.bq--amddilrv. + bq--aydcorbdgexum + +3.4 'Jordanian-Dental-Center.com.jr' [Arabic] + + UTF-16: U+0645 U+0631 U+0643 U+0632 - U+0627 U+0644 U+0623 U+0631 U+062F + U+0646 - U+0644 U+0644 U+0623 U+0633 U+0646 U+0627 U+0646 . + U+0634 U+0631 U+0643 U+0629 . U+0627 U+0644 U+0623 U+0631 U+062F + U+0646 + + DUDE: dq--m45j1k3j2-m27k4i3j1ifk6-m44ki3j3k6i7k6.dq--m34hk3i9. + dq--m27k4i3j1ifk6 + + LACE: bq--aqdekmkdgiaqaligaytuiizrf5dacabna4deirbdgndcorq. + bq--aqddimkdfe.bq--aydcorbdgexum + +3.5 'Mahindra.com' [Hindi]: + + UTF-16: U+092E U+0939 U+093F U+0928 U+094D U+0926 U+094D U+0930 + U+093E . U+0935 U+094D U+092F U+093E U+092A U+093E U+0930 + + DUDE: dq--p2ej9vi8kdi6kdj0u.dq--p35kdifjeiajeg + + LACE: bq--bees4oj7fbgsmtjqhy.bq--a4etktjphyvd4ma + +3.6 'Webdunia.com' [Hindi]: + + UTF-16: U+0935 U+0947 U+092C U+0926 U+0941 U+0928 U+093F U+092F + U+093E . U+0935 U+094D U+092F U+093E U+092A U+093E U+0930 + + DUDE: dq--p35k7icmk1i8jfifje.dq--p35kdifjeiajeg + + LACE: bq--beetkrzmezasqpzphy.bq--a4etktjphyvd4ma + +3.7 'Chinese Finance.com' [Traditional Chinese] + + UTF-16: U+4E2D U+83EF U+8CA1 U+7D93 . c o m + + DUDE: dq--ke2do3efsa1nd93.com + + LACE: bq--75hc3a7prsqx3ey.com + +3.8 'Chinese Readers.net' [Chinese] + + UTF-16: U+842C U+7DAD U+8B80 U+8005 . U+7DB2 U+7D61 + + DUDE: dq--o42cndadob80g05.dq--ndb2m1 + + LACE: bq--76ccy7nnroaiabi.bq--aj63eyi + +3.9 'Russian-Standard.com.ru' [Russian] + + UTF-16: U+0440 U+0443 U+0441 U+0441 U+043A U+0438 U+0439 - + U+0441 U+0442 U+0430 U+043D U+0434 U+0430 U+0440 U+0442 . + U+043A U+043E U+043C . U+0440 U+0444 + + DUDE: dq--k40jhhjaop-k3ausk1ij0tkgk0i.dq--k3aus.dq--k40k + + LACE: bq--a4ceaq2bie5dqoibaawqqbcbiiyd2nbqibba.bq--amcdupr4. + bq--aiceara + +3.10 'Vladimir-Putin.person.ru' [Russian] + + UTF-16: U+0432 U+043B U+0430 U+0434 U+0438 U+043C U+0438 U+0440 - + U+043F U+0443 U+0442 U+0438 U+043D . U+043B U+0438 U+0447 + U+043D U+043E U+0441 U+0442 U+044C . U+0440 U+0444 U+0020 + + DUDE: dq--k32rgkosok0-k3fk3ij8t.dq--k3bok7jduk1is.dq--k40k + + LACE: bq--bacdeozqgq4dyocaaeac2bieh5bueob5. + bq--bacdwochhu7ecqsm.bq--aiceara + + +4. Optional Case Preservation + +An extension to the DUDE concept recognizes that the first +character emitted by the variable length hex encoding algorithm is +always alphabetic. We encode the case (if any) of the original Unicode +character in the case of the initial "hex" character. Because the DNS +performs case-insensitive comparisons, mixed case international domain +names behave in exactly the same way as traditional domain names. +In particular, this enables reverse lookups to return names in the +preferred case. + +In contrast to other proposals as of this writing, such a case preserving +version of DUDE will interoperate with the non case preserving version. + +Despite the foregoing, we feel that the additional complexity of tracking +character case through the nameprep processing is not warranted by the +marginal utility of the result. + +5. Security Considerations + +Much of the security of the Internet relies on the DNS and any +change to the characteristics of the DNS may change the security of +much of the Internet. Therefore DUDE makes no changes to the DNS itself. + +DUDE is designed so that distinct Unicode sequences map to distinct +domain name sequences (modulo the Unicode and DNS equivalence rules). +Therefore use of DUDE with DNS will not negatively affect security below +the application level. + +If an application has security reliance on the Unicode string S, produced +by an inverse ACE transformation of a name T, the application must verify +that the nameprepped and ACE encoded result of S is DNS-equivalent to T. + +6. Change History + +The statement that we intended to submit a Nameprep draft was removed in +light of the changes made between the frist and second nameprep drafts. + +The details of DUDE extensions for case preservation etc. have been +removed. Basic DUDE was changed to operate over the relevant 20 bit +UTF32 code points. + +Examples have been extended. + +ACE security issues were clarified. + +7. References + +[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name +Proposals", draft-ietf-idn-compare; + +[IDNrACE] Paul Hoffman, "RACE: Row-Based ASCII Compatible Encoding for +IDN", draft-ietf-idn-race; + +[IDNLACE] Mark Davis, "LACE: Length-Based ASCII Compatible Encoding for +IDN", draft-ietf-idn-lace; + +[IDNREQ] James Seng, "Requirements of Internationalized Domain Names", +draft-ietf-idn-requirement; + +[IDNNAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of +Internationalized Host Names", draft-ietf-idn-nameprep; + +[IDNDUERST] M. Duerst, "Internationalization of Domain Names", +draft-duerst-dns-i18n; + +[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information +technology -- Universal Multiple-Octet Coded Character Set (UCS) -- +Part 1: Architecture and Basic Multilingual Plane. Five amendments and +a technical corrigendum have been published up to now. UTF-16 is +described in Annex Q, published as Amendment 1. 17 other amendments are +currently at various stages of standardization; + +[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate +Requirement Levels", March 1997, RFC 2119; + +[STD13] Paul Mockapetris, "Domain names - implementation and +specification", November 1987, STD 13 (RFC 1035); + +[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version +3.0", ISBN 0-201-61633-5. Described at +. + + +A. Acknowledgements + +The structure (and some of the structural text) of this document is +intentionally borrowed from the LACE IDN draft (draft-ietf-idn-lace-00) +by Mark Davis and Paul Hoffman. + +B. IANA Considerations + +There are no IANA considerations in this document. + + +C. Author Contact Information + +Mark Welter +Brian W. Spolarich +WALID, Inc. +State Technology Park +2245 S. State St. +Ann Arbor, MI 48104 ++1-734-822-2020 + +mwelter@walid.com +briansp@walid.com + +D. DUDE C++ Implementation + +#include +#include +#include +#include + +#define IDN_ERROR INT_MIN + +#define DUDETAG "dq--" + +typedef unsigned int uchar_t; + +bool idn_isRFC1035(const uchar_t * in, int len) +{ + const uchar_t * end = in + len; + + while (in < end) + { + if ((*in > 127) || + !strchr("abcdefghijklmnopqrstuvwxyz0123456789-.", tolower(*in))) + return false; + in++; + } + return true; +} + +static const char *hexchar = "0123456789abcdef"; +static const char *leadchar = "ghijklmnopqrstuv"; + +/* + dudehex -- convert an integer, v, into n DUDE hex characters. + The result is placed in ostr. The buffer ends at the byte before + eop, and false is returned to indicate insufficient buffer space. +*/ +static bool dudehex(char * & ostr, const char * eop, + unsigned int v, int n) +{ + if ((ostr + n) >= eop) + return false; + + n--; // convert to zero origin + + *ostr++ = leadchar[(v >> (n << 2)) & 0x0F]; + + while (n > 0) + { + n--; + *ostr++ = hexchar[(v >> (n << 2)) & 0x0F]; + } + return true; +} + +/* + idn_dudeseg converts istr, a utf-32 domain name segment into DUDE. + eip points at the character after the input segment. + ostr points at an output buffer which ends just before eop. + If there is insufficient buffer space, the function return is false. + Invalid surrogate sequences will also cause a return of false. +*/ +static bool idn_dudeseg(const uchar_t * istr, const uchar_t * eip, + char * & ostr, char * eop) +{ + const uchar_t * ip = istr; + unsigned p = 0; + + while (ip < eip) + { + if (*ip == '-') + *ostr++ = *ip; + else // if (validnc(*ip)) + { + unsigned int c = *ip; + + unsigned d = p ^ c; // d now has the difference (xor) + // between the current and previous char + + int n = 1; // Count the number of significant nibbles + while (d >>= 4) + n++; + + dudehex(ostr, eop, c, n); + p = c; + } + ip++; + } + *ostr = 0; + return true; +} + + +/* + idn_UTF32toDUDE converts a UTF-32 domain name into DUDE. + in, a UTF-32 vector of length inlen is the input domain name. + outstr is a char output buffer of length outmax. + On success, the number of output characters is returned. + On failure, a negative number is returned. + + It is assumed that the input has been nameprepped. + + If this routine is used in a registration context, segment and + overall length restrictions must be checked by the user. +*/ + +int idn_UTF32toDUDE(const uchar_t * in, int inlen, char *outstr, int outmax) +{ + const uchar_t *ip = in; + const uchar_t *eip = in + inlen; + const uchar_t *ep = ip; + char *op = outstr; + char *eop = outstr + outmax - 1; + + while (ip < eip) + { + ep = ip; + while ((ep < eip) && (*ep != '.')) + ep++; + + const char * tagp = DUDETAG; // prefix the segment + while (*tagp) // with the tag (dq--) + { + if (op >= eop) + { + *outstr = '\0'; + return IDN_ERROR; + } + *op++ = *tagp++; + } + + if (idn_isRFC1035(ip, ep - ip)) + { + if ((ep - ip) >= (eop - op)) + { + *outstr = '\0'; + return IDN_ERROR; + } + while (ip < ep) + *op++ = *ip++; + } + else + { + if (!idn_dudeseg(ip, ep, op, eop)) + { + *outstr = '\0'; + return IDN_ERROR; + } + } + + if (op >= eop) // check for output buffer overflow + { + *outstr = '\0'; + return IDN_ERROR; + } + if (ep < eip) + *op++ = *ep; // copy '.' + + ip = ep + 1; + } + + *op = '\0'; + + return (op - outstr) - 1; +} + +/* + idn_DUDEsegtoUTF32 converts instr, DUDE encoded domain name segment + into UTF32. + eip points at the character after the input segment. + ostr points at an output buffer which ends just before eop. + If there is insufficient buffer space, the function return is false. +*/ +static int idn_DUDEsegtoUTF32(const char * instr, int inlen, + uchar_t * outstr, int maxlen) +{ + const char * ip = instr; + const char * eip = instr + inlen; + uchar_t * op = outstr; + uchar_t * eop = op + maxlen - 1; + + unsigned prev = 0; + + while (ip < eip) + { + if (*ip == '-') + *op++ = '-'; + else + { + char c0 = tolower(*ip); + if ((c0 < 'g') || (c0 > 'v')) + return false; + + ip++; + + unsigned r = c0 - 'g'; + int n = 1; + while (ip < eip) + { + char cl = tolower(*ip); + if ((cl >= '0') && (cl <= '9')) + { + r <<= 4; + r += cl - '0'; + } + else if ((cl >= 'a') && (cl <= 'f')) + { + r <<= 4; + r += (cl - 'a') + 10; + } + else + break; + + ip++; + n++; + } + + if (r >= 0x0fffff) + { + return false; + } + unsigned mask = -1 << (n << 2); + + unsigned cu = (prev & mask) + r; + prev = cu; + + if (op >= eop) + return IDN_ERROR; + *op++ = cu; + } + } + *op = '\0'; + return (op - outstr); +} + +int idn_DUDEtoUTF32(const char * in, int inlen, uchar_t * outstr, int outmax) +{ + const char *ip = in; + const char *eip = in + inlen; + const char *ep = ip; + uchar_t *op = outstr; + uchar_t *eop = outstr + outmax - 1; + + while (ip < eip) + { + ep = ip; + while ((ep < eip) && (*ep != L'.')) + ep++; + + const char * tip = ip; + const char * tagp = DUDETAG; + while (*tagp && (tip < ep) && (tolower(*tagp) == tolower(*tip))) + { + tip++; + tagp++; + } + + if (*tagp) + { // tag doesn't match, copy segment verbatim + while (ip < ep) + { + if (op >= eop) + return IDN_ERROR; + *op++ = *ip++; + } + } + else + { + ip = tip; + int rv = idn_DUDEsegtoUTF32(ip, ep - ip, op, eop - op); + + if (rv < 0) + return IDN_ERROR; + + op += rv; + } + + *op++ = *ep; + + if (!*ep) + break; + + ip = ep + 1; + } + + if (op >= eop) + return IDN_ERROR; + + *op = '\0'; + + return (op - outstr) - 1; +} + +/* + DUDE test driver +*/ + +void printres(char *title, int rv, char *buff); +void printres(char *title, int rv, uchar_t *buff); + +int main(int argc, char *argv[]) +{ + char inbuff[512]; + + while (fgets(inbuff, sizeof(inbuff), stdin)) + { + char cbuff[128]; + uchar_t wbuff[128]; + uchar_t iwbuff[128]; + uchar_t *wsp = wbuff; + uchar_t wc; + int in; + int nr; + + char * inp = inbuff; + wsp = wbuff; + while (sscanf(inp, "%x%n", &in, &nr) > 0) + { + inp += nr; + *wsp++ = in; + } + fprintf(stdout, "\n"); + + int rv; + rv = idn_UTF32toDUDE(wbuff, wsp - wbuff, cbuff, sizeof(cbuff)); + printres("toDUDE", rv, cbuff); + + if (rv >= 0) + { + rv = idn_DUDEtoUTF32(cbuff, rv, iwbuff, sizeof(iwbuff)); + printres("toUTF32", rv, iwbuff); + } + + } + return 0; +} + +void printres(char *title, int rv, char *buff) +{ + fprintf(stdout, "%s (%d) : ", title, rv); + if (rv >= 0) + { + unsigned char *dp = (unsigned char *) buff; + while (*dp) + { + fprintf(stdout, "%c", *dp++); + } + } + fprintf(stdout, "\n"); +} + +void printres(char *title, int rv, uchar_t *buff) +{ + fprintf(stdout, "%s (%d) : ", title, rv); + if (rv >= 0) + { + uchar_t *dp = buff; + while (*dp) + { + fprintf(stdout, " %05x", *dp++); + } + } + fprintf(stdout, "\n"); +} diff --git a/doc/draft/draft-ietf-idn-icu-00.txt b/doc/draft/draft-ietf-idn-icu-00.txt deleted file mode 100644 index 3d85c6a62e..0000000000 --- a/doc/draft/draft-ietf-idn-icu-00.txt +++ /dev/null @@ -1,514 +0,0 @@ -IETF IDN Working Group Seungik Lee, Hyewon Shin, Dongman Lee -Internet Draft ICU -draft-ietf-idn-icu-00.txt Eunyong Park, Sungil Kim -Expires: 14 January 2001 KKU, Netpia.com - 14 July 2000 - - Architecture of 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 - - For restrict use of Domain Name System (DNS) for domain names with - alphanumeric characters only, there needs a way to find an Internet - host using multi-lingual domain names: Internationalized Domain Name - System (IDNS). - - This document describes how multi-lingual domain names are handled in - a new protocol scheme for IDNS servers and resolvers in architectural - view and it updates the [RFC1035] but still preserves the backward - compatibility with the current DNS protocol. - - - -2. 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]. - - "IDNS" (Internationalized Domain Name System) is used here to - indicate a new system designed for a domain name service, which - supports multi-lingual domain names. - - "The current/conventional DNS" or "DNS" (Domain Name System) is used - here to indicate the domain name systems currently in use. It - fulfills the [RFC1034, RFC1035], but implementations and functional - operations may be different from each other. - - The "alphanumeric" character data used here is the character set that - is allowed for a domain name in DNS query format, [a-zA-Z0-9-]. - - - -3. Introduction - - Domain Name System (DNS) has eliminated the difficulty of remembering - the IP addresses. As the Internet becomes spread over all the people, - the likelihood that the people who are not familiar with alphanumeric - characters use the Internet increases. The domain names in - alphanumeric characters are difficult to remember or use for the - people who is not educated English. Therefore, it needs a way to find - an Internet host using multi-lingual domain name: Internationalized - Domain Name System. - - -3.1 The current issues of IDNS - - IDNS maps a name to an IP address as the typical DNS does, but it - allows domain names to contain multi-lingual characters. The multi- - lingual characters need to be encoded/decoded into one standardized - format, and it needs changes in the conventional DNS protocol - described in [RFC1034] and [RFC1035]. But it is required to minimize - the changes in the present DNS protocol so that it guarantees the - backward compatibility. - - The IDNS issues have been discussed in IETF IDN Working Group. These - issues are well described in [IDN-REQ]. The main issues are: - - - Compatibility and interoperability. The DNS protocol is in use - widely in the Internet. Although a new protocol is introduced for DNS, - the current protocol may be used with no changes. Therefore, a new - design for DNS protocol, IDNS must provide backward compatibility and - interoperability with the current DNS. - - - Internationalization. IDNS is on the purpose of using multi-lingual - domain names. The international character data must be represented by - one standardized format in domain names. - - - Canonicalization. DNS indexes and matches domain names to look up a - domain name from zone data. In the conventional DNS, canonicalization - is subjected to US-ASCII only. However, every multi-lingual character - data must be canonicalized in its own rules for a DNS standardized - matching policy, e.g. case-insensitive matching rule. - - - Operational issues. IDNS uses international character data for - domain names. Normalization and canonicalization of domain names are - needed in addition to the current DNS operations. IDNS also needs an - operation for interoperability with the current DNS. Therefore, it is - needed to specify the operational guidelines for IDNS. - - -3.2 Overview of the proposed scheme - - Our proposed scheme for IDNS is also subjected on the issues - described earlier to fulfill the requirements of IDN [IDN-REQ]. - - The proposed scheme can be summarized as following: - - - The IN bit, which is reserved and currently unused in the DNS - query/response format header, is used to distinguish between the - queries generated by IDNS servers or resolvers and those of non-IDNS - ones [Oscarsson]. This mechanism is also needed to indicate whether - the query is generated by the appropriate IDNS operations for - canonicalization and normalization or not. - - - The multi-lingual domain names are encoded into UTF-8 as a wire - format. UTF-8 is recommended as a default character encoding scheme - (CES) in the creation of new protocols which transmit text in - [RFC2130]. This scheme allows the IDNS server to handle the DNS query - from non-IDNS servers or resolvers because the ASCII code has no - changes in UTF-8. - - - The UTF-8 domain names must be case-folded before transmission. It - minimizes the overhead on server's operations of matching names in - case-insensitive. It also guarantees that the result of caching - queries can be used without any further normalization and - canonicalization. If IDNS server gets non-IDNS query that is not - case-folded, it case-folds the query before transmitting to another - servers. - - - -4. Design considerations - - Our proposed scheme is designed to fulfill the requirements of IETF - IDN WG [IDN-REQ]. All the methods for IDNS schemes must be approved - by the requirements documents. The design described in this document - is based on these requirements. - - -4.1 Protocol Extensions - - To indicate an IDNS query format, we use an unallocated bit in the - current DNS query format header, named 'IN' bit [Oscarsson]. All IDNS - queries are set IN bit to 1. Without this bit set to 1, we cannot - guarantee that the query is in the appropriate format for IDNS. - - 'IN' bit is to indicate whether the query is from IDNS - resolvers/servers or not. It also reduces overhead on canonicalizing - operation at IDNS server. It will be described further in <4.4. - Canonicalization>. - - We devise new operations and new structures of resolvers and name - servers to add the multi-lingual domain name handling features into - the DNS. This causes changes of all DNS servers and resolvers to use - multi-lingual domain names. The new architectures for resolvers and - servers will be described in <5. Architectures> - - -4.2 Compatibility and interoperability - - The 'IN' bit is valid bit location of query for the conventional DNS - protocol to be set to zero [RFC1035]. And operations and structures - of IDNS preserve the conventional rules of DNS to guarantee the - interoperability with the conventional DNS servers or resolvers so - that the changes are optional. These make this scheme for IDNS - compatible with the current protocol. - - Although the current DNS protocol uses 7-bit ASCII characters only, - the query format of the current DNS protocol set is 8 bit-clean. - Therefore, we can guarantee the backward compatibility and - interoperability with the current DNS using UTF-8 code because the - ASCII code is preserved with no changes in UTF-8. - - Note: There are also in use implementations that are compatible with - the current DNS but extend their operations to use UTF-8 domain names. - The IDNS described here interoperates well with these implementations. - The interoperability with these implementations will be described in - <5.4 Interoperability with the current DNS>. - - -4.3 Internationalization - - All international character data must be represented in one - standardized format and the standardized format must be compatible - with the current ASCII-based protocols. Therefore, the coded - character set (CCS) for IDNS protocol must be Unicode [Unicode], and - be encoded using the UTF-8 [RFC2279] character encoding scheme (CES). - - The client-side interface may allow the domain names encoded in any - local character sets, Unicode, ASCII and so on. But they must be - encoded into Unicode before being used in IDNS resolver. The IDNS - resolver accepts Unicode character data only, and converts it to UTF- - 8 finally for transmission. - - -4.4 Canonicalization - - In the current DNS protocol, the domain names are matched in case- - insensitive. Therefore, the domain names in a query and zone file - must be case-folded before equivalence test. - - The case-folding issue has been discussed for a long time in IETF IDN - WG. The main problem is for case folding in locale-dependent. Some - different local characters are overlapped within case-folded format. - 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) - - Therefore, we case-fold the domain names in locale-independent in our - new IDNS design with a method defined in [UTR21]. - - Multi-lingual domain names should be case-folded in IDNS resolvers or - IDNS servers before transmitting to other IDNS/DNS servers. That is, - IDNS resolver should case-fold the domain name and converts it to - UTF-8 before transmission. In case of IDNS server, if it gets a query - with IN bit set to 1, then it needs not to make the multi-lingual - domain name canonicalized anymore. If the IDNS server gets a query - with IN bit set to 0, then it cannot determine the query is - appropriate canonicalized format for IDNS server, so that it case- - folds that multi-lingual domain name in the query, and set 'IN' bit - to 1. - - The current DNS queries contain the original case of domain names to - preserve the original cases. To be consistent with this rule, all - case-folded multi-lingual domain names should be stored by IDNS - resolvers or servers before case-folding, and should be restored - before sending response. - - In the case of case-folding UTF-8 code, using the case-folding method - in [UTR21], the UTF-8 should be converted to Unicode and it must be - mapped to the mapping table finally. Of course that if we could make - a case-folding mapping table of UTF-8 character data, this overhead - could be reduced. - - However it cannot avoid an overhead in IDNS servers for - canonicalization, because the canonicalization of international - character data is complicated. - - To minimize this overhead, we use 'IN' bit to indicate that the - canonicalization for the query has been already handled. That means - it needs not canonicalization operation anymore. The detailed - operations according to the 'IN' bit are described later in <5. - Architectures>. - - With international character data, the canonicalization (e.g. case- - folding) is much more complicated than the one with US-ASCII, and is - different from each other's by their locale contexts. - - But this document doesn't specify any method or recommendation more - than case-folding. For canonicalization of international character - data, [UTR15] is a good start. It must be discussed further and - specified in the IDNS protocol specification. - - -4.5 Operational issues - - In the current DNS scheme, it uses only ASCII code for a wire format. - But our new IDNS scheme uses UTF-8 code for a wire format. All the - IDNS resolvers must transmit queries encoded in UTF-8 and case-folded. - This format can be guaranteed by checking the IN bit: if IN bit is - set to 1, the query is encoded in UTF-8 and case-folded. Otherwise - the IDNS server cannot assure that the query is encoded in UTF-8 and - case-folded. Therefore it needs additional operations for encoding to - UTF-8 and case-folding, etc in this case. - - The current DNS resolvers transmit the queries in ASCII code. But - it's not considerable in IDNS servers because the ASCII code is - preserved with no changes in UTF-8. - - Some applications and resolvers transmit the queries in UTF-8 - although they don't fit on the new IDNS resolvers' structures, e.g. - Microsoft's DNS servers. We cannot guarantee that those queries are - case-folded correctly. Therefore, the IDNS servers should convert - them to appropriate IDNS queries instead of the IDNS resolver in that - case. - - All detailed operations of IDNS servers and resolvers are described - in <5. Architectures>. - - - -5. Architectures - - -5.1 New header format - - A new IDNS servers and resolvers must interoperate with the ones of - current DNS. Therefore, we need a way to determine whether the query - is for IDN or not. For this reason, we use a new header format as - proposed in [Oscarsson]. - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode |AA|TC|RD|RA|IN|AD|CD| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - - The IDNS resolvers and servers identify themselves in a query or a - response by setting the 'IN' bit to 1 in the DNS query/response - format header. This bit is defined to be zero by default in the - current DNS servers and resolvers. - - -5.2 Structures of IDNS resolvers - - To use multi-lingual domain names with IDNS servers, all the IDNS/DNS - resolvers must generate the query in a format of UTF-8 or ASCII. The - design of a resolver could be different with each other according to - the local operating systems or applications. We propose new design - guidelines of a resolver for a new standardization. - - The IDNS resolver accepts Unicode from user interface for domain - names. The other character sets should be rejected. It encodes all - such character data into UTF-8 for transmission to name servers. - - The procedures of the operation of an IDNS resolver are below: - - <1>. If the resolver gets a domain name in Unicode or ASCII then it - stores the original domain name query. Otherwise the request for - lookup is rejected. In the current DNS protocol, the original case of - the domain name should be preserved. Therefore, the resolver must - store the original cases of the domain names before canonicalization - (e.g. case-folding). - - <2>. Make the domain name case-folded with locale-independent case- - mapping table defined in [UTR21]. - - <3>. Convert it to UTF-8. - - <4>. Set IN bit to 1. It indicates the query is from IDNS resolver - and the format is UTF-8, case-folded. - - <5>. Send request query to name servers. - - <6>. Restore the original domain name query into the response query - format. - - <7>. Send response to the application. - - -5.3 Structures of IDNS servers - - The operation of IDNS server is similar to the current one of DNS - server, but the IDNS server accepts UTF-8 queries and converts them - to the appropriate formats additionally. - - The IDNS server distinguishes between the IDNS queries and DNS - queries by checking IN bit in the query/response format header. - According to the 'IN' bit, it operates differently. - - The procedures of the operation of an IDNS server are below: - - <1>. If the IN bit in the query/response format header is set to 1 - then it matches the domain name within zone file data or forwards - request query to resolve. It operates as same as the operations of - the current DNS servers but retrieves UTF-8 code. In this case, it - needs not to make domain name canonicalized because the domain name - is already canonicalized in the previous procedures of IDNS resolvers - or IDNS servers. Go to step <7>. - - <2>. Set IN bit to 1. - - <3>. Store the original domain name query. - - <4>. Make the domain name case-folded with locale-independent case- - mapping table defined in [UTR21]. - - <5>. Match the domain name within zone file data or send request - query to lookup. - - <6>. Restore the original domain name query into the response query - format. - - <7>. Send response for the query to the resolver or the other server - requested. - - -5.4 Interoperability with the current DNS - - The DNS servers and resolvers accept domain names in ASCII only. But - IDNS servers and resolvers accept domain names in UTF-8. Therefore, - the queries from DNS ones to IDNS ones can be well handled because - the UTF-8 is a superset of ASCII code. But the queries from IDNS ones - to DNS ones will be rejected because the UTF-8 code is beyond the - range of ASCII code. - - Note: There are some implementations which can handle UTF-8 domain - names although they don't fit on this specification of IDNS and fully - implemented with DNS protocol specification, e.g. Microsoft's DNS - server and resolvers. In this case, we cannot guarantee that the - queries from these 3rd-party implementations are encoded into UTF-8 - and well canonicalized. But this queries are set 'IN' bit to 0, so - that the IDNS evaluates whether the domain name is the range of UTF-8 - or not, and converts it into UTF-8 and makes it canonicalized finally. - - - -6. Security Considerations - - This architecture of IDNS uses 8bit-clean queries for transmission - and the UTF-8 code is handled instead of ASCII. The DNS protocol has - already allocated 8bit query format for domain names Therefore, the - IDNS protocol inherits the security issues for the current DNS. - - Canonicalization of IDNS is defined in [UTR15] and case folding in - [UTR21]. All security issues related with canonicalization or - normalization inherits ones described in [UTR15, UTR21]. - - 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. - - - -7. References - - [IDN-REQ] James Seng, "Requirements of Internationalized Domain - Names," Internet Draft, June 2000 - - [KWAN] Stuart Kwan, "Using the UTF-8 Character Set in the - Domain Name System," Internet Draft, February 2000 - - [Oscarsson] Dan Oscarsson, "Internationalisation of the Domain Name - Service," Internet Draft, February 2000 - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities," STD 13, RFC 1034, USC/ISI, November 1987 - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification," STD 13, RFC 1035, USC/ISI, November - 1987 - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119, March 1997 - - [RFC2130] C. Weider et. Al., "The Report of the IAB Character Set - Workshop held 29 February - 1 March 1996," RFC 2130, - Apr 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 - - [UNICODE] The Unicode Consortium, "The Unicode Standard - Version - 3.0," http://www.unicode.org/unicode/ - - [UTR15] M. Davis and M. Duerst, "Unicode Normalization Forms", - Unicode Technical Report #15, Nov 1999, - http://www.unicode.org/unicode/reports/tr15/ - - [UTR21] Mark Davis, "Case Mappings," Unicode Technical Report - #21, May 2000, - http://www.unicode.org/unicode/reports/tr21 - - -8. Acknowledgments - - Kyoungseok Kim - Chinhyun Bae - - - -9. Author's Addresses - - Seungik Lee - Email: silee@icu.ac.kr - - Hyewon Shin - Email: hwshin@icu.ac.kr - - Dongman Lee - Email: dlee@icu.ac.kr - - Information & Communications University - 58-4 Whaam-dong Yuseong-gu Taejon, 305-348 Korea - - - Eunyong Park - Email: eunyong@eunyong.pe.kr - Konkuk University - 93-1 Mojindong, Kwangjin-ku Seoul, 143-701 Korea - - - Sungil Kim - Email: clicky@netpia.com - Netpia.com - 35-1 8-ga Youngdeungpo-dong Youngdeungpo-gu Seoul, 150-038 Korea diff --git a/doc/draft/draft-ietf-idn-icu-01.txt b/doc/draft/draft-ietf-idn-icu-01.txt new file mode 100644 index 0000000000..6aec635ca0 --- /dev/null +++ b/doc/draft/draft-ietf-idn-icu-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +E. Park: eunyong@eunyong.pe.kr + + diff --git a/doc/draft/draft-ietf-idn-idne-01.txt b/doc/draft/draft-ietf-idn-idne-02.txt similarity index 84% rename from doc/draft/draft-ietf-idn-idne-01.txt rename to doc/draft/draft-ietf-idn-idne-02.txt index 8abd90dc78..c645528cd2 100644 --- a/doc/draft/draft-ietf-idn-idne-01.txt +++ b/doc/draft/draft-ietf-idn-idne-02.txt @@ -1,9 +1,9 @@ Internet Draft Marc Blanchet -draft-ietf-idn-idne-01.txt Viagenie -July 8, 2000 Paul Hoffman +draft-ietf-idn-idne-02.txt Viagenie +March 19, 2001 Paul Hoffman Expires in six months IMC & VPNC - Internationalized domain names using EDNS (IDNE) + Internationalized domain names using EDNS (IDNE) Status of this Memo @@ -19,11 +19,11 @@ 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 current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. Abstract @@ -98,11 +98,11 @@ 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 + 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 ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ + |0 1| ELT | Size | IDN label ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ ELT: The six-bit extended label type to be assigned by the IANA for an @@ -134,20 +134,20 @@ 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 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 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) + 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 @@ -161,25 +161,25 @@ Using the previous labels, one datagram might contain "www.m*.com" and 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 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 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 @@ -405,23 +405,9 @@ Bill Sommerfeld Francois Yergeau -B. Changes from -00 to -01 +B. Changes from -01 to -02 -1.1: Added reference to Unicode names. - -3: Clarified that a size of zero is not allowed. - -3.1.1 and 3.1.2: Fixed two very serious errors in the examples. - -6: Removed second paragraph, which was redundant with 7.3. - -12: Beefed up the security considerations. - -13: Added [ISO10646] and [UNICODE3]. - -Added Appendix A. - -Added Appendex B. +None. C. Authors' Addresses @@ -438,4 +424,3 @@ Internet Mail Consortium and VPN Consortium Santa Cruz, CA 95060 USA phoffman@imc.org - diff --git a/doc/draft/draft-ietf-idn-idnra-00.txt b/doc/draft/draft-ietf-idn-idnra-00.txt deleted file mode 100644 index d13e858d97..0000000000 --- a/doc/draft/draft-ietf-idn-idnra-00.txt +++ /dev/null @@ -1,334 +0,0 @@ -Internet Draft Paul Hoffman -draft-ietf-idn-idnra-00.txt IMC & VPNC -August 17, 2000 Patrik Faltstrom -Expires in six months Cisco - - Internationalized Host Names - Using Resolvers and Applications (IDNRA) - - -Status of this Memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material -or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Abstract - -The current DNS infrastructure does not provide a way to use -internationalized host names (IDN). This document describes a mechanism -that requires no changes to any DNS server that will allow -internationalized host names to be used by end users with changes only -to resolvers and applications. It allows flexibility for user input and -display, and assures that host names that have non-ASCII characters are -not sent to servers. - - -1. Introduction - -In the discussion of IDN solutions, a great deal of discussion has -focused on transition issues and how IDN will work in a world where not -all of the components have been updated. Earlier proposed solutions -require that user applications, resolvers, and DNS servers to be updated -in order for a user to use an internationalized host name. Instead of -this requirement for widespread updating of all components, the current -proposal is that only user applications and the resolvers on user's -systems be updated; no changes are needed to the DNS protocol or any DNS -servers. We also show that it is enough to update only the application, -and at the same time an encoded version of the host name can be used -even in current existing applications. - -The proposal is called IDNRA because it only requires changes to -resolvers and applications (the "R" and "A" in the name). - -1.1 Design philosophy - -To date, the proposals for IDN protocols have required that DNS servers -be updated to handle internationalized host names. Because of this, the -person who wanted to use an internationalized host name had to be sure -that their request went to a DNS server that was updated for IDN. -Further, that server could only send queries to other servers that had -been updated for IDN because the queries contain new protocol elements -to differentiate IDN name parts from current host parts. In addition, -these proposals require that resolvers must be updated to use the new -protocols, and in most cases the applications would need to be updated -as well. - -Updating all (or even a significant percentage) of the DNS servers in -the world will be difficult, to say the least. Because of this, we have -designed a protocol that requires no updating of any name servers. IDNRA -still requires the updating of applications and resolvers, but once a -user has updated these, she or he could immediately start using -internationalized host names. The cost of implementing IDN would thus be -much lower, and the speed of implementation will be much higher. - -IDNRA also specifies how to use old applications and/or old resolvers in -parallel with updated ones. - -1.2 Terminology - -The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and -"MAY" in this document are to be interpreted as described in RFC 2119 -[RFC2119]. - -1.3 IDN summary - -Using the terminology in [IDNCOMP], this protocol specifies an IDN -architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE), -and the method for distinguishing ACE name parts from current name parts -is ace-2.1.1 (add hopefully-unique legal tag). Because there is no -changes needed to the DNS, the transition strategy is trans-1 (always do -current plus new architecture). - - -2. Structural Overview - -In IDNRA, users' applications and resolvers are updated to perform the -processing needed to input internationalized host names from users, -display internationalized host names that are returned from the DNS to -users, and process the inputs and outputs from the DNS. - -2.1 Interfaces between DNS components in IDNRA - -The interfaces in IDNRA can be represented pictorially as: - - +------+ - | User | - +------+ - ^ - | Input and display: any charset - v - +-------------+ - | Application | - +-------------+ - ^ - | API call and return: UTF-8 - v - +----------+ - | Resolver | - +----------+ - ^ - | DNS query and response: RACE - v - +-------------+ - | DNS servers | - +-------------+ - -2.1.1 Users and applications - -Applications can accept host names using any character set or sets -desired by the application developer, and can display host names in any -charset. That is, this protocol does not affect the interface between -users and applications. - -An IDNRA-aware application can accept and display internationalized host -names in two formats: the internationalized character set(s) supported -by the application, and in RACE [RACE] ASCII-compatible encoding. -Applications MAY allow RACE input and output, but are not encouraged to -do so except as an interface for advanced users, possibly for debugging. -RACE encoding is opaque and ugly, and should thus only be exposed to -users who absolutely need it. The optional use, especially during a -transition period, of RACE encodings in the user interface is described -in section 3. - -2.1.2 Applications and resolvers - -Applications communicate with resolver libraries through a programming -interface (API). Typically, the IETF does not standardize APIs, although -it has for IPv6. This protocol does not specify a specific API, but -instead specifies only the input and output formats of the host names to -the resolver library. - -This protocol specifies that host names SHOULD be passed to resolvers -using UTF-8 [RFC2279] because there are many libraries for converting -between arbitrary charsets and UTF-8. However, because the API is not -specified in this document, some resolvers may use different charsets -for input and output, and applications must, of course, use the same -charset as the resolver library they call. - -IDNRA-aware applications MUST be able to work with both IDNRA-aware and -non-aware resolvers. An IDNRA-aware application that is resolving a -non-internationalized host name (one that conforms to RFC 1035[STD13]) -MUST use non-aware APIs such as "gethostbyname" and "gethostbyaddr". An -IDNRA-aware application that is resolving a internationalized host name -(one that does not conform to RFC 1035) MUST use an API that is specific -to IDNRA. - -2.1.3 Resolvers and DNS servers - -Before converting the name parts into RACE, the resolver MUST prepare -each name part as specified in [NAMEPREP]. The resolver MUST use RACE -ASCII-compatible encoding for the name parts that are sent in the DNS -query, and will always get name parts encoded in RACE from the DNS -service. DNS servers MUST use the RACE format for internationalized host -name parts. - -If a signalling system which makes negotiation possible between old and -new DNS clients and servers is standardized in the future, the encoding -of the query in the DNS protocol itself can be changed from RACE to -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. - - -3. Combinations of Resolvers and Applications - -IDNRA allows non-IDNRA applications to coexist with IDNRA-aware -resolvers, and non-IDNRA resolvers to coexist with IDNRA-aware -applications. This section describes the interactions between -applications and resolvers as users update each separately. - -In this section, "old" means an application or resolver that has not bee -upgraded to be IDNRA-aware, and "new" means an IDNRA-aware application -or resolver. The two APIs are also called "old" and "new". "Binary" -means any host name that is not compatible with current DNS character -restrictions. - -3.1 Old application, old resolver - -Because it is an old resolver (and an old application), all host names -MUST (and will) be resolved using the old API. A user cannot enter -binary names in the application. A user MAY enter a name that uses RACE -encoding. Each RACE-encoded name part in such a name MUST already have -had all name preparation done on it and be correctly converted to RACE -encoding; otherwise, it will not be matched in the DNS. - -When the resolver receives a RACE name in a response to a old API -gethostbyaddr-type query, the resolver will not convert the host name to -a binary form, and the application will thus display the name in RACE -format. Showing the results of a gethostbyaddr-type queries is rare in -typical Internet applications, so the display of RACE names is not -likely in typical environments. - -3.2 Old application, new resolver - -Because it is an old application, all host names MUST (and will) be -resolved using the old API. A user cannot enter binary names in the -application. A user MAY enter a name that uses RACE encoding. Each -RACE-encoded name part in such a name MUST already have had all name -preparation done on it and be correctly converted to RACE encoding; -otherwise, it will not be matched in the DNS. Note that, even though the -resolver is new, the resolver MUST NOT do further name preparation on -RACE-encoded name parts because the call was using the old API, which -tells the resolver that the resolver is dealing with an old application. - -If the resolver receives a RACE name in a response to a old API -gethostbyaddr-type query, the resolver MUST NOT convert the host name to -a binary form, and the application will thus display the name in RACE -format. Showing the results of a gethostbyaddr-type queries is rare in -typical Internet applications, so the display of RACE names is not -likely in typical environments. - -3.3 New application, old resolver - -Because it is an old resolver, all host names MUST (and will) be -resolved using the old API. If the user enters a binary host name, the -application SHOULD reject the name as illegal. This is due to the fact -that, if the application did not reject the name as illegal, the -application would have to contain all of the name preparation logic and -RACE-encoding logic, but that logic would only be used in the rare case -where a user had updated applications but not the resolver. It is likely -that applications would not fully implement and rigorously test the name -preparation logic, and it is therefore likely that some applications in -this scenario would give incorrect information to the user, and would -possibly be susceptible to spoofing attacks. If an application is going -allow the input of binary names and convert them to their RACE-encoded -form for use on the old API, the application MUST do full name -preparation exactly as it would have been done in a new resolver. - -If the application receives a RACE-encoded name part in a response to a -old API gethostbyaddr-type query, the application SHOULD convert the -host name to a binary form for display. However, the application MAY -have an interface that allows the display of RACE names that are -returned by gethostbyaddr-type queries, but the default setting of such -an interface SHOULD be to show the binary form, not the RACE form. - -3.4 New application, new resolver - -All host names MUST be resolved using the new API. A user MAY enter a -name that uses RACE encoding. Each RACE-encoded name part in such a name -MUST already have had all name preparation done on it and be correctly -converted to RACE encoding; otherwise, it will not be matched in the -DNS. - -When the resolver receives a RACE name in a response to a -gethostbyaddr-type query, if the query was to the old API, the resolver -MUST NOT convert the host name and MUST pass the RACE-formatted name to -the application. If the query was to the new API, the resolver MUST -convert the host name part to the binary form. The application MAY have -an interface that allows the user to decide whether to use the old or -new API, and therefore to show the results in RACE or binary format, but -the default setting of such an interface SHOULD be to use the new API. - - -4. Root Server Considerations - -Because there are no changes to the DNS protocols, adopting this -protocol has no effect on the root servers. - - -5. Security Considerations - -Much of the security of the Internet relies on the DNS. Thus, any change -to the characteristics of the DNS can change the security of much of the -Internet. - -Host names are used by users to connect to Internet servers. The -security of the Internet would be compromised if a user entering a -single internationalized name could be connected to different servers -based on different interpretations of the internationalized host name. - -Because this document normatively refers to [NAMEPREP], it includes the -security considerations from that document as well. - - -6. References - -[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name -Proposals", draft-ietf-idn-compare. - -[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of -Internationalized Host Names", draft-ietf-idn-nameprep. - -[RACE] RACE: Row-based ASCII Compatible Encoding for IDN, -draft-ietf-idn-race. - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", March 1997, RFC 2119. - -[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO -10646", January 1998, RFC 2279. - -[STD13] Paul Mockapetris, "Domain names - implementation and -specification", November 1987, STD 13 (RFC 1035). - - -A. Authors' Addresses - -Paul Hoffman -Internet Mail Consortium and VPN Consortium -127 Segre Place -Santa Cruz, CA 95060 USA -phoffman@imc.org - -Patrik Faltstrom -Cisco Systems -170 W Tasman Drive SJ-13/2 -San Jose, CA 9 5134 USA -paf@cisco.com diff --git a/doc/draft/draft-ietf-idn-idnra-01.txt b/doc/draft/draft-ietf-idn-idnra-01.txt new file mode 100644 index 0000000000..61bbd98b6e --- /dev/null +++ b/doc/draft/draft-ietf-idn-idnra-01.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +P. Hoffman: phoffman@imc.org +P. Faltstrom: paf@cisco.com + + diff --git a/doc/draft/draft-ietf-idn-sace-00.txt b/doc/draft/draft-ietf-idn-sace-00.txt deleted file mode 100644 index 59a7647769..0000000000 --- a/doc/draft/draft-ietf-idn-sace-00.txt +++ /dev/null @@ -1,276 +0,0 @@ -Internet Draft Dan Oscarsson -draft-ietf-idn-sace-00.txt Telia ProSoft -Expires: 27 February 2001 27 August 2000 - - Simple ASCII Compatible Encoding (SACE) - -Status of this memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - -Abstract - - This document describes a way to encode non-ASCII characters in host - names in a way that is completely compatible with the current ASCII - only host names that are used in DNS. It can be used both with DNS to - support software only handling ASCII host names and as a way to - downgrade from 8-bit text to ASCII in protocols. - - -1. Introduction - - This document defines an ASCII Compatible Encoding (ACE) of names - that can be used when communicating with DNS. It is needed during a - transition period when non-ASCII names are introduced in DNS to avoid - breaking programs expecting ASCII only. - - The Simple ASCII Compatible Encoding (SACE) defined here can be - compared to [RACE]. The main differences are: - - RACE encodes by first compressing and the encoding the resulting - bit stream into ASCII. SACE encodes each character directly in one - - - -Dan Oscarsson Expires: 27 Februray 2001 [Page 1] - -Internet Draft SACE 27 August 2000 - - - pass. - - SACE recognises that at lot of latin based names are mostly - composed of ASCII characters and gives a higher compression for - those. In the 63 byte limit of DNS RACE will allow 36 characters - for ISO 8859-1 and less if characters from the additional Latin - characters are needed. SACE will allow around 40 characters if - about 10 % of a Latin name is non-ASCII (in the UCS [ISO10646] - range 0-0x217). SACE is closer to the compression that UTF-8 have - than RACE. - - Most ASCII characters will not be encoded so Latin based names - composed of mostly ASCII characters will be somewhat readable. - - -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]. - -2. Simple ASCII Compatible Encoding - - The encoding encodes values using the available characters allowed in - a ASCII host name (a-z0-9 and hyphen). - - Values are encoded as follows: - - Character - value mapping - - value character value character - 0 a 18 s - 1 b 19 t - 2 c 20 u - 3 d 21 v - 4 e 22 w - 5 f 23 x - 6 g 24 y - 7 h 25 z - 8 i 26 1 - 9 j 27 2 - 10 k 28 3 - 11 l 29 4 - 12 m 30 7 - 13 n 31 9 - 14 o 32 0 - 15 p 33 8 - 16 q 34 5 - 17 r 35 6 - - - - -Dan Oscarsson Expires: 27 Februray 2001 [Page 2] - -Internet Draft SACE 27 August 2000 - - - In the following description the following syntax will be used: - B => one value in the range 0-35 mapped to a character as above - X => one value in the range 0-31 mapped to a character as above - - Each UCS character is identified as follows: - latin => a character in the range 0-0x217 - 10bit => a character in the range 0x218-0x2FFF - base36 => all other characters - - During encoding/decoding a string a current mode is used. In each - mode characters are encoded like this: - latin => as themselves, 00 for 0, 88 for 8 or as 10 bit value - encoded as 0XX (two 5 bit values) - 10bit => as 15 bits represented by its current prefix of 5 bits - followed by 10 bits encoded as XX - (the value is the 15 bits of prefix and - 10 bits concatenated) - base36 => as a base 36 value represented by its current base 36 - prefix followed by three base 36 digits encoded as BBB - (the value is prefix*36*36*36*36+B*36*36+B*36+B) - Before encoding the character value must first be - reduced: - if >= 0xd800 reduce by 8192 (private/surrogate start) - then reduce by 0x2FFF. - After decoding the character value need to be restored - as - add 0x2FFF - followed by adding 8192 if >= 0xd800 - - -2.1 Decoding a string - - During decode you start with: - Mode: latin - 10bit prefix: 0 - base36 prefix: 0 - - Then the characters in an encoded string are interpreted as follows - depending on current mode: - - When in latin mode: - 00 => the character 0 - 0XX => XX represents 10 bits which decodes to one character - 88 => the character 8 - 85 => switch to 10bit mode with same prefix as last time - 8X5 => switch 10 10bit mode setting X as current 10bit prefix - 87 => switch to base36 mode with same prefix as last time - 8X7 => switch to base36 mode setting X as current base36 prefix - - - -Dan Oscarsson Expires: 27 Februray 2001 [Page 3] - -Internet Draft SACE 27 August 2000 - - - other => the characters represent itself - - When in 10bit mode - - => the character - - 0 => switch to latin mode - X5 => switch 10 10bit mode using X as current prefix - 7 => switch to base36 mode with same prefix as last time - X7 => switch to base36 mode using X as current prefix - XX => current 10bit prefix plus XX gives the character - - When in base36 mode - -- => the character - - -0 => switch to latin mode - -5 => switch to 10bit mode with same prefix as last time - -X5 => switch 10 10bit mode setting X as current prefix - -X7 => switch to base36 mode setting X as current prefix - XXX => current base36 prefix plus XXX as base 36 values gives - character - - - 2.2 Encoding a string - - To encode a string you start with the data as UCS characters and: - Mode: latin - 10bit prefix: 0 - base36 prefix: 0 - - Then for each UCS character, the mode and/or prefix is switched if - needed and then the character is encoded as defined above. - - -3. References - - [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997, RFC 2119. - - [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", - RFC 2279, January 1998. - - [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 - - - - -Dan Oscarsson Expires: 27 Februray 2001 [Page 4] - -Internet Draft SACE 27 August 2000 - - - [IDNREQ] James Seng, "Requirements of Internationalized Domain - Names", draft-ietf-idn-requirement. - - [RACE] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding - for IDN", draft-ietf-idn-race. - -4. Acknowledgements - - Paul Hoffman for many good ideas. - - - -Author's Address - - Dan Oscarsson - Telia ProSoft AB - Box 85 - 201 20 Malmo - Sweden - - E-mail: Dan.Oscarsson@trab.se - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dan Oscarsson Expires: 27 Februray 2001 [Page 5] - diff --git a/doc/draft/draft-ietf-idn-sace-01.txt b/doc/draft/draft-ietf-idn-sace-01.txt new file mode 100644 index 0000000000..6594c15e68 --- /dev/null +++ b/doc/draft/draft-ietf-idn-sace-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +D. Oscarsson: dan.oscarsson@trab.se + + diff --git a/doc/draft/draft-ietf-idn-vidn-00.txt b/doc/draft/draft-ietf-idn-vidn-00.txt deleted file mode 100644 index fbf3150240..0000000000 --- a/doc/draft/draft-ietf-idn-vidn-00.txt +++ /dev/null @@ -1,537 +0,0 @@ - -IETF IDN Working Group Sung Jae Shim -Internet Draft DualName, Inc. -Document: draft-ietf-idn-vidn-00.txt 14 November 2000 -Expires: 14 May 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 describes a method that internationalizes existing as - well as future domain names in English, not making any change to the - current DNS, not requiring separate name server or resolver, and not - creating domain names in non-English languages. Based upon the - knowledge of transliteration between a local language and English, - the method allows a user to use virtual domain names in the user's - preferred local language by converting them into the corresponding - actual domain names in English that comply with the current DNS. The - conversion takes place automatically and transparently in the user's - applications before DNS queries are sent. The method uses the current - DNS as it is and meets all the requirements of internationalized - domain names as described in Wenzel and Seng [2]. - - - 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 - - - - Virtually Internationalized Domain Names November 2000 - - 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 that a user - prefers to use in a local context. - - A "virtual domain name" is a domain name in a local language, and it - is not registered with the DNS but used for the convenience of a - user. An "actual domain name" is a domain name in English, and it is - actually used in the DNS. A "domain name" refers to an actual domain - name in English that complies with the DNS, unless specified - otherwise. - - A "coded portion" is a pre-coded portion of a domain name (e.g., - generic organization codes including `com', `edu', `gov', `int', - `mil', `net', `org', and country codes such as `kr', `jp', 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., - organization name, server name, and so on). - - The method proposed in this document is called "virtually - internationalized domain names (VIDN)" because it uses virtual domain - names in local languages to internationalize actual domain names in - English that comply with the DNS. - - 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 - hosts on the Internet. The current DNS allows using only English - characters 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 or non- - English domain names. Recognizing this need, various methods have - been proposed to use non-English characters in domain names. But to - date, it seems that no method has met all the requirements of - internationalized domain names as described in Wenzel and Seng [2]. - - A group of earlier methods has tried to put internationalized domain - names inside some parts of the overall DNS system, using UCS encoding - - - Virtually Internationalized Domain Names November 2000 - - schemes. 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. Another group of earlier methods has tried to build - separate directory services for internationalized domain names or - internationalized keywords. But these methods also require complex - implementation efforts, duplicating much of the work already done for - the DNS. Both the groups of earlier methods have tried to build some - mechanisms inside or outside the DNS and put internationalized domain - names or internationalized keywords there in addition to existing - domain names in English. - - Unlike earlier methods that involve a lengthy and costly process of - implementation, VIDN provides a more immediate and less costly - solution to internationalized domain names by focusing on - internationalizing existing as well as future domain names in English - that comply with the current DNS, without actually creating domain - names in local languages. VIDN takes notice of the fact that most - domain names used in regions where English is not widely spoken, have - their entity-defined portions consisting of characters or words in - English as transliterated from characters and words in the respective - local languages. Based upon the knowledge of transliteration between - a local language and English, VIDN allows using virtual domain names - in a local language by converting them into the corresponding actual - domain names in English that comply with the current DNS. VIDN allows - the same domain names to be used not only in English as usual but - also in local languages, without creating additional domain names in - local languages. - - - 4. VIDN method - - 4.1. Objectives - - To date, the methods for internationalized domain names have tried to - create domain names or keywords in local languages one way or another - in addition to existing domain names in English, and put them inside - or outside the DNS, using special encoding schemes or lookup - services. These methods require a lengthy and costly process of - implementation. Even when they are successfully implemented, these - methods may localize the Internet by separating it into groups of - local languages that are less universal than English. Further, these - methods may cause disputes on copyrights, trademarks, and so on in - local contexts, in addition to all those disputes we observe with - current domain names in English. VIDN intends to provide a solution - to the problems of earlier methods, by (1) allowing the same domain - names to be used both in English and local languages, without - creating domain names in local languages, (2) working in applications - at user hosts automatically and transparently before DNS requests are - sent, (3) using the current DNS as it is, without requiring any - additional name server or resolver, and (4) being implemented - immediately with little cost. - - - 4.2. Description - - - Virtually Internationalized Domain Names November 2000 - - - It is important to note that most domain names used in regions where - English is not widely spoken have their entity-defined portions - consisting of characters or words in English as transliterated from - characters or words in local languages. These transliterated - characters or words in English do not have any meanings in English, - but their originals in local languages before the transliteration - into English have some meanings in local contexts, usually indicating - organization names, brand names, trademarks, and so on. VIDN allows - using these original characters or words in local languages as the - entity-defined portions of virtual domain names in local languages, - by transliterating them into the corresponding entity-defined - portions of actual domain names in English. In this way, VIDN allows - the same domain names in English to be also used virtually in local - languages without actually creating domain names in local languages. - - As domain names overlay IP addresses, so virtual domain names in - local languages do actual domain names in English. The relationship - between virtual domain names in a local language and actual domain - names in English can be depicted as: - - +---------------------------------+ - | User | - +---------------------------------+ - | | - +----------------|-----------------------|------------------+ - | v (Transliteration) v | - | +---------------------+ | +-----------------------+ | - | | Virtual domain name | | | Actual domain name | | - | | in a local language |--+->| in English | | - | +---------------------+ +-----------------------+ | - | User application | | - +----------------------------------------|------------------+ - v - DNS request - - VIDN uses the phonemes of a local language and English as a medium in - transliterating the entity-defined portions of virtual domain names - in the local language into those of actual domain names in English. - This process of transliteration can be depicted as: - - Local language English - +----------------------------+ +-----------------------------+ - | Characters ----> Phonemes -----------> Phonemes ----> Characters | - | | | | | | | - | | | | | | | - | (Inverse of transcription) | Match | (Transcription) | - +----------------------------+ +-----------------------------+ - | ^ - | (Transliteration) | - +------------------------------------+ - - First, each entity-defined portion of a virtual domain name in the - local language is decomposed into individual characters or sets of - - - Virtually Internationalized Domain Names November 2000 - - characters so that each individual character or set of characters can - represent an individual phoneme of the local language, which 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 that has the same or most proximate - sound. Third, each phoneme of English is transcribed into the - corresponding character or set of characters in English. Finally, all - the characters or sets of characters converted into English are - united to compose the corresponding entity-defined portion of an - actual domain name in English. - - For example, a word in Korean, `??' that means `century' in English, - is transliterated into `segi' in English, and so, the entity whose - name contains `??' in Korean may have an entity-defined portion of - its domain name as `segi' in English. VIDN allows using `??' in - Korean as an entity-defined portion of a virtual domain name in - Korean, which is converted into `segi' in English, the corresponding - entity-defined portion of an actual domain name in English. More - specifically, the phonemes represented by the characters consisting - of `??' in Korean have the same sounds as the phonemes represented - by the characters consisting of `segi' in English. In the local - context, `??' in Korean is clearly easier to remember and type and - more intuitive and meaningful than `segi' in English. - - An entity-defined portion of a virtual domain name in Korean, `??', - is transliterated into `yahoo' in English, since the phonemes - represented by the characters consisting of `??' in Korean have the - same sounds as the phonemes represented by the characters consisting - of `yahoo' in English. That is, `??' in Korean is pronounced as the - same as `yahoo' in English, and so, it is easy for Korean-speaking - people to deduce `??' in Korean as the virtual equivalent of - `yahoo' in English. VIDN allows using virtual domain names in a local - language for domain names whose originals are in the local language, - e.g., `??' in Korean, as well as domain names whose originals are - in English, e.g., `??' in Korean. In this way, VIDN can make domain - names truly international, allowing the same domain names to be used - both in English and local languages. - - The coded portions of domain names such as organization codes, - geographic codes and country codes, can also be transliterated from a - local language into English, using the phonemes of the two languages - as a medium. For example, seven generic organization codes in English, - `com', `edu', `gov', `int', `mil', `net', and `org', can be - transliterated from `?', `??', `??', `??', `?', `??', `??' in - Korean, respectively, which can be used as the corresponding - organization codes of virtual domain names in Korean. Based upon its - meaning in English, each coded portion of actual domain names also - can be pre-assigned a virtual equivalent word or code in a local - language. For example, seven generic organization codes in English, - `com', `edu', `gov', `int', `mil', `net', and `org', can be pre- - assigned `??' (meaning `commercial' in Korean), `??' (meaning - `education' in Korean), `??' (meaning `government' in Korean), - `??' (meaning `international' in Korean), `??' (meaning `military' - in Korean), `??' (meaning `network' in Korean), and `??' (meaning - - - Virtually Internationalized Domain Names November 2000 - - `organization' in Korean), respectively, which can be used as the - corresponding organization codes of virtual domain names in Korean. - - Since VIDN uses the phonemes of a local language and English as a - medium of the transliteration, it does not create such complexities - as other conversion methods based upon semantics do. 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 of a language may represent - more than one phoneme. Also, some phonemes of a language may be - represented by more than one character or set of characters. But - these variations usually occur in particular situations, and so, VIDN - incorporates the special provisions to deal with such variations. In - addition, not every character or set of characters in a local - language may be neatly transliterated into only one character or set - of characters in English. In practice, people often transliterate the - same word in a local language differently into English or vice versa. - VIDN also incorporates the provisions to deal with such variations - caused by common usages or idiomatic expressions. Because of these - variations, however, it is probable for one virtual domain name - entered in a local language to result in more than one actual domain - name in English. - - VIDN includes a coding scheme in order to make each virtual domain - name entered in a local language correspond to exactly one actual - domain name in English. In this coding scheme, a unique code is pre- - assigned to one of the corresponding actual domain names in English - for each virtual domain name to be entered in a local language. The - code is kept somewhere at the server host that has the actual domain - name in English, for example, in the main HTML document at the server - host, so that VIDN can check the code. VIDN also generates the same - unique code whenever the corresponding virtual domain name is entered - in user applications. Then, VIDN checks whether the code at each - server host matches with the code generated in user applications. If - one of the server hosts has the code that matches with the code - generated in user applications, VIDN recognizes that the virtual - domain name entered by the user corresponds only to the actual domain - name of that server host, and connects the user host to the server - host. The domain names of the remaining server hosts that do not have - the matching code may be listed to the user as alternative sites. For - security purpose, this coding scheme may use an encryption technique. - - For example, `??.?', a virtual domain name entered in Korean, may - result in four corresponding domain names in English including - `jungang.com', `joongang.com,' `chungang.com', and `choongang.com', - since the phonemes represented by characters consisting of `??.?' - in Korean 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. In - - - Virtually Internationalized Domain Names November 2000 - - 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 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 a local language correspond to only one actual domain name in - English, 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 characters in a local language and - English 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 also 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 - - - Virtually Internationalized Domain Names November 2000 - - 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 a local language and English, without - creating additional identifiers in the local language. The conversion - of VIDN can be done between any two languages interchangeably. Thus, - even when the DNS accepts and registers domain names in other - languages in addition to English, VIDN can allow using the same - domain names in any two languages by converting virtual domain names - in one language into actual domain names in another language. - - - 4.3. Implementation - - In a preferred arrangement, VIDN is implemented in applications at - the user host. That is, the conversion of virtual domain names in a - local language into the corresponding actual domain names in English - 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 local language into the - corresponding actual domain names in English. A user needs only the - module for conversion of his or her preferred local language into - English. Also, VIDN can be implemented at a central server host or a - cluster of local server hosts. A central server with all the language - modules of VIDN can provide the conversion service for all local - languages, or a cluster of local server hosts can share the - conversion service. In the latter case, each local server host with a - language module or a set of language modules can provide the - conversion service for the respective local language or set of local - languages 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 a local language in - accordance with the principles of VIDN is very intuitive to those who - speak the local language. 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 into which a virtual domain - name in a local language is neatly transliterated in accordance with - the principles of VIDN, and to have a pre-assigned code kept at its - server host for one-to-one matching of its actual domain name and a - virtual domain name to be used by users. Most entities in regions - where English is not widely spoken already have such domain names in - English. 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 - - - Virtually Internationalized Domain Names November 2000 - - confuse users, as already observed in some regions where some of - these methods have already been commercialized, e.g., Korea, it is - important to find and implement the most effective solution to - internationalized domain names as soon as possible. - - - 4.4. Testing results - - A testing version of 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 except the coding scheme. - While the final version of the program is planned to include the - coding scheme, the testing version lists all the domain names in - English that correspond to a virtual domain name entered in Korean so - that a user can choose one. The testing results of a sample of - randomly selected domain names used in Korea show that the program - can cover more than ninety percent of the sample. The results - indicate that more than ninety percent of web sites in Korea can be - accessed using virtual domain names in Korean without creating - additional domain names in Korean. The remaining ten percent of - domain names are mostly those that contain acronyms, abbreviations or - initials. With improvement of its knowledge of transliteration, the - final version of the program is expected to cover most 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 Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997 - - - - - Virtually Internationalized Domain Names November 2000 - - 2 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-idn-vidn-01.txt b/doc/draft/draft-ietf-idn-vidn-01.txt new file mode 100644 index 0000000000..fbab57dfc6 --- /dev/null +++ b/doc/draft/draft-ietf-idn-vidn-01.txt @@ -0,0 +1,505 @@ +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-default-addr-select-02.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-03.txt similarity index 81% rename from doc/draft/draft-ietf-ipngwg-default-addr-select-02.txt rename to doc/draft/draft-ietf-ipngwg-default-addr-select-03.txt index 02de64b3e4..33115b5517 100644 --- a/doc/draft/draft-ietf-ipngwg-default-addr-select-02.txt +++ b/doc/draft/draft-ietf-ipngwg-default-addr-select-03.txt @@ -2,7 +2,7 @@ IPng Working Group Richard Draves Internet Draft Microsoft Research -Document: draft-ietf-ipngwg-default-addr-select-02.txt November 24, 2000 +Document: draft-ietf-ipngwg-default-addr-select-03.txt March 3, 2001 Category: Standards Track Default Address Selection for IPv6 @@ -54,8 +54,8 @@ Abstract These addresses may also be "preferred" or "deprecated" [3]. Privacy considerations have introduced the concepts of "public addresses" -Draves Standards Track - Expires June 2001 1 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 +Draves Standards Track - Expires September 2001 1 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 and "temporary addresses" [4]. The mobility architecture introduces @@ -112,8 +112,8 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 -Draves Standards Track - Expires June 2001 2 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 +Draves Standards Track - Expires September 2001 2 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 1.1. Conventions used in this document @@ -163,17 +163,21 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 address pairs having the longest possible common prefix. For source address selection, temporary addresses [4] are preferred over public addresses. In mobile situations [5], home addresses are preferred - over care-of addresses. + over care-of addresses. If an address is simultaneously a home + address and a care-of address (indicating the mobile node is "at + home" for that address), then the home/care-of address is preferred + over addresses that are solely a home address or solely a care-of + address. + +Draves Standards Track - Expires September 2001 3 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + The framework optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a configurable table that specifies precedence values and preferred - -Draves Standards Track - Expires June 2001 3 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - source prefixes for destination prefixes. If an implementation is not configurable, or if an implementation has not been configured, then the default policy table specified in this document SHOULD be @@ -222,38 +226,36 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 IPv4 addresses should be treated as having "preferred" configuration status. + + +Draves Standards Track - Expires September 2001 4 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + 2.3. IPv6 Addresses with Embedded IPv4 Addresses IPv4-compatible addresses [2] and 6to4 addresses [12] contain an embedded IPv4 address. For the purposes of this document, these - addresses should be treated as having the scope of the embedded IPv4 - -Draves Standards Track - Expires June 2001 4 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - - address. For example, the IPv6 address ::169.254.3.18 has link-local - scope and the address 2002:0a01:0203::1 has site-local scope. + addresses should be treated as having global scope. IPv4-compatible addresses should be treated as having "preferred" configuration status. 2.4. Loopback Address and Other Format Prefixes - The loopback address should be treated as having link-local scope - and "preferred" configuration status. + The loopback address should be treated as having link-local + scope [9] and "preferred" configuration status. - NSAP addresses, IPX addresses, and other addresses with as-yet- - undefined format prefixes should be treated as having global scope - and "preferred" configuration status. Later standards may supercede - this treatment. + NSAP addresses and other addresses with as-yet-undefined format + prefixes should be treated as having global scope and "preferred" + configuration status. Later standards may supercede this treatment. 2.5. Policy Table The policy table is a longest-matching-prefix lookup table, much like a routing table. Given an address A, a lookup in the policy - table produces three values: a precedence value Precedence(A), a - classification or label SrcLabel(A), and a second label DstLabel(A). + table produces two values: a precedence value Precedence(A) and a + classification or label Label(A). The precedence value Precedence(A) is used for sorting destination addresses. If Precedence(A) > Precedence(B), we say that address A @@ -261,10 +263,10 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 will prefer to sort destination address A before destination address B. - The labels SrcLabel(A) and DstLabel(A) allow for policies that - prefer a particular source address prefix for use with a destination - address prefix. The algorithms prefer to use a source address S with - a destination address D if SrcLabel(S) = DstLabel(D). + The label value Label(A) allows for policies that prefer a + particular source address prefix for use with a destination address + prefix. The algorithms prefer to use a source address S with a + destination address D if Label(S) = Label(D). IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined @@ -273,23 +275,23 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 specified here in conjunction with the following default policy table: - Prefix Precedence SrcLabel DstLabel - ::1/128 50 0 0 - ::/0 40 1 1 - 2002::/16 30 2 2 - ::/96 20 3 3 - ::ffff:0:0/96 10 4 4 + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + 2002::/16 30 2 + ::/96 20 3 + ::ffff:0:0/96 10 4 One effect of the default policy table is to prefer using native source addresses with native destination addresses, 6to4 [12] source - addresses with 6to4 destination addresses, and v4-compatible [2] - source addresses with v4-compatible destination addresses. Another -Draves Standards Track - Expires June 2001 5 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 +Draves Standards Track - Expires September 2001 5 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + addresses with 6to4 destination addresses, and v4-compatible [2] + source addresses with v4-compatible destination addresses. Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available. @@ -340,14 +342,15 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 specifies a source address that is in the candidate set for the destination, then the network layer MUST respect that choice. If the application or upper-layer does not specify a source address, then + + +Draves Standards Track - Expires September 2001 6 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + the network layer uses the source address selection algorithm specified in the next section. - -Draves Standards Track - Expires June 2001 6 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - 4. Source Address Selection The source address selection algorithm chooses a source address for @@ -369,9 +372,9 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 If SA = D, then choose SA. Similarly, if SB = D, then choose SB. Rule 2: Prefer appropriate scope. - If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB + If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then choose SB and otherwise choose SA. - Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < Scope(D), then + Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then choose SA and otherwise choose SB. Rule 3: Avoid deprecated addresses. @@ -380,9 +383,12 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 one that is preferred. Rule 4: Prefer home addresses. - If SA is a home address and SB is a care-of address, then prefer SA. - Similarly, if SB is a home address and SA is a care-of address, then - prefer SB. + If SA is simultaneously a home address and care-of address and SB is + not, then prefer SA. Similarly, if SB is simultaneously a home + address and care-of address and SA is not, then prefer SB. + If SA is just a home address and SB is just a care-of address, then + prefer SA. Similarly, if SB is just a home address and SA is just a + care-of address, then prefer SB. An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer care-of addresses over home addresses. @@ -394,18 +400,17 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 send to D and SA is assigned to a different interface, then prefer SB. - Rule 6: Prefer matching label. - If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D), - then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and - Label(SA) <> MatchSrcLabel(D), then choose SB. - - -Draves Standards Track - Expires June 2001 7 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 +Draves Standards Track - Expires September 2001 7 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + Rule 6: Prefer matching label. + If Label(SA) = Label(D) and Label(SB) <> Label(D), then choose SA. + Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then + choose SB. + Rule 7: Prefer temporary addresses. If SA is a temporary address and SB is a public address, then prefer SA. Similarly, if SB is a temporary address and SA is a public @@ -454,16 +459,16 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. + +Draves Standards Track - Expires September 2001 8 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + Rule 1: Avoid unusable destinations. If there is no route to DB or if Source(DB) is undefined, then sort DA before DB. Similarly, if there is no route to DA or if Source(DA) is undefined, then sort DB before DA. - -Draves Standards Track - Expires June 2001 8 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - Rule 2: Prefer matching scope. If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), then sort DA before DB. Similarly, if Scope(DA) <> Scope(Source(DA)) @@ -475,15 +480,19 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 is deprecated, then sort DA before DB. Rule 4: Prefer home addresses. - If Source(DA) is a home address and Source(DB) is a care-of address, - then sort DA before DB. Similarly, if Source(DA) is a care-of - address and Source(DB) is a home address, then sort DB before DA. + If Source(DA) is simultaneously a home address and care-of address + and Source(DB) is not, then sort DA before DB. Similarly, if + Source(DB) is simultaneously a home address and care-of address and + Source(DA) is not, then sort DB before DA. + If Source(DA) is just a home address and Source(DB) is just a care- + of address, then sort DA before DB. Similarly, if Source(DA) is just + a care-of address and Source(DB) is just a home address, then sort + DB before DA. Rule 5: Prefer matching label. - If SrcLabel(Source(DA)) = DstLabel(DA) and SrcLabel(Source(DB)) <> - DstLabel(DB), then sort DA before DB. Similarly, if - SrcLabel(Source(DA)) <> DstLabel(DA) and SrcLabel(Source(DB)) = - DstLabel(DB), then sort DB before DA. + If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), + then sort DA before DB. Similarly, if Label(Source(DA)) <> Label(DA) + and Label(Source(DB)) = Label(DB), then sort DB before DA. Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then sort DA before DB. @@ -508,6 +517,11 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 implementation somehow knows which destination addresses will result in the "best" communications performance. + +Draves Standards Track - Expires September 2001 9 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + 6. Interactions with Routing This specification of source address selection assumes that routing @@ -516,12 +530,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 However, implementations may use source address considerations as a tiebreaker when choosing among otherwise equivalent routes. - - -Draves Standards Track - Expires June 2001 9 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - For example, suppose a node has interfaces on two different links, with both links having a working default router. Both of the interfaces have preferred global addresses. When sending to a global @@ -567,24 +575,41 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 information in its implementation of destination address selection, or if the ordering of a cached list of destination addresses is possibly stale, then it should ensure that the destination address + +Draves Standards Track - Expires September 2001 10 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + ordering returned to the application is no more than one second out of date. For example, an implementation might make a system call to check if any routing table entries or source address assignments - that might affect these algorithms have changed. + that might affect these algorithms have changed. Another strategy is + to use an invalidation counter that is incremented whenever any + underlying state is changed. By caching the current invalidation + counter value with derived state and then later comparing against + the current value, the implementation can detect if the derived + state is stale. - - - - -Draves Standards Track - Expires June 2001 10 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - 8. Security Considerations This document has no direct impact on Internet infrastructure security. + Note that most source address selection algorithms, including the + one specified in this document, expose a potential privacy concern. + An unfriendly node can infer correlations among a target node's + addresses by probing the target node with request packets that force + the target host to choose its source address for the reply packets. + (Perhaps because the request packets are sent to an anycast or + multicast address, or perhaps the upper-layer protocol chosen for + the attack does not specify a particular source address for its + reply packets.) By using different addresses for itself, the + unfriendly node can cause the target node to expose the target's own + addresses. For example, the unfriendly node might correlate the + target's current IPv6 temporary address with its IPv4 address by + sending requests with a global source address and an IPv4-compatible + source address. + 9. Examples This section contains a number of examples, first of default @@ -608,6 +633,11 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Sources: fe80::1 vs 2001::1 Result: 2001::1 (prefer appropriate scope) + +Draves Standards Track - Expires September 2001 11 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + Destination: ff05::1 Sources: fe80::1 vs fec0::1 vs 2001::1 Result: fec0::1 (prefer appropriate scope) @@ -632,12 +662,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Sources: 2002:836b:2179::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2002:836b:2179::2 (prefer matching label) - - -Draves Standards Track - Expires June 2001 11 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - Destination: 2001::1 Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2001::d5e3:7953:13eb:22e8 (prefer temporary address) @@ -667,7 +691,11 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Destinations: 2001::1 vs fec0::1 vs fe80::1 Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (prefer smaller scope) - + +Draves Standards Track - Expires September 2001 12 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + Sources: 2001::2 (care-of address) or 3ffe::1 (home address) or fec0::2 (care-of address) or fe80::2 (care-of address) Destinations: 2001::1 vs fec0::1 @@ -691,11 +719,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Sources: 2002:836b:4179::2 or 2001::2 or fe80::2 Destinations: 2002:836b:4179::1 vs 2001::1 - -Draves Standards Track - Expires June 2001 12 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 2002:836b:4179::2) (prefer higher precedence) @@ -707,12 +730,12 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 administrator can change the policy table to prefer IPv4 addresses by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: - Prefix Precedence SrcLabel DstLabel - ::1/128 50 0 0 - ::/0 40 1 1 - 2002::/16 30 2 2 - ::/96 20 3 3 - ::ffff:0:0/96 100 4 4 + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + 2002::/16 30 2 + ::/96 20 3 + ::ffff:0:0/96 100 4 This change to the default policy table produces the following behavior: @@ -724,6 +747,13 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Sources: fe80::1 or 131.107.65.117 Destinations: 2001::1 vs 131.107.65.121 + + + +Draves Standards Track - Expires September 2001 13 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) @@ -742,26 +772,14 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 site-local destinations, and site-local destinations before link- local destinations: - - - - - - - - -Draves Standards Track - Expires June 2001 13 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - - Prefix Precedence SrcLabel DstLabel - ::1/128 50 0 0 - ::/0 40 1 1 - fec0::/10 37 1 1 - fe80::/10 33 1 1 - 2002::/16 30 2 2 - ::/96 20 3 3 - ::ffff:0:0/96 10 4 4 + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + fec0::/10 37 1 + fe80::/10 33 1 + 2002::/16 30 2 + ::/96 20 3 + ::ffff:0:0/96 10 4 This change to the default policy table produces the following behavior: @@ -788,6 +806,12 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Each site has two global prefixes, one from the high-performance ISP and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 + + +Draves Standards Track - Expires September 2001 14 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + from the high-performance ISP and prefix 2007:0:aaaa::/48 from its normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All @@ -805,13 +829,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b - - - -Draves Standards Track - Expires June 2001 14 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) (longest matching prefix) @@ -836,17 +853,23 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 desired behavior via policy table configuration. For example, they can use the following policy table: - Prefix Precedence SrcLabel DstLabel - ::1 50 0 0 - 2001:aaaa:aaaa::/48 45 5 5 - 2001:bbbb:bbbb::/48 45 5 5 - ::/0 40 1 1 - 2002::/16 30 2 2 - ::/96 20 3 3 - ::ffff:0:0/96 10 4 4 + Prefix Precedence Label + ::1 50 0 + 2001:aaaa:aaaa::/48 45 5 + 2001:bbbb:bbbb::/48 45 5 + ::/0 40 1 + 2002::/16 30 2 + ::/96 20 3 + ::ffff:0:0/96 10 4 This policy table produces the following behavior: + + +Draves Standards Track - Expires September 2001 15 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then @@ -865,11 +888,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 host in some other site C, the traffic uses the normal ISP as desired. - -Draves Standards Track - Expires June 2001 15 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP @@ -888,8 +906,9 @@ References 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-12.txt, April 2000. - 6 R. Troll. "Automatically Choosing an IP Address in an Ad-Hoc IPv4 - Network", draft-ietf-dhc-ipv4-autoconfig-05.txt, March 2000. + 6 S. Cheshire. "Dynamic Configuration of IPv4 Link-local + Addresses", draft-ietf-zeroconf-ipv4-linklocal-01.txt, November + 2000. 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -903,6 +922,13 @@ References 10 Y. Rekhter et. al, "Address Allocation for Private Internets", RFC 1918, February 1996. + + +Draves Standards Track - Expires September 2001 16 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + + 11 F. Baker, Editor. "Requirements for IP Version 4 Routers", RFC 1812, June 1995. @@ -912,9 +938,10 @@ References Acknowledgments The author would like to acknowledge the contributions of the IPng - Working Group, particularly Steve Deering and Ken Powell. Please let - the author know if you contributed to the development of this draft - and are not mentioned here. + Working Group, particularly Steve Deering, Jun-ichiro itojun Hagino, + M.T. Hollinger, Ken Powell, Markku Savela, Dave Thaler, and Mauro + Tortonesi. Please let the author know if you contributed to the + development of this draft and are not mentioned here. Author's Address @@ -922,17 +949,27 @@ Author's Address Microsoft Research One Microsoft Way Redmond, WA 98052 - - -Draves Standards Track - Expires June 2001 16 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - Phone: 1-425-936-2268 Email: richdr@microsoft.com Revision History +Changes from draft-ietf-ipngwg-default-addr-select-02 + + Changed scope treatment of IPv4-compatible and 6to4 addresses, so + they are always considered to be global. Removed mention of IPX + addresses. + + Changed home address rules to favor addresses that are + simultaneously home and care-of addresses, over addresses that are + just home addresses or just care-of addresses. + + Combined SrcLabel & DstLabel in the policy table into a single Label + attribute. + + Added mention of the invalidation counter technique in the + implementation section. + Changes from draft-ietf-ipngwg-default-addr-select-01 Added Examples section, demonstrating default behavior and some @@ -942,6 +979,13 @@ Changes from draft-ietf-ipngwg-default-addr-select-01 of source addresses and the source address selection rule that prefers source addresses of appropriate scope. + + + +Draves Standards Track - Expires September 2001 17 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + Simplified the default policy table. Reordered the source address selection rules to reduce the influence of policy labels. Added more destination address selection rules. @@ -980,12 +1024,6 @@ Changes from draft-ietf-ipngwg-default-addr-select-00 Added a rule to source address selection to handle home/care-of addresses. - - -Draves Standards Track - Expires June 2001 17 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 - - Changed to allow destination address selection to sort both IPv6 and IPv4 addresses. Added entries in the default policy table for IPv4- mapped addresses. @@ -1001,7 +1039,11 @@ Changes from draft-draves-ipngwg-simple-srcaddr-01 Added mechanism to allow the specification of administrative policy that can override the default behavior. - + +Draves Standards Track - Expires September 2001 18 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 + + Added section on routing interactions and TBD section on mobility interactions. @@ -1035,13 +1077,29 @@ Changes from draft-draves-ipngwg-simple-srcaddr-00 + + + + + + + + + + + + + + + + -Draves Standards Track - Expires June 2001 18 -draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 +Draves Standards Track - Expires September 2001 19 +draft-ietf-ipngwg-default-addr-select-03 March 3, 2001 Full Copyright Statement @@ -1098,4 +1156,4 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 -Draves Standards Track - Expires June 2001 19 \ No newline at end of file +Draves Standards Track - Expires September 2001 20 \ No newline at end of file diff --git a/doc/draft/draft-whr-dnsext-secure-online-update-00.txt b/doc/draft/draft-whr-dnsext-secure-online-update-00.txt deleted file mode 100644 index 6833196c3d..0000000000 --- a/doc/draft/draft-whr-dnsext-secure-online-update-00.txt +++ /dev/null @@ -1,580 +0,0 @@ -INTERNET-DRAFT X. Wang, Y. Huang, D Rine (GMU) - June 2000 - -Updates: RFC 2136 -Replaces: RFC 2137 - - - - Secure Online Domain Name System (DNS) Dynamic Update - - -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 authors or the DNSIND WG mailing - list namedroppers@internic.net. - - This draft expires on December 9, 2000. - - Copyright Notice - - Copyright (C) The Internet Society (2000). All rights reserved. - - -Abstract - - This document proposes an alternate architecture to enable secure - online Domain Name System (DNS) dynamic updates. It is intended - - - -Expires December 2000 [Page 1] - -INTERNET-DRAFT Secure Online DNS Dynamic Update June 2000 - - - to enable a DNS zone to provide online dynamic update and at the - same time, maintain the zone's security including role separation - and intrusion tolerance against insider and outsider attacks. - Threshold digital signature is used to implement the proposed - architecture. - -1 - Introduction - - This document proposes an alternate architecture to allow a - DNS zone to provide secure online dynamic update. In contrast - to existing dynamic update scheme, the proposed architecture - distinguishes itself in that it provides high security - for a zone when allowing it support online dynamic update. - - Familiarity with the DNS system [RFC1034, RFC1035], DNS - Security Extension [RFC2535], dynamic update [RFC2136] and - secure dynamic update [RFC2137] is helpful and is assumed by - this document. - - This document obsoletes RFC 2137, an alternate proposal - for secure dynamic update, due to implementation experience. - - 1.1 - Overview of DNS Security Extension - - DNS Security Extension (DNSSEC) is proposed in [RFC2535]. - The DNSSEC provides RR authentication by the use of digital - signatures. In DNSSEC, each zone is equipped with a - public/private key pair. The private key is used to digitally - sign all the RRs in that zone. The response to a DNS query - will also include the requested RRs and a SIG RR - (signature RR), which contains the digital signature of the - requested RRs. The zone public key, used to verify signatures, - is disseminated by means of KEY RRs. - - A major security principle of the DNSSEC is the role separation: - it differentiates the roles of the DNS server administrator from - the DNS zone manager. One advantage of the role separation - is that it helps to prevent power abuses [SBM99]. In DNSSEC, - it is the DNS zone manager, not the DNS server administrator, - who is responsible for the security of a zone. A DNS server is - just a place to publish the digitally signed DNS data of the zone. - Thus, compromise of a secondary server or, if the zone private - key is kept off line, even the primary server for a zone, will - not necessarily affect the degree of assurance that a DNS - client receives [RFC2535]. When zone data is updated, the zone - manager will sign the new zone data off-line. - - 1.2 - Overview of DNS Dynamic Update and DNS Secure Dynamic Update - - The idea of keeping zone private key off-line and computing - the signatures of RRs off-line is based on the assumption - that RRs in a DNS zone are relatively static. Indeed, in - normal situations we can expect that bindings between domain - names and IP addresses do not change frequently. However, it - has been pointed out that DNS dynamic updates, which enable - real-time changes (that is, add, delete, or update) in - name/address bindings, are useful under many circumstances - [Liu99,RFC2136]. (For example, such an update allows a - -Wang, Huang & Rine [Page 2] - -INTERNET-DRAFT June 2000 - - - corporation to switch to a new domain name without waiting for - the slow, manual processing of the name change request by a - domain name registrar.) For a dynamic RR update to take effect - immediately and securely, the signature of the updated RR must - be computed online. It is worthwhile to note that although - a DNS dynamic update requestor is communicating with a name - server, the name server itself has no rights to update the - zone data. Instead, it is the zone private key, instead of - the name server's private key, that is needed in the dynamic - update. - - In [RFC2137], two modes are defined to achieve the above goal. - In mode A, the zone private key is kept off-line and any - dynamic requests will be authorized by a dynamic update key - that is kept online. However, in this mode, since the zone - private key is not kept online, zone transfer security is - not automatically provided for dynamically added RRs, where - they could be omitted, and authorization is not provided for - the server denial of the existence of a dynamically added - type [RFC2137]. In this sense, this mode is not a genuine - DNS dynamic update. In mode B, on the other hand, the zone - private key is kept online at the zone primary name server; - thus, any legitimate DNS dynamic updates can be in effect - immediately. - - 1.3 - The existing drawbacks - - Both of the above modes above require that a zone security - related private key be kept on line at the primary name server. - This practice raises security concerns [RFC2137]. First, it makes - the primary name server a single point of attack to an outside - attacker. Should the primary server be compromised, the online - private key will be exposed, rendering dynamic RRs insecure - in mode A or, even worse, all RRs in the entire zone insecure - in mode B. Second, as an insider, the name server administrator - has access of this private key, compromising the role separation - principle and making it possible for the name server - administrator to abuse his/her power. (The importance of fending - off insider attacks has been emphasized by the security - community [RFC2196].) - -2 - The Secure On-line DNS Dynamic Update Architecture - - 2.1 - Background: Threshold Cryptography - - Threshold cryptography is a branch of cryptography that - enables a group of n members, 1,2, ..., n, to act as a single - communication party, using one pair of public and private keys - [Des87,Des94,Des97]. Similar to the traditional public key - cryptography, the public key is known to the public. Unlike - the traditional public key cryptography, the private key of - the group, K_private, does not exist as a whole. Rather, each - member i, 1 <= i <= n, will be assigned a number of key shares - of the private key. (For each public key cryptography algorithm, - - -Wang, Huang & Rine [Page 3] - -INTERNET-DRAFT June 2000 - - - a corresponding key sharing mechanism must be devised.) To - perform a cryptographic computation (such as decryption, signing, - identification, etc.) on message m with key K_private, b, - b <= n , group members will be required. Each member will compute - a partial result. Subsequently, the partial results are combined - to produce the final result. The combiner is not necessarily to - be trusted. Note that during this whole process the shared - private key, K_private, is never reconstructed. Further, - threshold cryptography requires that the shared private key - cannot be reconstructed from any t < b group members. - - Practical threshold cryptography for RSA and DSS have been - designed. A practical threshold RSA is given by [DDB94] where - b = t+1 and a practical threshold DSS is given by [GJKR96b] where - t < n/2 and b = 2t+1. - - 2.2 - Introduction - +------------------------+ - +---------+ #####| zone-security server 1 | -+---------+ | DNS | # +------------------------+ -|DNS | DNS query | | # -| Inquirer|---------> | | # -+---------+ | Primary | # +------------------------+ - | |#########| zone-security server 2 | - | Name | # +------------------------+ - | | # - | | # . . . -+------+ | Server | # . . . -|DNS | DNS Dynamic | | # . . . -| User |=============> | | # +--------------------------+ -+------+ Update request| | #####| zone-security server n-1 | - | | +--------------------------+ - +---------+ - | - | zone transfer - \|/ - +-----------------+ - | DNS Secondary | - | Name Server | - +-----------------+ - - In the above proposed architecture, we assume that there exist - (n-1), n >= 2, machines in a given DNS zone that are under the - control of the zone manager, but not under the control of the - name server administrators. These machines are called the - zone-security servers. - - Using a threshold cryptography scheme with n > t >= 1, the - zone private key is shared among the (n-1) zone-security servers - and the primary name server. To update zone's data dynamically, - some of the servers will be needed. Let b > t be the number of - zone private key shares needed in the computation of the - signature of an RR. Since b >= 2, any change to the zone data - will need the cooperation of at least one zone-security server; - - -Wang, Huang & Rine [Page 4] - -INTERNET-DRAFT June 2000 - - - the name server administrator will have no way to modify the - digitally signed zone data. Thus, the role separation principle - holds. Moreover, the above architecture enhances intrusion - tolerance of DNS. - - A DNS system is said to be k-intrusion-tolerant against an - entity, E, if breaking into k servers (including the - zone-security servers and the DNS name servers, if applicable) - that are outside E's control will not help E gain any knowledge - of the zone private key. A DNS system is said to be intrusion - tolerant against an outsider (insider) if it is at least - 1-intrusion-tolerant against the outsider (insider). The - architecture proposed in this document can be configured to be - intrusion tolerant against outside and inside attackers. - - Intrusion tolerance against outsider attacks. In the - architecture, the zone private key cannot be recovered from - any single location, thus, making the system intrusion - tolerant against an outside attacker. That is, even when an - outside attacker manages to corrupt l, l <= t, of relevant - servers (including the name servers and the zone-security - servers), secrecy of the zone private key is still - maintained. - - Intrusion tolerance against insider attacks. The presence of - zone security servers and the necessity of their involvement - in signature computations constitute a defense line - against insider attacks, in particular, attacks from name - server administrators. Clearly, a hostile name server - administrator must break into at least t zone security - servers (to get access to the respective key shares) in - order to perform unauthorized RR signature computations. - -3 - Implementation Details - - [RFC2535] defines two types of SIG records, the DSA SIG and - the RSA/MD5 SIG. The important configuration and implementation - aspects of our proposed architecture with respect to these two types - of SIGs are given next. In the following statement, - the primary name server will be referred to as server 0 and the - (n-1) zone-security servers will be referred to as servers - 1, 2, ... , (n-1). - - 3.1 - Example Configurations - - The following table gives some representative configurations, in - terms of t and n, to achieve the above security levels in - different application cases. - - -Wang, Huang & Rine [Page 5] - -INTERNET-DRAFT June 2000 - - - +----------------------------+----------------------------+ - | | RSA/MD5 SIG | DSA SIG | - | SECURITY LEVEL +-------------+--------------+ - | | 1-2 | 2-4 | 1-3 | 2-5 | - +----------------------------+-----+-------+-------+------+ - |Intrusion tolerant against | | | | | - | outsider attackers (Y/N) | Y | Y | Y | Y | - +----------------------------+-----+-------+-------+------+ - |Intrusion tolerant against | | | | | - | insider attackers (Y/N) | N | Y | N | Y | - +----------------------------+-----+-------+-------+------+ - - 3.2 - The RSA/MD5 SIG - - Assume that, in RSA, the zone's private key is d and its - public key is (e, N). Phi(N) is the Euler function of N, i.e., - phi(N) = (p-1)(q-1) where N = p * q. We use the threshold - digital signature scheme given in [DDB94] and now give - how the zone private key is shared and how to generate a - RSA/MD5 SIG RR online. - - The 1-2 case. In this case, the zone manager generates a random, - d1, 1 < d1 < phi(N), and compute d2, d2 = d - d1 mod phi(N). - Values d1 and d2 are sent securely to the primary name server - and the zone-security server respectively. - - To generate a RSA/MD5 SIG of m, where m is the MD5 digest of - an RR, the two servers will compute m^d1 mod N and m^d2 mod N - respectively. Then any one of them can combine the partial - results as m^d1 * m^d2 mod N = m^d mod N, the digital signature - of m by the zone private key. - - The 2-4 case. To generate key shares, the zone manager generates - 4 random numbers, d1, d2, d3, d4, where 1 < di < phi(N) - for 1 <= i <= 4. He/she will also compute two numbers, - d5 = d - d1 - d2 mod phi(N) and d6 = d - d3 - d4 mod phi(N). - Subsequently, d1 and d6 are sent to the primary name server, - d2 and d6 are sent to server 1, d3 and d5 are sent to server 2, - d4 and d5 are sent to server 3, as shown in the following table. - - +---------------------+----------+----------+----------+---------+ - | | SERVER 0 | SERVER 1 | SERVER 2 | SERVER 3| - +---------------------+----------+----------+----------+---------+ - | KEYS ASSIGNED | d1, d6 | d2, d6 | d3, d5 | d4, d5 | - +-------------+-------+----------+----------+----------+---------+ - |PARTICIPATING|(0,1,2)| d1 | d2 | d5 | | - | +-------+----------+----------+----------+---------+ - | |(0,1,3)| d1 | d2 | | d5 | - | +-------+----------+----------+----------+---------+ - | |(0,2,3)| d6 | | d3 | d4 | - | SERVERS +-------+----------+----------+----------+---------+ - | |(1,2,3)| | d6 | d3 | d4 | - +-------------+-------+----------+----------+----------+---------+ - - -Wang, Huang & Rine [Page 6] - -INTERNET-DRAFT June 2000 - - - To generate a RSA/MD5 SIG, any 3 of the 4 servers will be - needed. For example, if the primary name server and the - zone-security servers 1 and 2 are present (the (0,1,2) case in - the above table), the three servers will compute m^d1 mod N, - m^d2 mod N, and m^d3 mod N respectively. After that any one of - them can combine the partial results to produce - m^d1 * m^d2 * m^d3 mod N = m^d mod N, the digital signature of - m by the zone private key. Other possibilities of computing - the signature of m are summarized in the above table. - - 3.3 - The DSA SIG - - In this case, for a t-n configuration (such as the 1-3 and 2-5 - configurations), the zone manager will generate n shares of the - zone private key and distribute them to the n servers - using a (t,n) Shamir secret sharing scheme [Sha79]. When the - zone data needs updating, (2t+1) servers are required to jointly - compute the DSA SIG RR [GJKR96b]. - -5 - Security considerations - - This document proposes an architecture to allow a DNS zone to - provide secure online DNS dynamic update. It uses threshold - digital signature to maintain the role separation principle and can - also provide intrusion tolerance against both outside attackers - and inside attackers. - - It should be noted that the authentication a DNS dynamic update - requestor and authorization of a update request, which is handled - elsewhere such as [RFC2535], is not dealt in this document, - -6 - Acknowledgements - - The authors wish to thank for many helpful discussions on the - DNSSEC mailing list and would like to give special thanks to - Yvo Desmedt. - -7 - References - - [DDB94] Y. Desmedt, G. Di Crescenzo, and M. Burmester. - ``Multiplicative nonabelian sharing schemes and their - application to threshold cryptography''. In J. Pieprzyk - and R. SafaviNaini, editors, Advances in Cryptology - - Asiacrypt '94, volume 917 of Lecture Notes in Computer - Science, pages 21--32, Wollongong, Australia, - November/December 1994. Springer-Verlag. - - [Des87] Y. Desmedt. ``Society and group oriented cryptography: - a new concept''. In C. Pomerance, editor, Advances in - Cryptology, Proc. of Crypto '87, volume 293 of Lecture - Notes in Computer Science, pages 120--127, Santa Barbara, - California, U.S.A., August 16--20, 1988. Springer-Verlag. - - -Wang, Huang & Rine [Page 7] - -INTERNET-DRAFT June 2000 - - - [Des94] Y. Desmedt. ``Threshold cryptography''. European Trans. - on Telecommunications, 5(4):449--457, July-August 1994. - - [Des97] Y. Desmedt. ``Some recent research aspects of threshold - cryptography''. In E. Okamoto, G. Davida, and M. Mambo, - editors, Information Security, volume 1396 of Lecture - Notes in Computer Science, pages 158--173, Tatsunokuchi, - Ishikawa, Japan, September 1997. Springer-Verlag. - - [DSA2] National Institute for Standards and Technology. - ``Digital signature standard (DSS)'', February 2000. - - [GJKR96b] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin. - ``Robust threshold DSS signatures''. In U. Maurer, - editor, Advances in Cryptology - Eurocrypt '96, - volume 1070 of Lecture Notes in Computer Science, - pages 354-371, Zaragoza, Spain, May 12--16 1996. - Springer-Verlag. - - [GMP] T. Granlund. ``GNU MP''. Source code available from - http://www.gnu.org/manual/gmp/index.html. - - [Liu99] C. Liu. ``Securing an Internet name server''. - Presentation, 1999. Available at - http://www.acmebw.com/papers/securing.pdf. - - [RFC1034] P. Mockapetris, ``Domain Names - Concepts and - Facilities,'' RFC 1034, ISI, November 1987. - - [RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, ISI, November 1987. - - [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic - Updates in the Domain Name System,'' RFC 2136, ISC & - Bellcore & Cisco & DEC, April 1997. - - [RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' - RFC 2137, CyberCash, April 1997. - - [RFC2196] B. Fraser. ``Site Security Handbook,'' RFC2196, September - 1997. - - [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' - RFC 2535, IBM, March 1999. - - [SBM99] R. Sandhu, V. Bhamidipati, and Q. Munawer. ``The ARBAC97 - model for role-based administration of roles''. ACM - Transactions on Information System Security, 2(1):105- - 135, February 1999. - - [Sha79] A. Shamir. ``How to share a secret''. Commun. ACM, - 22:612-613, November 1979. - - -Wang, Huang & Rine [Page 8] - -INTERNET-DRAFT June 2000 - - -8 - Author's Address - - A postscript of this document is available from - http://www.cs.gmu.edu/~xwang4/dnssecureonline.ps - - Send all comments to xwang4@cs.gmu.edu - - Xunhua Wang - Department of Computer Science - George Mason University - Fairfax, VA 22030-4444 - USA - - Phone: +1-703-993-1536 - Fax: +1-703-993-1710 - EMail: xwang4@cs.gmu.edu - - Yih Huang - Department of Computer Science - George Mason University - Fairfax, VA 22030-4444 - USA - - Phone: +1-703-993-1540 - Fax: +1-703-993-1710 - EMail: hyangyih@cs.gmu.edu - - David Rine - Department of Computer Science - George Mason University - Fairfax, VA 22030-4444 - USA - - Phone: +1-703-993-1546 - Fax: +1-703-993-1710 - EMail: drine@cs.gmu.edu - - -9 - Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain - it or assist in its implementation may be prepared, copied, - published and distributed, in whole or in part, without restriction - of any kind, provided that the above copyright notice and this - paragraph are included on all such copies and derivative works. - However, this document itself may not be modified in any way, - such as by removing the copyright notice or references to the - - -Wang, Huang & Rine [Page 9] - -INTERNET-DRAFT June 2000 - - - 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." - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires December 2000 [Page 10] - -INTERNET-DRAFT Secure Online DNS Dynamic Update June 2000 diff --git a/doc/draft/draft-whr-dnsext-secure-online-update-01.txt b/doc/draft/draft-whr-dnsext-secure-online-update-01.txt new file mode 100644 index 0000000000..e1c70e9122 --- /dev/null +++ b/doc/draft/draft-whr-dnsext-secure-online-update-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +Y. Huang: huang@infonet.com + +