> 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 > >> 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... 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
