Re: Draft "summary of decisions"

On Fri, Jan 27, 2017 at 10:58 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> This is the meat of what I plan to send (note there is no decision on
> the first two items - I will move them to a separate section when
> sending). Please let me know what I got wrong:
>
> ================================================
> webrtc-pc
> ---------
> Issue 979/PR 996: When is an RTCSctpTransport Created and Destroyed?:
> Something about being created at pr-answer - I did not record any
> decision apart from "Taylor will update PR"
>

Decision: RTCSctpTransport is created when both an offer and an answer have
been processed; this is the earliest time datachannels can be used, and the
earliest time a value is available for maxmessagesize (which is the main
point of the object). We can create it on pr-answer (if not for pr-answer,
it would be logical to create it when entering a stable state).


>
> Issue 116/PR 990: Add an explicit stats selection algorithm: discussed,
> two things noted: J-I would prefer something recursive instead of a
> fixed list. Several preferred having sender/receiver as selcetor instead
> of track
>

Decision: J-I will craft a worked example of what will be returned under a
recursive algorithm; J-I will craft a PR for selecting on sender/receiver
rather than track, as a basis for further discussion.


>
> PR 988: Add RTCOfferOptions.reofferOptions: DECISION: We will not merge
> this one. JSEP expected to provide what is needed.
>

I'd phrase the last part as "Discussion in JSEP will result in either
asking for this again, asking for something else, or dropping the issue".


>
> Issue 709: offerToReceiveAudio/offerToReceiveVideo remain in
> implementations: DECISION to add this back into the spec (in the
> compatibility section). Note that only the binary/boolean version will
> be added back in (indicating that you are offering to receive one track)
>
> Issue 961: Effect of a BYE on RTCRtpReceiver.track: Bernard's proposed
> resolution was generally liked, but there are some corner cases to sort.
> DECISION: to go in the direction of Bernard's proposed resolution.
>
> Issue 962: Event when a transceiver is stopped via remote action:
> Bernard's proposed solution was like, DECISION to add to spec.
>

nit: s/like/liked/


>
> Issue 714/PR 1000: STUN/TURN auth credential management (OAuth):
> DECISION: got with the "hybrid" API, and make username optional.
>
>
> mediacapture-main
> -----------------
> Issue 404: Revive createObjectURL?: The idea of reviving was disliked.
> DECISION: do not revive. (Implementors promised to add deprecation
> warnings and similar, and demo code etc. will be gone through to change
> to .srcObject.)
>
> Issue 425: Do we update legacy methods to keep up with the spec?:
> DECISION: do nothing (for the time being at least).
>

Suggest to add: This means that legacy methods are shims over the main
methods, and changes and clarifications in the main spec will also change
the legacy methods.


>
> Issue 426: Move “advanced” out of constrainable pattern: DECISION: defer
> this discussion until there is some spec that intend to use
> constrainable pattern and does not like to implement advanced.
>
> =========================================================
> Br,
> Stefan
>

Looks good!