+1 Don't ignore, but dont actively work on... On 3 Jun 2015 11:04, "Brian Trammell" <i...@trammell.ch> wrote:
> > > On 03 Jun 2015, at 16:48, go...@erg.abdn.ac.uk 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 > >> Taps@ietf.org > >> https://www.ietf.org/mailman/listinfo/taps > >> > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > >
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
