RE: "pranswer" status (or get rid of it)

Currently, we are working on bringing WebRTC 1.0 to "Candidate Recommendation" (CR), which is the first stage of the W3C standardization process. 

By bringing the specification to CR, the WG is attesting that the specification is "feature complete" (e.g. that the specification meets the requirements), and is ready for implementation. 

As part of this process, a review of the WebRTC specification (with a deadline of May 31) is currently in progress:
https://lists.w3.org/Archives/Public/public-webrtc/2017May/0103.html

Getting the specification ready for CR has kicked off the process of developing a test suite, documenting implementation status, etc.

That work, once completed, provides the basis for the specification to advance to the PR level. 

This context is provided to explain why the current process is focusing largely on determining what features should be marked as "at risk", as opposed to removal of features. 

Since the CR stage signals that the specification is ready for implementation, we do not yet have the information necessary to make a removal determination. 

Given that implementations of significant parts of the specification (such as Section 5) have only gotten underway relatively recently, if we were to systematically remove every feature that does not yet have 2 interoperable implementations, much of the current specification would need to be removed (and the remainder probably would not meet the requirements). 

Even with respect to marking of "features at risk", feedback from the WG has indicated the desire to be systematic and deliberate: 
https://lists.w3.org/Archives/Public/public-webrtc/2017May/0027.html

The "poster boy" for a less-than-desirable process was the marking of provisional answer as a "feature at risk". 

In early April, an issue was filed about this: 
https://github.com/w3c/webrtc-pc/issues/1106

Subsequently based on a limited discussion in GitHub (rather than a posting on the public-WebRTC mailing list) PRANSWER was marked as "at risk":
https://github.com/w3c/webrtc-pc/pull/1110

However, at the May Virtual Interim it was noted that Firefox did indeed plan to implement PRANSWER, and therefore marking this as a feature "at risk" was pre-mature, so that it was reverted.
________________________________________
From: Iņaki Baz Castillo [ibc@aliax.net]
Sent: Monday, May 22, 2017 3:49 AM
To: public-webrtc@w3.org
Subject: "pranswer" status (or get rid of it)

Hi,

Firefox does not support "pranswer" and Chrome breaks ICE/DTLS things
if "pranswer" is used.

I still see the "pranswer" monster in the WebRTC 1.0 draft. We don't
need it. It can be perfectly emulated via JS by means of (assuming
SIP):

1) pc.createOffer() => offer

2) pc.setLocalDescription(offer)

3) Send INVITE

4) Receive 183 with SDP

5) pc.setRemoteDescription(pranswer)

6) Receive 200 with SDP

7) pc.setLocalDescription(pc.localDescription)

8) pc.setRemoteDescription(answer)

"pranswer" is the ugliest and most useless stuff in WebRTC API and
nobody implements/uses it.

Can we get rid of it before 1.0.0 is out?

--
Iņaki Baz Castillo
<ibc@aliax.net>

Received on Monday, 22 May 2017 19:36:03 UTC