[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] IDNA questions
A couple of comments on this discussion.
"Adam M. Costello" wrote:
> Erik Nordmark <Erik.Nordmark@sun.com> 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/