Subject: Re: [idn] Document Status?

From: John C Klensin <[email-masked]>
Date: Sun, 01 Sep 2002 00:28:27 -0400

The rarity of Dave's and my agreeing is again noted for the
record.  Lest we get too carried away by it, one observation
below.

--On Saturday, August 31, 2002 10:13 AM -0700 Dave Crocker
<[email-masked]> wrote:

>...
> Personally, I believe that publishing as Experimental is
> unnecessary and that it would be disastrous.
> 
> Experimental makes sense when a technology is not well
> understood.  That is not the problem, here.  The problem,
> here, about making difficult decisions, not about
> understanding them.
>...

Well, I think there is a problem that may border on
understanding, and it is tied up with my major personal
objection to the general style of the work that has come out of
the WG.  I believe that IDNA (and the supporting documents) are,
with the exceptions and qualifications Dave and I are pushing
on, a reasonably well-understood solution to _some_ problem.
I'm not sure I know what that problem is, who cares about it,
and whether it is important enough to justify changes to the way
the DNS works and is interpreted.  Re those changes, we can
debate how significant they will be, and there are differences
of opinion about who will be impacted and how much pain they
will feel, but I think it is relatively certain that the pain
level will be non-zero.

This is not a joke.  I know that the IDNA approach, with
adequate definition of the characters to be used, will permit
internationalization of low-level identifiers.  If that is all
we care about, then there is a case to be made that it is
actually more mechanism than is needed: if the same constrained
processes are to be used to access a name that cause it to be
created, than the subtle issues of character matching for
different codepoints may not be relevant.  By contrast, it is
clear that the WG has not solved (Dave would, I think, say that
it has no scope or charter to even examine) the set of questions
associated with accurate transcription of DNS names from other
environments and media.  It is equally clear that many people
are focused on that problem and won't consider any "DNS
internationalization" problem to be solved unless it has some
adequate resolution.

So I would [still] like to see a clear statement about what
problem the IDN WG's solution solves.

> The Internet needs workable IDN now.  (Actually, it needed it
> a few years ago.)  So, we need to make the difficult
> decisions, to make IDN workable.  And we need to publish as
> Proposed.

I agree with this in principle.  I will agree in practice as
soon as someone tells me what "workable IDN" means, in precise
language, so that goal and the IDN WG solutions can be compared.
I'm sure that answer is clear to many of you, but it is not
clear in the documents -- to a greater or lesser degree, they
describe how to do something, but not, at a abstract level, why
one would want to do it--  and it is not clear to me (and I have
tried, very hard, to understand it).

    john

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 1 Sep 2002 05:24:01 +0000

"JFC (Jefsey) Morfin" <[email-masked]> wrote:

> 1. would it not be a good occasion of getting rid of the odd phrase
> about domain/host names and to introduce a stable wording such as
> "internet name" and "international internet names" or "multilingual
> internet names" which corresponds to the compromise we actually use?

Various people have had various discussions trying to come to a common
understanding of the precise meanings of "domain name" versus "host
name", with very little success.  Just about the only thing everyone
agrees on is that every host name is a domain name, but some domain
names might not be host names.  Settling this type-of-names issue is
beyond the scope and ability of this working group.  IDNA is a mechanism
for allowing non-ASCII characters to be used in domain names, whatever
those might be.  Internationalized domain names can be used wherever
domain names can be used, wherever that might be, except in non-IN
class DNS resource records (this exclusion is stated in the forthcoming
idna-11 draft).

> - I am concerned about using a concept (international) for another
> (multilingual) when the international concept may become another issue
> with national DNS views.

I don't know exactly what the difference is between internationalization
and multilingualization.  I think one reason the latter term was
not used is that domain names have no language tag.  Maybe there
were other reasons, or maybe it was arbitrary.

> 2.  I am confused about the implications of the proposed change of
> part 7.

Are you referring to the first paragraph of section 7?  The change
between idna-09 and idna-10 was a failed attempt at clarification.  The
forthcoming idna-11 rewords that paragraph as:

    Existing DNS servers do not know the IDNA rules for handling
    non-ASCII forms of IDNs, and therefore need to be shielded from
    them.  All existing channels through which names can enter a DNS
    server database (for example, master files [STD13] and DNS update
    messages [RFC2136]) are IDN-unaware because they predate IDNA, and
    therefore requirement 2 of section 3.1 of this document provides the
    needed shielding, by ensuring that internationalized domain names
    entering DNS server databases through such channels have already
    been converted to their equivalent ASCII forms.

Does that help?

> Could we not just define a "DNS character set" (as "0-9 a-Z -."       
> today) and say that it can extend with DNS specifications.            

The DNS standard (RFCs 1034 and 1035) has already defined the DNS
character set to be US-ASCII.  (It allows all octets 0..255, but the
character set is ASCII; the standard assigns no interpretation to octets
128..255.)

> 3. is "IESG--" meant to stay, or is it temporary?

The draft says:

    [[ Note to the IESG and Internet Draft readers: The two uses of the
    string "IESG--" below are to be changed at time of publication to a
    prefix which fulfills the requirements in the first paragraph.  IANA
    will assign this value. ]]

    The ACE prefix, used in the conversion operations (section 4), is
    two alphanumeric ASCII characters followed by two hyphen-minuses.

Does that answer your question?  If not, I must not understand your
question.

AMC

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 01 Sep 2002 14:40:04 +0200

Thank you for your responses.

 > On 07:24 01/09/02, Adam M. Costello said:
 > beyond the scope and ability of this working group.

This is my point. As you say IDNA is only a mechanism. It may apply to any 
semantic made of labels linked by dots. I also feel there are several 
issues related to the specific use of the names. In removing references to 
the usage of the names, we would have a stable universal system. Special 
adaptations for particular uses, if there are some, would be understood as 
particular cases. Would this not be more logical and easier to maintain?

 > were other reasons, or maybe it was arbitrary.

 From my understanding one of the issue is about real life typographies 
(language oriented).

I am in the Eurolinc bootstrap (European languages as Minc and Ainc). 
Impossible to make anyone understand that we care both about the 
"international" .eu domain names (ie supporting accents, etc..) and about 
"multilingual" .eu sites (ie presenting the same information in different 
languages)

We asked a small set of 30 people (gov, university, press, managers, 
France, Africa, Europe). Most understood International domain names as 
".eu" domain names (vs national ccTLDs ones). All of them qualified what we 
name "international domain names" as multilingual or "natural language". 
All said the current domain names were "international" since they could be 
internationally used on International keyboards. All said : ICANN is 
International,  so are International "ICANN Domain Names".

We plan to run a general questionnaire on domain name issues all over 
Europe this falls. We may add that question?  The most asked question was 
"I have a .fr name without accent, will AFNIC bundle the natural French 
accentuated name as a comprehensive package?".

1/ when asked about the IETF process two linguists responded 
"naturalization" for transforming "international" names into local language 
names, and "globalization" or "internationalization" when transforming 
local language names into ASCII Names.

2/ The "International domain name issues" are more easily understood as 
international naming issues vs domestic access control. Examples: Viet-Nam 
domestic/international views, French Justice vs Yahoo, Judge Garzon in 
Spain. Two said that an International domain name was a name the local Gov 
would warranty against international pressure (like an "off-shore" domain 
name).

3/ when explained about current terminology, most found it confusing. Two 
said they felt hurt because it was negative discrimination against "non US 
speaking users".

Most probably worth to consider. IMHO multilingual Internet names support 
is what we talk about. But you are better English speaker than me.

 > forthcoming idna-11 rewords that paragraph as:

yes.

 >    been converted to their equivalent ASCII forms.

I suppose it does. But is it that complex? One year from now most will ask 
themselves about "existing": are there changes? Also about "channels": are 
there other ways to enter the DNS?

Also, does that means that sometimes the DNS is going to become 
Unicode?  The impact on automation via Internet may be very negative as it 
introduces possible instablity, "layer violation" (cf. Leissig) leading to 
an over complexity in the mechanical interface.

 > character set is ASCII; the standard assigns no interpretation to octets

OK. Poor wording of mine. I meant "DNS names character set", or any more 
adequate wording than my Frenglish, to tell "the characters authorized in 
ASCII domain names, at any given time".

 > Does that answer your question?  If not, I must not understand your

Yes, it does. Thank you.
jfc

---

From: "vinton g. cerf" <[email-masked]>
Date: Sun, 01 Sep 2002 08:53:59 -0400

One working definition of internationalization is that the encoding/expression is "understood" by speakers of all languages. There is global agreement, I believe, that block Latin characters can be used by anyone in any country to express the name of a destination country in a postal address. So for example "UNITED STATES" or "FRANCE" or "AUSTRALIA", "JAPAN", "VIETNAM" are all considered acceptable in every country. This agreement allows, for example, that the destination address, except for the name of the country, can be rendered in a language local to the target country and does not have to be understood by the postal service in the originating country. Consequently, someone sending a letter from the US to a recipient in Vietnam can write the destination address in Vietnamese and the US postal service need only understand the characters "VIETNAM" at the bottom of the destination address.

Multilingualization is more focused on what is sometimes called "localization" - that is, the characters used in rendering a local language can be used (e.g. for domain names or for filling out forms etc) and these renderings need not be universally understood.

This definitional distinction helps (me anyway) to appreciate that the creation of multilingual domain names may not necessarily contribute to universal ability to use the resulting strings because it may be difficult to impossible to render or enter arbitrary character sets at the user interface to a local service. We have collectively probably created some confusion for ourselves by using the term "internationalized domain names" to cover both concepts. It strikes me that the IDNA documents are more aimed at localization/multilingualization than internationalization, using the "definition" in the first paragraph above. 

Concerns about how cut/paste will work are germane to the discussion about the utility of IDNs because such actions may be the ONLY way in which someone may be able to enter special character strings into text intended to represent an IDN. Something like this happens to me regularly as I compose email to friends whose names involve the use of characters with various accent markings. Since I don't know how to enter these from my simple ASCII keyboard, I usually end up cutting and pasting the characters. This works because the text of email is permitted to be pretty general in its encoding. I don't know how that would work out if I were dealing with non-Latin character sets. I know I would need special software to render Hangul or Kanji, for instance, but I assume that the rendering packages also serve to make highlighting and cut/paste work. 

One of the important questions that I sense is being asked in the discussion of IDNA is just how applications that encounter these encoded objects/strings should handle them, particularly if the intent is to allow cut/paste to insert these encodings into places where domain names are expected to appear. Precision in the specification and elimination of ambiguity seems essential to assure interworking of the many software pieces that need to interwork for the whole scheme to be "universally" beneficial.

I hope I haven't done any damage to all the concepts expressed in the long debate about IDNA - but I am sure that people more knowledgable than I will set me straight if this message contains serious misunderstandings.

Vint Cerf

>were other reasons, or maybe it was arbitrary.

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 01 Sep 2002 18:03:00 +0200

--On 2002-09-01 08.53 -0400 "vinton g. cerf" <[email-masked]> wrote:

> I know I would need special software to render Hangul or Kanji, for
> instance, but I assume that the rendering packages also serve to make
> highlighting and cut/paste work.

The copy and paste problem is difficult, but not so hard as people belive
(I think).

I know how copy and paste work on the Apple Macintosh platform, and as that
has been around and worked that way for decades(!) I take for granted it
works the same way in for example Windows.

When doing "copy", the software "sending" the copied information identifies
the selection and calls a routine which notifies the operating system that
data exists in the paste buffer. The information passed include information
like what type(s) the data can be fetched as, the size(s) etc. Note that
several alternatives can be stored there.

It looks like the content-type mechanism in email. Very precise tagging of
the data.

Now, some other application have a menu which is to be drawn. The menu
includes an item called "paste". Before doing the actual drawing, it calls
a routine to check (a) if there is something in the paste buffer, and (b)
if the data is of a type which it can interpret. If both are true, the menu
item "paste" is _not_ shadowed.

The paste operation happens, and it can either grab data which is already
generated by the sender application, or the sender application is called
and asked to produce the data which is to be sent. The receiving
application gets a pointer (handle) referencing the data.

Similar things happens with drag & drop.

Ok, the important thing is the tagged data. We are _not_ talking about
plain bits which are arbitrary from arbitrary scripts etc.

I see we now have a cople of different scenarios:

(a) I get an email with IDNA encoded sender address. I want to add that to
some address book software. That imply copy and paste from email program to
address book program. The email address have ACE encoded labels in them.

(a1) The email program understand IDNA, but not the address book program.
As it understands IDNA, it will display (if the script and font exists) the
correct Unicode characters, and not the ACE encoded string. Now, the copy
operation happens, and I would if I were the email programmer put two (2)
things in the paste buffer: One "email address" which is the ACE encoded
string. Same thing as what is passed in SMTP or POP. One which is the
address in Unicode (or local script, which will be named as part of the
tag). The addressbook which fetches data from the paste buffer gets the
string, and notice it is ace encoded, and can choose to decode that if it
can/know etc.

(a2) The email program does not understand IDNA. It will only see the ACE
encoded string, and  will just like today place the ACE encoded string into
the paste buffer. See (a1) for rest of story.

(b) I can type some weird codepoints in my email application, but the
address book can not handle it. Also in this case the safest way of moving
forward is to place the ACE encoded string in the paste buffer.

So, in both cases, I compare the paste buffer with a random protocol which
according to the IDNA spec should have domain names encoded in ACE, if not
negotiation can take place. In some cases the negotiation can happen in the
protocol, and the same way negotiation _can_ happen in the copy/paste
buffer because of the tagging.

My conclusion after working on these things for a while is that I still
don't think we have any problem at all as long as the domain name is stored
as bits.

Only issue are applications which don't understand IDNA, but one can enter
non-ascii characters in labels, something which should not be possible if
the application was working according to the RFC's.

Problem is when changing bits to sound or ink and then back to bits again.

   paf

---

From: Stephen Dyer <[email-masked]>
Date: Sun, 01 Sep 2002 18:34:34 +0100

At 00:28 01/09/2002 -0400, John C Klensin wrote:

>the WG.

Dear John & All,

I have followed this group with interest and often mystification. It 
appears that members of the group have widely different understandings of 
the scope and objective. The multi-lingual and cross-cultural aspects have 
exacerbated this situation.

(I do not blame or criticise the IDN group - it's not their fault if the 
initial question is wrong, and they were asked to look at a narrow 
technical aspect of a much wider problem.)

My "view from the hill" is that overall we want to get to a position where 
the Internet can be comfortably and reliably used by the users of different 
character sets and languages.

That simply expressed goal is a long way off, but we have at our disposal a 
set of possible technologies and protocols. It seems to me that IDN has 
been a process of trying to rationalise these with the character sets and 
produce a single, fully inter-operable answer.

I think we need an additional process - a plan for evolving 
internationalization over an extended period. There is however a need for 
some visible progress here because the current hegemony of the English 
language and character set is divisive.

Firstly, I believe we should examine a process that deploys quickly the 
fullest possible range of 8-bit ascii characters.
Many of these, especially accented characters, were sidelined by us Anglos 
or unnecessarily hi-jacked by operating systems (especially by Unix). This 
is a quick fix, but will give great benefits to the populations of Western 
Europe, South America, much of Africa and ex-colonies of Western 
"Imperialist" nations in general.

Even this short-term action will cause considerable pain and is not 
immediate, requiring work on emailers, proxies and some databases etc. It 
is in my judgement a worthwhile action which does not detrimentally impact 
the wider problem.

(I am sure someone will point out that this won't work because the Swedish 
"Foo" maps to the Lithuanian "Bar" but this is mere sophistry because these 
sort of confusions exist already between and within many character sets and 
languages and we humans cope with them - we have to.)

Secondly we need to start a process which ends up with the deployment of a 
Unicode-like system across all Internet addressing systems. This is the 
nearest thing to the work of the current IDN group. I believe it is a 
mammoth task that will require phasing. It may also suffer from 
considerable political interference.

Thirdly, and most importantly we need to address how the Internet is used 
by the users. A Korean who speaks only Korean and types only Korean wants 
answers in Korean. This simplifies the IDN problem (for a uni-lingual 
Korean) hugely. What he requires is not necessarily a fully-functional 
internationalised DNS that he can access directly. He needs a very clever 
search engine which understands his linguistic abilities and the languages 
in which web-sites, files etc are written.

We probably need a new generation of search engines which lie above and 
alongside DNS. They can drive the DNS system, (extended or not) as the 
addressing system it was always meant to be and can handle many of the 
"linguistic intersect" problems locally where they can be addressed, and 
where they are not so significant.

A more user-oriented approach may give a less universal but more 
implementable solution and make the Internet available to billions. The 
alternative may be that they start to set up alternative language 
Internets. This may be politically attractive to some régimes but damaging 
to our vision of a universal Internet.

Regards

Steve Dyer

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 01 Sep 2002 19:42:50 +0200

> string, and notice it is ace encoded, and can choose to decode that if it

At least in X11 cut'n'paste works by transfering charset tagged but
otherwise opaque character arrays.  What you are proposing seem to
require a cut'n'paste protocol to be implemented in both the MUA and
the address book application.  The protocol must specify how the
structure containing the raw string and the ACE encoded string is
encoded and identified by both applications.  Will IDNA define this
protocol for X11, MacOS, Windows etc?

Assuming IDNA will limit itself to not require modifications to
cut'n'paste operations in various operating systems, you will only be
able to cut'n'paste charset tagged but opaque text strings.  If the
strings are to be ACE encoded or raw encoded is not specified anywhere
as far as I can tell, and different implementations will chose
different strategies.  If the application is running in a Unicode
environment, it might (only might!) make sense to transfer the raw
Unicode encoding, but if it is running in a non-Unicode environment
the IDNA specification leaves you in the cold as for how to implement
anything.  The result won't be pleasing.

In general, cut'n'paste of IDNA in the real world is not well defined,
since IDNA only solves the IDNA problem for Unicode, and the real
world isn't running Unicode everywhere.  Even if you dodge that
problem, there are other issues (like whether to send raw or ACE
encoded data).  IMHO, let's limit the scope of IDNA to exclude the
cut'n'paste problem because there are dragons there.

> forward is to place the ACE encoded string in the paste buffer.

There are other scenarios as well.

(c) The email address was located in the message body, and thus not
    ACE encoded.  If the message body was non-Unicode, see (d) for the
    rest of the story, if the message body was Unicode, it is not
    clear which application, or if at all, will ACE encode it, and you
    have the situation in (a) again.

(d) Email program understands IDNA but is running in a non-Unicode
    environment.  The address is tagged and is transfered to address
    book application using e.g. ISO-8859-1.  IDNA doesn't handle or
    care about this scenario, but it do exists in the real world
    (e.g. my machine).

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 01 Sep 2002 18:07:50 +0200

On 14:53 01/09/02, vinton g. cerf said:
>One working definition of internationalization is that the 
>encoding/expression is "understood" by speakers of all languages. There is 
>global agreement, I believe, that block Latin characters can be used by 
>anyone in any country to express the name of a destination country in a 
>postal address. So for example "UNITED STATES" or "FRANCE" or "AUSTRALIA", 
>"JAPAN", "VIETNAM" are all considered acceptable in every country. This 
>agreement allows, for example, that the destination address, except for 
>the name of the country, can be rendered in a language local to the target 
>country and does not have to be understood by the postal service in the 
>originating country. Consequently, someone sending a letter from the US to 
>a recipient in Vietnam can write the destination address in Vietnamese and 
>the US postal service need only understand the characters "VIETNAM" at the 
>bottom of the destination address.

Absolutely correct. This is what is used as a default international set by 
common sense,  postal agreements and EDI. You may note that this is also 
the way international mnemonics work (JFK, CDG, LAX, ... and ISO 3166 2/3 
letters we use in ccTLDs, or as X.121 DNICs or telephone numbers, etc.).

They usually are organized in a way O, I, 0 and 1 cannot be confused. As 
you note it, they are often used in printed uppercases.

This means that we are using a 28 character set (0-9, A Z, dot and dash). 
In adding column, slash, comma/crosshatch and star we may have a 32 touch 
pad for future telephone sets?

That reasoning in line with EDI, common language, etc. makes the current 
domain names the international default.

>Multilingualization is more focused on what is sometimes called 
>"localization" - that is, the characters used in rendering a local 
>language can be used (e.g. for domain names or for filling out forms etc) 
>and these renderings need not be universally understood.

Absolutely correct. The "local" wording - which may differ with different 
dialects or ways of writing - can also be used with that mechanic to 
consistently fill forms. The same namepreparation used in IDNA will most 
probably be used for brainware consistency everywhere: we cannot start 
learning and using different schemes when entering a domain name in an URL 
and in a database field, then why to use a library for a field and a 
different one for the next one. This RFC specifies an universal "internet 
name" multiingualization stable mechanism with most probably a lo of 
variations in their massaging.

>This definitional distinction helps (me anyway) to appreciate that the 
>creation of multilingual domain names may not necessarily contribute to 
>universal ability to use the resulting strings because it may be difficult 
>to impossible to render or enter arbitrary character sets at the user 
>interface to a local service. We have collectively probably created some 
>confusion for ourselves by using the term "internationalized domain names" 
>to cover both concepts. It strikes me that the IDNA documents are more 
>aimed at localization/multilingualization than internationalization, using 
>the "definition" in the first paragraph above.

This is why we should correct the wording now, while we still can do it. 
The idea of a universal open solution should be appealing enough to help 
people understand this more global approach. It would also be a good 
occasion to clean a complex commercial and political situation, permitting 
to simplify the implementation process in having a broader support?

We could say that a "multilingual internet name is a multi label string 
which can be internationalized into an ASCII label string and 
remultilingualized into a local string of commonly accepted identical 
meaning by the concerned linguists, IP jurisprudence etc...". Because 
languages change and have dialects. Only the International transcoding is 
our only stability: the more people use it in their own applications, the 
broader are our chances that it becomes a consensus. This is what we have 
to help.
jfc

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 01 Sep 2002 20:26:53 +0200

--On 2002-09-01 19.42 +0200 Simon Josefsson <[email-masked]> wrote:
> otherwise opaque character arrays.

Ok. Good.

> What you are proposing seem to
> the address book application.

Not at all.

What I say is that one should send the ACE encoded string in the paste
buffer. Further, that is what will happen when an application doesn't know
anything about IDNA at all. In cases like MacOS where one can have
alternative forms of the data, it is possible to define a new type for the
Unicode version of the domain name.

> If the
> different strategies.

IDNA says that if no negotiation exists between two entities which exchange
domain names between them, ACE encoding should be used. There is no
difference between a protocol which uses IP or the paste buffer. It is the
same thing.

> world isn't running Unicode everywhere.

IDNA do specify how to encode a domain name which is to be passed between
two applications. If there is no negotiation, ACE encoded Unicode is to be
used.

>     have the situation in (a) again.

You already today have this problem because detecting where a URI start and
end inside unstructured data like an email message body. Yes, you will get
problems in this situation.

>     care about this scenario, but it do exists in the real world

See above, if the address is to be transferred to other application, it
should either be negotiated that it is an IDN in a specific charset (like
8859-1) or sent as ACE.

   paf

---

From: Soobok Lee <[email-masked]>
Date: Mon, 2 Sep 2002 03:59:04 +0900

> string, and notice it is ace encoded, and can choose to decode that if it

I often run xterm and then launch MUTT (or PINE).
Even if MUTT would become IDNA-aware in the future, copy & paste operations 
grab the IDN-like strings directly from the xterm, not from the MUTT.
So, the MUTT cannot have any opportunity to toss ACE-encod the IDN into the 
receiving applications or the clip board area. Text-based MUA does not have
any copy&paste support to/from it. Xterm does all the job.

Consistent IDNA-specific and IDNA-aware copy&paste operations, if we make any,
should be implementable and meaningful also in xterm which has been regarded
as a purely textual application.

Soobok Lee

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 01 Sep 2002 21:21:52 +0200

>> the address book application.

OK, then I misunderstood what you said.  Disregard my mail..

> should either be negotiated that it is an IDN in a specific charset (like

Even tagging data as being an IDN encoded into a (legacy) coding
system isn't sufficient to use IDNA interoperably, as no transcoding
tables are specified.  But I'm starting to repeat myself from another
thread now.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 01 Sep 2002 21:34:26 +0200

> any copy&paste support to/from it. Xterm does all the job.

The specifications seems quite clear on what should happen here -- if
there is no negotiation, ACE should be used.  TTY MUAs therefor must
display ACE strings as there is no negotiation between xterm and the
MUA that an IDNA string is being displayed.

> as a purely textual application.

Fully agree.  That's also why I think IDNA should not try to specify
cut'n'paste operations because it will require fundamental changes in
how cut'n'paste work in most operating systems and there are many
dragons there.  IDNA cut'n'paste won't be solved by this WG.

If the goal of IDNA was clearly defined, we wouldn't need to have this
discussion...

---

From: Dave Crocker <[email-masked]>
Date: Sun, 01 Sep 2002 13:25:59 -0700

At 12:28 AM 9/1/2002 -0400, John C Klensin wrote:
>I believe that IDNA (and the supporting documents) are... a reasonably 
>well-understood solution to _some_ problem. I'm not sure I know what that 
>problem is, who cares about it, and whether it is important enough to 
>justify changes to the way the DNS works and is interpreted.

We should all be *very* worried that this major IETF effort has gone on for 
nearly 3 years, yet such a question can be seriously raised.  (Or rather, 
that such a question legitimately reflects a concern among serious 
participants, as it clearly does.)

This suggests strongly that the charter and the working group process 
adequately characterized *neither* the problem to solve nor the benefactors 
of the solution.

Here is my own effort at doing both:

IDN Scope and Goals
-------------------

1.  The set of characters available for use in domain names is problematic 
for large portions of the global Internet user population.  Many users do 
not use Latin characters *ever*.  Current technology standards permit them 
to use their local set of non-Latin characters for all their Internet 
activities, EXCEPT domain names!  Hence, the set of characters that can be 
used for domain names needs to be increased.

2.  The most immediate need is for support of this increased set of 
characters in email and web domain names.

3.  Domain names are used both by humans and by computers.  The human uses 
occur within free text and even non-computer contexts, such as business 
cards and advertising.  The human benefit of domain names, over such 
alternatives as numeric strings, is mnemonic salience.  The darn things are 
simply easier to remember, though not necessarily easy to guess.

4.  A long history of making changes to Internet infrastructure highly 
recommends finding a way to do this enhancement so that it a) does not 
disturb the installed base, b) interworks with that installed base, and c) 
permits incremental benefit when there is incremental adoption.

Hence, the immediate functional description of IDN is that users will be 
able to register and use non-Latin characters in domain names that are part 
of email and web addresses.  Further, the method of transmitting those 
characters, in the DNS protocol environment, needs to use a layered 
encoding scheme, along the lines of content-transfer-encoding for binary 
data in MIME.

>I know that the IDNA approach, with adequate definition of the characters 
>to be used, will permit internationalization of low-level identifiers.

That is excellent, because that is exactly what it is supposed to 
do.  After all that is what domain names are, albeit identifiers with some 
mnemonic qualities.

>  If that is all
>different codepoints may not be relevant.

I really hate to ask this, but I am not even sure what you mean "character 
matching for
different codepoints", unless this is the Unicode equivalent to ASCII 
case-INsensitivity.

If my guess happens to be correct, I admit to continued ignorance about the 
reasonableness of having strings be case insensitive for non-Latin 
characters.  And this is one of those issues that, frankly, simply requires 
a decision.  While case insensitivity can be a Very Good Thing, we have 
plenty of examples of its absence being acceptable, even when it is quite 
inconvenient.

>   By contrast, it is clear that the WG has not solved (Dave would, I 
> think, say that
>environments and media.

You are prescient.  Cut and paste is a *user interface* issue that already 
exists, far beyond domain names.  And the world already has mechanisms for 
dealing with it.

However well or poorly those mechanisms work, it is not within IETF scope 
to try to alter them.

>   It is equally clear that many people are focused on that problem and 
> won't consider any "DNS internationalization" problem to be solved unless 
> it has some adequate resolution.

This is a good example of the reason "DNS Internationalization" is not a 
useful term.  It is also a good example of the reason the target usage 
scenarios need to be extremely explicit, as I have tried to make them, above.

The IETF has a long history of participants wanting to pursue topics beyond 
what is practical.  The solution is to NOT pursue those topics.

At 08:53 AM 9/1/2002 -0400, vinton g. cerf wrote:
>encoding/expression is "understood" by speakers of all languages.

This highlights why "localization" is probably a much more useful term.

While retaining global interoperability, this domain name enhancement needs 
to permit use of characters that are tailored to smaller communities -- 
where one such "smaller" community is more than a billion people...

>Consequently, someone sending a letter from the US to a recipient in 
>Vietnam can write the destination address in Vietnamese and the US postal 
>service need only understand the characters "VIETNAM" at the bottom of the 
>destination address.

IDNA accomplishes this combination of global "interpretation routing".  In 
fact, it is inherent in domain names, and IDNA strings are valid domain 
names within the current DNS.

So what does IDNA do that might be viewed as a problem?  The answer is that 
an *encoded* IDNA string has no mnemonic value for anyone.  It looks like a 
random string.

IDNA strings that are in Unicode are as mnemonic as ASCII strings, for 
those users who support the relevant Unicode set of characters.  For those 
who do not, they will not see those Unicode characters.  They will see the 
"random" string, which is a valid domain name, but lacks mnemonic benefit.

>multilingual domain names may not necessarily contribute to universal 
>ability to use the resulting strings because it may be difficult to 
>impossible to render or enter arbitrary character sets at the user 
>interface to a local service.

Has MIME's ability to support non-ASCII characters been helpful to the 
overall utility of the Internet?  I claim it has, even though I cannot read 
any of those other characters.  (I am, after all, a typical American....)

The real issue, here, is whether the Internet infrastructure properly 
labels and carries information that can be understood by some users, but 
not others.  Frankly, I see the question of non-Latin characters as being 
the same as using obscure vocabulary.  It is fine to use that vocabulary, 
as long as it works with the intended recipients.

Presumably, no one has a problem with a domain name like 
tak-apa.com.  However, only speakers of Bahasa are likely to know that it 
means "no problem".

We need to make exactly the same distinction between semantic/mnemonic 
utility, versus mechanical utility.  IDNA permits a much broader -- and 
more localized -- range of semantic/mnemonic domain names, while retaining 
all of the necessary global, mechanical interoperability.

>  We have collectively probably created some confusion for ourselves by 
> using the term "internationalized domain names" to cover both concepts.
>  It strikes me that the IDNA documents are more aimed at 
> localization/multilingualization than internationalization, using the 
> "definition" in the first paragraph above.

You are exactly correct.  The problematic nature of the term 
"internationalization" has been discussed before.  I would have wished for 
different terminology, too.

>Concerns about how cut/paste will work are germane to the discussion about 
>the utility of IDNs because such actions may be the ONLY way in which 
>someone may be able to enter special character strings into text intended 
>to represent an IDN.

The technical issues about multi-data-type cut-and-paste are beyond the 
competence of this community.

All we know -- and all we need to know -- is that modern user interfaces 
are quite good at supporting cut and paste of pictures, voice, labeled 
strings, and lots more.  There is no reason to believe that an IDN is even 
slightly difficult for such an environment.

>I usually end up cutting and pasting the characters. This works because 
>the text of email is permitted to be pretty general in its encoding. I 
>don't know how that would work out if I were dealing with non-Latin 
>character sets.

And you do not know that it will NOT work.

We DO know that it needs to work, and we DO know that it is a matter 
entirely within the purview of user interface designers, not protocol geeks.

>One of the important questions that I sense is being asked in the 
>discussion of IDNA is just how applications that encounter these encoded 
>objects/strings should handle them,

Is there some reason that the IETF should pursue this matter any more 
deeply than it has done for MIME?

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: "vinton g. cerf" <[email-masked]>
Date: Sun, 01 Sep 2002 19:32:36 -0400

I think it is important for IETF to understand as well as it can the side effects of using IDNA in applications - since I think user expectations will be high. This need not necessarily impinge on the IDNA specifications but it might cast light on the effectiveness of the IDNA design in actual use.

vint

At 01:25 PM 9/1/2002 -0700, Dave Crocker wrote:
>Is there some reason that the IETF should pursue this matter any more deeply than it has done for MIME?

Vint Cerf

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 2 Sep 2002 01:40:35 +0000

"vinton g. cerf" <[email-masked]> wrote:

> localization/multilingualization than internationalization

> IMHO multilingual Internet names support is what we talk about.

I personally wouldn't mind seeing IDN renamed to MDN, but I suppose it's
the area directors that would need to make that decision.

What we really want is a word that means multiple scripts,
rather than multiple languages, but I don't know of such a word.

AMC

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 2 Sep 2002 02:30:10 +0000

"JFC (Jefsey) Morfin" <[email-masked]> wrote:

> As you say IDNA is only a mechanism.  It may apply to any semantic
> made of labels linked by dots.  I also feel there are several issues
> related to the specific use of the names.  In removing references
> to the usage of the names, we would have a stable universal system.
> Special adaptations for particular uses, if there are some, would be
> understood as particular cases.

It sounds like you're talking about "domain names".  The DNS standard
makes it clear that domain names can be used for an arbitrary variety
of purposes.  The only thing they all have in common is their syntax:
sequence of labels, ASCII, case-insensitivity, and the size limits.
(Labels are customarily separated by dots, but not always.  For example,
not in DNS protocol messages.)

The IDNA spec defines a mechanism for arbitrary domain names, regardless
of what they are naming or what protocols they are used in.

> >    them.  All existing channels through which names can enter a
> >    DNS server database (for example, master files [STD13] and DNS
> >    update messages [RFC2136]) are IDN-unaware because they predate
> >    IDNA, and therefore requirement 2 of section 3.1 of this document
> >    provides the needed shielding, by ensuring that internationalized
> >    domain names entering DNS server databases through such channels
> >    have already been converted to their equivalent ASCII forms.
>
> But is it that complex?

Yes, it is that simple.  :)

> One year from now most will ask themselves about "existing": are there
> changes?

I cannot predict what new channels might appear in the future.
Obviously, you can't stuff data in format X into a program that is
unaware of format X and expect it to work.  If new incompatible
native-IDN channels are defined in the future, they will obviously be
intended for use with new IDN-aware DNS servers, and the specifications
of these new channels will presumably contain warnings that they can't
be used with IDN-unaware DNS servers.

> Also about "channels": are there other ways to enter the DNS?

No, "way by which to enter" and "channel through which to enter"
mean essentially the same thing.  It's just a slight difference in
connotation.

> Also, does that mean that sometime the DNS is going to become Unicode?

No.  It might, or it might not.  That's not something we need to know in
advance in order to specify and deploy IDNA now.

> I meant "DNS names character set", or any more adequate wording than
> my Frenglish, to tell "the characters authorized in ASCII domain
> names, at any given time".

It depends on more than just time, it depends on how the name is being
used.  For example, names of hosts must not contain underscores or
slashes, but names of SRV records must contain underscores, and RFC 2317
shows names of PTR records that contain slashes.

AMC

---

From: "vinton g. cerf" <[email-masked]>
Date: Sun, 01 Sep 2002 22:28:32 -0400

part of the problem is that scripts lead to languages and that's likely how most people will think of the IDN names.

vint

Vint Cerf

---

From: "James Seng" <[email-masked]>
Date: Mon, 2 Sep 2002 10:40:40 +0800

This is a deja vu, a discussion we have before. I tried to refrain myself
from kicking at this dead horse again but...*sigh*

There is a difference between "script" vs "language".

Language are written in scripts. Some languages use more then one script.
(e.g. Japanese). And some languages share and use the same script (e.g.
Arabic script, Han Ideograph). So language != script.

When we say "localization", we deal with "local language, local expression,
local pharses" etc.

When we say "multilingual", we deal with multi-languages.

When we say "internationalization", we design system that handle multiple
scripts.

Domain name deal with script. It has no capability to deal with language.
When I write a domain name on a napkin (aka "the napkin test"), say
"現代.com", and you give it to someone else, you have no way knowing this is a
chinese or japanese or korean without me telling you (out-of-band
communication).

So in domain name, we cant do "multilingual". We do "internationalization".
If you want "multilingual", you are not looking at domain name but something
else.

These definition is a bit different from the layman defintion of
"international" and "local" in Jefsey's email. But we engineers have to be
more precies.

-James Seng

---

From: Soobok Lee <[email-masked]>
Date: Mon, 2 Sep 2002 11:43:33 +0900

On Mon, Sep 02, 2002 at 11:09:29AM +0900, YangWoo Ko wrote:
> On Sun, Sep 01, 2002 at 09:34:26PM +0200, Simon Josefsson wrote:
> Dear Simon,
> Oops. Then I will encounter very ugly environment in the near future.

Yes, if and only if we enforce that the copy & paste buffer should *always* be filled 
with the ACE-encoded IDN . Otherwise,if we also allow in the paste buffer 
other local-charset-encoded IDN , instead, various interoperability problems 
will arise. Both situations seem ugly... :-)

Soobok Lee

---

From: YangWoo Ko <[email-masked]>
Date: Sun, 01 Sep 2002 19:45:46 -0700

Dear Simon,

Dear idn-ers,

Please tell me that simon's understanding is wrong. Negotiation in IDNA
draft seems either poorly documented or poorly understood.

Korean mutt user.

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Sep 2002 22:58:23 -0400

--On Monday, September 02, 2002 10:40 AM +0800 James Seng
<[email-masked]> wrote:

>...
> Domain name deal with script. It has no capability to deal
> with language. When I write a domain name on a napkin (aka
> "the napkin test"), say "ç?¾ä»£.com", and you give it to
> someone else, you have no way knowing this is a chinese or
> japanese or korean without me telling you (out-of-band
> communication).

Actually, James, domain names don't deal with scripts, either.
They deal with characters, chosen without restrictions from a
repertoire.  As long as that repertiore is, as the IDN WG has
specified so far, all of Unicode less some prohibited characters
(or, more precisely, code points) than any of the non-prohibited
Unicode characters can appear in a DNS name, in any order, with
no restriction to, e.g., script homogenity within a label.

> So in domain name, we cant do "multilingual". We do
> "internationalization". If you want "multilingual", you are
> not looking at domain name but something else.

Yes.  But, again, no restrictions to scripts either.

     john

---

From: "James Seng" <[email-masked]>
Date: Mon, 2 Sep 2002 11:13:11 +0800

This is really deja vu :)

To be even more precies, domain names don't deal with characters either. It
deals with bits that represent codepoints, that may be grapheme that forms
characters.

-James Seng

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "James Seng" <[email-masked]>; "IETF idn working group"
<[email-masked]>
Sent: Monday, September 02, 2002 10:58 AM
Subject: Re: [idn] Document Status?

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Sep 2002 05:16:58 +0200

> draft seems either poorly documented or poorly understood.

I agree the specifications aren't clear, but at least Patrik Fältström
answered clearly in another part of this thread, unless I
misunderstood him again -- which isn't unlikely, as I fail to locate
the text in the IDNA specification that back the claims made.  From
<35817839.1030912013@localhost>:

Patrik Fältström wrote:

> Simon Josefsson wrote:

> Simon Josefsson wrote:

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 2 Sep 2002 03:16:56 +0000

> otherwise opaque character arrays.

Cut & paste in X11 works fine when everything is ASCII.  Otherwise, in
my experience, it is quite broken already, even before IDNs enter the
picture.

For example, I often run a text-mode editor in one kterm, and a
text-mode browser in another.  I can cut and paste English and Japanese
text between them with no problems.  However, if I try to copy Japanese
text from Netscape 4 into a kterm, it does not work.  I figured out how
it was broken and implemented a hack to make it possible (a small tcl/tk
program that provides a button that grabs the selection, performs the
transcoding, and re-exports the selection).

Now when I try to copy text from Mozilla 1.0 into a kterm, it doesn't
work, but it's broken in some other way that I haven't investigated
yet, so then what I do is copy the URL, load the page into my text-mode
browser, and copy the text from there.

So I think it's true that cutting and pasting IDNs in X11 will fail in
many cases, but not because IDNs are so difficult, but only because
cutting and pasting anything other than ASCII text is already broken to
begin with.

Patrik Fältström <[email-masked]> wrote:

> IDNA says that if no negotiation exists between two entities which
> exchange domain names between them, ACE encoding should be used.

IDNA says that the ASCII form must be used when a domain name is put
into an IDN-unaware domain name slot.  IDNA says that ACE forms should
not be shown to users (unless the non-ACE form would cause problems).
That still leaves some cases up in the air.  When a domain name is put
into a place that is not a domain name slot (for example, a generic
text context) and the place is not user-visible, then IDNA makes no
recommendation about which form to use.

> There is no difference between a protocol which uses IP or the paste
> buffer.  It is the same thing.

I don't think so.  When the user copies a domain name from the displayed
header of a mail message, is the user intending to copy text, or
intending to copy a domain name as such?  Is the user going to paste it
into a text editor where a message body is being composed (in which case
the user wants text), or is the user going to paste it into the location
field of a browser (in which case the user wants a domain name as such).

Cut&paste buffers are a tricky case because they have no specified
purpose; they can be used for anything.

As you said, in the ideal situation the buffer would contain two
versions of the selection, one tagged as plain text, and one tagged
as a textual identifier or as structured text, so that the receiving
application could choose the appropriate representation.

But if only one representation can be put in the buffer, it is not clear
whether the ACE form or the non-ACE form should be used, and the IDNA
spec does not require either one, because the buffer is not a domain
name slot and is not user-visible.

Simon Josefsson <[email-masked]> wrote:

> > Even if MUTT would become IDNA-aware in the future, copy & paste
> > operations grab the IDN-like strings directly from the xterm, not
> > from the MUTT.  So, the MUTT cannot have any opportunity to toss
> > ACE-encod the IDN into the receiving applications or the clip board
> > area.  Text-based MUA does not have any copy&paste support to/from
> > it.  Xterm does all the job.
>
> there is no negotiation, ACE should be used.  TTY MUAs therefore must

That conclusion does not follow from the IDNA spec.  ASCII forms are
required only in IDN-unaware domain name slots.  The tty is not a domain
name slot, it's just a generic text terminal.

It would be silly to forbid all tty-based applications from displaying
non-ASCII domain names, just because cut&paste might fail sometimes.
IDNA does not make such a prohibition.

AMC

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Sep 2002 23:31:24 -0400

--On Monday, September 02, 2002 11:13 AM +0800 James Seng
<[email-masked]> wrote:

> To be even more precies, domain names don't deal with
> characters either. It deals with bits that represent
> codepoints, that may be grapheme that forms characters.

James, I was about to respond by saying "yes".   Then I realized
that this is actually an area of controversy, and one of the
sources of my "and what problem did you say the IDN WG solved?"
question.  Let me try to explain, in the unlikely event that it
is helpful...

The defining DNS documents, at least I read them, really do talk
about "characters".  That was, I think, largely because in ASCII
there are no composed characters (combining of two code points
to produce one character); there are no composite sequences to
make up phonemes or words (as in Hangul, at least as I
understand it); there are no diacriticals, no optional accent
marks or vowels, no peculiar spaces or breaks, and no alternate
(or multiple) codings for the same glyph.

I think your "bits that represent codepoints, that may be
grapheme that forms characters" definition may be an accurate
characterization of where we have ended up.  But I believe we
have ended up here more or less as an accidental sequence of
events, driven by the design work of a small number of people,
and without any explicit decision by the WG that this is what we
are doing.  And that, in turn, brings us back to one of the
issues Dave and I keep trying to raise, which is that the IDN
WG's output constitutes a (or several) significant change(s) in
how the DNS is used and interpreted, and we need to be very
explicit about those changes.

If one of them is that we have moved from "characters" to "bits
that represent...", then that is some that should be explicit.
And it isn't in any of the documents I've seen so far.

      john

---

From: Dave Crocker <[email-masked]>
Date: Sun, 01 Sep 2002 20:37:16 -0700

At 07:32 PM 9/1/2002 -0400, vinton g. cerf wrote:
>I think it is important for IETF to understand as well as it can the side 
>effects of using IDNA in applications

understanding is always a good thing.  in this case, however, concern over 
the user interface has been one of the tenacious reasons for taking 3 years 
to do work that should have taken 1.

That is why it is so striking to see such basic issues being raised again, 
during Last Call.

d/

----------

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Sep 2002 23:42:30 -0400

--On Monday, September 02, 2002 12:25 PM +0900 YangWoo Ko
<[email-masked]> wrote:

> Within the context of Domain Name, can somebody teach me the
> benefit of using "script" instead of "language", or its
> reverse ? Can somebody teach me the benefit of using
> "multilingualization" instead of "internationalization" ? I am
> lost.

Let me try, with the understanding that there is great confusion
about these terms (i.e., you are not the only one who is lost)
and that they tend to cause arguments all out of proportion to
their value.

"multilingual" and its variants seem to be properly used only
when _language_ issues (syntax, methods of forming words or
phrases, legitimate word or phrase construction, etc.) are
involved.  Since there have been no serious proposals to
incorporate _language_ issues like these into the DNS (although
some proposals have assumed it is there already or will happen
by magic), the term is typically inappropriate for DNS contexts
(even though it is often used).

A "script" is a collection of characters used to write one or
more languages.  As James pointed out, some languages use more
than one script (e.g., there are some European and, I think,
African languages that can be written in different character
collections, although the language remains the same.   The use
of Hangul or Hanji to write Korean, or of Hiragana or Kanji to
write Japanese, may be another example of this, although it is
important to remember that analogies in these areas are never
exact and that over-using them often leads to trouble.  We also
have, as James again pointed out, the same script (sometimes
with small variations) use to write several different languages.
Arabic script is also used to write other languages, Roman-based
scripts are used to write German and French and several other
languages in addition to English and Italian, and so on.   So,
if all one can talk about is the characters being used (and
coded), without reference to the language involved, "script" is
probably appropriate.

"internationalization" is an extremely broad term, used to
describe, I believe, any attempt to get ones arms around this
mess and, in particular, make systems suitable for use by people
all over the world, regardless of the script or language they
normally use.

Does that help?

     john

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 01 Sep 2002 22:45:25 -0500

> I often run xterm and then launch MUTT (or PINE).

<snip>

This problem goes beyond xterm. For all practical purposes, all apps will
be required to use the text form for all exchanges, except in those cases
where the operating environment provides an "i18n domain name" data-type
as part of the clipboard protocol. Unless an application is willing to
explicitly claim support for ACE encoded domain names, there can be no
guarantee that the recipient application will be able to make sense of the
domain name.

Separately, the canonical problem here is managing multiple
representations and trying to negotiate over which representation should
be used for some specific function. This problem won't go away until the
i18n form is available in all protocols and applications directly. In this
regard, IDNA is a patch that introduces a new problem, not a cure to the
existing problem. Having said that, some degree of transition and
therefore negotiation is of course necessary. It should not be the end,
however. I would hate to think that we consider the problem resolved after
only having made it worse.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 01 Sep 2002 22:53:15 -0500

> permits incremental benefit when there is incremental adoption.

I would reiterate the factual point that IDNA requires a forklift upgrade
of the Internet's current application clients, and it therefore does not
satisfy the ground covered in points "a" and "b".

Call it what it is, not what we want it to be. It's a cute hack that
allows for the sale and register of i18n domain names, and which may allow
for the visual representation of these domain names once compliant
applications are deployed.

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 2 Sep 2002 03:55:51 +0000

James Seng <[email-masked]> wrote:

> To be even more precies, domain names don't deal with characters
> either.  It deals with bits that represent codepoints, that may be
> grapheme that forms characters.

In Unicode terminology, no code point represents multiple characters,
and no code point represents a part of a character.  Each code point
represents one character (or no characters).

A case can be made that domain names do (or should) deal with
characters.  The domain label "nicemice" is a sequence of eight
characters.  They happen to be represented by ASCII codes whenever the
are sent via DNS (or most other protocols), but the label can also
be written on paper, or represented in EBCDIC.  Its essence is the
characters, not the bits.

At least, that's the view taken by URIs.  A URI is explicitly defined
as a sequence of characters, not bytes, and one field of most URIs is a
domain name.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 01 Sep 2002 23:03:37 -0500

[oops]

on 9/1/2002 10:45 PM Eric A. Hall wrote:

> Unless an application is willing to explicitly claim support for
> ACE encoded domain names,
  ^^^^^^^^^^^
 internationalized

> there can be no guarantee that the recipient
> application will be able to make sense of the domain name.

...so the default will always be ASCII.

Proof: dozens if not hundreds of common applications that accept i18n data
as input and don't error out until the back-end protocol(s) fail.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Sep 2002 06:07:23 +0200

> my experience, it is quite broken already, even before IDNs enter the

Recent versions of X11 and various utilities work better (e.g., in the
Unicode based RedHat Linux beta), but there are still applications
that doesn't work fully.  Latin-1 cut'n'paste has worked for me for
years.

> IDNA does not make such a prohibition.

You are right, I trusted the simplified explanation given earlier.  In
the particular example of a MUA running in XTERM (or a Unicode unix
console, for that matter), it will likely not work out as I'm not
aware of any API between a TTY application and the terminal to query
which unicode characters it can display, and whether it supports bidi,
and in that case it seems this paragraph from 6.4 would apply,
suggesting that MUAs should use ACE anyway:

,----
| If an application decodes an ACE name using ToUnicode but cannot show
| all of the characters in the decoded name, such as if the name contains
| characters that the output system cannot display, the application SHOULD
| show the name in ACE format (which always includes the ACE prefix)
| instead of displaying the name with the replacement character (U+FFFD).
`----

Or is that section only applicable to domain-name slots?  It is not
clear.

Whether section 6.4 must be followed or not at all seems a bit unclear
after reading the following in section 6.1: "The optional use,
especially during a transition period, of ACE encodings in the user
interface is described in section 6.4.".  Is section 6.4 optional?

---

From: Dave Crocker <[email-masked]>
Date: Sun, 01 Sep 2002 21:23:29 -0700

At 11:31 PM 9/1/2002 -0400, John C Klensin wrote:
>the IDN WG's output constitutes a (or several) significant change(s) in 
>how the DNS is used and interpreted,

1.  IDNA makes no changes to DNS "semantics" and no changes to basic DNS use.

2.  IDNA increases the set of valid domain name characters from a subset of 
ASCII to a subset of Unicode.

3.  IDNA uses an encoding trick of the type used in MIME, to provide an 
upgrade path that has minimal impact on the installed base, yet permits 
interoperability.

>If one of them is that we have moved from "characters" to "bits that 
>represent...",

It is NOT one of the changes.

>satisfy the ground covered in points "a" and "b".

Hmmmm.  Let's see...

Applications that currently speak only ASCII, for domain names, need to be 
changed to support Unicode for domain names.  This sort of change is 
certain to be significant for any application making the enhancement, no 
matter what the details are.

So along with that inherent set of changes, IDNA imposes a special encoding 
requirement, to map the unicode onto ascii.

>applications are deployed.

The MIME-like encoding technique is a cute hack, proven to work well.

Increasing the set of valid characters is what it is, not what some might 
want it to be, and it certainly is not a cute hack.

d/

----------

---

From: YangWoo Ko <[email-masked]>
Date: Mon, 2 Sep 2002 13:59:44 +0900

Dear John Klensin,
   
Thanks for kind reply but it does little help without clearly sorting  
out which issues are "multiligual" ones while others are not. Another
answer which should be prepared is how to avoid those "multilingual"
issues wisely enough not to ruin "internatinalization".
  
With my best regards

-- 
/*------------------------------------------------
  Ko, YangWoo : [email-masked] / SPSoft
------------------------------------------------*/

---

From: YangWoo Ko <[email-masked]>
Date: Mon, 2 Sep 2002 13:59:19 +0900

Dear all,
   
Why should IETF WG handle implementation issues of specific OS/GUI ?   
What about just let others handle them ?
  
Is it possible to remove every application-related features out of IDNA
document except IDN being ACE encoded somewhere and somehow outside of
DNS ? Does it help or harm ?
  
Regards

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 02 Sep 2002 07:15:16 +0200

--On 2002-09-01 20.37 -0700 Dave Crocker <[email-masked]> wrote:

> That is why it is so striking to see such basic issues being raised
> again, during Last Call.

Not surprising at all. People still don't understand how MIME works, and
that has only been defined since around 1993.

We will have this problem as long as we use multiple representations of
characters when moving them around as bits.

Which will be forever.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 02 Sep 2002 07:05:19 +0200

> MUA that an IDNA string is being displayed.

It is not more strange than what we have for Subject-lines today.

Should the tty client display subject lines encoded according to RFC 2047,
or decoded? If you cut and paste via xterm something which is decoded, and
paste somewhere else, it is still up to the email client and other involved
applications "to do the right thing". Right thing is to see that non-IDNA
applications get the ACE encoded version of domain names.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 02 Sep 2002 07:09:50 +0200

--On 2002-09-02 11.43 +0900 Soobok Lee <[email-masked]> wrote:

> Yes, if and only if we enforce that the copy & paste buffer should
> *always* be filled  with the ACE-encoded IDN .

Not needed if the copy-paste buffer can include tagged data. You talk about
transcoding tables, but for many non-unicode charsets the mapping table is
a 1:1 mapping, especially Unicode strings after Nameprep has been applied.
And, there is no problem with tagged data to say that "for this type, this
transcoding table is to be used.

You talk about X11 which only have charset information in the tagging, and
yes, there it might be problematic. On other operating systems, like MacOS,
there will be no problem.

But, as you point out, if an application is conservative and only give out
ACE to other applications, you will be safe, as all IDNA-aware applications
can detect and decode ACE.

Be conservative with what you send, and generous with what you receive.

    paf

---

From: "Soobok Lee" <[email-masked]>
Date: Mon, 2 Sep 2002 14:37:25 +0900

----- Original Message ----- 
From: "YangWoo Ko" <[email-masked]>
To: "IETF idn working group" <[email-masked]>
Sent: Monday, September 02, 2002 1:59 PM
Subject: Re: [idn] Re: Document Status?

> What about just let others handle them ?

Implementation specifics and implementability issues are different. The latter 
one may be one of architectural/security issues which we should discuss on.

> DNS ? Does it help or harm ?

If you begin to remove those features, only Punycode draft  will remain in the pool.
IDN is not only a problem of DNS server/client, but also problems around applications
which uses domain names as *local* identifiers and do comparisons on them.

Soobok Lee

---

From: Martin Duerst <[email-masked]>
Date: Mon, 02 Sep 2002 14:48:23 +0900

>bottom of the destination address.

Some comments:

- 'Internationalization', in the context of software, means the basic
   work that is needed to use different scripts, languages,...
   James and John already explained that.

- For postal addresses, strictly speaking, you are guaranteed delivery
   from any country if you use the French contry name. English may also
   work pretty well in practice, but I'm not sure it's guaranteed.

>to represent an IDN. Something like this happens to me regularly as I 
>compose email to friends whose names involve the use of characters with 
>various accent markings. Since I don't know how to enter these from my 
>simple ASCII keyboard, I usually end up cutting and pasting the 
>characters. This works because the text of email is permitted to be pretty 
>general in its encoding. I don't know how that would work out if I were 
>dealing with non-Latin character sets. I know I would need special 
>software to render Hangul or Kanji, for instance, but I assume that the 
>rendering packages also serve to make highlighting and cut/paste work.

Seeing that you use:
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii
References: <[email-masked]>
  <[email-masked]>
  <[email-masked]>
  <[email-masked]>
  <[email-masked]>
  <01cd01c25096$b6845ec0$8e00a8c0@JAMESSONYVAIO> <3609004.1030770370@localhost>
  <[email-masked]>

I understand why you are a bit sceptical about cut/paste.

The Windows version of Eudora is well known for it's lack
of support for Unicode. The English version does Latin-1,
and the Japanese version I use does iso-2022-jp, but nothing
more. I hope that Eudora for Windows will finally be upgraded
to decent Unicode support when they do IDN. The Mac version
of Eudora is different, no problem with Unicode at all.

On newer versions of Windows (as well as other OSes), cut/paste
of any Unicode text isn't really a problem at all if the
application does the right thing.

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Mon, 02 Sep 2002 14:31:13 +0900

>Yes.  But, again, no restrictions to scripts either.

Please note that the recent changes for bidi introduced
some restrictions on how you can combine scripts in
a single label.

Regards,    Martin.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 02 Sep 2002 01:12:37 -0500

> It is not more strange than what we have for Subject-lines today.

Except that Subject: is unstructured data which is not processed as
protocol data. And even when where parts of Subject: are interpreted as
data (such as "Re:"), they are required to be in ASCII for them to work.

Domain names are structured and used as protocol data everywhere. Any
strangeness with a domain name is an opportunity for total failure, even
outside the scope of the local application. It won't take long for folks
to figure out that they have to use ASCII for everything, except where
some function provides an explicit IDN data-type and can guarantee that it
will handle any necessary conversion.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Sep 2002 08:25:05 +0200

> It is not more strange than what we have for Subject-lines today.

There is a important difference; subject lines aren't used to route
mail or identify persons.

If I cut'n'paste a subject line and it is garbled, the only harm will
be a garbled subject line.

If I cut'n'paste an IDN email address and it is garbled, I will send
mail to the wrong person, potentially even encrypted mail embedding
sensitive information, as security systems like OpenPGP and S/MIME
uses email addresses to identify people.

Just making IDN "work", as in displaying fancy glyphs, isn't good
enough, it also shouldn't generate new security problems.  MIME only
dealt with the data, it did not modify interpretation of the
addressing system, and still managed to generate security problems.

---

From: YangWoo Ko <[email-masked]>
Date: Mon, 2 Sep 2002 13:36:28 +0900

Dear all,

Regards

--
Time to apologize, president Bush
--
/*------------------------------------------------
  Ko, YangWoo / a human / [email-masked]
------------------------------------------------*/

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 02 Sep 2002 09:16:34 +0200

> mail or identify persons.

I was not thinking of what we use it for. 

I was thinking of the errors one can get.

   paf

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Sep 2002 01:28:48 -0700

>I was not thinking of what we use it for.

Folks,

Let's assume that these various "differences" do exist.

So what?

If someone is going to claim that IDNA will not work as it is designed to 
work, they need to explain how it will fail.

d/

----------

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 2 Sep 2002 14:19:14 +0200

On Sun, Sep 01, 2002 at 06:34:34PM +0100,
 Stephen Dyer <[email-masked]> wrote 

> "Imperialist" nations in general.

Since you work on the .eu project, I will limit myself to Europe, but
the problem is much broader. Even only for Europe, your suggestion
is not a good one.
 
There is not one 8-bits character set which can be used for all the
European languages, unless you convince many countries to change their
default script :-)

In the present European Union, Latin-1 and Greek are both required and
they already do not fit together in 8-bits charsets. In 2004, Latin-2
countries like Poland will join the EU.

So, although "Let's make the simple thing first and we'll see later
for the complicated one" is often reasonable, it cannot work here. We
need Unicode from the beginning (handling Unicode only is simpler than
handling Latin-1, Latin-2 and Greek, and waiting Bulgaria to join with
its Cyrillic alphabet).

---

From: Stephen Dyer <[email-masked]>
Date: Mon, 02 Sep 2002 18:23:28 +0100

At 14:19 02/09/2002 +0200, Stephane Bortzmeyer wrote:
>snip..

If you deploy the fullest possible range of ASCII codes, in *practice* a 
huge range of usable domains will become available. It may be that by 
allowing "élève.com" you may eliminate a Bulgarian word that happens to use 
exactly the same code string but it's a very long shot and results in a 
happy Frenchman and an unhappy Bulgarian. At the moment they are both 
unhappy, and this sort of intersect can happen right now anyway.

Regards

Steve

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 3 Sep 2002 02:56:31 +0000

Simon Josefsson <[email-masked]> wrote:

> In the particular example of a MUA running in XTERM (or a Unicode unix
> | If an application decodes an ACE name using ToUnicode but cannot
> | show all of the characters in the decoded name, such as if the
> | name contains characters that the output system cannot display,
> | the application SHOULD show the name in ACE format (which always
> | includes the ACE prefix) instead of displaying the name with the
> | replacement character (U+FFFD).
> `----

The spec says that an application SHOULD NOT show the ACE form if it can
correctly display the Unicode form, and it SHOULD show the ACE form if
it cannot correctly display the Unicode form.  Both recommendations have
equal weight.  If the application cannot know which Unicode characters
can be displayed, then it cannot know which recommendation applies.
If the application is optimistic about the display capabilities, it
risks violating the second recommendation, and if the application is
pessimistic, it risks violating the first recommendation.

The situation is symmetric.  I see no reason to conclude that the spec
favors optimism or pessimism.

> Or is that section only applicable to domain-name slots?  It is not

The section begins:

    Any application that might show the user a domain name obtained
    from a domain name slot, such as from gethostbyaddr or part of a
    mail header, will need to be updated if it is to prevent users from
    seeing the ACE.

The section is about what happens when names obtained *from* domain name
slots are shown to users.  Generally, user-visible things are not domain
name slots, they're generic text widgets/terminals.

> interface is described in section 6.4.".  Is section 6.4 optional?

No, and I can't see anything in section 6.4 that this sentence could
be referring to.  The only description of "the optional use of ACE
encodings in the user interface" that I can find is right there in the
same paragraph as the sentence in question:

    Applications MAY allow input and display of ACE labels, but are not
    encouraged to do so except as an interface for special purposes,
    possibly for debugging.

    Because name labels encoded as ACE name labels can be rendered
    either as the encoded ASCII characters or the proper decoded
    characters, the application MAY have an option for the user to
    select the preferred method of display; if it does, rendering the
    ACE SHOULD NOT be the default.

I wonder if this cross-reference to section 6.4 is an obsolete relic
from an earlier draft that got left in by mistake.  I'll ask Paul and
Patrik about it.

AMC

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 3 Sep 2002 13:30:45 -0400

Hi Steve,

I concur with your analogy, but I think it is a transition strategy for
registries you are talking about here.  How responsible registry operators
should roll out multilingual domain names to their users, and how
responsible software providers should allow passageway for resolutions to
happen immediately.

Since this is a transitional strategy, it is not going to be the "standard"
and I think this is a very important distinction to me made.  To that end, I
have put together an I-D that is intended to be "informational"
(http://www.ietf.org/internet-drafts/draft-ietf-idn-dnsii-trace-01.txt) for
registries, or shall I say industry operators who actually care about the
fact that names sold work.

It talks about how a registry/DNS operator could prepare its zone to respond
positively to IDN requests sent by existing applications, while being fully
prepared for the eventual "standard".  The reason this is very important, is
that we all know that users wil attempt to access multilingual domain names
they see using their existing applications and that request will reach the
registry name servers.  It will be very irresponsible to ignore these
request, and create a negative user experience for the technically less
sophisticated public.

Anyway, my point is that while I agree to your point, I think we should make
it clear whether they are discussions on the "standard" or the "transition".
To me, the "transition" must be to allow 8bit requests to be correctly
responded to inorder to create a positive and transparent end-user
experience for multilingual domain names, regardless of the "standard", yet
driving towards it.

Edmon

PS. while the I-D has been there for sometime it has not been announced
precisely because I believe we do not wish to muddy the water between "the
standard", and a "transition strategy".

----- Original Message -----
From: "Stephen Dyer" <[email-masked]>

Regards

Steve

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 10:49:43 -0700

>Since this is a transitional strategy, it is not going to be the "standard"

Edmon,

ACE technology is the same as used for MIME.  Is MIME a transitional strategy?

MIME is 10 years old.  When are we going to see its replacement?

Why will ACE follow a path that is different?

d/

----------

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 3 Sep 2002 13:59:57 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
> Why will ACE follow a path that is different?

I am not saying it will ;-)

In fact, I believe it will take as long if not longer...

I am just saying that it is important to make clear what the "standard" is
and what the "transition" might look like.  They are two different
discussions.  We could say that the "transition" is to have 8bit clean, but
it sure doesnt look like a viable long term "standard" to me.

Edmon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 11:18:31 -0700

At 01:59 PM 9/3/2002 -0400, Edmon Chung wrote:
>and what the "transition" might look like.

A standard is what we are specifying now and what will be used now.

Anything for the future is just that.  For the future.

Having a discussion about possible transition issues and targets is fine, 
but it is not fine to deprecate the current work as "merely" transitional.

Something that is going to be used for more than a decade is more than 
transitional.

d/

----------

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 3 Sep 2002 15:52:21 -0400

ok, let me make it really clear.  In my opinion this is where I see us
heading:
1. the standard being IDNA (MIME like approach)
2. transition strategies that takes into consideration immediate user
experience will be deployed by responsible registries for their users
    - these may be and are most likely 8bit+ solutions
    - and takes the query sent by existing applications and resolves it
correctly

I am saying that my work on TRACE-01 is transitional.  Yes maybe it will be
used for a decade and more, but it is meant to be an informational document
on how to get from where we are now towards IDNA, however long it may take.

Edmon

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 03 Sep 2002 15:34:14 -0500

> ACE technology is the same as used for MIME.  Is MIME a transitional

ACE is not the same as MIME. I have avoided making this argument because
the comparison is useful for introductory purposes, but there are subtle
yet strong differences at lower levels which keep them from being mirrors.

Specifically, end-nodes typically extract data from MIME and use it within
the local context of that application *ONLY*. The encoded data is RARELY
used inside of other applications, and the extracted data is typically
used for this purpose, when needed. On the other hand, domain names are
frequently cross-populated among applications, and as the argument
regarding clipboards shows, the encoded form will be the norm.

If all Internet applications had to support the MIME encoding formats for
all of their data -- FTP offering quoted-printable as a transfer type --
then it would be equal to IDNA.

Furthermore, MIME and its constituent application protocols are being
extended so that binary data *CAN* be transferred without being encoded
first. Think about why this is so, and then ask yourself if the ability to
transfer i18n domain names in binary form would also not be desirable, for
the same kinds of reasons.

As far as that goes, an argument for MIME equality is an argument in favor
of an unencoded transfer mode.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 14:16:17 -0700

At 03:34 PM 9/3/2002 -0500, Eric A. Hall wrote:
>used inside of other applications,

1.  you are wrong about the range and frequency of venues for MIME data.

2.  what difference does it make where the data are used, in terms of 
utility of IDNA?

>  On the other hand, domain names are

The discussion about uses environment implementation and use is mostly 
doing a good job of showing that this is not a productive forum for 
discussing user environment implementation and use.  Given the skillset of 
this community, that should not come as a surprise to anyone.

>then it would be equal to IDNA.

Yeah.  I guess that having MIME in both email and the web does not mean much.

>first.

10 years, Eric.  10 years.  So far.  And still counting.

d/

----------

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 3 Sep 2002 17:38:13 -0400

I cannot agree more to Eric's analogy.  To me the key is that IDN has to be
used in multiple apps and it is therefore important we consider that.

> the same kinds of reasons.

This is what IDNA has not provided us with and what we probably should
consider.  I am not sure when... but now might be a good time to start.

Edmon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 15:47:50 -0700

>used in multiple apps and it is therefore important we consider that.

TCP is used in multiple apps.  I guess we had better not standardize it 
until we have considered that.

HTTP is used in multiple apps.  I guess we...

You are confusing host-specific implementation issues with network protocol 
issues.

> > extended so that binary data *CAN* be transferred ...
>

Actually, now is a particularly bad time to start.

Starting now provides excellent distraction from the necessary focus on the 
immediate work, namely IDNA.

d/

----------

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 3 Sep 2002 19:43:48 -0400

fine.  aside from making the doc more readable to ppl who need to use it on
development works, whatelse do we need to add to IDNA?  Personally I dont
quite like the new bidi arrangement, but since I know nothing about the
languages, I have nothing much to offer.  Except perhaps that I do know that
Chinese also has a bidi issue!  I havent seen anyone raise this, but sure
enough Chinese could be written from right to left with English words going
left to right.  Pretty much like the Arabic case.  Anyway, that was not my
point... Other than that, I think the IDNA framework is fairly stable now,
whether it is because people are just too tired to keep talking about it or
that we have successfully dealt with the mulitple issues and found some
ground that we could live with.  Going forward, there are really just two
things I can see that needs real thoughts:

1. A set of possible transition schemes that will get us from here to IDNA
2. Do we want anything beyond IDNA?  Perhaps a protocol that handles the
binary correctly...

what are your thoughts on the remaining issues anyway?

Edmon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 16:54:49 -0700

At 07:43 PM 9/3/2002 -0400, Edmon Chung wrote:
>development works, whatelse do we need to add to IDNA?

Very little is required, in my view.

I have twice listed my own concerns on this list, and issued an I-D with 
suggested changes to resolve those concerns.

What has been missing is any public discussion and resolution of those few 
points.

When IDNA is issued as a Draft Standard it will be time to consider 
enhancements.

d/

----------

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 3 Sep 2002 16:51:21 -0700

>regarding clipboards shows, the encoded form will be the norm.

Many people copy-and-paste MIME content all the time, just as they 
will copy-and-paste IDNs. Non-mail programs look at mail mailboxes 
for things like harvesting for address books or PIMs, and those 
programs interpret the MIME because they store the text in some 
internal format that is certainly not MIME.

>extended so that binary data *CAN* be transferred without being encoded

Which Internet Drafts are you speaking of here?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 03 Sep 2002 20:25:15 -0500

> Which Internet Drafts are you speaking of here?

| Network Working Group                                       G. Vaudreuil
| Request for Comments: 3030                           Lucent Technologies
| Obsolete: 1830                                             December 2000
| Category: Standards Track
|
|                         SMTP Service Extensions
|                        for Transmission of Large
|                         and Binary MIME Messages

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 03 Sep 2002 20:36:27 -0500

> 10 years, Eric.  10 years.  So far.  And still counting.

What is this comment supposed to mean exactly?

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 4 Sep 2002 10:57:30 +0900

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 04, 2002 8:51 AM
Subject: Re: [idn] Document Status?

> internal format that is certainly not MIME.
 
MIME (and even RFC2047)encodes texts or descriptors , not ciritical identifiers 
like domain names as far as i understand. 
So, I can't accept any attemps to draw an analogy between MIME and IDN encodings.

Soobok Lee

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 19:27:01 -0700

>What is this comment supposed to mean exactly?

It means that talking about such work for MIME does not mean much, since we 
still do not have a demonstration that it is particularly popular 
yet.  Until it is popular, it does not demonstrate real need or real solution.

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 19:28:25 -0700

>like domain names as far as i understand.

How does that difference matter?  What is it about that difference that 
makes experience with MIME not apply for IDNA?

d/

----------

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Sep 2002 04:53:03 +0200

Dave Crocker <[email-masked]> writes:

> How does that difference matter?  What is it about that difference
> that makes experience with MIME not apply for IDNA?

If I press the PRINT button on a MIME part in my mail reader, noone
cares that the rendered MIME body, which is printed, is infeasible to
put back into the original MIME part.

If I press the PRINT button on an IDNA in my mail reader, it is
important that people are able to put it back into the original IDNA
[given some reasonable assumptions about the people].

IDNA will be used to identify entities.  If there is any confusion as
to which identity a certain IDNA really points at, there will be
security consequences.  MIME doesn't have this property.

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 4 Sep 2002 12:10:33 +0900

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: <[email-masked]>; "Paul Hoffman / IMC" <[email-masked]>
Sent: Wednesday, September 04, 2002 11:28 AM
Subject: Re: [idn] Document Status?

> makes experience with MIME not apply for IDNA?
 
IDN penetrates into all the applications which use domain names as local or
online identifiers, while MIME is used within internet messaging applications.
For example, MIME is not used in customer enrollment databases, while domain
names are. Future SQL statements support separate IDN comparison operators  ??
One database uses ACE in primary key, while joined database in other host uses UTF8. 
Is it allowed?

I see huge groups of interconnected and interoperating databases,applications and 
directories which came from differnt sources and regions and have their own management 
policies in the global internet. 

domain names have different criteria for interoperability ,
revision, and stability than messages and MIME have.  introducing IDN will
amplify all those severe problems and increase deployments costs, without
addressing them in a technically clear manner. 
 
Soobok Lee

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 03 Sep 2002 22:20:34 -0500

on 9/3/2002 9:27 PM Dave Crocker wrote:
> It means that talking about such work for MIME does not mean much,
> since we still do not have a demonstration that it is particularly
> popular yet.

Binary transfers aren't popular with HTTP?

I still don't understand the "10 years" comment, either. RFC 1341 defined
a Content-Transfer-Encoding type of BINARY in 1992, while RFC 1830 defined
a binary transfer mode for SMTP in 1995, while RFC 1945 did the same for
HTTP in 1996. That is ~four years between publication of the original spec
and the two most common protocols.

If you originally meant to say that i18n DNS *should* be just like MIME,
then I would agree with that statement for as far as it would carry us.
That would of course entail reducing IDNA down to a simple codec and
defining alternative codecs that protocols could deploy according to their
usage models. It seems that you agree with part of this but not the other
part, although I'm unable to figure out where the line is.

Can you state your issues without using this metaphor?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 20:40:16 -0700

At 12:10 PM 9/4/2002 +0900, Soobok Lee wrote:
> > >MIME (and even RFC2047)encodes texts or descriptors , not ciritical
> > >identifiers like domain names as far as i understand.
> >

All of your note is devoted to very nice description of concepts and 
principles.  However you do not describe any networking technical scenarios 
that will fail.

IDNA is networking standard.

If there is a problem with it, please describe a precise scenario for which 
IDNA will fail, and explain how it will fail.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 20:46:08 -0700

>Binary transfers aren't popular with HTTP?

They are not popular in email.  Please remember that IDNA tackles the 
problem of placing 8-bit data in a 7-bit field, the same as MIME for email.

>I still don't understand the "10 years" comment,

The comment is about how long it takes to make change and it is about being 
careful what we use for making decisions.  Making decisions based on a 
hypothetical future is usually a mistake.  Making a decision based on 
actual practise is always safer and usual makes for better decisions.

>  either. RFC 1341 defined
>HTTP in 1996.

You should worry about the fact that after 10 years, it still does not have 
a particularly major position in Internet mail.

>Can you state your issues without using this metaphor?

My "issues" are that IDNA is the right technical solution for the 
particular set of technical and operational constraints it is targeted.

You think otherwise, so the real question is the basis for YOUR issues.  So 
far, you appear to be preferring to rely on possible futures, and on claims 
that IDNA is somehow special.  Yet the implementation and operational 
impacts of this specialness has not yet been made clear.

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 20:34:32 -0700

Mostly the problem with this thread is that people are trying to debate 
concepts and principles, but they are failing to provide any detailed 
scenarios that cause problems.

>important that people are able to put it back into the original IDNA

If you are printing it, you are not "putting it back" anywhere, so i have 
no idea what you mean.

In any event, as noted, user interfaces deal with multiple data types just 
fine.  There is nothing about an DNA that makes it particularly distinctive 
from other, labeled, structured data types that UIs already deal with.

But mostly this line of discussion continues to fail to distinguish between 
over-the-wire encoding, versus encodings within the host.  After 30 years 
of networking protocols, it would be nice for people to keep this 
distinction clear.

>security consequences.

IDNA strings are unique domain name strings.  They are unambiguous 
identifies.  Nothing that has been presented here alters that simple 
fact.  Hence there is no way of guessing what "confusion" you are referring to.

And, by the way, it has nothing to do with the encoding trick that makes 
IDNA similar to MIME content-transfer-encoding.

d/

----------

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 4 Sep 2002 13:10:03 +0900

----- Original Message ----- 
> IDNA is networking standard.
 
IDNA does not extend the LDH namespace, but just redefine xx--yyy subset of
the space to have new i18n meanings.  They are ASCII domain names that are declared
as displayable in other scripts. networking scenarios around IDNA are the same to
those of ASCII domains, in principle. IDNA may work well with DNS and SMTP networking. 
But with others ones or new ones to come, it would make another obstacles to optimal
i18n of protocols works.

Moreover, all the mess around i18n which does not belong
to "network standard" , was not addressed and just postponed or ignored.
To be usable, security issues and interoperabilsy issues in applications should be 
addressed in IDN standards because IDN will penetrate to all the applications as soon
as we issue some drafts and a few vendors begin to support IDN.
backwards compatiblity consideration wrt networking seems not enough from
the angle of how to fullfull the need for which we try to provide i18n'ed protocols
to end users.

Networking is not enough. Applications' need matters.

Soobok Lee

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 21:34:40 -0700

At 01:10 PM 9/4/2002 +0900, Soobok Lee wrote:
>the space to have new i18n meanings.

Sorry, but IDNA very much does define an enhanced character space for 
domain names.

Yes, it also defines a mapping for those enhanced characters onto the 
existing 7-bit ASCII domain name space, but it is important to distinguish 
between the Unicode domain name, versus the ASCII encoding.

>to "network standard" , was not addressed and just postponed or ignored.

Please provide descriptions of specific usage scenarios that demonstrate 
technical failings that are special to IDNA.

d/

----------

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 4 Sep 2002 13:48:50 +0900

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 04, 2002 1:34 PM
Subject: Re: [idn] Document Status?

> Sorry, but IDNA very much does define an enhanced character space for 

true in display and input (that is what i meant), but the norm is ACE in protocols.
of course, some new application protocols may negotiate to use native-encoding instead.

> technical failings that are special to IDNA.

I am not a vocal opponent of ACE princicple itself. 
The most problems also lies in non-IDNA proposals as fas i know.
But, one severe problem special in IDNA is the troyan horse.

If some company don't want to trust and invite IDN and don't want to modify its applications,
but, IDN is encoded in trusted ASCII and penetrate into the applications and
get trusted by the unmodified applications as other trusted ASCII domains. IN protocol world,
Dynamic DNS updates protocols are affected directly by that holes.

Other one may find other special examples of IDN troyan horses.

Soobok Lee

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 21:56:49 -0700

At 01:48 PM 9/4/2002 +0900, Soobok Lee wrote:
>true in display and input (that is what i meant),

you need to distinguish between the abstract, formal name space, versus the 
over-the-wire encoding of that name space.

the current specification does not make this distinction clear, but that is 
a problem with the documentation, not the formal change.

>get trusted by the unmodified applications as other trusted ASCII domains.

You are concerned that an IDNA string somehow has a lower level of 
authentication than a regular, ASCII DNS string?

This cannot be true, since an IDNA string is a regular ASCII DNS string.

>  IN protocol world,

IDNA introduces no changes to the mechanism for Dynamic DNS updating.

d/

----------

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 4 Sep 2002 14:09:59 +0900

----- Original Message ----- 
> IDNA introduces no changes to the mechanism for Dynamic DNS updating.
 
THey have been suggested may reasons why some companies may not want to trust
and support IDN (IDNA + all other utf8 based proposals) in their applications. 
IDN  introduce ambiguity in higer layers than machine protocols.

By "trust" i mean that 7bit applications accept 7bit ASCII domains as fairly 
"unambiguous" identifiers historically and had been putting trust in it ..
I didn't mean soome trust mechanisms like DNSSEC or X509. Just common trust in ASCII
which is  the greast common divisor in all internationally-used scripts.

IDNA strings does not deserve the same trust as ASCII domains have now in end 
users.

Soobok Lee

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 04 Sep 2002 00:38:52 -0500

on 9/3/2002 10:46 PM Dave Crocker wrote:

> You should worry about the fact that after 10 years, it still does not
> have a particularly major position in Internet mail.

Oh please, that's more of a reflection on deploying features into a
hop-by-hop network than anything. Cripes, ~everything takes a decade to
widely deploy with SMTP. Meanwhile, you are blatantly ignoring the other
side of the coin, which is that protocols like FTP and HTTP had a null
deployment window simply because they did not require encoding (FTP could
ignore it, and HTTP could go straight to binary).

> the real question is the basis for YOUR issues.

My position has been consistent. Regardless, this thread is about your
claim that IDNA is "the same as MIME" which is patently false. They have
different usage models and different architectures. Such a comparison is
useful to the hoi polloi but it is a dead-end as any sort of engineering
discussion point.

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 4 Sep 2002 05:41:54 +0000

Dave Crocker <[email-masked]> wrote:

> you need to distinguish between the abstract, formal name space,
> versus the over-the-wire encoding of that name space.

Just to clarify, this is NOT a picture of the IDNA model:

    +----------+            +---------+
    |          |            |         |
    | abstract |            | encoded |
    | domain   |   <---->   | domain  |
    | labels   |            | labels  |
    |          |            |         |
    +----------+            +---------+

This is a picture of the IDNA model:

    +----------------------------+
    |  internationalized labels  |
    |                            |
    |  +----------------+        |
    |  |  ASCII labels  |        |
    |  |                |        |
    |  |  +--------+    |        |
    |  |  | ACE    |    |        |
    |  |  | labels |    |        |
    |  |  +--------+    |        |
    |  +----------------+        |
    +----------------------------+

There is only one space (internationalized labels), which has a subset
(ASCII labels), which has a subsubset (ACE labels).  The non-ASCII
labels (in the outer ring) are unsuitable for use in IDN-unaware
protocols/formats/interfaces, and the ACE labels (in the center) are
unsuitable for display to users.  Fortunately, there is an equivalence
relation between the non-ASCII labels and the ACE labels, so if you ever
find yourself with a label you can't use, there is an equivalent label
you can use instead.

AMC

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Sep 2002 07:57:09 +0200

Dave Crocker <[email-masked]> writes:

> Mostly the problem with this thread is that people are trying to
> debate concepts and principles, but they are failing to provide any
> detailed scenarios that cause problems.

The failure scenarios have been named, and as a result I think some
are now even discussed in the specifications.  From the top of my
tired head (I'm sure you'll correct my errors):

+ The entire world doesn't use Unicode, which is where IDNA starts.
  There are examples of characters in european charsets that may fail
  to translate into Unicode properly (e.g., greek beta and german ss
  in CP437).  I suspect this might be more common in non-western
  charsets.  If someone has looked into this area closer, I'd
  appreciate a pointer.  The IDN specifications surely doesn't deal
  with it.  Detailed scenario that fails: www.ßeta.com browsed from
  CP437 platform.

+ The choice of Unicode normalization KC has been questioned.  Again
  since I'm familiar with european charsets, I have the simple example
  of normalization of ß into ss.  There are supposedly distinct words
  where this normalization process removes the possibility of
  distinguishing between the words.  Non-western charsets probably has
  more cases like this. Detailed scenario that fails: www.masse.de
  (translation: mass, majority) and www.maße.de (translation: metrics,
  gauges) are indestinguishable.

+ Any modifications to the Unicode code charts or normalizations
  tables destroy stability of IDN.  This is handled by locking IDN to
  Unicode 3.2 (I believe).  I haven't a specific scenario which fails,
  but this will add considerably code complexity in software since
  they need to implement Unicode normalization, Unicode tables and
  possibly also Unicode bidi algorithms internally instead of relaying
  on a unicode implementation in the operating system.  It may seem
  like this problem can't be solved in a better way, but I have a
  feeling a better design could fix this.

+ Unicode normalization and bidi rules interact problematically.
  Consider the string U+05D0 U+0966, it is a forbidden bidi sequence.
  U+2135 U+0966 is not a forbidden sequence.  Yet, U+2135 is
  normalized into U+05D0.  Detailed scenario that fails: STRINGPREP on
  string www.U+2135U+05D0.com work from machines that doesn't perform
  Unicode normalization (which IS optional).  Yes, OK, this is not a
  IDN problem but a STRINGPREP problem, but STRINGPREP seem to come
  out of this group so it is related.

These are things I've discovered by participating here for a month or
two and I don't pretend to understand these issues.  If the
specification doesn't solve, or at least discusses, the issues above,
how will they be implemented correctly?

PS.
  My point of view of IDN is not to enable fancy glyphs with it; it
  is to integrate IDN securely in protocols like TLS, Kerberos,
  OpenPGP and S/MIME which uses domain names for security critical
  things.  What may be sufficient for the web browsing herd may not be
  adequate for the security conscious club.  This focus seems to have
  been neglected.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 23:05:05 -0700

>ignore it, and HTTP could go straight to binary).

1.  Long revision adoption latencies are primarily caused by installed base.

2.  To use your own perspective, DNS is a hop-by-hop system, when viewed 
properly.

>claim that IDNA is "the same as MIME" which is patently false.

The comment was that the encoding approach of IDNA was the same as the MIME 
encoding approach for binary data in a 7-bit environment.  And that, I'm 
afraid, is patently true.

>  They have different usage models and different architectures.

they have the same architecture.  8-bit data translated onto a 7-bit 
environment.

>  Such a comparison is useful to the hoi polloi but it is a dead-end as 
> any sort of engineering discussion point.

Eric, forgive me.  I forgot that you had extensive experience in developing 
and revising these protocols and in seeing them deployed.  As someone new 
to the topic, I often get confused about such these architectural issues.

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 23:14:55 -0700

>+ The entire world doesn't use Unicode, which is where IDNA starts.

Protocol standards rarely cover 100% of all possible situations.

The result is a limitation, not a failure.  The difference is key.

>+ The choice of Unicode normalization KC has been questioned.

Are you claiming that a) the behavior is not well understood, or that b) 
the working group did not reach rough consensus on this matter?  If you are 
claiming anything else, then it is not a "failure".

>   tables destroy stability of IDN.

Even I remember this issue being resolved.  Efforts like these always have 
an issue with outside work being incorporated, and that outside work 
getting revised.

The IETF approach is the usual one:  The specification refers to a specific 
version of Unicode.  If Unicode gets revised, the IETF may consider 
adopting it.  Just because there is a new version of Unicode, the old one 
does not stop working.

>+ Unicode normalization and bidi rules interact problematically.

Please refer to the "are you claiming" response, above.  It applies here, too.

>two and I don't pretend to understand these issues.

As nearly as I can tell, you have raised issues that are not failures in 
the specification, but rather issues about which some people are 
dissatisfied.  There are always people dissatisfied with a 
specification.  That does not mean it has technical failings.

>   adequate for the security conscious club.  This focus seems to have

How do IDN strings involve security issues that are different from classic 
ASCII domain names?

In other words, rather than "neglected" I believe the issue does not exist.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 04 Sep 2002 01:19:58 -0500

on 9/3/2002 10:34 PM Dave Crocker wrote:

>> Dave Crocker <[email-masked]> writes: If I press the PRINT button
>> on an IDNA in my mail reader, it is important that people are able to
>> put it back into the original IDNA
>
> If you are printing it, you are not "putting it back" anywhere, so i
> have no idea what you mean.

I would assume he means typing the printed output into an application,
since that's pretty much what he said.

> In any event, as noted, user interfaces deal with multiple data types
> just fine.  There is nothing about an DNA that makes it particularly
> distinctive from other, labeled, structured data types that UIs already
> deal with.

Few will care if the subject line isn't transcribed properly, but
everybody will care if an email address or URL isn't transcribed properly.
To stick with the current example, this means that printed output will
also have to use the encoded form if it is to survive. Even with mail
bodies this isn't a problem since the body itself is still relatively
unstructured, and something like kanji text being exchanged between two
japanese-speaking users is likely to be understandable by those users even
if it is packaged in non-MIME form. This is patently false with the email
address however, since the headers will break the protocol.

> But mostly this line of discussion continues to fail to distinguish
> between over-the-wire encoding, versus encodings within the host.

And when it does get raised, it gets dismissed as out-of-scope.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 04 Sep 2002 01:41:38 -0500

on 9/4/2002 1:05 AM Dave Crocker wrote:

> 2.  To use your own perspective, DNS is a hop-by-hop system, when
> viewed properly.

Indeed it is, with proxies and replication and everything. But we're not
just talking about DNS, we're also talking about the applications that
have to accept domain names and use them for in-band structured data. The
majority of the applications which will make use of domain names do not
suffer these considerations, and they can be enabled with a simple option
negotiation sequence.

I have also said that a *complete* migration of the DNS service would be a
20 year effort, so I don't know what your statement hopes to disprove.

> they have the same architecture.  8-bit data translated onto a 7-bit

MIME provides multiple data-types with multiple codecs, with applications
being able to choose among the data-types and codecs that are best suited
to that specific usage. IDNA provides a single [usable] data-type with a
single codec. They are completely different architectures.

> Eric, forgive me.  I forgot that you had extensive experience in
> developing and revising these protocols and in seeing them deployed.

Your mix of ignorance and paternalistic politics is what makes people
think of you as an intellectually and spiritually weak troll, crocker.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 23:44:25 -0700

>I would assume he means typing the printed output into an application,

the printed output is a valid, 7-bit domain name.  typing it in will work 
the same as all other 7-bit domain names.

>Few will care if the subject line isn't transcribed properly, but

1.  No one has said that UI issues are not important.

2.  The UIs handle these sorts of things quite well already.

>  This is patently false with the email

I don't know what "headers" you mean, but in any event, the ACE version of 
an IDN is valid to type in anywhere that a "regular" 7-bit ascii domain 
name is allowed.

So, if you are claiming that it won't work, you still need to provide a 
specific, concrete scenario that will fail.

>And when it does get raised, it gets dismissed as out-of-scope.

Not quickly enough.

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Wed, 04 Sep 2002 00:11:31 -0700

At 01:41 AM 9/4/2002 -0500, Eric A. Hall wrote:
>Indeed it is, ...

you were somehow implying that email's hop-by-hop nature was a relevant 
point of distinction.

i was merely trying to take that perspective and note that it applies 
equally to the DNS.

>single codec. They are completely different architectures.

The comparison was not between their full architectures.

It was between the encoding methods, in particular the one MIME uses for 
binary data...  Does it help you if 'base64' is cited explicitly?

So, the points of larger difference that you are citing were not part of my 
reference.  I was referring to a specific MIME base64 
content-transfer-encoding scheme as being architecturally similar to IDNA's 
ACE scheme.

>think of you as an intellectually and spiritually weak troll, crocker.

thanks for the demonstration of professional superiority.  we all can learn 
from it.

d/

----------

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 04 Sep 2002 13:26:46 +0200

On 05:46 04/09/02, Dave Crocker said:
>You think otherwise, so the real question is the basis for YOUR 
>issues.  So far, you appear to be preferring to rely on possible futures, 
>and on claims that IDNA is somehow special.  Yet the implementation and 
>operational impacts of this specialness has not yet been made clear

Dear Dave,
I am afraid you base your comments on what you consider as the standard 
common today practice. That practice for you today is to use standard 
writing when sending a mail or entering a domain name. To universally 
enlarge that capacity (such as using 16 or 64 bytes character coding) is 
for you a future scenario of middle interest.

Our today practice is to be blocked by a passed scenario (8 bits) in not 
using the standard writing when sending a mail or entering a domain name. 
We are only trying to remove asap that specialness. Because we do suffer 
for years of that limited implementation and of the operational impact on 
all our other application and common life. As if you were obliged to use 
computers only in Cyrillic uppercases.

As long as this has not been accepted, we obviously have an understanding 
and a wording problem. Which may result into a disinterest, and alternative 
solutions to be used, there too.
jfc

---

From: Soobok Lee <[email-masked]>
Date: Wed, 4 Sep 2002 21:22:50 +0900

On Wed, Sep 04, 2002 at 01:33:21PM +0200, JFC (Jefsey) Morfin wrote:
> On 06:10 04/09/02, Soobok Lee said:
> 
> >Networking is not enough. Applications' need matters
> 
> hmmm. ....
> 
> 1. are you sure Internet is about networking or about computer remote access
> 
> 2. IMHO networking must match applications requirements. Otherwise Networks 
> are of no use. But networking is allowed to make it smartly the best way 
> for both. Massaging (namepreparation) IMHO is at the hedge of the 
> networking since you may want to customize it. But it is stall networking 
> because it should be neutral to the application. It is not information 
> processing as it is ancillary service (as per USC definition of 
> contributing to the data transfer)
> 
> Do we agree on that? 

Networking serves Applications, as SMTP serves to move RFC822-compliant
messages between two messaging Applicatons. IDN promises to improve the
presentation layers of most internet applications by facilitating 
localized access to domain names. So, IDN's inception itself was to be 
user-oriented/user-friendlier.  To connecting two host machines does not 
need i18n of domain names nor user-friendliness, Ascii one is enough. 
IDN goal is closer to Applications.

IDN's expanded character repoitores introduce various ambiguity/security
problems into DNS and then into all applications that accepts IDN strings.
IDN strings should be dealt with additional cares and cautions, 
but they are moved silently as encoded in trusted ASCII encoding so that
most applications cannot notice that happens. That's why i call that kind
of tunneling a troyan horse from the rigorous/conservative security viewpoints.
And that is the very point where MIME(base64) encoding of Subject: header
and the ACE-encoding of email addressess divorce far from each other.

Soobok Lee

---

From: Soobok Lee <[email-masked]>
Date: Wed, 4 Sep 2002 22:09:40 +0900

> > contributing to the data transfer)

Moreover, IDN and ASCII domains names are used as not only mnemonic handles
to numeric IP address for networking but also   identifiers  like email 
addresses. For example, MS Passport membership databases use  email 
addressess as primary key identifiers. We can find similar identifier use
of domain names in server certificates and individual email certificates
that form one component of critical PKI-based authentication framework for
the internet.

> IDN's expanded character repoitores introduce various ambiguity/security

s/repoitore/repertoire/

Soobok Lee

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 4 Sep 2002 08:56:38 -0700

>   with it.  Detailed scenario that fails: www.ßeta.com browsed from

This is not a case of a character "failing to translate to Unicode
properly."  That would be true if we were talking about a Glagolitic
letter or Egyptian hieroglyph.  This is a case of ambiguity between
legacy character mappings.

The argument here is that Unicode should not be used for intersystem
communication because characters in legacy character sets have a history
of being overloaded.  Arguments of this type are gradually disappearing
as people begin to realize that the problem exists with or without
Unicode.

The alternative would be to stick with legacy character sets and tag all
IDN's with the character set.  This doesn't solve the overloading
problem, since non-CP437 applications still must decide whether to
convert CP437 0xE1 to German ss or Greek beta.  And you would
additionally run into the ISO 2022 problem, in which applications are
expected to implement the entire repertoire of character conversion
tables, but most don't because of the overhead.  Are you sure that every
Unix, Linux, Windows, and Mac client would provide a mapping table for
CP437?

Unicode publishes informative mapping tables to various legacy character
sets, including CP437.  They map CP437 0xE1 to U+00DF LATIN SMALL LETTER
SHARP S.  Although these mappings are only informative, an application
could reasonably be expected to implement them.  (In any case, it must
be said that CP437 is a lousy choice for interchanging Greek text -- 737
or 869 would be better -- so the mapping to German ss is hardly
counterintuitive.)

>   gauges) are indestinguishable.

If NFKC were not used, the security mavens would be out in droves,
complaining about the numerous lookalike characters that could be used
to fool unsuspecting users.

Most languages have "minimal pairs" of words that differ only in case.
Few people complain that the existing DNS cannot distinguish between
words such as "mark," what you do with a pen on paper, and "Mark," a
proper name.  The same is true for Masse and Maße.  The DNS is not
supposed to handle "names" in languages on this level.  It is
unfortunate that the term "domain name" has come to convey the meaning
of language-aware names, since domain names are merely identifiers,
hopefully more mnemonic than strings of integers separated by dots.

>   feeling a better design could fix this.

Adding more characters to Unicode does not destroy the stability of
anything, because the normalization tables are supposed to be frozen and
new characters will not have compatibility decompositions.  I know there
have been changes to the normalization of two characters since Unicode
3.0 -- not exactly an overwhelming number -- but part of the rationale
was that applications such as IDN that require such stability were not
yet available.  It is extremely unlikely that we will see any changes to
normalization after IDN is rolled out.  We will, of course, see
thousands of new characters, but as I said, that causes NO stability
problems.

>   out of this group so it is related.

Stringprep, the generic algorithm, makes normalization optional.
Nameprep, however, is a specific profile of stringprep that *requires*
normalization form KC.

U+05D0 is HEBREW LETTER ALEF.
U+2135 is ALEF SYMBOL.
U+0966 is DEVANAGARI DIGIT ZERO.

If you create a domain name consisting of some combination of these, and
it does not work on some systems due to differences in normalization
and/or bidi, you are unlikely to garner much sympathy for your choice of
domain names.  This is a pathological example and you know it.

To paraphrase Churchill, Unicode is the worst character encoding
standard except for all those others that have been tried from time to
time.

-Doug Ewell
 Fullerton, California

---

From: Soobok Lee <[email-masked]>
Date: Thu, 5 Sep 2002 22:25:35 +0900

On Wed, Sep 04, 2002 at 10:09:40PM +0900, Soobok Lee wrote:
> > IDN's expanded character repertoires introduce various ambiguity/security

Above paragraph seems somewhat offending to the ACE principle. So, I am oblidged
to add the next well-known virtus of ACE to prevent anyone from misunderstanding 
ACE principle, as I am not such extremist opponent of ACE concept itself.

Even when some email server operators want to trust/support *any* IDN 
email addresses but does want to upgrade any server s/w, ASCII-tunneled ACE-encoded
email addresses would pass through the old 7bit server and successfully be delivered
to the recipients.  In this cae, ACE will the free gift (networking) to them.
This is the virtue of ACE principle and the BASE64 used MIME.

Soobok Lee

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Sep 2002 04:15:51 +0200

[snip]
> Are you claiming that a) the behavior is not well understood, or that
> b) the working group did not reach rough consensus on this matter?  If
> you are claiming anything else, then it is not a "failure".
[snip]

You said people in this thread argued without having detailed specific
scenarios that fail in mind.  I tried to provide some specific such
scenarios that I had in mind.  I don't claim any of the above, nor
that IDN is a failure.

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 7 Sep 2002 10:17:46 +0200 (CEST)

> The current specification has not made at least one essential, difficult 
> decision.  As a consequence, someone registering an IDN for use with email 
> or the web cannot know the correct set of characters available to them.

Which text in the specification are you referring to?
I need specifics to understand your issue.

The only text I recall which has some bearing on this is:
  It is expected that some name-handling bodies, such as large
  zone administrators and groups of affiliated zone administrators, will
  want to limit the characters allowed in IDNs further than what is
  specified in this document, such as to prohibit additional characters
  that they feel are unneeded or harmful in registered domain names.

I don't see how registries limiting the set of Unicode code points
that can be used in a part of the name space has any negative impact on 
interoperability; registries limit the types of names for various policy
reasons already (such as only allowing registered companies in some
parts of the name space) without any adverse effect on interoperability.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 7 Sep 2002 10:37:55 +0200 (CEST)

> This is a picture of the IDNA model:

Hmm - I wonder if putting that picture in the draft would result in
less confusion.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 7 Sep 2002 10:31:38 +0200 (CEST)

> the area directors that would need to make that decision.

Perhaps I should give my views on this then ...

> rather than multiple languages, but I don't know of such a word.

I think such a change at this point in time would be unwise.
If nothing else, it would probably cause us to replay 6 months
worth of discussion around languages vs. scripts vs. codepoints vs ...

But even having this discussion seems to be a distraction from
gettting IDNA finished.

  Erik

---

From: "vinton g. cerf" <[email-masked]>
Date: Sat, 07 Sep 2002 09:35:30 -0400

I think erik is right about that - despite the misnomer (in my opinion), better to get on with implementation experience than continue to argue over intangibles.

v

Vint Cerf

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Sep 2002 09:01:06 -0700

>Hmm - I wonder if putting that picture in the draft would result in

I kept looking at that picture and stayed confused.  Until this morning 
when I finally realized that that the picture is exactly correct.

In other words, the process of resolving the confusion is exactly what the 
picture is good for.

It does not show a connection between the outer-most box and the inner-most 
box, but a) it's not clear how to create one usefully, and b) it is not 
essential for showing the difference between the name space and the 
encoding space.

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Sep 2002 09:16:22 -0700

>I need specifics to understand your issue.

Erik,

A moment of process concern:

         You have been given the specifics, including a specific Last Call 
posting to the IESG, private discussion from me, and an independent 
internet draft on the subject.

         Your question implies rather strongly that the IESG did not 
consider this input.  The input was provided 2 months ago.  If that input 
was not understood, why were no clarifications requested?

         I will add that asking someone to point to the place in a document 
where something is *missing* is a rather curious assignment.  How can one 
point to something that does not exist?

To provide you with the specifics, again:

         The current DNS has usage for email and web addresses that limits 
the range of valid characters.  IDN does not define a parallel 
structure.  The implication is that IDN strings do not have different 
ranges of valid characters for email/web domain names and for, for example, 
domain name tags for SRV records.

         If it is correct that there is no difference, that should be 
stated in the document.  Given the history with ASCII domain names, it is 
essential to document this issue explicitly.

         I will again note that even one of the IDNA authors is under the 
misapprehension that the set of valid characters might, somehow, be 
restricted later.  The idea that we do not get to declare existing names 
invalid seems to be absent from the thinking on this topic.

The simple questions are this, Erik:

         I want to register a Unicode domain name for use in my email 
address.

         What are the set of valid Unicode characters?

         Where is this documented?

>   zone administrators and groups of affiliated zone administrators,
>...

I am hoping that I am misunderstanding what you have just written, Erik.

You are suggesting that the set of valid characters -- leaf 
characters?  intermediate node characters? -- will depend upon the portion 
of the DNS tree that the name is under?  This is a fundamental change to 
the DNS.

Since you disagree, please cite an existing example of such a dependency, 
on place in the tree, in the current DNS.

d/

ps.  you might also wish to comment on the fact that the IDNA specification 
makes a formal increase to the set of valid characters, from a subset of 
ASCII to (a subset of?) Unicode, yet this fact is not documented in the 
current specification.

----------

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 8 Sep 2002 01:58:35 +0000

> Hmm - I wonder if putting that picture in the draft would result in

Maybe, although I must warn you that the above picture is simplified,
and contains a slight lie.  The box called "ASCII labels" is really
"labels X such that Nameprep(X) is ASCII".  Let's use the phrase
"effectively ASCII labels" for that.  An accurate and complete picture
would be:

    +-----------------------------------+
    | internationalized labels          |
    |                                   |
    |  +---------------------------+    |
    |  | effectively ASCII labels  |    |
    |  |                           |    |
    |  |  +--------------+         |    |
    |  |  | ASCII labels |         |    |
    |  |  |              |         |    |
    |  |  |  +-----------+----+    |    |
    |  |  |  |    ACE labels  |    |    |
    |  |  |  |           |    |    |    |
    |  |  |  |           |    |    |    |
    |  |  |  +-----------+----+    |    |
    |  |  +--------------+         |    |
    |  +---------------------------+    |
    +-----------------------------------+

Unfortunately, the picture is starting to look daunting.  The exact
subset relationships between every pair of the various sets is not so
important, as long as you know these two:

  * The ASCII labels are a subset of the internationalized labels.
  * The ACE labels are a subset of the internationalized labels.

The other things you need to know to make sense of the model, which are
not easily depicted, are:

  * For every internationalized label, there is an equivalent ASCII
    label.  ToASCII can compute it.  You need ASCII labels for old or
    IDN-unaware protocols.

  * For every internationalized label, there is an equivalent non-ACE
    label.  ToUnicode can compute it.  You want non-ACE labels for
    display to users.

AMC

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 08 Sep 2002 18:18:34 +0200

Having a larger box called "Unicode strings" outside all of those
boxes would be useful too.  I think the picture, and your discussion
of it, helps alot for the understanding of IDNA.  A daunting picture
conveys the information that IDNA isn't trivial, which is a good mind
set to have when implementing it.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 9 Sep 2002 11:03:09 +0200 (CEST)

> internet draft on the subject.

Dave,

I have to vested interest in the IDNA specification but I'm merely
trying to help move things along in a productive fashion based on the
wishes of the WG rough consensus as guaged and expressed by the WG co-chairs
(which is to advance the set of specifications).

In my personal view the most productive way to get changes into the WG
rough consensus documents is to point out specific issues and suggested
text from clarifying things, since I have a hard time understanding how
the independent drafts can actually make the process move forward in
an effective manner. Of course, the WG is free to take a different
tack than my personal view e.g. to adopt your drafts and
move them forward instead of the current set of drafts - all I would expect
is discussions on the WG mailing list and a note from the co-chairs
to tell me to hold off moving the current IDNA draft through the process.

> point to something that does not exist?

Perhaps by suggesting specific limited text (a paragraph or so) which
fills in the missing piece?

> essential to document this issue explicitly.

Send a suggested paragraph of text.

> invalid seems to be absent from the thinking on this topic.

And I will note that I brought up exactly this issue in an email
sent to the IDN list on May 6th with the subject
"IDNA questions".
The resulting change in the IDNA document based on that comment
was rather minor, and I would welcome proposed text that make
the intent more clear.

> ASCII to (a subset of?) Unicode, yet this fact is not documented in the 

To me this is clear from the Abstract in the idna spec.
But perhaps a sentence of two could be added to make this more clear.

   Erik