Hi, Michael, et al.,
I find it difficult to resolve this with the fact that basically only
TCP* gets through NATs, and the lack of widespread use of DCCP and SCTP.
(* more specifically, transport "6" with a passing resemblance to TCP's
header format, esp. SYN segments)
I.e., what's the point in an app asking for what it wants if the only
answer is "TCP"?
This might be an interesting topic for a research prototype, but
otherwise seems out of scope for the IETF - esp., as was noted, given
the IETF's current 'appreciation' for the role of APIs in protocol design.
Joe
On 10/8/2013 4:57 AM, Michael Welzl wrote:
Dear all,
Sorry if you receive multiple copies of this! I sent it to all the lists
with potentially interested folks... (this should be okay to do
according to RFC5434, which says "various mailing lists").
A community of interest is being formed to gauge whether there is
sufficient interest to host a BOF at the London IETF, on the topic of
"Transport Services". The intention is to create a WG that would define
the set of services that transport protocols offer to applications, such
that applications could at some point in the future request a service,
not a protocol. This could foster innovation (protocols could be tried
out, with a fall-back, without requiring the application programmer to
include such functionality); it could also give more freedom to whatever
resides below the API to automatically make the best out of what it
currently has available.
If you're interested in this problem space, please visit the related
webpage that I have set up:
https://sites.google.com/site/transportprotocolservices/
There you'll find an initial stab at a charter and all information about
the mailing list - please join us and participate in discussions! Thanks!
Cheers,
Michael
