Hi all,
On 03.06.2015 17:04, Brian Trammell wrote:
On 03 Jun 2015, at 16:48, [email protected] wrote:
Hi,
I know this has been discussed before, but only briefly. I have two
arguments that I'd like to bring forward towards removing RTP (/RTCP) from
draft-ietf-taps-transports-04 and the documents that will follow it. I
understand that it's a non-obvious question whether RTP should be
considered a transport protocol or not, and I don't want to take a side in
this or step on anyone's toes here - these are more practical, pragmatic
considerations, and I'd just like to see how people react. If folks go
crazy in response to this I won't keep arguing, but I'd be happy if I'd
see some agreement:
Argument #1: RTP implementations need to be tied closer to the application
than the implementation of transport such as TCP, DCCP, SCTP. There is
usually a very tight interaction with the codec and RTP - a reaction to
one specific incoming RTCP message, for instance. So I'd rather see a
future TAPS system being *used* by RTP instead of *providing* RTP
functionality.
I think the same.
+1
Actually I think I don't agree here. Yes, it's tied closer to the application
but I think for taps this is a (good) example where the interface is at a much
higher level and therefore might have a value to discuss it. However... (see below)
Argument #2: TAPS has a non-negligible risk of ending up as an academic
exercise. I understand that but I don't want that - I think we should do
our best to keep TAPS "real". If that is our goal, including the world's
largest protocol isn't perhaps ideal... I think it should be in our
interest to try to keep the list in draft-ietf-taps-transports-04.txt
reasonably contained.
I'd prefer the document not to ignore RTP - but to say enough, so that
people can read further should this wish. If the above is correct, then I
think perhaps this document can cover this in the introduction, along with
a mention perhaps of other framing or content-oriented protocols that can
use transports.
Agree as well. If we completely ignore RTP, it will be conspicuous in its
absence.
I'd suggest a bit of tombstone text in the RTP section that explains the
rationale behind not really digging into RTP for components/features... I can
put together something (based more or less on this message) for the -05 rev I'm
working on...
... I agree here. But I think (right now) I would still like to have an own RTP
section but be very brief and give some reasoning why we don't wnant to go into
further details. Just as a side remark, I don't see any reason to mention RTP in
any following documents though.
Mirja
Cheers,
Brian
Cheers,
Michael
Gorry
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
--
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland
Room ETZ G93
phone: +41 44 63 26932
email: [email protected]
------------------------------------------
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
