[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Minutes of IDN WG at IETF47
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