RE: [registrars] IESG Statement on IDN (fwd)

[Rick Wesson <wessorh@ar.com>]

Michael,

Is that the Alexa Raad from CyberCash fame? Isn't She is the IDN product
manager? couldn't we get someone more technical? I don't think she goes to
the IETF or has participated in the community in the development of IDN.

If you want to make it more IETF like, invite somone who isn't going to
market to us...

In your search for meeting materials links to relivant EU delicarations
would be of benifit.

-rick

On Tue, 11 Feb 2003, Michael D. Palage wrote:

> With regard to the IDN discussion next week, I received a couple of
> inquiries from European registrars last week to invite Alexa Raad from
> VeriSign to our meeting. In an attempt to make our meetings more IETF
> oriented (no surprises) Alexa will be providing some material for registrars
> early next week for us to review prior to our meeting. In fact I am trying
> to get material for all of the topics available to members prior to the
> meeting to expediate discussions.
>
>
> > -----Original Message-----
> > From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> > Behalf Of Rick Wesson
> > Sent: Tuesday, February 11, 2003 9:38 PM
> > To: Registrars List
> > Subject: [registrars] IESG Statement on IDN (fwd)
> >
> >
> >
> >
> > FYI
> >
> > The latest statement from the IESG on IDN is below.
> >
> > Do registrars have any interest in developing a formal position on IDN and
> > it deployment/use? We will have some time devoted to IDN in DC so please
> > bring or develop your positions with you next week.
> >
> > best,
> >
> >
> > -rick
> >
> >
> > ---------- Forwarded message ----------
> > Date: Tue, 11 Feb 2003 21:04:10 -0500
> > From: The IESG <iesg-secretary@ietf.org>
> > To: IETF-Announce:  ;
> > Subject: IESG Statement on IDN
> >
> >
> >
> > IESG Statement on IDN:
> >
> >  IDNA [IDNA] specifies an encoding of characters in the Unicode
> >  character repertoire [UNICODE] which is backwards-compatible with the
> >  current definition of hostnames. This implies that domain names
> >  encoded according to IDNA will be able to be transported between
> >  peers using any existing protocol, including DNS.
> >
> >  IDNA, through its requirement of Nameprep [NAMEPREP], uses equivalence
> >  tables that are based only on the characters themselves; no attention
> >  is paid to the intended language (if any) for the domain name. However,
> >  for many domain names, the intended language of one or more parts of
> >  the domain name actually does matter to the users.
> >
> >  Similarly, many names cannot be presented and used without ambiguity
> >  unless the scripts to which their characters belong are known. In both
> >  cases, this additional information should be of concern to the registry.
> >
> >  If there are no constraints on registration in a zone, people can
> >  register combinations of characters in a manner that increases the
> >  risk of misunderstandings, cybersquatting, and other forms of
> >  confusion. A somewhat similar situation existed before the introduction
> >  of IDNA exemplified by domain names such as example.com and examp1e.com
> >  (note that the latter domain has the digit "1" instead of the letter
> >  "L").
> >
> >  For some human languages, there are strings of characters that have
> >  equivalent or near-equivalent meanings. When someone registers a name
> >  containing such a string, the registry might want to automatically
> >  generate a list of semantically or visually equivalent strings and
> >  suggest that they also be registered. Further, some registries might
> >  want to prevent particular characters for language-based reasons.
> >
> >  Some registries, in particular the gTLD ones, are not naturally part
> >  of any specific language group. In these cases, extra care must be
> >  taken not to create unacceptable problems for any of the languages that
> >  might be used.
> >
> >  It is suggested that a registry act conservatively when starting to
> >  accept IDNA-based domain names. Equivalences are very hard (if not
> >  impossible) to define after registration has started. Assume that the
> >  labels "x" and "y" at first are different, but later the tables for the
> >  registry are changed so that "x" and "y" are then treated as being the
> >  same. If x.example.com and y.example.com both were already registered
> >  to different registrants, it is unclear which of them has to withdraw
> >  the registration, how that selection process done, and so on. Thus,
> >  having complete, publicly-stated policies before accepting
> >  registration will lead to a much more stable registration process.
> >
> >  There are also other problems that we know to be difficult when
> >  dealing with IDNA-based domain names, for instance when to convert them
> >  between their display format and their wire format, how to deal with
> >  display formats on systems that do not support all of Unicode 3.2, and
> >  how to deal with the problem of domain names in one format showing up
> >  where names in the other format was expected by protocols or by people.
> >  These problems are largely outside the scope of the IDNA standards
> >  themselves, but they are of concern to anyone attempting to implement
> >  the IDNA standard in products. See the IDNA specification for more
> >  examples.
> >
> >  The use of display-format IDNA-based domain names in other protocols
> >  is not yet part of any standard; implementors are admonished to use
> >  the wire format, i.e. ASCII-encoded, of the name until protocol
> >  updates allowing the use of display format, e.g. Unicode-based
> >  international character/glyph, are standardized.
> >
> >  [IDNA] "Internationalizing Domain Names in Applications (IDNA)",
> >  draft-ietf-idn-idna.
> >
> >  [NAMEPREP] "Nameprep: A Stringprep Profile for Internationalized Domain
> >  Names", draft-ietf-idn-nameprep.
> >
> >  [UNICODE] The Unicode Consortium. The Unicode Standard, Version 3.2.0
> >  is defined by The Unicode Standard, Version 3.0 (Reading, MA,
> >  Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode
> >  Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/)
> >  and by the Unicode Standard Annex #28: Unicode 3.2
> >  (http://www.unicode.org/reports/tr28/).
> >
>