Re: [dnssd] A concrete example of the Punycode fallback variants for the <Domain> portion

[Douglas Otis <[e-mail]>]

On Dec 16, 2013, at 9:45 AM, Andrew Sullivan <[e-mail]> wrote:

> Hi,
> 
> I'm not sure I entirely understand your message.  But. . .
> 
> On Mon, Dec 16, 2013 at 09:07:31AM -0800, Douglas Otis wrote:
>> 
>> 1) Hostnames should be subjected to the same canonicalization to
>> establish valid UTF-8 strings prior to conversion.  Bonjour already
>> supports a means to override naming conflicts often seen as a
>> prefixed number value (n).  Once proper canonicalization is applied,
>> users may be required to adjust the hostname if unhappy with the
>> results. 
> 
> When you say "the same canonicalization", what do you mean?  The DNS
> owner names that result from RFC 6763 are in Net-Unicode (RFC 5198);
> this entails NFC, but not much more.  The U-label portions of any
> owner name arising from IDNA2008 have more restrictions -- most
> punctuation is disallowed, upper case characters are not permitted
> because they're not stable under case folding and NFKC, spaces are
> disallowed, and so on.  This difference is why I suggested a common
> interoperable profile (see draft-sullivan-dnssd-label-miprofile-00.
> Stuart had some quibbles about the recommendations in there, but in
> any case the recommendations are outside our charter.  I'm supposed to
> pull out the problem statement part, which I guess I could be doing
> rather than writing this mail).

Dear Andrew,

I hope to create a write-up better describing this situation.  Bonjour should not be considered equivalent to DNS, although DNS plays a role. Once resolving services beyond link local are in scope, a type of canonicalization which includes RFC5198 normalization is required in checks for hostname conflicts.  Bonjour hostnames are not constrained to what is legal for registered domains, but this freedom is for a single left-most label when resolving the hostname.  Labels that do not represent hostnames should fall within the constraints imposed by DNS.  

>> 2) There are two processes normally involved.  One is discovering
>> services after selecting from a list of domains, and resolving
>> services after selecting from a list of hostnames.  In each case,
>> both of these presentations can be done using UTF-8 (provided proper
>> canonicalization is applied.  Whether the label gets converted to an
>> A-Label will depend on the selection of the domain.  
> 
> If I understand the above, you're suggesting that the user will know
> how to cope with the issue.  Frankly, I think that is just naïve.
> Users do not have a theory of operation of IDNA vs. plain UTF-8 labels
> in the DNS, and subtle inconsistencies between them are going to be at
> least mystifying and at worst opportunities for bad behaviour.

Users should only see UTF-8 strings, not A-Labels.  A resolution process must apply rules needed to satisfy Bonjour and DNS separately as a two or three step process,  Domain/Service/Hostname or Service/Hostname.  Of course DNS will require registered domains expressed as A-labels, but hidden from users.  Don't expect users to recognize A-label domains. 

Combining domain selection with hostname selection will not scale well when scope goes beyond link local.  Use of search domains must be handled carefully and may even require confirmation by users.  

Regards,
Douglas Otis