Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

["Matthew Kaufman (SKYPE)" <[e-mail]>]

The good news is that I co-authored and Microsoft published a nice starting point for discussing a specification that doesn't have SDP O/A.

The bad news is that it was voted down for future consideration at W3C.

The good news is that W3C has apparently abdicated the entire responsibility for producing a browser API to IETF, where it has not yet been voted down.

More good news is that if and when the W3C considers the current specification that the IETF produces, if it is not complete enough to independently replicate without looking at other browser's source code (in other words, if the SDP that is produced is not fully specified in an interoperable way in either the W3C specification itself or, worst case, in the entire stack of normative references), I will also have the pleasure of co-authoring a formal objection to publishing that specification.

One might consider that since the current SDP-based path we are on does not have anywhere near a complete set of implementable normative references, and that producing such might actually be harder than using something that doesn't rely on SDP as the API surface, you might be a lot farther from something that finishes the entire W3C process than you think.

Matthew Kaufman

________________________________
From: [e-mail] [[e-mail]] on behalf of Ted Hardie [[e-mail]]
Sent: Tuesday, June 18, 2013 1:15 PM
To: Iñaki Baz Castillo
Cc: [e-mail]
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

I've read the messages on this thread up to lunchtime in California on June 18th.  I have not consulted with the other chairs, because we are still somewhat out of synch, so this is my personal response, rather than a chair response.

SDP occurs as an API control surface in this protocol, and it may also be used in O/A semantics between endpoints.  The request does not clearly state which aspect is asking for reconsideration.  Since one is handled in a different group, that is critical.  Secondly, the requirement the group has is that the solution *provides support sufficient to allow O/A semantics*, not that these must be used between two parties using the same signalling.   Being clear on what you would like to see by writing a draft proposal, rather than simply asking to re-open concluded discussions would be helpful.

Speaking very personally, I would like to see the group close having completed its milestones.  While I am very aware that re-using a syntax like SDP makes for some unpleasant moments, I'm not sure that any system that actual has any level of interoperability with existing SIP deployments as a goal will avoid that unpleasantness--at best, you have a mechanism on one end that looks different *but must be mapped to SDP* in the interoperability case.   Creating something new that accomplishes that and is substantially better than SDP seems like a long task to me.

Again, not as a chair decision or statement, but to give some response to the points made.

regards,

Ted Hardie