Subject: [port-srv-reg] The draft should updated the SRV RFC

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Sep 2009 16:36:39 +0200

Hi,

I have chatted with Alexey about the document. One comment directly is
that we should mark this document as updating the SRV RFC.

I think we all should do a review of the doc to see what we are missing
or need to do work. We should try to ensure that we have a version that
we think are ready by Hiroshima so that we can ask for WGLC. It is time
to get this done.

Alexey also volunteered to do a review and also be the responsible AD
for this document when it is time to publication request it.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 29 Sep 2009 13:18:47 -0700

> that we should mark this document as updating the SRV RFC.

Since one of the goals of this document is to clearly define the  
registry and rules for RFC 2782 SRV names, I think we should have a  
section that spells out precisely how our new well-defined service  
names are to be used in the context of SRV records.

Choosing an appropriate service name can be harder than it seems at  
first. In draft-gudmundsson-dns-srv-iana-registry they propose  
"overlay" protocols (such as HTTP and XMPP), e.g. for SRV records  
like _service._http.example.com. This is something I've given much  
thought over the last few years, and while these structured names  
seem superficially sensible, in reality they're a terrible idea. I  
have some text explaining why in Section 7 of <http://files.dns- 
sd.org/draft-cheshire-dnsext-dns-sd.txt>. I suggest putting this  
text, or something along these lines, into a new section in our draft- 
ietf-tsvwg-iana-ports document.

Thoughts?

7. Application Protocol Names

    The <Service> portion of a Service Instance Name consists of a pair
    of DNS labels, following the established convention for SRV records
    [RFC 2782], namely: the first label of the pair is an underscore
    character followed by the Application Protocol Name, and the second
    label is either "_tcp" or "_udp".

    Application Protocol Names may be no more than fourteen characters
    (not counting the mandatory underscore), conforming to normal DNS
    host name rules: Only lower-case letters, digits, and hyphens; must
    begin and end with lower-case letter or digit.

    Wise selection of an Application Protocol Name is very important,
    and the choice is not always as obvious as it may appear.

    In many cases, the Application Protocol Name merely names and refers
    to the on-the-wire message format and semantics being used. FTP is
    "ftp", IPP printing is "ipp", and so on.

    However, it is common to "borrow" an existing protocol and repurpose
    it for a new task. This is entirely sensible and sound engineering
    practice, but that doesn't mean that the new protocol is providing
    the same semantic service as the old one, even if it borrows the  
same
    message formats. For example, the local network music sharing
    protocol implemented by iTunes on Macintosh and Windows is little
    more than "HTTP GET" commands. However, that does *not* mean that it
    is sensible or useful to try to access one of these music servers by
    connecting to it with a standard web browser. Consequently, the
    DNS-SD service advertised (and browsed for) by iTunes is  
"_daap._tcp"
    (Digital Audio Access Protocol), not "_http._tcp". Advertising
    "_http._tcp" service would cause iTunes servers to show up in
    conventional web browsers (Safari, Camino, OmniWeb, Internet
    Explorer, Firefox, Chrome, etc.) which is of little use since it
    offers no pages containing human-readable content. Similarly, if
    iTunes were to browse for "_http._tcp" service, that would cause it
    to find generic web servers, such as the embedded web servers in
    devices like printers, which is of little use since printers
    generally don't have much music to offer.

    Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
    makes sense for an NFS server to advertise that it provides "SUN  
RPC"
    service. Likewise, Microsoft SMB file service is built on top of
    Netbios running over IP, but that doesn't mean it makes sense for
    an SMB file server to advertise that it provides "Netbios-over-IP"
    service. The DNS-SD name of a service needs to encapsulate both the
    "what" (semantics) and the "how" (protocol implementation) of the
    service, since knowledge of both is necessary for a client to
    usefully use the service. Merely advertising that a service was
    built on top of SUN RPC is no use if the client has no idea what
    the service actually does.

    Another common question is to ask whether the service type  
advertised
    by iTunes should be "_daap._http._tcp." This would also be  
incorrect.
    Similarly, a protocol designer implementing a network service that
    happens to use Simple Object Access Protocol [SOAP] should not feel
    compelled to have "_soap" appear somewhere in the Application
    Protocol Name. Part of the confusion here is that the presence of
    "_tcp" or "_udp" in the <Service> portion of a Service Instance Name
    has led people to assume that the structure of a service name has to
    reflect the internal structure of how the protocol was implemented.
    This is not correct. All that is required is that the service be
    identified by a unique Application Protocol Name. Making the
    Application Protocol Name at least marginally descriptive of
    what the service does is desirable, though not essential.

    The "_tcp" or "_udp" should be regarded as little more than
    boilerplate text, and care should be taken not to attach too much
    importance to it. Some might argue that the "_tcp" or "_udp" should
    not be there at all, but this format is defined by RFC 2782, and
    this document does not propose to change that. In addition, the
    presence of "_tcp" has the useful side-effect that it provides a
    convenient delegation point to hand off responsibility for service
    discovery to a different DNS server, if so desired.

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Sep 2009 13:56:16 -0700

Stuart Cheshire wrote:
...
> first. In draft-gudmundsson-dns-srv-iana-registry they propose "overlay"
> protocols (such as HTTP and XMPP), e.g. for SRV records like
> _service._http.example.com.

is this intended to be:

_service._http._tcp.example.com ??

Much as I like the idea of indicating that many protocols use existing
framing, they tend to implement a subset of that framing (e.g., GET, but
not POST), so I'm not sure it really helps to indicate that.

IMO, this is useful to discuss, but out of scope for this doc. IMO, this
ought to be in a separate doc that explains DNS SRVs.

I.e., this doc ought to focus on the procedure for asking for
names/ports, and the basic syntax for the names. Other detail ought to
be in other places.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 29 Sep 2009 14:40:41 -0700

On 29 Sep, 2009, at 13:56, Joe Touch wrote:

>> "overlay"

It's an example of a bad idea. As such, there are many similarly bad  
variants, like the one you suggest.

> not POST), so I'm not sure it really helps to indicate that.

Indeed. It's at best utterly worthless. In practice it may actually  
be worse than merely worthless, because it's misleading and  
encourages confused thinking.

> ought to be in a separate doc that explains DNS SRVs.

One of the primary goals of this document (I thought) is to codify  
the ability to register a named service without a corresponding  
reserved port, for use in (among other things) RFC 2782 SRV records.

To have the document then say nothing about either the semantics  
(what information is represented by a service name) or the syntax  
(how you put the name into an SRV record) of said service names seems  
like a fatal flaw. It's like having the document say, "This is how  
you register these name entities, but we're not going to tell you  
what they mean or what they're for."

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Sep 2009 15:07:11 -0700

Stuart Cheshire wrote:
...
> One of the primary goals of this document (I thought) is to codify the
> ability to register a named service without a corresponding reserved
> port, for use in (among other things) RFC 2782 SRV records.
> 
> To have the document then say nothing about either the semantics (what
> information is represented by a service name) or the syntax (how you put
> the name into an SRV record) of said service names seems like a fatal
> flaw. It's like having the document say, "This is how you register these
> name entities, but we're not going to tell you what they mean or what
> they're for."

It should cite a different doc for that. This is supposed to be
procedural, not technical.

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Sep 2009 11:18:31 +0200

>    discovery to a different DNS server, if so desired.

I think this text should be expanded on. It is used by certain services
to find out if the service is available over different transports. I
think _sctp or _tcp makes more sense for a lot of serives, than chosing
between TCP or UDP. But I wouldn't rule that out either.

Cheers

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Sep 2009 07:29:12 -0700

> between TCP or UDP. But I wouldn't rule that out either.

While I agree with the need for this text, it seems preferable to
separate the technical from the procedural. The current document updates
the process, and provides only as much context as is needed to
understand the process.

Whatever technical content is there - for SRV records or port numbers -
IMO should be moved to separate documents.

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Sep 2009 16:37:21 +0200

> IMO should be moved to separate documents.

Yes, I agree with that.

Cheers

Magnus Westerlund