I'm sorry if I haven't been paying attention, but what do you mean by "the topic of transport services"?
Several things come to mind: - please deliver my data - y/n reliable delivery - y/n out-of-order delivery - y/n fast connect, w/ or w/o crypto protection - optimize for min latency vs optimize for max throughput - weighted congestion control for fine tuning priorities - y/n multiple paths or endpoints - y/n "nat compatible" - y/n for event notification (up/down etc) - etc In varying degrees we know how to do most of these in both TCP and SCPT. The trick to providing them as "services" is to unbundle the (sub)layers. If you mean to design a API, I think you will find that the IETF has a lot of trouble with stuff that is not visible on the wire, and has repeatedly failed to converge on such issues. Your broadcast message should have included "Please discuss on xxxx list." Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Oct 8, 2013 at 4:57 AM, Michael Welzl <[email protected]> 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 >
