Re: IDNA questions

A couple of comments on this discussion.

"Adam M. Costello" wrote:

> Erik Nordmark <[email protected]> wrote:

> > But why not take the same approach as for ASCII and allow space
> > characters, control characters, etc in INHL?
> 
> Good question.  I wouldn't mind seeing those characters allowed in
> non-host IDNs.

Let me also add my support for this. Protocols should be able to use the
full US-ASCII range of 0x00-0x7F if they really have a need to do so. This
is already supported in STD13, so not allowing them is guaranteeing
eventual problems.

> > Avoiding downcasing of ASCII code points by ToASCII in an all-ASCII
> > label seems a bit odd.
> >
> > The reasons I've seen seem to be that some applications would take
> > the result of ToASCII and use it in protocol fields such as the
> > From: in SMTP. The effect of having ToASCII downcase an all-ASCII
> > label is that users will see different case characters when they
> > upgrade to IDNA-aware applications even though they do not use an
> > IDN themselves. Thus there might be some noticeable short-term
> > effect depending on exactly how the IDNA-aware application is coded.
> 
> Yes, that is my main concern.  And also the general principle that
> extending a standard should not alter the behavior of things that were
> already covered in the old standard.

Dan O also brought up the issue wrt PTR labels providing domain names as
RR data which are sometimes used with case-sensitive access maps. Probably
not the best programming in the world but it's out there and also
supported by STD13.

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