Subject: [idn] Figuring out what can be displayed (was: Re: Document Status))

From: John C Klensin <[email-masked]>
Date: Tue, 10 Sep 2002 10:10:52 -0400

Coming back to an old-ish thread whose implications I think I
have finally managed to explain to myself...

--On Tuesday, 03 September, 2002 02:56 +0000 "Adam M. Costello"
<[email-masked]> wrote:

> 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.

In a number of, probably most, contemporary and recent operating
systems, applications actually have no clue what "they" can
display.  They organize and format a string and pass that string
to some sort of TTY or print routine, and the device driver /
display interface routines do whatever they think is appropriate
with that string.  It is only very rarely the case that the
application can query the display/TTY routines about whether a
particular character sequence can be displayed reasonably
(whatever "reasonably" means).  And, for most contemporary
operating systems, that is the way it _must_ be: the capability
of stream diversion by a calling agent or operating system or
file manipulation call (in U**x terminology, think "pipe")
implies that the display capabilities of "an application" is
unknown to the code of that application at the time it is
executing.

So, an application must, ultimately, either decide that its
operating environment can handle Unicode acceptably, convert the
ACE form to Unicode, pass that off to the display driver in some
locally-preferred form, and hope for the best.  If the operating
system and display cannot process and display Unicode, something
will, no doubt, be displayed -- some hex representation, black
blocks, etc., depending on the system and configuration settings
-- but it almost certainly won't be ACE.  Or the application
must decide that it can't know and therefore must display the
ACE form always, in which case IDNA is not a solution, or even
helpful, to the effort to provide user-level IDNs turns out to
be hopeless.

If, in order to be fully-conformant, a specification requires an
implementation to make a decision based on something it can't
know, that is, IMO (in the language of RFC 2026) a "technical
omission", and one of fairly serious proportions.  If we cannot
provide a better model, the text cannot, I think, say anything
stronger than that the application MAY show either the ACE or
the Unicode form, at its discretion, and leave this issue up to
user pressure and implementation quality.

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

I agree.  Non-discriminatory.  Screwed either way :-(

     john

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 10 Sep 2002 21:01:00 +0000

John C Klensin <[email-masked]> wrote:

> > 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.
>
> So, an application must, ultimately, either decide that its operating
> environment can handle Unicode acceptably...
>
> Or the application must decide that it can't know

Those are not the symmetric choices.

> and therefore must display the ACE form always...

That does not follow from not knowing.

The cases are:

 1. The application can determine whether the environment can handle the
    non-ACE form.  In this case, exactly one of the two recommendations
    applies, and it's perfectly clear what to do.

 2. The application cannot know.  It is then faced with the following
    two symmetric choices:

    2a. Optimistically try to display the non-ACE form, which might
        or might not work.

    2b. Pessimistically display the ACE form, which is guaranteed to
        look like garbage to humans and guaranteed to be okay for
        software.

> implementation to make a decision based on something it can't know,

The spec says "SHOULD".  RFC 2119 says "there may exist valid
reasons in particular circumstances to ignore" a SHOULD.  I think
the unavailability of sufficient information about the environment
to determine whether the recommendation applies is a particular
circumstance that qualifies as a valid reason to ignore the SHOULD.

> that is, IMO (in the language of RFC 2026) a "technical omission", and
> one of fairly serious proportions.

It's an omission if something has been omitted.  What has been omitted?

> If we cannot provide a better model, the text cannot, I think, say
> anything stronger than that the application MAY show either the ACE or
> the Unicode form, at its discretion, and leave this issue up to user
> pressure and implementation quality.

We can do better than that.  When the application can determine whether
the non-ACE form can be displayed, we don't need to leave it up to the
application's discretion, we can prescribe the proper choice.

AMC

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Sep 2002 18:36:31 -0400

Adam,

With all due respect, this does not pass the laugh test.  Yes,
there are grounds for ignoring a "SHOULD".  That is why we call
it "SHOULD" and not "MUST".  But we don't describe things that
violate SHOULDs with phrases like "fully conforming", regardless
of the cause (please see RFC 1122 and 1123, full Internet
Standards, which 2119 does not supercede/obsolete).  I chose my
language carefully.

I decided caution and politeness was appropriate in my previous
note.  But, to drive the point home here, please identify at
least two operating systems in common use today in which an
application can accurately determine that it can display a
particular, arbitrarily-chosen, Unicode character.  (Determining
that it can't is easy -- any operating system that doesn't
support passing of Unicode characters to a print/display routine
would essentially permit applications to make that determination
at compile-time.)

     john

--On Tuesday, 10 September, 2002 21:01 +0000 "Adam M. Costello"
<[email-masked]> wrote:

>> > 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.
>> 
>> operating environment can handle Unicode acceptably...
>> 
>  1. The application can determine whether the environment can
> handle the     non-ACE form.  In this case, exactly one of the
> two recommendations     applies, and it's perfectly clear what
> to do.
> 
>  2. The application cannot know.  It is then faced with the
> following     two symmetric choices:
> 
>     2a. Optimistically try to display the non-ACE form, which
> might         or might not work.
> 
>     2b. Pessimistically display the ACE form, which is
> guaranteed to         look like garbage to humans and
> guaranteed to be okay for         software.
> 
>> If, in order to be fully-conformant, a specification requires
>> an implementation to make a decision based on something it
>> can't know,
> 
> reasons in particular circumstances to ignore" a SHOULD.  I
> think the unavailability of sufficient information about the
> environment to determine whether the recommendation applies is
> a particular circumstance that qualifies as a valid reason to
> ignore the SHOULD.
> 
>> that is, IMO (in the language of RFC 2026) a "technical
>> omission", and one of fairly serious proportions.
> 
>> If we cannot provide a better model, the text cannot, I
>> think, say anything stronger than that the application MAY
>> show either the ACE or the Unicode form, at its discretion,
>> and leave this issue up to user pressure and implementation
>> quality.
> 
> We can do better than that.  When the application can
> determine whether the non-ACE form can be displayed, we don't
> need to leave it up to the application's discretion, we can
> prescribe the proper choice.
> 
> AMC
> 
> 
>

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 11 Sep 2002 00:36:30 +0000

John C Klensin <[email-masked]> wrote:

> Yes, there are grounds for ignoring a "SHOULD".  That is why we call
> it "SHOULD" and not "MUST".  But we don't describe things that violate
> SHOULDs with phrases like "fully conforming", regardless of the cause

Okay, but I don't see why that's a problem.  If the spec says you SHOULD
do something and it's simply impossible to do it, then you do the best
you can, you don't conclude that you can't implement the spec.  On the
other hand, if the spec had said MUST, then you would have to conclude
that you can't implement the spec.

That said, I don't really care whether the spec says "SHOULD" and
"SHOULD NOT", or "encouraged" and "discouraged", when talking about
choosing which form of label to display.  That would be a technical
change that I don't see the need for, but you can try convincing the
other authors and the area directors.

> please identify at least two operating systems in common use today in
> which an application can accurately determine that it can display a
> particular, arbitrarily-chosen, Unicode character.

This is not my area of expertise, but after poking around on the web, I
found two such platforms:

In Java, Font.canDisplayUpTo(String) will tell you whether a given font
can display a given string.

In MacOS X, NSFont.coveredCharacterSet() will return the set of Unicode
characters that a given font can display.

AMC

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Sep 2002 21:23:20 -0400

--On Wednesday, 11 September, 2002 00:36 +0000 "Adam M.
Costello" <[email-masked]> wrote:

>> Yes, there are grounds for ignoring a "SHOULD".  That is why
>> we call it "SHOULD" and not "MUST".  But we don't describe
>> things that violate SHOULDs with phrases like "fully
>> conforming", regardless of the cause
> 
> Okay, but I don't see why that's a problem.  If the spec says
> you SHOULD do something and it's simply impossible to do it,
> then you do the best you can, you don't conclude that you
> can't implement the spec.  On the other hand, if the spec had
> said MUST, then you would have to conclude that you can't
> implement the spec.

No one is asking for MUST here.  I'm arguing that it can't make
the statement it makes about selection criteria and still use
SHOULD.

> That said, I don't really care whether the spec says "SHOULD"
> and "SHOULD NOT", or "encouraged" and "discouraged", when
> talking about choosing which form of label to display.  That
> would be a technical change that I don't see the need for, but
> you can try convincing the other authors and the area
> directors.

This may be the root of several differences of opinion about the
document.  I tend to take the notion of a standards-track
document seriously, and that includes being able to understand
when something does, or does not, conform.  To the degree to
which the specification has user-visible implications, that also
means that the behavior, as seen by the user, should be
predictable (or the areas in which it is not should be clearly
delineated).

Of course, ymmd.

>> please identify at least two operating systems in common use
>> today in which an application can accurately determine that
>> it can display a particular, arbitrarily-chosen, Unicode
>> character.
> 
> This is not my area of expertise, but after poking around on
> the web, I found two such platforms:
> 
> In Java, Font.canDisplayUpTo(String) will tell you whether a
> given font can display a given string.
> 
> In MacOS X, NSFont.coveredCharacterSet() will return the set
> of Unicode characters that a given font can display.

I don't think Java is an OS, but let's not quibble.  In both
cases, if I understand your description, what these functions
are providing is information about whether a given string can be
displayed given a font and a device capable of rendering that
font.  But the first is only vaguely knowable (again, think
about the cases in which program display output may be piped, as
a string, to another application).  And the second is, in the
general case, not knowable at all.

And that doesn't even start to mention the cases in which the
"native" CCS used on the local operating system is different
from Unicode and the local display fonts are bound to it.

Please note that, in this case, I'm not arguing that there is
anything wrong with IDNA conceptually.  I am suggesting that the
text of the specification is somewhere between misleading and
badly broken _as a document being considered for
standardization_.   If we can give application writers a
specification about what they are expected to do, one that
testers can test and evaluate against, then we should certainly
do so.  If we cannot, if we are expressing a wish about what
will happen where the actual choice depends on the risks an
implementor is willing to incur, then the specification language
should not be stronger than "MAY" and we probably need some
additional "security considerations" notes.

regards,
      john

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 11 Sep 2002 12:12:44 +0200 (CEST)

idna-11 says:

> 3) ACE labels obtained from domain name slots SHOULD be hidden from
> users except when the use of the non-ASCII form would cause problems or
> when the ACE form is explicitly requested.

Seems like John is asking for
3) ACE labels obtained from domain name slots SHOULD be hidden from
users when it is known that the environment can handle the non-ACE form, except
when the ACE form is explicitly requested.

When it is not known whether the environment can handle the non-ACE form, 
the application MAY use the non-ACE form (which
might fail e.g. by not being displayed propertly) or it MAY instead use the
ACE  form (which will look unintelligle to the user).
--

I think something like the above text is better than what is in the document.

  Erik

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Sep 2002 07:09:13 -0400

--On Wednesday, 11 September, 2002 12:12 +0200 Erik Nordmark
<[email-masked]> wrote:

> idna-11 says:
> 
>> 3) ACE labels obtained from domain name slots SHOULD be
>> hidden from users except when the use of the non-ASCII form
>> would cause problems or when the ACE form is explicitly
>> requested.
> 
> 3) ACE labels obtained from domain name slots SHOULD be hidden
> from users when it is known that the environment can handle
> the non-ACE form, except when the ACE form is explicitly
> requested.
> 
> When it is not known whether the environment can handle the
> non-ACE form,  the application MAY use the non-ACE form (which
> might fail e.g. by not being displayed propertly) or it MAY
> instead use the ACE  form (which will look unintelligle to the
> user). --

That would certainly meet my needs.  My personal hypothesis that
the first case ("when it is known that the environment...") is
null in practice is not problematic in this form, whether it is
correct or not.
 
> I think something like the above text is better than what is

Indeed.
     john

---

From: Soobok Lee <[email-masked]>
Date: Wed, 11 Sep 2002 20:55:14 +0900

> When it is not known whether the environment can handle the non-ACE form, 

The next two options are  "mutually exclusive" ones ?   

> ACE  form (which will look unintelligle to the user).

how about to add this ?

  "or most preferrably, it MAY use both forms displayed side-by-side".

BTW, if IDN display issue deserves this specification, why doesn't IDN  copy&paste 
recommendation  have its place in the document ?
I think copy&paste is a kind of higher-layer communication protocol between processes
which may reside on the same machine or on the two different machines. That requires
proper negotiations between applications/OSes to work correctly.

Soobok Lee

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 11 Sep 2002 14:23:50 +0200 (CEST)

>   "or most preferrably, it MAY use both forms displayed side-by-side".

While we might not want to go into what is preserved (since different
folks probably have different preferences), it wouldn't hurt to
point out that both forms could be used i.e. that the MAYs are not
mutually exclusive.

Note thatIn the case of an actual display it is likely to be possible to use 
both, but there are cases of use (such as the output from a textual
application  running under xterm) where the output format might be constrained
to only one field which contains the address.
But I don't think the document needs to go into that detail.

> BTW, if IDN display issue deserves this specification, why doesn't IDN 
> copy&paste  recommendation  have its place in the document ?
> I think copy&paste is a kind of higher-layer communication protocol between
> processes which may reside on the same machine or on the two different
> machines. That requires proper negotiations between applications/OSes to
> work correctly.

I think this would be a slippery slope. If we think copy&paste
needs to be specified in the standard, then the case can be made
the other implementation specific inter-application communication mechanisms
(such as Unix pipes etc) warrant the same level of specification.

Having said that, I wouldn't mind seeing a well-informed and well-written
informational document which discusses implementation issues around copy&paste
if such a document provides useful information to the community.

  Erik

---

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

On Wed, Sep 11, 2002 at 02:23:50PM +0200, Erik Nordmark wrote:
> I think this would be a slippery slope. 

I agree.

> If we think copy&paste

Sure it is. copy&paste is the only available input method of exotic foreigh scripts
to most end users. I think IDN copy&paste issue is closer to IDN *input* issue.
Input and Display should receive the same concerns.

> if such a document provides useful information to the community.

Do you think above IDN display issue can be separated from the IDNA document and 
then be put into new "Informational" supplementary document ?

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 11 Sep 2002 14:51:55 +0200 (CEST)

> Do you think above IDN display issue can be separated from the IDNA document
> and  then be put into new "Informational" supplementary document ?

Which "display" issue?

The thing for which I suggested new text, based on the comments on the list,
is careful to talk about "use" - not "display".
The term "use" covers everything - copy&paste, display, write to stdout in Unix
(which might be a pipe), etc.

Discussing specific uses, such as display or copy&paste, would be better
served  by a well-written informational document.

  Erik

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 11 Sep 2002 15:49:50 +0200

Gentlemen,
I have discussed here the IDNA issue. I have related with Adam Costello on 
the list and off list and I thank him for that. I have heard the different 
remarks of many. I will now tell you how I will document and implement my 
axcess engine system "IDNA" support.

I offer that to permit an analysis on a real project. I do not expect to be 
criticized on religious/theoretical grounds but to be helped towards a 
better end-user and OPES support, in a way creating the minimum discrepancy 
or no discrepancy with the standard you propose.

I do this because I fight for my own business survival in a real 
international world, not as a corporate manager or a distinguished 
academic. I only possibly paid by real customers with real users.

My premises:

1. I live for 25 years (1977) in the international data communications 
world. I always made my money there for ma family, except since I came into 
the IP world. I still accept it as a long investment period.

2. Since the very beginning I am involved with the international namespace 
(INS). It interconnected in 1984 with DNS (there are some differences in 
perspectives quoted by John Klensin who was not involved here by then but 
has a command of the Internet history. Probably because of the time flow, 
and because when you build a gateway there is by nature a male and female 
perceptions). This is of low interest. What is of interest is the 
experience: we must take advantage from the pros of both sides and avoid 
the cons of both sides (I understand that is what he means). This gives me 
an unique experience about the way the real world behaves; and some more 
intuitive knowledge of the needs and constraints than those who related on 
the matter with Govs, operators, market, corporates, law makers, end users, 
local tech support, end-application developers. Sorry to quote that: it is 
only to explain why I suppose this mail might be of use.

3. for 20 years the only thing which really worked and made the "Internet" 
in most people minds is the DNS part of the namespace. The reasons why it 
works is because it is stable, simple and most of all consistent with 
intuitive addressing feeling.

I co-created the namespace in a form which developed all over the world,. 
But with a semantic which would NOT have had the same impact as the DNS.

We started with the root names, then from LEFT to RIGHT (as in a sorts, 
disk directories etc.) we permitted operators to add hostname as an 
extension, then sub-hosts. We created the hierarchy, but it was a mess.

Because we had no zone (as in IP addresses). What the DNS brought was to 
respond intuitively to the need of the users in sorting out clearly that 
mess. The reversing from right to left at the gateway and the use of the 
"." as a reversing indicator did it all. RFC 920 the "prefix" of the time 
was the suffix ".arpa".
(When you start with an unique thing you start with two: it and not it. Two 
is by nature a family and a family grows).

It did it all, because the resulting addressing logic was brainware 
consistent with postal addressing and EDI rules. Country last. And you can 
keep adding details first. Like on an envelope the name (e-mail name) comes 
first (and as in the "vielle France" etiquette: the use the "@" [at the 
proper "à Monsieur," place] as it was created for this in Middle-Age (@ is 
latin "ad"). This means a brainware consistent system with an habitus of 
more than 8 centuries.

We kept BOTH system working. We interfaced a few people to ARPA in right to 
left hierarchy and supported in left to right the numeric names X121 
hierarchy. From 1982 to 1986 I carried the same task as IDNA - but the 
other way : instead of expanding from 38 characters to billions, I reduced 
from 36 to 10. For the same public.

 From experience, the reason why it worked (IMHO) is that we adapted to the 
least able technology. We were using names and had to support digital only 
addresses. We used "numeric names". But we had all the capacities of the 
names, so when Transpac was only using an IP-address like scheme , we had 
the flexibility of a complete real time, flexible and powerful database. So 
we proposed value added services but not a new system.

I think the only way IDNA can succeed is the same way. Unicode is the 
powerful system: DNS is the less powerful one. I am an seaman: the speed of 
a convoy is the speed of the slowest vessel less the zig-zags. IDNA must be 
considered as a DNS service, subject to the constants of a dual system.

IDNA can only be DNS value added, not as an alternative system, even 
embedded.. The only alternative system would be to study, specify, develop, 
experiment a new DNS. IMHO it cannot be done in two minutes (IMO it will 
take years and due to the political implications that it is a big, big task 
ahead which will involved 190 countries universities, Telcos, Govs, 
communities). I also think it cannot be done one shot. This is why I 
suggest to look into DNS.2 (improving stabilizing the system, its 
operational architecture, its political insertion, etc... in compatible way 
with the current DNS - I do not even know if we need to increase the 
character set). This is why I also work on top of it on extended DNS 
services, like IDNA, authetification, access engines, etc (DNS+). This is 
the rational of the Dot-Root proposition ( http://dot-root.com ) still in 
infancy and only partly documented in English. But with gaining interest.

So I only consider serious and conform use of the DNS: the rule and the 
bible. Errors/tricks in using it are of no concern to me. Errors and tricks 
do not make the basis for a rule (this is a basis of the Roman Law and of 
social life).

There is a hierarchy of the addressing information. That hierarchy is 
necessary to get the next info. There is no use to know an ASCII or Unicode 
the forename of someone if you do not know the name, the city and the 
country. The way you write that information does not make it different.

Question: are there existing additional hierarchies in postal (brainware) 
addressing? ie something the mailman need to chose between different mail 
destination - and or mail path?

- not the title (Mr, Mrs, Dr, M. Mme, Snr, M.M., Her, Esq. etc...)
- not the type of information: a nickname is accepted as long as the layer 
below accepts it. I mean than "Jack" is accepted for "John" in an Irish 
family and "Jefsey Morfin" will be accepted in the "Morfin" mailbox.
- partly the service : is it a hierarchy/an added information in the naming 
hierarchy? Postal Services all over the world use "Port Payé" or "Port du". 
The same as all the DNS Managers use "MX". The routing: "AirMail" or 
"ParAvion". (note: these hierarchies are not in naming. They are used when 
applying before or in parallel to the routing).
- the scripting is an intuitive (real) hierarchy: is the scripting local to 
the sender, to the sendee or  international scripting? Usually only 
international and sendee scriptings are accepted. The place where the 
discrimination is carried is the first point where a scripting is not 
understood anymore. In some cases it can go beyond through an alternative 
path: in adding "c/o some go-between" who will translate.

4. access engine. To understand the way I am going to use IDNA+, and why, 
one has to understand the access engine concept. I name and develop "access 
engines" DNS resolvers which use an extended resolution strategy. For 
example my domain name is http://utel.net . There is no access engine 
implemented there, but http://jefsey.morfin.utel.net could accept the call 
as the default for utel.net and resolve the 3 and 4LD as 
jefsey.morfin.utel.net, morfin.jefsey, jefsey, morfin, vacations etc...

This kind of OPES provides a directory service but also an easy ULD (upper 
level domains) management system in using LDAP like system or more advanced 
directory solutions, etc...

This means that I have no problem to introduce transparently punnycode 
support in my existing names. http://U+xxxU+yyyyU+zzzz.utel.net are OK.

The access engine resolves in two ways. Either as a reroute or as a normal 
DNS server. This depends on the economics and on the user system 
architecture. They are transparent. http://jefsey.utel.net can resolve one 
day as a reroute to http://jefsey.com and the next day as a CNAME for 
http://jefsey.com. I note that the test for a French application supports 
1.500.000 names with a target for 150.000.000, with some added value 
variations (abbreviations, accents,e ct) what corresponds to billions of 
names. The DNS could not support all this, but provide a stable, simple, 
existing support for the ULDs.

These access names are either free or cheap and will be legally enforced 
one day (we will support the national IDs, immotic telemates, etc). We 
cannot plan to spend much energy to support billions of names for millions 
of people.

Obviously these names must be transparent to different accepted writings: 
upper, lower, accentuated cases. "eleve" must be bijective with "élève".

That engine can to some extend accept the most common typos and the 
sound-alike wording. But it will not easily accept that a French "O" is 
replaced by a Greek "o".

5. legal issues. Due to the IETF current lack of documentation between the 
software domain name as an alphanumeric pointer to an IP address, and the 
brainware mnemonic cannonic/alias to a domain name, there are out of 
context laws/jurisprudence such as ACPA, Whois, etc. we must live with.

I do not want to run into endless UDRPs and "a la Joe Sims" contractual 
issues because a Chinese way to write something will print on all the 
French non-IDNA displays and printers as "iesg-ibm.fr" or as a racist text.

Not a minute nor single penny to spend helping other to understand if what 
will legally counts is one or the other formula.

Now the "Jefsey's solution".

6. From all this (and other economy, marketing, social etc... points) my 
implementation and explanation will be as follows.

a) there is an unique DNS naming sequence. That sequence utilizes the 
International Domain Names System Character set, named "IDNScode". Today 
IDNScode includes 0-9, A-Z dash and dot. Nothing prevents it to be extended 
by the DNS designers.

b) the extended-Unicode set (e-Unicode) includes the current Unicode 
version plus the current IDNScode version..

c) the support of natural Internet names is organized through specialized 
sub-domains the charter of which defines the e-Unicode supported sub-set, 
and the bijective e-Unicode/IDNScode reading/writing function. Their ULD 
(upper level domain) will be of the form ".prefix--suffix.tld", where

- prefix indicates the conversion system
- the suffix indicate the used e-Unicode restriction.

The prefix will be the "iesg--" prefix for the IDNA system. The null suffix 
will default to "IDNScode".

d) registrations will use current NIC management systems with a 
transwritting using a punnycode routine after a sub-namespace character filter.

e) abbreviated name presentation will be supported to possibly hide/insert 
the script sub-domain. This will be insured by "prefix--suffix" loaded or 
embedded plug-ins (on the system) or as OPESes.

Discussion

7. I will use the French name "élève" (pupil) fro this discussion, since it 
is supported by my keyboard and should probably be by all of yours.

a) support of international registration by AFNIC : http://eleve.fr

b) support of the French registration by AFNIC:
   - uppercase scripting : http://ELEVE.FR - existing as http://eleve.fr
   - accentuated lower case : http://élève.iesg--fr.fr
     entered also as :
     - http://eleve.fr  (decision to be taken by AFNIC to comply with 
French law)
     - http://eleve.iesg--fr.fr (until the IDNScode == Unicode)

c) update of the e-Unicode character set
   - one shot ^parallel registration of the new scripting equivalent
   - management of the possible conflicts
   - de registration of the obsolete e-Unicode scripts once every user 
supports the new version.

d) work to be done to support this service
   - creation of the "iesg--fr" domain name
   - adding of a French character set list in the Punnycode C code.
   - delay to the market: 24 hours after the release of the "iesg--" 
characters.

e) user implementation
   - this is transparent to the current situation
   - e-Unicode support can be provided by who wants and different natural 
character sets can be implemented depending on the user keyboard.

f) legal implications
   - none
   - the e-Unicode scripting is by nature 3+LD names outside of the WIPO 
area of influence.
   - jurisprudence will develop probably on brainware mnemonic second 
level, but it should be related to the documented good, rather than a good 
by itself. if the good is the domain name: the standard UDRP apply on the 
registered DNS entry: nothing changed. If it applies on any other good: 
domain names are not even only more considered as such.

g) extensibility
   - there is no addition to the DNS which can be as freely extended as before
   - there is an unlimited extension of the natural character set through 
the suffix. There an unlimited capacity of extension on the processes 
through the prefix. There is a quasi unlimited capacity of extension though 
another semantics.

h) load
   - the load forecast on the DNS imposed by current IETF proposition may 
be tremendous a TLD may become a new worldwide ".com" with hundred of 
millions of entries, on the whim of a fashion. The sub-domain approach 
obviously permits the transparent load of billions of Internet names.
    - however the load shifts towards the sub-domain information management 
within the work frame of the new loads imposed on the root server system 
and on the DNS. This load is to be considered all together with the load 
imposed by Microsoft's "dynamical" DNS management, portables, DNS lookup 
leaks, racing multiple root calls for speed of some resolvers, ENUM 
support, security concerns etc..

Summary.

The whole Recommendation is that the Internet Community agrees that a 
domain name including a double dash "--" means a domain name which can been 
hidden/created by applications should the corresponding set of recursive 
processes (defined by its charter) it describes, have been applied.

Some examples:

- iesg-- : this domain specializes in IDNScode scripts
- iesg-fr  this domain specializes in "French names".
- fm-- : this domain specializes in telephone follow-me services
- iesg--fm-fr : this domain specializes in telephone follow-me services in 
French accentuated names.
- enum--fr: enum names tel://139500510.enum--.fr
- tel--fr: enum through french name names : tel://eleve.tel--fr.fr entered 
on my mobile as "éléve.fr" that may be transcoded into tel://eleve.fr, 
tel://élève.tel--.fr.fr http://eleve.iesg-tel--fr etc. depending on the 
services organized by the operator.

I certainly accept that it is rather different from the current wording and 
concerns. But I think it is compatible. I hope it may help. I will keep 
posting on the implementation ... as I find the funding.

jfc

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Sep 2002 10:53:45 -0400

--On Wednesday, 11 September, 2002 14:51 +0200 Erik Nordmark
<[email-masked]> wrote:

> The thing for which I suggested new text, based on the
> comments on the list, is careful to talk about "use" - not
> "display".
> The term "use" covers everything - copy&paste, display, write
> to stdout in Unix (which might be a pipe), etc.
> 
> Discussing specific uses, such as display or copy&paste, would
> be better served  by a well-written informational document.

While I agree with this in principle, I note that such a
document, to be useful, has to get published.  It isn't on the
WG's charter, and my sense from watching the RFC Editor queue is
that "individual contribution" informational documents are being
processed FINO (first-in, never-out), i.e., it is not moving at
all.

     john

---

From: "James Seng" <[email-masked]>
Date: Wed, 11 Sep 2002 23:19:39 +0800

What you described (at least the technical part) is quite different from
IDNA so it should not be mixed up with IDNA.

Since you are a probably new to the IETF process (see RFC 2026), let me
repeat the same thing I told others:

The best way to proceed is to document your proposal in an internet draft
and submit it to the IETF. Only then could we have a proper discussion of
the proposal.

You may also want to look at some other drafts the group have seen.
Particulary, John's dnssearch.

-James Seng

---

From: "Soobok Lee" <[email-masked]>
Date: Thu, 12 Sep 2002 08:12:05 +0900

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 11, 2002 9:51 PM
Subject: Re: [idn] Figuring out what can be displayed

> > and  then be put into new "Informational" supplementary document ?

The issue of Non-ACE/ACE form  in IDN display.

> (which might be a pipe), etc.

In addition, do you think it should encompass IDN "use" in networking protocols 
like SMTP, HTTP and RFC822 ?

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 11 Sep 2002 20:42:05 -0500

on 9/11/2002 5:12 AM Erik Nordmark wrote:

> users when it is known that the environment can handle the non-ACE
> form, except when the ACE form is explicitly requested.

This still has the potential to cause non-trivial breakage. Message-ID,
search, etc.

> When it is not known whether the environment can handle the non-ACE
> form, the application MAY use the non-ACE form (which might fail e.g.
> by not being displayed propertly) or it MAY instead use the ACE  form
> (which will look unintelligle to the user). --

My position remains that the Unicode form MUST NOT be rendered unless and
until the governing specification for the affected protocol and/or service
explicitly allows it and describes how such data is to be handled.

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

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 12 Sep 2002 02:41:30 +0000

Erik Nordmark <[email-masked]> wrote:

> > users except when the use of the non-ASCII form would cause problems
> > or when the ACE form is explicitly requested.
>

I'd prefer to retain the "problems" escape hatch:

    3) ACE labels obtained from domain name slots SHOULD be hidden from
    users when it is known that the non-ACE form can be handled by the
    environment and will not cause problems, unless the ACE form is
    explicitly requested.

> (which will look unintelligle to the user).

We are in a section called "Requirements", but this is not a
requirement, it's just the opposite.  I don't think it's necessary
at all (because the application obviously MAY do anything that's not
forbidden), but if you want something like this, I think it belongs in
section 6.1 and/or 6.4.

AMC

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 12 Sep 2002 10:59:20 +0200 (CEST)

> In addition, do you think it should encompass IDN "use" in networking
> protocols  like SMTP, HTTP and RFC822 ?

The IDNA specification talks about IDN-unaware domain name slots.
That covers protocols which predate the IDN specification.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 12 Sep 2002 11:16:10 +0200 (CEST)

> This still has the potential to cause non-trivial breakage. Message-ID,

Potentially, because it depends on how you define "the environment".

One of the things the IETF needs to do is to take the IDN base and produce
specifications on how it applies in more detail to various application
protocols. I've seen drafts on URI issues, but I don't recall any drafts on
specifics for email.

In order to get the right folks involved in the discussion it is probably
better to have it on the [email-masked] list, or on some smtp specific
mailing list.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 12 Sep 2002 11:19:50 +0200 (CEST)

>     environment and will not cause problems, unless the ACE form is

OK.

> forbidden), but if you want something like this, I think it belongs in

I think the dual "MAY"s make it clear that the specification
doesn't require or recommend either. This could of course be done
without using the upper case MAYs, but I think it would be a bad
idea to move this statement of non-requirement away from the very closely
related "SHOULD" requirement, since that will make it much harder
for the reader to piece together the complete picture here.

  Erik