[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
alpha draft requirement
- To: idn@ops.ietf.org
- Subject: alpha draft requirement
- From: James Seng <jseng@POBOX.ORG.SG>
- Date: Tue, 11 Jan 2000 18:07:17 +0800
- Delivery-date: Tue, 11 Jan 2000 22:20:20 -0800
- Envelope-to: idn-data@psg.com
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.