- From: Henrik Nordström <henrik@henriknordstrom.net>
- Date: Mon, 06 Feb 2012 23:28:44 +0100
- To: Ted Hardie <ted.ietf@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
mån 2012-02-06 klockan 13:07 -0800 skrev Ted Hardie: > "Datagram transport does not require or provide reliable or in-order > delivery of data. The DTLS protocol preserves this property for > payload data. " This is a property of the underlying transport, not DTLS itself. DTLS preserves the same guarantees (or lack thereof) as the underlying transport. > The major point of DTLS is that it works without a reliable transport; its > advantages over TLS are there. Yes. > At least as I understand it, it also does not > guarantee this property when run over any transport. That's not my understanding. If the transport is reliable then DTLS is as well. > It might, for example, > deliver data out of order even when the underlying transport will re-transmit > to get in-order delivery; it depends on the implementation to determine when > the data is passed up. Not sure what you talk about here. in-order transports do not provide DTLS out-of-order access to the data. > I suspect it gets to be ignorant about the transport in part because it gets > to assume certain things about the transport. If you change those things, > I think the applications that are built on top of HTTP may want new tools from > HTTP (or they will each have to build those same tools for themselves). This > is particularly the case for applications where non-idempotent methods are > used. Well, to be honest those problems are there already even with TCP. Just slightly different. Please note that I do not say that HTTP/UDP is universally applicable to all applications or even makes sense at all times. Only that UDP is one of many transports HTTP may operate over and which makes sense for some applications. There is applications using HTTP/UDP today even if not part of any HTTP standard. Not because it's cool, but because it makes sense for those specific applications. Regards Henirk
Received on Monday, 6 February 2012 22:32:44 UTC