alpha draft requirement

[James Seng <jseng@POBOX.ORG.SG>]

Ok, I basically go thru all the emails exchanged so far, pull out comments
from people which is related to the requirements of idn and sort them out. It
is very very rough and further editing and lots of work need to be done. But
at least, it is something we can work by.

I dont think we are even 10% close to what the final requirement looks like.
Thinking how to structure such a document in itself is a headache...

-James Seng

--- CUT HERE ---
               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 .

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 [RFC2119].

    "I18C" is oftenly used in this document to refer to internationlized 
    characters or non English characters.

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 Backwards compatibility

The DNS is essential to the entire Internet. Therefore, implementation
of idn must not damage present DNS interoperability. It must (should?)
do minimum amount of changes to existing protocols on all layers of the
stack. It must continue to allow any system anywhere to resolves any
domain names.

The same request should generate the same response, regardless of the
location (or localisation settings) of the resolver, the master server
and any slave or caching servers involved.

It should be possible to build a caching server which does not understand
the language set in which a request (or response) is encoded, and which 
works as well for IDNs as in the ASCII-only case.

[JS: These are still too vague. We need clearer defination of what is 
meant by backwards compatibility. Can the implementors modify RFC1035?
Or how about work done by DNSEXT? Or how about proposing new RR, new
RCODE etc?]

2.2 Internationalization (I18N)

Internationalized characters must be allowed to be represented and used 
in DNS names and records. Implementation must specify what character 
sets are used and how these characters are encoded in the DNS names
and records. 

This document does not define any character sets that should be used
for I18N. However, non-standard character sets must not be used to 
avoid duplicate work on general I18N. If multiple character sets are
used, they must be clearly identified. 

The DNS protocol should remain deterministic. No DNS element (resolver,
network, server or zonefile) should be required to do guess work. 

Implementation of idn should not make any assumptions about where in the
host name that I18N might appear.
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 allw I18C in DNS PTR records.>
[JS: We are getting to specific here no?]

I18N of domain names should be able to handle mix language characters
and script, within the same label and/or within the same FQDN. 
[JS: I hear at least one strong objections to this]

2.3 Matching and comparsion

Matching rules are the most complicated process of I18N of domain 
names. Strict rules are neccessary to ensure consistency in results.

"For all parts of the DNS that are part of the official protocol, all
comparisons between character strings are done in a case-insensitive
manner." from RFC1035 Section 2.3.3. This principle must be retain 
for US-ASCII.

For example, Latin captial letter A (U+0041) must match Latin small 
letter A (U+0061).

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).

If a canonicalisation algorithm is proposed, the algorithm must be
easily upgradable as new languages/writing systems are added.

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 should not generate any more traffic than a non
IDN capable resolver.

3. Specific Requirements

3.1 Client Requirements

3.2 Server Requirements

3.3 Zone file Requirements

4. Compatibility

Total compatibility with all existing standards and software which is 
related to domain names cannot be achieved. More realistically is to 
specify how many standards and software the implementation of idn is
going to break.

"Each one of these protocols have to be reviewed and updated given the result
of this wg. I would like to say that starting with DNS, and then go through
the protocols."

5. Security Considerations

    This memo raises no security issues;

References

    [RFC2119]   "Key words for use in RFCs to Indicate Requirement 
                Levels", rfc2119.txt, March 1997, S. Bradner.

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>

    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.