[Ietf-not43] issues and questions on FIRS

[Eric A. Hall]

on 8/26/2003 4:31 PM Andrew Newton wrote:

> Eric A. Hall wrote:
> 
>> Unless you mandate two indexes against one data-store, it will be two
>>  data-stores.
> 
> I do not presume to know how all registries/registrars store their IDN
> data.  Some may store both the originating Unicode and the 7-bit 
> version.  Some may store only one and calculate variants.  Some may not
> support IDN's at all.

That's fine, except where some people want to get the contacts for
exämple.com and others want to get the contacts for xn--exmple-cua.com.

I'm not saying you need to dictate operational behavioral, but AFAICT you
haven't specified whether or not the queries should even return the same
data, which is the point here not the operational stuff.

>>> I good client should stop the user from entering malformed data.
>> 
>> What is malformed for one client would be legitimate for another if
>> you don't specify the algorithm.
> 
> Specifying that the input should be punycode/nameprepped/whatever
> should give client writers enough direction.

It's a start, but it won't guarantee consistent results. You need to
require two-pass conversions for all input to guarantee that all of the
data in the system is in a consistent form.

>> My discussion on escape syntaxes for octet values is a demonstration
>> of this; in some cases, octet values could be considered as
>> legitimate charset-codepoints.
> 
> Why are they escaped if the field is UTF-8 capable?

Again, octet values are legal in domain names. Secondarily, the user side
of the client has a high probability of using something else (UCS-2,
8859-1, 2022-JP, whatever). Cumulatively, the user can enter an octet
value in a local charset which will get mapped to UTF-8 as part of the
canonicalization routines, so data that is explicitly an octet value
(rather than a character at that codepoint) needs to be protected.

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