Re: [idn] What happens to 8bit DNS requests

["Edmon" <edmon@neteka.com>]

Thanks so much for your comment.  I understand that it would be very hard to
make it totally comprehensive, but at least it goes to show that even when
OSs go UTF, it does not necessarily mean that DNS packets are correctly
packaged in UTF.  Which means that regardless of whether we choose
UTF8/16/32 or even ACE most applications still have to be changed.  However
I do agree that, making UTF8/16/32 right should be easier than introduce yet
another transformation.

As we go along, we will continue to update the document on other
applications.  Meanwhile, I look to all of you all to add to the document if
you already know of some irregularities regarding certain applications.
Once its considerably comprehensive, I think it is valuable to be turned
into a draft.

Edmon


> > I appreciate that there are different issues associated with UTF-8 or
other
> > non-ASCII approach, my main point is that even if we do go to IDNA,
chances
> > are that users unknowingly will still be sending multilingual dns
requests
> > through existing products that are non-IDNA aware.
>
> agreed.  I think such a document could be useful, with the following
caveats:
>
> - it would be very hard to make it sufficiently comprehensive that
>   it could serve as guidance for the design of an IDN solution, or
>   even to serve as a guide for users wanting to know which products
>   to buy.
>
> - it could take a large amount of time and energy
>
>
> so I wouldn't mind at all seeing such a document produced, but I wouldn't
> want to see such an effort divert resources from the primary work on IDNs,
> or delay the primary work on IDNs.
>
> regarding the document you referenced (http://www.openidn.org/issues.html)
>
> - there are many more kinds of components affected than those that you
>   list (web browser, kernel, proxy server)
>
> - there are many more implementations of each of these kinds of components
>   than those that you list.
>
> - there are other platforms than those you list, with different issues
>   than these.
>
> all of which just illustrates that it's difficult to make this kind of
> list comprehensive.
>
> - it's not clear exactly what is meant by "kernel" or how it comes into
>   play in the interaction between applications.
>
> - it appears to be difficult to isolate or even document the nature of
>   certain problems, especially given that the behavior may change
>   depending on program preferences, presense of proxies, choice of
>   platform, etc.
>
> - the issues you cite are good examples of how 8-bit characters get
mangled
>   by some existing programs, but it's hard to know how to use this
>   information except to demonstrate that 8-bit characters get mangled
>   in a variety of ways.
>
> - the "solution" it recommends for squid is somewhat dubious:
>   it oversimplifies the problem of making IDNs work for the web.
>
>   e.g. even if we adopted a UTF-8 on-the-wire solution for URLs in the
>   HTTP protocol (something that is not within the scope of this group
>   to decide), it's not sufficient to simply change these programs to be
>   8-bit transparent for typed-in URLs.  there are other interfaces
>   which contain URLs (web pages, config files, APIs used to control
>   the browser, cut-and-paste), nameprep would certainly have to be
>   applied to URLs in the browser so that local caching would work
>   (even if proxies and remote servers were also taught to do nameprep)