Re: [tae] New draft: announcing the supported transports via DNS

[Joe Touch <[e-mail]>]

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

Jumping down to the punchline:

> A) If we *start* with the new protocol, and it simply does not go through, we:
> 
> 1) can not determine whether it was because the request was blocked
> or because the other end does not support this protocol.

True if you start with an existing protocol (e.g., TCP) and add an
option as well.

> 2) still need to fallback to something that you know may work better.

Agreed.

> B) Moreover, assuming we start the exchange on the new protocol in
> parallel with the "default fallback protocol", then either:
> 
> 1) we still need to verify whether the negotiated protocol works
> (since the protocol negotiation protocol is a different one)
> 
> 2) or we need to upfront use the inband negotiation within the
> protocol that the other end will speculatively support. Which we can not
> know because of the (A.1) above.
> 
> As I wrote earlier, "introducing new protocol" for a transport and 
> and "introducing new protocol" for the selection of new protocols for
> share a common subset of issues, the above is one of the examples.
> 
> What's your opininon ?

I agree.

IMO, this calls for a a protocol *between the endpoints* to determine
how to proceed. I don't think that fits or is appropriate for a TCP
option. I don't think the DNS is a useful protocol for this purpose
(whether between the endpoints or placed separately in the network).

Joe


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrLc28ACgkQE5f5cImnZrsZWwCfec4qgI74IlMP1KmQ0DTOBr+5
GDAAn2MZS2G4DoDdnJyf3Repmj9XKvn3
=OQXq
-----END PGP SIGNATURE-----