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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

I agree with most of James' conclusions, with some caveats:

james woodyatt wrote:
> 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'd say a transport layer is defined as the first protocol header in the
payload of the network header addressed to the host. That is typically
the innermost IP packet, but not always.

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

These are all transparent to the transport protocol; I agree that they
are not transport issues.

...
>> 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)."

I disagree; keep in mind that port number assignments aren't IP-version
specific, so if a service is assigned to port A, then it is assigned to
port A for IPv4 and IPv6. I see no reason why SRV records should either
support or encourage a network-protocol specific port number for a given
service.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk3CZYACgkQE5f5cImnZrvRJQCgjn2orbTOLfx0PKyILnWu1fin
xzsAoNzyIVz/8vPouTEyP+7rfPYLeZcb
=XJRD
-----END PGP SIGNATURE-----
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae