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

On Dec 3, 2008, at 13:07, Stuart Cheshire wrote:
>
> The problem is that what constitutes a "transport layer" is a bit  
> slippery.

I don't think it should be.  The "transport layer" is identified by  
the upper layer protocol header at the end of the extension header  
chain of the inner-most encapsulated IP packet.  I think it would be a  
lot simpler if we didn't succumb to the temptation to overload that  
concept with a lot of other ones that really belong in the layers  
above the transport layer.  For example...

> 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?

Speaking as a participant in the now-defunct BEEP working group, which  
wrangled these issues to the ground a long time ago, the answer I  
would give to all these questions is, "No."  They are all application  
profile negotiations.  Some of them happen to be profile negotiations  
designed to tune the application protocol for certain transport layer  
extensions, e.g. security, compression, etc., and others are purely  
application layer negotiations, but none of them are negotiations of  
which transport layer to use.

> The combinatorial explosion gets out of control. The correct answer  
> IMHO, is to not even try.

And to say, "No, these are not transport layer negotiations; they're  
application profile negotiations."

> 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: [...]

I certainly agree with that, but I think SRV makes a number of  
mistakes and this is only one of them.  I would prefer a different  
definition where the record type is a union of different structure  
types discriminated by transport protocol identifier.

While I'm dreaming, I think I'd ask for two record types to be  
defined: one for IPv4 and the other for IPv6.  That way, the DNS-SD  
usage of PTR records could allow registrants to advertise things like  
"this service is available for IPv6 at TCP port A and for IPv4 at TCP  
port B (which I've got mapped at my NAT gateway to port A)."

--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering

_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae