Re: [idn] WG last call documents

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

I wrote:

> What do you think of this wording:
> 
>   2) 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.  Given an
>   internationalized domain name, an equivalent domain name containing
>   no ACE labels can be obtained by applying the ToUnicode operation
>   (see section 4) to each label.  When requirements 1 and 2 both
>   apply, requirement 1 takes precedence.

"Eric A. Hall" <ehall@ehsco.com> replied:

> Was there a problem with the explicit text I provided?

I prefer to be more concise.  I tried to incorporate all the points I
agreed with.  The above wording is significantly less strong that the
wording in the current draft.

> The text presented here still encourages a default behavior of
> transliterating anything that looks like a domain name,

Not things that look like domain names, things that are known to be
domain names.  That's what the "obtained from a domain name slot" is
for.  And I added "except when the use of the non-ASCII form would cause
problems".  But yes, I still want users to be shown the non-ASCII form
except when there's a reason for them to be shown the ACE form.

> when it should be the opposite.

I'm afraid I disagree.  People have said in the past that IDNA is
pointless if users always see the ACE form.  The world you seem to be
envisioning is one in which users would be seeing the ACE form an awful
lot.

> > We should be able to update mail user agents (like Pine) and
> > immediately be able to use IDNs in email addresses without having
> > to touch mail transfer agents (like sendmail) or DNS servers (like
> > bind), and without having to wait for any updates to protocol
> > specifications (like the DNS spec and the SMTP spec) or data format
> > specifications (like RFC 2822).
>
> Not possible.
>
> We seem to have a disconnect here.

Apparently.

> "LDH slot"?

Many generic domain name slots allow all ASCII characters, not just LDH
characters.  But "ASCII slot" is not appropriate either, because the
essence of the concept is not what the slot allows or what standard it
cites; the essence of the concept is what standard the slot does *not*
cite, namely the IDNA spec.  So the term needs to convey non-specialness
or non-i18n-ness.  If you don't like "generic" or "vanilla" or
"ordinary" or "non-internationalized" or anything along those lines,
then we're probably not going to find common ground.

> The prohibition needs to be against all punctuation.

For host names, right, not domain names in general?  I think I like this
model:  Just as ASCII host names exclude many of the characters allowed
in ASCII domain names, internationalized host names would exclude
many of the characters allowed in internationalized domain names (the
same sorts of characters: punctuation and symbols).  There would be
two stringprep profiles, nameprep with a small prohibition table, and
hostprep with a large prohibition table.

However, I think it's probably too late for this.  I very much doubt
that most people would be interested in making such drastic changes at
this late date.  Non-ASCII punctuation is not threatening enough to
warrant derailing the process.

AMC