Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00

From: Stuart Cheshire <[email-masked]>
Date: Sun, 02 Feb 2014 23:10:23 -0800

On 27 Jan, 2014, at 19:50, Andrew Sullivan <[email-masked]> wrote:

> Now, suppose instead that the department's content server is called
> instead "Source de Télévision, Département de Langues".  This is great
> in an mDNS context: DNS-SD will find it just fine.  But if you enter
> "Source de Télévision, Département de Langues.lang.example.edu", the
> effects are unpredictable.

There’s been an awful lot of recent discussion on various ways to solve what I view as a non-problem.

Users don’t “enter” the name of a service. Their system *discovers* a list of available services, presents the list to the user, and the user selects one. That’s why it’s called “Service Discovery”, not “Service the-user-finds-out-the-name-somehow-and-then-types-it-in”.

> On some systems, that will be passed
> through to the resolution layer unchanged, and the lookup will match
> the octets modulo the 0x20 processing of ASCII characters.  On other
> systems, it will be intercepted by the application or the system
> resolver or both as a potential IDNA label, and processed according to
> local IDNA rules.

No, they won’t. Applications that use Service Discovery use Service Discovery libraries, that adhere to whatever relevant specifications dictate the behavior of those Service Discovery libraries. Suitable Service Discovery libraries are already included with Mac OS X, iOS, and Android. The same APIs are available on Windows when you install Bonjour for Windows. Applications that want Service Discovery use those APIs, not some other APIs.

In the Service Discovery model I’ve argued for, service names can contain any character that can be represented in Unicode. In particular, spaces and uppercase letters are allowed, as they are in filenames in most modern filesystems. Fortunately, supporting spaces and uppercase letters is not particularly hard.

DNS-Based Service Discovery [RFC6763] uses DNS as a suitable substrate for that user-friendly Service Discovery model. That means it borrows the DNS packet format, but the client-side and server-side libraries that use that DNS packet format are allowed to be new code.

The DNS protocol and packet format support 8-bit data, and the client libraries make use of that. The interpretation of that 8-bit data is a matter for the source and the consumer alone; the intermediate transport (e.g., the DNS infrastructure) merely has to preserve the 8-bit data faithfully, not interpret it. Fortunately, the DNS infrastructure seems to do this pretty well. If the source and the consumer choose to interpret 8-bit data as UTF-8, then that’s all that matters. By analogy, a filesystem doesn’t have to “support” JPEG images. It just has to preserve 8-bit data faithfully; only the source and the consumer of that 8-bit data need to know what a JPEG image is.

draft-sullivan-dnssd-mdns-dns-interop-00 says:

>    In particular, [RFC6763], section 4.1.3 recommends that
>    rich text, human-readable labels be used, and includes punctuation
>    and space characters in the examples.  It is not clear whether such
>    uses will be possible, because spaces and most punctuation are
>    permitted neither in U-labels nor in LDH labels.

The doubt about “whether such uses will be possible” is odd, since such uses have worked for a long time. This is not new.

To demonstrate such use, I created Service Discovery DNS records for your “Source de Télévision, Département de Langues” example.

To see this example for yourself, on a Mac, add “dns-sd.org” as a search domain in Network Preferences. Then click on the “Bonjour” menu in Safari, and you’ll see that the “Source de Télévision, Département de Langues” example does in fact appear, complete with spaces, uppercase letters, and accents. (If you don’t see the “Bonjour” menu in Safari, go to “Safari > Preferences > Advanced” to turn on the Bonjour option, and then click the “Bonjour” menu to see the advertised service.)

Stuart Cheshire

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Feb 2014 10:07:07 -0500

On Sun, Feb 02, 2014 at 11:10:23PM -0800, Stuart Cheshire wrote:
> 
> Users don’t “enter” the name of a service. Their system *discovers*
> a list of available services, presents the list to the user, and the
> user selects one. That’s why it’s called “Service Discovery”, not
> “Service the-user-finds-out-the-name-somehow-and-then-types-it-in”. 

Yes. IDNA interprets both display and typing. I don't see how this is
relevant.
 
> No, they won’t. Applications that use Service Discovery use Service
> Discovery libraries, that adhere to whatever relevant specifications
> dictate the behavior of those Service Discovery libraries. Suitable
> Service Discovery libraries are already included with Mac OS X, iOS,
> and Android. The same APIs are available on Windows when you install
> Bonjour for Windows. Applications that want Service Discovery use
> those APIs, not some other APIs.

If I understand this, you are claiming that the SD libraries don't use
the system's DNS resolver libraries _at all_, and instead handle
resolution on their own?  If that's right, then you're quite correct.
Our only problem in this case is sending all manner of junk queries to
the public DNS for names that don't exist and will never exist.  This
is ugly but not actually broken.  

> Fortunately, the DNS infrastructure seems to do this pretty well.

Some of it does, yes.
 
> The doubt about “whether such uses will be possible” is odd, since such uses have worked for a long time. This is not new.

What is new, of course, is the deployment and adoption of IDNA2008 and
TLDs that use IDNA labels.  That's the only reason I'm worried about this.

> To see this example for yourself, on a Mac

I fail completely to see how, "If you do this on a system that
implements all my assumptions about how resolvers work, it works
fine," is any kind of demonstration of, "This will work reliably
everywhere."  Nobody invented IDNA because random 8-bit strings worked
reliably in the DNS and all the associated uses of DNS names.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 05 Feb 2014 22:49:44 -0800

> is ugly but not actually broken.

Yes, Service Discovery libraries issue their own DNS queries, and pass through the 8-bit data they receive from the public DNS unmolested.

I don’t know what “junk queries” for “names that don’t exist and will never exist” you are talking about. If you try the Safari example I suggested, the Service Discovery libraries on your machine will issue DNS queries for rich-text service names that *do* exist in the public DNS. If the names didn’t exist in the public DNS, then Safari would fail to resolve the service, and the web page would not appear.

> everywhere."

I don’t know whether you mean “everywhere” in the sense of “everywhere geographically” or “using libraries that don’t work for DNS-Based Service Discovery”.

DNS-Based Service Discovery does work everywhere geographically.

On the other hand, trying to perform DNS-Based Service Discovery using inappropriate code makes no sense to me. It’s like arguing that JPEG is a bad file format for images because if you try to view those files using vi on a VT100 terminal you see nonsense on the screen. Limiting ourselves to ASCII art because that’s all you can view using vi on a VT100 terminal is not a sensible restriction. If you want to view JPEG files, you need to use software and a display that is capable of displaying JPEG images. Saying that service names can’t contain spaces or uppercase letters is similarly not a sensible restriction.

Fortunately, DNS-Based Service Discovery is a lot simpler than decoding JPEG images. All you need is network-layer code that passes though 8-bit data unmolested, and a display system that can render Unicode text. Admittedly, rendering all possible Unicode text is no trivial task, but thankfully others have solved that problem, and all modern display systems can handle Unicode. As protocol designers, we just need to be concerned with how to deliver 8-bit UTF-8 data to the display system, which will then do a fine job of rendering it on the screen.

Stuart Cheshire

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 6 Feb 2014 09:04:10 -0500

> Yes, Service Discovery libraries issue their own DNS queries, and pass through the 8-bit data they receive from the public DNS unmolested.

It would probably be useful to write down advice somewhere that DNS-SD
implementations not use other resolver libraries lest those libraries
implement IDNA automatically.

> I don’t know what “junk queries” for “names that don’t exist and
> will never exist” you are talking about. If you try the Safari
> example I suggested, the Service Discovery libraries on your machine
> will issue DNS queries for rich-text service names that *do* exist
> in the public DNS. 

The Safari example you suggested doesn't have internationalized labels
in all the positions.  If you wanted to discover services underneath 
互联网中心.中国, for instance (I have no idea what that name is -- it's
an example I pulled off CNNIC's FAQ), you'd send a query to the root
for 中国, and get NXDOMAIN, so then you'd send a query to the root for
xn--fiqs8s.  Then you'd send a query to the relevant name server for 
互联网中心.xn--fiqs8s, and that would return NXDOMAIN, so you'd send a
query for xn--fiq7iq58bfy3a8bb.xn--fiqs8s, and that would return the
NS set.  And so on.

Unless what you're saying is that the way you got to be trying to
select a service beneath 互联网中心.中国 in the first place was
IDNA-using.  That is, let's suppose the search domain in the network
preferences knows that it's using IDNA (or just uses it that way
because that's what DHCP handed it.  This is an excellent question, by
the way -- the search-path handling in DNS is already a mess, and I
wonder what happens to people who try to do predictable things with it
in an IDNA context) and therefore the display is just correct.  But
since the displayed label is a U-label, and since the U-label is
UTF-8, why doesn't DNS-SD try the UTF-8 version first?  That is what
the algorithm says to do.

> I don’t know whether you mean “everywhere” in the sense of
> “everywhere geographically” or “using libraries that don’t work for
> DNS-Based Service Discovery”.

"Using ordinary system resolvers."  I have very little difficulty
imagining the case where an implementer does DNS-SD by relying on the
system resolver because DNS is 8 bit, and a system resolver that has
been ginned up to catch UTF-8 labels and turn them into A-labels
because the IETF said that's how we're handling internationalized
domain names, and therefore the whole result being unsatisfactory.
I'm not saying anyone must do that.  But it's surely our
responsibility as people who want to ensure interoperability to point
out this sharp corner.  That's all I was trying to do in the first
place.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]