NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 02-Mar-00
James Seng <email@example.com>
Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
Internet Area Director(s):
Thomas Narten <firstname.lastname@example.org>
Erik Nordmark <email@example.com>
Internet Area Advisor:
Erik Nordmark <firstname.lastname@example.org>
To Subscribe: email@example.com
Description of Working Group:
John Klensin (firstname.lastname@example.org)
Harald Tveit Alvestrand (Harald@Alvestrand.no)
The goal of the group is to investigate and specify the requirements for internationalized access to domain names.
The scope of the group is to investigate the possible means of doing this and what methods are feasible given the technical impact they will have on the use of such names by humans as well as application programs, as well as the impact on other users and administrators of the domain name system.
A fundamental requirement in this work is to not disturb the current use and operation of the domain name system, and for the DNS to continue to allow any system anywhere to resolve any domain name.
The group will not address the question of what, if any, body should administer or control usage of names that use this functionality.
The Action Item(s) for the Working Group are
1. An Informational RFC specifying the requirements for providing Internationalized access to domain names. The document should provide guidance for development solutions to this problem, taking localized (e.g. writing order) and related operational issues into consideration.
2. An Informational RFC or RFC's documenting the various proposals and Implementations of Internationalization (i18n) of Domain Names. The document(s) should also provide a technical evaluation of the proposals by the Working Group.
Goals and Milestones:
First draft of the requirements document
First draft of the proposal document(s)
Presentation and discussion at IETF-Adelaide
Second version of the requirement document
Second version of proposal document(s)
IETF presentation and wg last call
Requirements and proposal(s) sent to IESG for publication as Informational
No Request For Comments
Reported by David R. Conrad.
- (bad news) marc blanchet, co-chair, send his regards for not able to attend the meeting because (good news :) of a new baby girl. congrat marc!
- mark andrews not here so he's been shifted \
- no other changes
Requirements from Japan - Yoshiro YONEYA
- requirements for IDN
- naturally readable and writable in its language context.
- ascii should be usable anywhere for backwards compatible should not depend on natural lang structure (e.g., word order, wrting order, etc.)
- common framework to make localization easy
- differences between characters should be local issue
- guidelines for localization should be documented in an rfc
- long labels should be supported in IDN
- IDN should have corresponding ascii domain name for backwards compatiblity
- reverse mapping should produce one or more ascii name
- idn character encoding should be stateless
- utf8 desired
- requirements for IDN implmentations
- internationalization should be solved in servers, localization in clients
- tools may use localized characters
- conversion and normalization should be done on client side
- use of proxy servers possible
- idn servers should be backwards compatible
- new rrs should be examined for language selector
- applications and resolvers should be 8bit clean
- transition tools should be prepared to reduce confusion
- two experimental implementations
- proxy dns server, accepts japanese converts to utf-5
- 8bit clean BIND, uses CNAME for multilingual lables
- see http://www.nic.ad.jp/en/research/idn/index.html
JK: if same query from two locals, you get two different answers for the same question?
YY: reverse can return multiple answers, normal lookup will return a single answer
BC: on page 5, is "language" really language, not script?
YY: guidelines for each language and scripts to deal with such
BC: need language tags as well as script tags
JS: is canonicallization and normalization per language, not just per script
BC: implies you need language tag somewhere
Requirements from Korea - KIM Kyongsok
1. code - ISO/IEC 10646, possibly with encoding/transformation
2. encoding - user interface/resolver/name server where should it be done?
3. process to finalize IDN document itemize and evaluate the requirements in a stepwise fashion
4. term of solutions
a) short term -- use 7 bit encoding
b) mid-range -- use 8-bit/UTF-8
c) long-range -- UCS without any transformation
which solution? side effects of 8-bit clean bind?
5. whether or not to create new TLDs put all internationalized domains under cctlds
6. use cname and/or dname to support IDN
7. root server management structure, tree or forest?
tree does not imply centralization of registration or administration
8. comments about IDN requirement docs
"legal" too strong
CES and charset should be clarified
caching server requirements need to be evaluated
support both ascii and ascii encoded solutions
after ces, ascii should be unchanged
what 'existing ces' means
folding cases unclear
canonicalization algorithm for caching server should be removed
centralized administration should be corrected
canonicalization and normalization should be clarified
signed and unsigned zonefiles should be clarified
internationalized host name and internationalized domain name
should be clarified
KC: on item 5. in Korea, expand ccTLDs but no consensus on new gTLDs.
RA: item 5 is outside of scope
JK: IETF may affect ICANN and vice versa
JS: outside of scope of this WG
BM: if you have a different encoding method then you create a new TLD
JK: not true
BM: close enough for IETF work
The big picture - Harald Alvestrand
- need to make sure we have right is terminology and basic architecture.
- when you do a dns query, there are a number of boxes involved in different roles, boxes or software.
- Interface A
- you have user who hits a key
- you have client software which takes keystroke and turns them into a dns query these are out of scope of the ietf
- Interface B
- when you have a dns query or want a response is the ietf
- which part of the picture are we happy with breaking?
- convergence on terms hostname and domain name
- the DNS service doesn't care about octets, except for case folding
- on top of DNS service, hostnames assign meanings to the octets in [a-zA-Z\-]
- on top of hostname service, other services such as email and web are built
- we are trying to extend hostname into idn hostname
- if we don't keep the layering, we screw up
- need to do modeling of use cases in the DNS
- need to write down which use cases we address and do something about
Internationalization of URLs - Larry Masinter
introducing an internet draft masinter-url (2 or 3 years old) for use of non-english in urls. has been in discussion since the early days (at least 5 years ago). has been a lot of analysis and possible
you can have a philosophical argument about whether it is a dns problem or a url problem. urls are most important application for this issue.
key insights: how to get around the compatibility dilemma, how to introduce change. as long as you think about changing existing protocol element, you have a problem. rather than changing, talk about introducing a new protocol and transitioning over time.
section 3 of the draft talks about different kinds of software elements for processing urls with their compatibiltiy and upgrade reuiqrements. they apply to hostnames as well as urls. talking about different elements at the same time leads to confusion
iurls and idns should be compatible, iurl syntax can be changed.
JS: reads part of the idn charter> so yes idn will have to take care of many protocols including iurl
RE: the problem that nees to be solved ins't in the DNS, rather is how the applications make use of the domain names. until you get a common understanding on how applications deal with idns, idns will be a waste of time.
JS: we're doing internationalized host names, not internationalized domain name system
Hostnames vs. Domain names - Mark Andrews
domain names can take any arbitrary binary value.
1-255 octets for a full domain name
domain name presentation format is printable ascii with no whitespace.
all non-printable characters are presented as decimal escapes (\DDD).
any character can be preceded by a \ to create a literal (to get \.
into a label)
- mailboxes: mark\.andrews.nominum.com
- service location records
- mail domains
- HESIOD databases
hostnames - a strict subset of domain names
what is legal: a-z, A-Z, 0-9, '-', and '.'
question: where does this restriction come from:
MA: 952 and 1123
BM: implementations do not enforce names
RE: 952 defines names in hosts.txt and has no other utility whatsoever
MA: 1123 says 952 defines hostnames
RE: but only for hosts.txt
JK: and in a large number of applications
JA: 1035 underspecified, but we really meant hostnames
service location defines a protocol and a transport in SRV records.
internationalized names shouldn't collide with service locations
mailboxes used to encode email addresses, not valid 822 format.
first label is the lefthand side of the '@'. idn should look at
internationalizing the first label. we don't want to overly restrict
RA: in security community, ipsec uses mailbox format
JK: this definition is exactly right, where is \. in the first label standardized
JK: this was removed in 1123
JA: no, it wasn't
mail domains have same syntax as hostnames
hostnames are embedded in other domain names
Rquirements document - James Seng
- must, must not, etc. same as 2119
- idn really means internationalized host names, will be fixed in future drafts
- examples use unicode form, not implying we use unicode -- want any/all proposals
- need more and clarify -- will expand this section
- general requirements
- distinction between internationalized domain name and an internet
- internationalized domain to take into account the purely internal uses of domain names
- idn is enhancement not modification
- same request must generate the same response
- idns must be universal
- some proposals will have trouble with this.
- 1034 and 1035 may be modified, but we hope we don't have to.
EL: not a requirement that you change 1034 or 1035
HA: you can see it as a negative requirement
BC: the issue is practical operation and backwards compatibility, not twiddling an RFC
JS: most important is network compatibility
- fallback strategy is a short term solution
- best solution is one that is backwards compatible.
- should not create a new CCS
- need to rephrase paragraph on us-ascii
- we should not assume a domain name should be in only one language
- we don't touch the user interface
- what glyph should be the '.'?
- don't touch the user interface
- use unicode as the reference
- us ascii is folded as normal, but haven't discussed other language/scripts in completion.
- canonicalization rules must be applies, but what hasn't been decided how should caching servers respond
- is canonicalization on domain names or host names?
- operational issues
- zone file should remain easily editable
- is utf8 easily editable? need better definition of editable
- we don't want to break the internet
- idn server shouldn't generate more traffic, what is definition of more
- don't want to create a new centralized administration
- idns must deal with dnssec
- dnames might be useful
- dns provides stuff other than A and PTR records
- you may need to upgrade your software
- may cause problems for other protocols
SB: worried about compatibility, most machines are not upgraded. need compatibility mechanism.
JS: agree. is fallback strategy practical
SB: need something that works better -- looking at 8 year deployment optimistically
AL: dns mixes two layers mapping identifiers and a form of directory service. idn can't solve the problem since it only looks at one layer. mammilian brain needs to be layered on top of reptilian brain. add another layer of indirection.
JS: we are doing idn not idnsystem
HA: it is entirely possible that this can't work
JK: 8 years is optimistic for deployment
RA: 40% of the DNS is still in BINDv4
JK: worries we're looking for requirements for a system so over constrained that there is no solution space, e.g., can't spend more time in doing a lookup. Looking at who will get hurt. If you don't do this, you get contradictory requirements
KM: assumption there is a conversion mechanism between old and new systems, doesn't believe this to be the case. many interfaces are not defined so negotiation cannot be performed. moving to 8bit smtp is an example.
JS: some nameservers must be upgraded. how do we maintain backwards compatibility
KM: servers are irrelevant, the problem is in the user and client interfaces.
LM: adding another layer of indirection is addressed in CNRP
EL: if making more queries are required, you could have strange effects, e.g., if you're doing call set up, you're delaying call set up. Conflicts in document must be resolved. First requirement could be simplified to "must be handled at the presentation layer". We have experience in extended smtp in this area. If you keep the core DNS the same, you'll get faster deployment
JK: there is an awful lot of garbage out there and people are dependent on it. you can make a decsion to break the garbage, but it has serious implications. global ecommerce will not work in a country that deploys something that breaks the rest of the world.
BS: there is a country that is implementing idns -- china. other countries are implementing solutions. microsoft has shipped win2k that does idn. there will be a bof to form a multinational idn consortium to help move the process forward.
Implementation Document(s) - Paul Hoffman
not given do to lack of time.
JK - John Klensin
YY - Yoshiro Yoneya
BC - Brian Carpenter
JS - James Seng
KC - Kilnam Chon
RA - Ran Atkinson
HA - Harald Alvestrand
JA - Joshua Auerbach
BM - Bill Manning
RE - Robert Elz
MA - Mark Andrews
EL - Eliot Lear
SB - Steve Belovin
AL - Albert Langer
KM - Keith Mitchell
BS - Bill Semich
Boxes involved in DNS
Requirements for IDN and its Implementations from Japan
Domain and Host Names
Boxes involved in DNS