Hi Michael, > >Okay, it seems we're all on the same page. My heavy reaction to the email >before (and sorry Karen, I had forgotten why you sent it! Indeed that was >agreed upon at the last meeting) was because I'm afraid of the logical >conclusion: >"this is what applications currently configure in current protocols" => >"this is >what a TAPS API would need to provide".
[Karen ] No problem - the clarification was important :-). Yes I think so (one the same page). And I did not intend to make the above corollary. The purpose of the posting was to provide information on presently drawn on transport service API granularity by a set of applications (Real-time signaling applications). I believe such information is relevant to put the abstraction of Taps into context. Regardless of where the line of abstraction ends up being drawn. > >Rather, I think it would be better to focus on *why* applications currently >configure the things they do, such that we can then provide something >reasonable and meaningful to them. >Then again, even that is something we could spend much time on, and >possibly in vain: I believe that applications that are configuring all >these things >nowadays probably wouldn't be "customers" of TAPS anyway. >TAPS generally targets programmers of applications who are willing to give >up >some control, for the possible benefits that come with abstraction. This >will >always only be a subset of applications. > [Karen ] Yes - the difficult job is to strike the right balance. >Cheers, >Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
