W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2017

Re: Announcing intent to request CR transition for webrtc-pc, and to gather implementation experience regarding issue 1283

From: Cullen Jennings <fluffy@iii.ca>
Date: Thu, 19 Oct 2017 20:16:13 -0700
Cc: WebRTC WG <public-webrtc@w3.org>
Message-Id: <F9208951-2284-478B-B23E-938BABF8B520@iii.ca>
To: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>

I think we need to resolve the contradiction between this spec and specs it normatively references before we go to CR. 

> On Oct 18, 2017, at 9:03 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
> 
> After all recent discussion regarding Issue 1283 [1] on how to transmit 
> video in cases when there is a dimension mismatch between the sourcing 
> track and what can be sent we have concluded that the group may not be 
> ready to make a decision yet, but that more implementation (and use) 
> experience is needed. We therefore plan to remove the "Resolve before 
> CR" label from Issue 1283 and request transition to CR, because, after 
> all, 'to gather implementation experience' is one of the reasons why W3C 
> publishes a Candidate Recommendation [2].
> 
> Let us know before the end of this week (i.e. by end of October 21st) if 
> you object to this. We plan to request the transition early next week if 
> we don't receive objection.
> 
> Also note that in parallel discussions are ongoing, and if those are 
> successful, we can merge changes into the document going forward.
> 
> To give a bit more background: webrtc-pc [3] currently specifies (but is 
> unclear on certain details) one way (which was agreed on during the 2016 
> Lisbon TPAC meeting), while JSEP specifies [4] another way, to cope with 
> video dimension mismatch. At the October 12th webrtc WG meeting [5] it 
> was proposed to allow the application to select between multiple 
> behaviors, but it has been questioned whether the gain from that 
> motivates the added complexity. To our understanding the question is 
> mostly relevant when interoperating with non browser endpoints (since 
> JSEP rules for imageattr creation [6] gives one min and one max value 
> for width and height, and that implementations SHOULD allow reception of 
> arbitrarily small resolutions).
> 
> Stefan for the chairs
> 
> [1] https://github.com/w3c/webrtc-pc/issues/1283
> [2] https://www.w3.org/2017/Process-20170301/#maturity-levels
> [3] https://w3c.github.io/webrtc-pc/#rtp-media-api
> [4] https://rtcweb-wg.github.io/jsep/#rfc.section.3.6.2
> [5] https://www.w3.org/2011/04/webrtc/wiki/October_12_2017
> [6] https://rtcweb-wg.github.io/jsep/#rfc.section.3.6.1
> 
Received on Friday, 20 October 2017 03:16:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:52 UTC