Hi Joe,
the document defines one more term:
Transport Service Instance: an arrangement of transport protocols
with a selected set of features and configuration parameters that
implements a single transport service, e.g. a protocol stack (RTP
over UDP).
This is to describe also a stack of protocols which an application might use to
get a certain transport service. (we might need to re-write this maybe, because
I now have the feeling that this is hard to understand).
Currently we are not using this term in this document because we try to
describe components of anything that might/could provide a transport service
feature of all protocols that that might be part of a protocol stack that can
be accessed by an application.
That’s what we had in mind when we came up with this terminology and I think
think it covers the case where HTTP over TCP is used as a transport
‚substitute‘.
Mirja
> Am 04.06.2015 um 23:20 schrieb Joe Touch <[email protected]>:
>
>
>
> On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote:
>> In my presentation in Dallas I had suggested adding RTP (and even
>> HTTP) because as both Mirja and Christian mention some 'applications'
>> are requesting functionalities that are got given elsewhere.
>
> The core of this issue is "what is a transport protocol".
>
> To the user, "transport" is the entire stack between their program and
> the network (IP) layer - sometimes even including that (e.g., IPsec).
>
> To typical transport protocols (e.g., UDP, TCP), everything that
> accesses a transport protocol is the "application" layer.
>
>> From the document:
> Transport Service: a set of transport service features, without an
> association to any given framing protocol, which provides a
> complete service to an application.
>
> Transport Protocol: an implementation that provides one or more
> different transport services using a specific framing and header
> format on the wire.
>
> By those definitions, EVERYTHING between the user program and the link
> layer is arguably part of the services an app sees, which include "shim"
> services and layers such as: IPsec, TLS, and RTP.
>
> I would argue that HTTP is the application that uses TCP (or TLS/TCP),
> but not a separate service, but that's true only for conventional web
> service.
>
> There are many services built on top of HTTP, at which point HTTP is
> just another part of what this document calls a "transport service".
>
> As a result, unless you'll be describing every possible stack between
> the user program and the link layer, this document cannot proceed with
> the current definitions.
>
> Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
