Re: [idn] WG last call documents

["Eric A. Hall" <ehall@ehsco.com>]

"Adam M. Costello" 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.

Was there a problem with the explicit text I provided? The text presented
here still encourages a default behavior of transliterating anything that
looks like a domain name, when it should be the opposite.

We seem to have a disconnect here. You're concerned with the symptoms, I'm
talking about the root cause. Every protocol and data-format has its own
specific considerations, and it is not possible to mandate (or strongly
suggest, if you prefer) that every Internet service change its behavior to
suit IDNA. It's absurd. The only thing you can do here is say "don't do
anything until the masters of the spec say how to do it".

Again, consider WHOIS output. Should a WHOIS server transliterate output?
Should it be performed at the client so that negotiation is not required?
And you have described the protocol negotiation or client behavior where?

Or consider HTML, which has a limited notion of PDU structures. Should
domain names enclosed in HREF tags be transliterated? or should IDNA never
be transliterated, and if a user wants an i18n domain name to be displayed
then they should use the charset capabilities for this? And you have
documented this behavior for the W3C developer community where?

Even if you want to limit this behavior to a very specific community,
something small and syntactically precise such as email header fields,
which header fields should do this? Should this be limited to the
originator and recipient header fields only? And you have documented this
extension to RFC 2822 where? I mean, even RFC 2047 is restricted to
specific data-types.

You only have one choice here: nobody transliterates nothing until the
governing specifications for the network service in question clearly
describe how it should be done.

The exception is local presentation of connection identifers. There is no
reason that ping shouldn't be able to handle IDN<->IDNA conversion,
although even that has to be handled with care. Look, I can't even tell
one of my newsreaders to use an i18n domain name since the .newsrc files
are shared by multiple clients.

> the design of IDNA was this one:  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. See above.

> > The use of "generic" is what bothers me, because it implies that the
> > slot (another word I dislike) can hold any domain name.

> Other words that could serve the same purpose are "vanilla" and
> "ordinary".  Would either of those be better?  Or maybe
> "non-internationalized".

"LDH slot"?

> > So you have an example of another WG specification where only half
> > the opinions are provided, and that they provide value towards
> > understanding the protocol or service? Citations Please
> 
> Not an IETF spec, but the PNG spec includes a rationale appendix, and
> we've received comments saying that it was helpful and it would be nice
> if other specs did the same.  I don't think we ever received comments
> saying it should not have been included.

If it wasn't lop-sided opinion (aka religion), you probably wouldn't have
gotten the two complaints you got here either.

> > It is also factually in error.
> 
> If that's true, it should be fixed.

 | Many proposals for IDN protocols have required that DNS servers be
 | updated to handle internationalized domain names.

Do you honestly seriously believe that IDNA will not require upgraded
servers to handle transliteration on input? That it *CAN* work without an
upgrade does not mean that it *WILL* work without an upgrade. Which of
those words is a property of "required"? Both.

 | Because of this, a person who wanted to use an internationalized
 | domain name would have to be sure that their request went to a DNS
 | server that had been updated for IDN.

The two dual-mode proposals before this WG have both allowed legacy
servers to provide answers. False.

Etc. The logic-path is entirely corrupt and based on nothing more than an
opinion that an encoding which appears nowhere else in the known universe
is somehow better than embracing the pain of an incremental upgrade.

> > A prohibition against combining characters is not feasible. See
> > <200111212258.OAA23757@birdie.sybase.com> from K Whistler.
> 
> He said that we could not simply prohibit combining characters, and
> I agree.  I was suggesting that we might want to prohibit *initial*
> combining characters.  Combining characters combine with the character
> preceeding them, so a label beginning with a combining character is a
> strange beast, and might cause bizarre and suprising behavior.

When rendered, it will combine with the dot separator. However, that's
only half the complaint. Also consider that leading punctuation is often
used as a command-line qualifer (-verbose). The prohibition needs to be
against all punctuation. When I looked (very briefly, that was composed at
a hotel room), the characteristic that seemed most useful was a property
of diacritical mark or dashes. I don't think there is a property of
punctuation. I should look.

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