Re: [tae] [tsv-area] Transport negotiation

[Stuart Cheshire <[e-mail]>]

On 26 Nov, 2008, at 16:24, Joe Touch wrote:

> http:// doesn't "just work" - it specifically indicates "HTTP over  
> TCP"
> IMO. And http://10.0.0.1/ specifies "HTTP over TCP over IPv4".


I think Joe is right about this.

I think the whole notion of "transport negotiation" is flawed. It  
seems attractive to say, "DNS runs over both TCP and over UDP, so we  
should be able to dynamically negotiate which," but under scrutiny  
the idea falls apart.

The problem is that what constitutes a "transport layer" is a bit  
slippery.

In a text-based protocol that can use either UTF-8 or Latin-1, is the  
UTF-8/Latin-1 choice a transport negotiation?

In a protocol that can run over TCP or over TLS, is that a transport  
negotiation?

If a web server can optionally gzip content to save bandwidth, is  
that a transport negotiation?

What about gzip'd UTF-8 vs. gzip'd Latin-1? What about gzip'd UTF-8  
over TLS? What about ASN.1 vs. XDR vs. XML?

The combinatorial explosion gets out of control. The correct answer  
IMHO, is to not even try. The Application Protocol Name in the SRV  
record needs to be an opaque identifier that denotes the entire top- 
to-bottom slice through the protocol stack -- semantics, packet  
formats, encoding rules, transport protocol. (Once the client has got  
a connection to the server, negotiating things like optional  
compression at that layer is then feasible and sensible.)

Even having the _udp or _tcp is, IMO, a historical mistake. This is  
what I say about it in draft-cheshire-dnsext-dns-sd-05.txt:

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 <[e-mail]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

_______________________________________________
tae mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tae