Proposed Edits Re: alpha v0.2

["J. William Semich" <bsemich@mail.nu>]

Hello;

I have:

1. cleaned up the text in a "copy editor's" role (I used to be a magazine
editor, so I claim rights to that role <smile>);

2. Added some comments and suggested changes/modifications/simplifications
of my own;

and

3. Noted places in sections 2.2. and 2.3 which use the phrase "character
set" with the hope that Martin Durst could suggest alternative language,
based on his earlier comment about not using the phrase "character set" in
any documents or discussions.

All editing changes have been bracketed and capitalized; all changes
suggested by myself or comments are bracketed only, not capitalized.

-- Bill Semich

At 11:57 PM 1/22/00 +0800, James Seng wrote:
>-James Seng               Requirements of Internationalized Domain Names
>
>Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six
>    months and may be updated, replaced, or obsoleted by other documents
>    at any time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    To view the entire list of Internet-Draft Shadow Directories, see
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on DD MMMM YYYY.
>
>Copyright Notice
>
>    Copyright (C) The Internet Society (2000). All Rights Reserved.
>
>Abstract
>
>    This informational document describes the requirement for encoding
>    international characters into DNS names and records. This document 
>    should be considered as a guidance for developing of solutions of 
>    internationalised domain names. 
>    
>    This document is being discussed on the "idn" mailing list. To join
>    the list, send a message to <majordomo@ops.ietf.org> with the words
>    "subscribe idn" in the body of the message. Archives of the mailing
>    list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
>
>Conventions
>    
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
>    "I18C" is often used in this document to refer to internationlized 
>    characters or characters not within the US-ASCII.
>
>    Characters mentioned in this document are identified by their 
>    position in the Unicode character set. The notation U+12AB, for 
>    example, indicates the character at position 12AB (hexadecimal) 
>    in the Unicode character set. However, this is not an indication 
>    of any requirement to use Unicode.
>
>    "IDN" is used in this document as an abbreviation for 
>    "internationalized domain name". This is defined as a domain name 
>    that contains one or more characters that are outside the set of 
>    characters specified as legal characters for domain names in 
>    [RFC1034] Section 3.5.
>
>    "RR" is used in this document as an abbreviation for "Resource
>    Record" as defined in [RFC1035].
>
>    A master server for a zone holds the main copy of that zone. This 
>    is sometimes stored in a zone file.  A slave server for a zone 
>    holds a complete copy of the records within that zone. A caching 
>    server holds temporary copies of DNS records, it can use these 
>    records to answer identical queries but restricted by time-to-live
>    (TTL) of the records. Further explaination on master/slave server
>    can be found in [RFC1034] and [RFC1996].
>
>
>Table of Contents
>    1. Introduction ...............................................    2
>    ...
>    ...
>
>
>1. Introduction
>
>    This informational document describes the requirement for encoding
>    international characters into DNS names and records. This document 
>    should be considered as a guidance for developing of solutions of 
>    internationalised domain names (idn). 
>
>    ...
>
>    Examples quoted in this document should be considered as a form to
>    further the explaination of the meanings and principles adopted by
>    the document. It is not a requirement to satisfy the examples.
>
>2. General Requirements
>
>2.1 Compatibility and Interoperability
>
>The DNS is essential to the entire Internet. Therefore, IDN must not 
>damage present DNS interoperability. It must 
[MAKE] [DELETE do]
[THE] minimum amount of 
>changes to existing protocols on all layers of the stack. It must 
>continue to allow any

[STANDARD, UNMODIFIED] system anywhere to resolve[DELETE s] any domain 
name[DELETE s].
>
>Implementation of IDN must preserve the basic concept and facilities
>of domain 

name[S] as described in [RFC1034]. It must maintain a single, 
>global, universal and consistent
 
hiera[RCHICAL] [DELETE chary] namespace.
>
>The same name resolution request should generate the same response,

[This may not be technically possible if clients do not use a standardized
"charset" for queries - do we want to be this specific? I would delete this
sentence.]
 
>regardless of the location (or localisation settings) of the resolver, 
>the master server and any slave or caching servers involved. 
>
>IDN should also allow a caching server which does not understand the 
>charset in which a request (or response) is encoded to be 
build [BUILT?], and 
>which works as well for IDNs as in the ASCII-only case. 

[The caching
>server must perform[DELETE s] correctly if it gives the essentially the same
>answer as the master server would have done if presented with the same
>request (of course without the authoritative bit).]

[I suggest rewording the above bracketed section to:
The caching server must give essentially the same answer as does the master
server when presented with the same request (of course without the
authoritative bit set).-BS]

>
>If the IDN implementation specifies a canonicalisation algorithm then 
>a caching server should perform correctly regardless of how much (or 
>how little) of that algorithm it has implemented. 
>
>[Implementors may proposal modification to DNS protocol [RFC1035] and
>other related work undertaken by [DNSEXT] WG. However, these changes 
>should be as minimal as possible and it must be approved by the DNSEXT
>WG.]

[I would propose to delete the paragraph above and replace it with:

It is expected that changes to the DNS protocols [RFC1035 and others] will
be required in order to implement IDN -BS]. 

>
>The best solution is one that maintains 
[MAXIMUM FEASIBLE] [DELETE complete]  compatibility with 
>current DNS standards as long as it meets the other requirements in 
>this document. 
>
>2.2 Internationalization (I18N)

[In several places below, the phrase "character set" is used. Should these
instances be modified? - BS].

>
>Internationalized characters (I18C) must be allowed to be represented 
>and used in DNS names and records. Implementation must specify what 
>character set is used and how these characters are encoded in the 
>domain names and DNS records. 
>
>This document does not recommand any character set for I18N. However, 
[a] non-standard character set must not be used to avoid duplicate work 
>on general I18N. 

>If multiple character sets are used then the 
>implemention must specify all the character sets being used and for 
>what purpose.

[Why? I would delete the sentence above...-BS]


>IDN should not make any assumptions where in the domain name that I18N 
>might appear. In other words, it should not differentiate between any
>part of a domain name as it may impose a restrict on future I18N
>effort.

[I don't think I agree with the above sentence either. the whole mixed
charset argument...-BS]


>IDN should also not make any 
cultur[AL] [DELETE e] restrictions in the protocol.
>For example, an IDN implementation which only allows

[a] domain name to use a single script would immediately restrict
multinational 
>organisation. 

[I am a bit confused by the language above. This is  a technical standard,
not a cultural one, right? So what word instead of "culture" or "cultural"
would better achieve the intention of this sentence? My preference would be
to delete the whole sentence -BS]

>
>IDN must be able to handle localized requirement of different languages.
>For example, IDN must be able to handle right-to-left writing order of
>Arabic. 

[I do not agree with the above sentence - I think it has already been
discussed. Can we delete it?  -- BS]


>In addition, IDN must
>
>1. provide a record which can contain internationalised text 
>   (similar to TXT RR). [1 request to remove this as it is not IDN]
>
>--- need comments ---
>Must allow I18C in DNS queries.
>Must allow I18C in DNS RR response.
>Must allow I18C in DNS TXT records. 
>Must allow I18C in DNS CNAME records.
>Must allow I18C in DNS PTR records.
>---
[I would propose to delete everything above after 1. and rewrite it as
follows:

In addition, IDN must be able to provide the same DNS resources using
internationalized text as it currently provides using ASCII text. - BS]


>2.3 Canonicalization
>
>Matching rules are the most complicated process of I18N of domain 
>names. Canonicalization of characters must follow precise and 
>predictable rules to ensure consistency.
>
>In order to retain backward compatiblity, the implementation must 
>(should?) retain the case-insensitive comparsion for US-ASCII as 
>according to [RFC1035] Section 2.3.3.
>
>For example, Latin captial letter A (U+0041) must match Latin small 
>letter A (U+0061).
>
>If other canonicalization is done, then it
>1. must be done before the domain name is resolved.
>2. must be easily upgradable as new languages and writing systems
>   are added.
>
>[CHARREQ] is a recommanded as a guide on canonicalisation.
>
>Any conversion (case, ligature folding, punctuation folding, ...) from 
>what the user enters into a client to what the client asks for 
>resolution MUST be done identically on all requests.
>
>"Thus, it must be specified in the protocol, not in the requirements 
>document. The requirements document might list the kinds of conversions 
>we might expect, but should not mandate where the converstions happen."
>
>[JS: In this case, can i remove the rest of the section? Personally,
>I think this is one of the most troublesome part of IDN and if this
>is not cleared now in the requirement, we might get into a lot of 
>argument in future.]
>
>Case folding should also be used.
>
>For example, Latin captial A with a ring above (U+00C5) should match
>Latin small A with a ring above (U+00E5).
>
>[JS: This opens up cans of worms for context sensitive folding? What
>about CJK? How is the folding to be done?]
>
>On the other hand, similar glyphs given different codespace on a
>character set should be treated differently.
>
>For example, cyrillic A (U+0410) should not match to Latin A (U+0041).
>For example, Greek captial letter omicron (U+039F) should not match
>to Latin captial letter O (U+004F).
>
>2.4 Operational Issues
>
>Zone files should remain easily editable.
>
>Character set of a signed zone file should be capable of being the same
>as the character set of the unsigned zone file.
>
>IDN capable resolver or server should not generate any more traffic 
>than a non IDN capable resolver or server.

[I would delete the above sentence. It is impossible to quantify "any more
traffic" -- BS]

>
>IDN should add no new centralized administration for the DNS. A domain 
>administrator should be able to create internationalized names as 
>easily as adding current domain names. 
>
>IDN must allow offline DNSSEC signing. It should also be able to look
>at the signed file and see that it is the same as the unsigned one.
>
>2.5 Others
>
>The DNS protocol should remain deterministic. No DNS element (resolver,
>server or zonefile) should be required to do guess work. 

[I would delete the above. Unless clients, resolvers and servers all use a
single standard for the query, *something* will have to do guess work.
There are too many variables -- BS]

>
>3. Specific Requirements
>
>3.1 Client Requirements
>
>3.2 Server Requirements
>
>3.3 Zone file Requirements
>
>4. Technical Analysis
>
>There are many standard protocols and RFCs which 
[ARE] [DELETE is] dependent on the
>domain name and 
[DELETE have] make various 
assumption[s about] [delete on] its character set. 

>Therefore, any implementation must contain a summary of the 
>compatiblity issues and security 
consideration[S]

>with, but not limited 
>to, the following protocols:
>
><...list the sets of RFCs which we would like to have an summary...>
>
>In addition, the implementation document must contain a summary of the
>technical 

opinion[S] of the [members of the] -BS working group.
>
>5. Security Considerations
>
>Any solution that meets the requirements in this document must not 
>be less secure than the current DNS. Specifically, the mapping of 
>internationalized host names to and from IP addresses must have the 
>same characteristics as the mapping of today's host names.
>
>Specifying requirements for internationalized domain names does not 
>itself raise any new security issues. However, any change to the DNS 
>may affect the security of any protocol that relies on the DNS or on 
>DNS names. A thorough evaluation of those protocols for security 
>concerns will be needed when they are developed.
>
>References
>
>    [RFC2119]   "Key words for use in RFCs to Indicate Requirement 
>                Levels", rfc2119.txt, March 1997, S. Bradner.
>
>    [RFC1034]	"Domain Names - Concepts and Facilities", rfc1034.txt,
>                November 1987, P. Mockapetris
>
>    [RFC1035]   "Domain Names - Implementation and Specification", 
>                rfc1035.txt, November 1987, P. Mockapetris
>
>    [RFC1996]   "A Mechanism for Prompt Notification of Zone Changes
>                (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie
>
>    [CHARREQ]   "Requirements for string identity matching and String
>                Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
>                World Wide Web Consortium
>
>    [DNSEXT]    "IETF DNS Extensions Working Group", 
>                namedroppers@internic.net, Olafur Gudmundson, Randy Bush
>
>Author's Address
>
>
>Appendix A. Acknowledgements
>
>    The editor gratefully acknowledges the contributions of:
>
>    Harald Tveit Alvestrand <Harald@Alvestrand.no>
>    Martin Duerst <duerst@w3.org>
>    Patrik Faltstrom <paf@swip.net>
>    Andrew Draper <ADRAPER@altera.com>
>    Bill Manning <bmanning@ISI.EDU>
>    Paul Hoffman <phoffman@imc.org>
>    James Seng <jseng@pobox.org.sg>
>    Randy Bush <randy@psg.com>
>    Alan Barret <apb@cequrux.com>
>
>    as authors of corresponding sections and the contributions of:
>
>    for their useful comments.
>
>
>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.
>
>Acknowledgement
>
>    Funding for the RFC editor function is currently provided by the
>    Internet Society.
>