Update of "Sorting issues into categories"

For the record. This is a minor update of the mail titled "Sorting 
possible technical issues into categories" 
(http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0142.html).

* The issues in categories "Being addressed" and "Needs to be addressed" 
now all have ACTIONs associated with them.

* The issues in category "Needs to be more clearly described" now have 
descriptions (I link to Martin's mail). However, this in most cases 
moves them into the "Needs further discussion" category (one exception).

To make it a bit easier to see what has been added, all new lines start 
by "--"

Stefan
-----------------------------------------------------------------------

*Will not do*
-------------
- *Remove SDP*: the poll was clear

*Not a question for this WG*
----------------------------
- *H.264 SVC support*: IETF matter

- *Testing of continued connection liveness*: IETF matter

- *Interoperability with varying ICE and ICE-like agents*: IETF matter

*Being addressed*
-----------------
- *Learn what ICE candidates are in use*: this is part of the proposed
stats report
-- ACTION-12 and ACTION-54

- *Pausing and muting of streams*: there is already enable/disable on
tracks available [3], and there has recently been a proposal to move
this functionality to the consumer (e.g. PeerConnection) [2].
-- ACTION-57

- *Expose additional ICE state:*, *Remove offer/answer*, *Description of 
state/behavior is currently incomplete*, *Document how the different
state machines interact*: The discussion of states for PeerConnection,
including SDP exchanges, is ongoing
-- ACTION-51

- *Are MediaStreams mutable objects?*: According to [3] they are (but
there is a recent proposal that a MediaStream being received from a peer 
shall not be mutable [4])
-- ACTION-58

*Needs to be addressed*
----------------------
- *Rollback of offers*
-- ACTION-55

- *Provide congestion feedback API for flows*, *Bandwidth allocation*,
*Bandwidth estimation feedback* (there is a bug filed related to this
[5]; [4] proposed an API surface that might suitable; BW allocation is
perhaps mostly and IETF matter)
-- ACTION-56

*Needs further discussion*
--------------------------
- *DTMF onTone event*: unclear if there is consensus for supporting this 
feature, is currently not covered by use-case document [6])

- *Set Security Description*: need the discussion in IETF to finalize first

- *Learning of network change events*: need to discuss the role of app
and the role of the UA

- *Priority allocation*: need further discussion

- *API for discovering capabilities* (this has to some extent been
discussed in the Media Capture TF)

*Needs to be more clearly described*
------------------------------------
- *Control connection establishment based on certificate*
-- Described in [8]
-- Spawned "related identity issues" (see [8])
-- Needs further discussion

- *Split SDP between PeerConnection and MediaStream*
-- Described in [8]
-- Needs further discussion

- *Serialization of duplicated tracks*
-- Described in [8]
-- Proposed to consider this issue not relevant

- *Programmatic description of described streams*
-- Described in [8]
-- Needs further discussion

[1] http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0194.html
[2] 
http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0029.html

[3] http://dev.w3.org/2011/webrtc/editor/getusermedia.html

[4] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0025.html

[5] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861
[6] 
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/
[7] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html
[8] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0146.html

Received on Wednesday, 3 October 2012 12:38:19 UTC