Re: [rtcweb] Checkpointing decisions in RTCWEB

On Fri, Mar 8, 2013 at 8:57 AM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> Mary,
>   How can there be interoperability issues if no one is required to use SDP over the wire?
[MB]  My concern is extrapolated a bit beyond just RTCWEB to the
extensions that are being proposed for SDP to support RTCWEB -
independent of whether RTCWEB uses it over the wire.  In cases where
folks want interop with "legacy" SIP some form of the SDP needs to go
over the wire.  In an ideal world, that would be the same SDP blob,
but it doesn't appear that would be the case where RTCWEB is now.
[/MB]

[MB] Are you saying that there are things that we need that SDP cannot
express (or cannot be extended to express)?
[MB] Right now, there are things you need in SDP that there is no
agreement as to how they should be expressed.  I agree that the group
could certainly pick a way and then try to live with it.  However,
some of these things overlap with what CLUE needs.  If CLUE wants to
use the same building blocks (and not create yet another way to do
multi-stream), then CLUE would reuse some of what is being driven to
meet RTCWEB requirements.  A CLUE application/endpoint will be using
the SDP over the wire.  As I said initially, I arrived at my current
position after seeing the lack of consensus that was being reached at
the interim meeting.  I could be a total pessimist and all this will
get figured out next week in Orlando, but I am typically over
optimistic about work getting done in IETF, so I'm wouldn't put any
money on it.
 [/MB]
>
> - Jim
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mary Barnes
> Sent: Friday, March 08, 2013 9:50 AM
> To: Ted Hardie
> Cc: rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
> Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
>
> As an individual that's also a chair, I truly do understand your pain.
>  I realize that a change this late in the game is not at all a good thing.  I also realize the impact this might have on folks whose products are very entrenched in SDP (including my own employer).  But, this seems very much to be a pay now or pay later situation.  I have 100% confidence that this energetic and intelligent group of folks can come up with a protocol spec that relies on SDP - we have shown over and over that we can eventually make decisions when there are strong proponents with different approaches.  I don't debate that at all, but I am concerned about interoperability issues and the fragility of SDP.
>  This is not at all a new sort of problem - it's a pattern that exists very often in product development.  In my experience, doing something that seems a little more novel and disruptive can be done more quickly than trying to work with existing code/architectures that are being pushed well beyond their limits (based upon original design intent).
> I've seen this time and again in developing products.
>
> We also have a number of situations in IETF where we have been determined to complete something based upon a decision that was made and we have successfully completed protocol documents in these cases.
> However, we have a number of these cases where those documents just get put on a shelf.
>
> Best Regards,
> Mary
>
>
>
> On Thu, Mar 7, 2013 at 4:48 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> Howdy,
>>
>> For any working group to be able to make consistent progress, it must
>> be able to rely on decisions that have already been taken to remain
>> stable in the absence of new technical issues.    Re-raising old
>> issues without new information does not help move the work forward,
>> and, as tempting as it may be for those who raised it the initial
>> times, nor does a chorus of "I thought that all along".
>>
>> For the specific question in the thread entitled "Proposed Plan for
>> Usage of SDP and RTP - Lower level API minus SDP", I believe every
>> point in the thread has been raised before.  SDP has been unlovely and
>> arcane for many years, so this is not new news.  Despite that old
>> news, we have run consensus calls on this topic in both the IETF and
>> the W3C and agreed to use both it and offer/answer.
>>
>> May I politely suggest we finish that work *before* we examine the
>> need and feasibility of an addtional, potentially lower-layer approach
>> to this?  Finishing the work before us does not close off all related
>> work for all time, but failure to produce something viable soon likely
>> will.
>>
>> I'm not sure what hat to wear for this message, so assume a "grumpy
>> old timer" porkpie, size 7 and 3/8ths.
>>
>> regards,
>>
>> Ted Hardie
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>