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

[Andrew Yourtchenko <[e-mail]>]

my 2 cents based also on reading of the exchange between Bryan, Dan and 
Caitlin inline:

On Sun, 20 Sep 2009, Michael Welzl wrote:

>
>>  I think the following objectives need to be met for any probe-based
>>  solution:
>>
>>  1) Must add no additional messages when the default protocol is selected.

There are at least two possible scenarios I'd see:

a) default protocol is "selected" in case the peer simply does not have 
the support for the transport selection
b) the default protocol is "selected" after the fact because the more 
advanced protocol that was negotiated does not succeed.

and a worst case to consider is where the piggybacking on the existing 
"default" protocol breaks it - so there needs to be a fallback scenario 
for that case.

(a) is quite possible.
(b) very much not sure if possible.

>>  2) TCP must be a valid default protocol.
>>  3) There may be a case for adding UDP to that set for RTTP.

I'd phrase it something like: "There should always exist a valid 
fallback/default protocol that is defined on a per-application basis 
under the assumption that the transport selected is not implemented on 
the other endpoint".

>>  4) It should be capable of learning when a given client/server pair is
>>  blocked
>>      from using Transport X by some middle-box. Note: this is something a
>>      directory-based solution probably cannot do.,

+1. And the directory-based solution alone indeed can not do it. However, 
learning about the protocol being blocked, implies extra messages followed 
by a fallback to the "default" - the case of (1b) above.

I think it could be useful for first explicitly splitting the functions 
of "discovery" and "selection", and then seeing how they can be combined, 
if - a form of refactoring.

Having them originally split allows to focus on smaller chunks at a time, 
IMHO. When those chunks are well understood, it is easier to compose them.

thanks,
andrew