Am 04.06.2015 um 23:20 schrieb Joe Touch:
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,
Shouldn't this ideally be the (long-term) goal of TAPS?
Of course it will never be feasible to consider every conceivable existing or
future stack in practice. Thankfully, since it has been stated multiple times
that TAPS is not intended to replace everything that exists out there, it's
maybe good enough to have a look at some stacks...?
this document cannot proceed with the current definitions.
So could a possible way forward be to leave the definitions as they are and add
a description of the considered stack(s) to the document? For now "just" TCP,
UDP, SCTP, ... over IPv4/6 etc.
At a later point that could be updated to services provided by the same stack
with RTP and the likes on top and a third with HTTP over TCP(/TLS) ... the goal
being to at least cover the "popular" stack (combinations) at some point.
Wouldn't that help to simplify the discussion which protocols are in and out of
scope as service providers at a given point in time a lot?
Joe
Apologies for just barging in like that. Im a long-time TAPS lurker so to speak
and genuinely interested in opinions regarding such an approach.
Helge
--
Karlsruhe Institute of Technology (KIT)
Institut für Telematik
Dipl.-Inform. Helge Backhaus
research assistant
Zirkel 2
Building 20.20
Room 352
D-76128 Karlsruhe
phone: +49 721 608 46402
backh...@kit.edu
www.tm.kit.edu
KIT – Universität des Landes Baden-Württemberg und
nationales Großforschungszentrum in der Helmholtz-Gemeinschaft
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
