Subject: Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt

From: Stuart Cheshire <[email-masked]>
Date: Tue, 14 Dec 2010 17:08:19 -0800

On 21 Nov 2010, at 8:44 PM, Doug Barton wrote:

> That said, I'm reasonably supportive of the draft moving forward

Thanks.

> 1. In Section 4.1, 4th full paragraph, the bit, " (because of the  
> limitations of the typing-based user interfaces of that era)"  
> should be stricken. It does not add value to the clarity of the  
> text, nor would arguing about whether it's correct or not.

I see your point, but I think the text provides useful context to  
remind readers about the user-interface considerations of that era --  
especially young readers who don't remember the time when computers  
only had text-based interfaces.

> 2. In that same paragraph, shortly after the above, "from a list of  
> choices presented on the screen ..." should be something similar to  
> "from a list of choices presented by the user interface ..."

Very good point. Of course, the concept of having a screen doesn't  
even apply to Apple's new telepathic-projection antimatter-powered  
iPhone. We've updated the document accordingly.

> One could also argue that the "not intended to ever by typed in"  
> should be replaced with the appropriate 2119 language.

The text is illustrative, not prescriptive. We have changed the text  
to say this:

    Users generally access a service not by typing in the Instance Name,
    but by selecting it from a list presented by a user interface.

> 3. In Section 7, 3rd full paragraph, it says, "conforming to normal  
> DNS host name rules: Only lower-case letters ..." The "normal DNS  
> host name rules" [citation required] do not permit only lower case  
> letters. I do think however that it would be ok to spell out that  
> this protocol requires that, like what was done with disallowing  
> names without an alphabetic.

Good catch. We have removed the incorrect and irrelevant side comment  
mentioning "normal DNS host name rules":

    Application Protocol Names may be no more than fifteen characters
    (not counting the mandatory underscore), consisting of only letters,
    digits, and hyphens, must begin and end with a letter or digit, and
    must contain at least one letter. The requirement to contain at  
least
    one letter is prevent service names such as "80" or "6000-6063"  
which
    could be misinterpreted as port numbers or port number ranges. While
    both upper case and lower case letters may be used for mnemonic
    clarity, case is ignored for comparison purposes, so the strings
    "HTTP" and "http" refer to the same service.

This is however just temporary text, and will be removed entirely  
when draft-ietf-tsvwg-iana-ports is published.

> 4. I'm not sure Section 15.2 needs to be in the document at all,  
> although I am not formally opposed to its inclusion.

User interface considerations were a central aspect of the design  
constraints for DNS-SD and mDNS. Rather than design a protocol first  
and then work out the UI second, with DNS-SD and mDNS we first worked  
out the user experience we wanted, and then designed the protocols to  
provide that user experience. This section explains how those  
requirements influenced the design decisions for the protocol.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 14 Dec 2010 18:41:21 -0800

On 23 Nov 2010, at 12:55 PM, Doug Barton wrote:

> Allow me to amplify my argument more completely. There are already  
> 2 open source implementations of dns-sd that I'm familiar with,  
> mDNSResponder and avahi; in addition to apple's Rendezvous. The OS  
> versions are mostly interoperable on the protocol level, but not on  
> the binary level. One example that I've been working with lately  
> can be found at http://www.avahi.org/ticket/303.

That is an API compatibility issue. The bug report says  
"kDNSServiceFlagsShareConnection not implemented, affects CUPS". You  
won't find a mention of "kDNSServiceFlagsShareConnection" anywhere in  
draft-cheshire-dnsext-dns-sd-07.txt.

The IETF specifies on-the-wire protocols, not APIs.

There are many different implementations of DNS-SD, with different  
APIs, for different languages. The fact that people are complaining  
about subtle differences in one particular API between two different  
independent implementations should be a sign of how widely deployed  
this is.

> Regarding the document itself, I have reservations about the  
> quality of the document, and whether or not it describes the  
> protocol in sufficient detail that someone starting from scratch  
> could develop another interoperable version.

I think the Avahi bug report you found is adequate evidence of  
independent interoperable implementations.

> However I tend to agree with the point of view that the world is a  
> better place if we have _a_ spec than if we have none, so I'm  
> specifically not asking to re-address all of the concerns that have  
> been discussed previously with the document. However the bit about  
> lower case labels should definitely be fixed (either by removal, a  
> citation, or a clarification that the requirement applies only to  
> this protocol).

This has been corrected.