Reported by David R. Conrad. Agenda Bashing -------------- - (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 ---------------------------------------- - scope - requirements for IDN o naturally readable and writable in its language context. o ascii should be usable anywhere for backwards compatible should not depend on natural lang structure (e.g., word order, wrting order, etc.) o common framework to make localization easy + differences between characters should be local issue o guidelines for localization should be documented in an rfc o long labels should be supported in IDN o IDN should have corresponding ascii domain name for backwards compatiblity o reverse mapping should produce one or more ascii name o idn character encoding should be stateless + utf8 desired - requirements for IDN implmentations o internationalization should be solved in servers, localization in clients + tools may use localized characters o conversion and normalization should be done on client side + use of proxy servers possible o idn servers should be backwards compatible o new rrs should be examined for language selector o applications and resolvers should be 8bit clean o transition tools should be prepared to reduce confusion - two experimental implementations o idnx/idnx-jp + proxy dns server, accepts japanese converts to utf-5 o gdns + 8bit clean BIND, uses CNAME for multilingual lables o see http://www.nic.ad.jp/en/research/idn/index.html - questions 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 langauge 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 - questions 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 o you have user who hits a key o you have client software which takes keystroke and turns them into a dns query these are out of scope of the ietf - Interface B o when you have a dns query or want a response is the ietf o which part of the picture are we happy with breaking? - convergence on terms hostname and domain name o the DNS service doesn't care about octets, except for case folding o on top of DNS service, hostnames assign meanings to the octets in [a-zA-Z\-] o 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 - questions none. 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 solutions 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. - questions 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) uses: - hostnames - 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 local component. RA: in security community, ipsec uses mailbox format JK: this definition is exactly right, where is \. in the first label standardized MA: 1035 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 questions: none. Rquirements document - James Seng --------------------------------- - defintions: o must, must not, etc. same as 2119 o idn really means internationalized host names, will be fixed in future drafts o examples use unicode form, not implying we use unicode -- want any/all proposals o need more and clarify -- will expand this section - general requirements o distinction between internationalized domain name and an internet o internationalized domain to take into account the purely internal uses of domain names o idn is enhancement not modification o same request must generate the same response + idns must be universal + some proposals will have trouble with this. o 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 twidling an RFC JS: most important is network compatibility o fallback strategy is a short term solution o best solution is one that is backwards compatible. - internationalization o should not create a new CCS o need to rephrase paragraph on us-ascii o we should not assume a domain name should be in only one language o we don't touch the user interface - localization o what glyph should be the '.'? o don't touch the user interface - canonicalization o use unicode as the reference o us ascii is folded as normal, but haven't discussed other language/scripts in completion. o canonicalization rules must be applies, but what hasn't been decided how should caching servers respond o is canonicalization on domain names or host names? - operational issues o zone file should remain easily editable + is utf8 easily editable? need better definition of editable o we don't want to break the internet + idn server shouldn't generate more traffic, what is definition of more o don't want to create a new centralized administration o idns must deal with dnssec o dnames might be useful - others o dns provides stuff other than A and PTR records o you may need to upgrade your software - security o may cause problems for other protocols questions: 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. Contributors ------------ 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