i'm fine with all that... Sent from my iPhone
> On 3. juni 2015, at 17:58, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> > wrote: > > Hi all, > >> On 03.06.2015 17:04, Brian Trammell 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 > > 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 >>>> 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 > > -- > ------------------------------------------ > 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: mirja.kuehlew...@tik.ee.ethz.ch > ------------------------------------------ > > _______________________________________________ > 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
