Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

[Flemming Andreasen <[e-mail]>]

 From a chair point of view, the intent with "scope is WebRTC" was 
largely what Paul described as option 1) below although I'd change 
"solely" to "primarily" (intent being that WebRTC is the primary driver, 
but if we can trivially and without controversy provide solutions that 
apply beyond that, then that would be desirable).

As Keith points out, this limited scope deliverable creates a new 
question in terms of scope for all the derived deliverables that have to 
be developed in the various WGs. It's not clear that we will have a 
single answer for all of these and taking BUNDLE as an example, it's 
currently an MMUSIC WG item, but its scope so far has not been limited 
to WebRTC (and I believe Colin argued in favor of keeping it that way at 
the Berlin meeting as well).

Thanks

-- Flemming


On 8/7/13 1:26 PM, DRAGE, Keith (Keith) wrote:
> I said that all the involved groups need to make a second step with all their deliverables, which is to decide whether what they are doing is used generally, or solely in the context of WEBRTC.
>
> Deciding whether it is 1) or 2) has not been defined in my understanding, and would really come under the scope of the second decision.
>
> I for one am hoping as much of this as possible comes out as being generally applicable, and obviously designed as such as a result, but the MMUSIC WG did not appear to be ready to say that last week. So some steps to get there.
>
> Keith
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Paul Kyzivat
>> Sent: 07 August 2013 14:41
>> To: [e-mail]
>> Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"
>>
>> On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:
>>> As one of those that used the term, my intention was that the initial
>>> decision was to agree to define what RTCWEB needed.
>>>
>>> As each dependent working group looks at the extensions they need to do,
>>> then they need to make the decision as to whether a wider scope of
>>> possible, desirable, or dangerous.
>>>
>>> So the BUNDLE status at the moment is that any changes for the unified
>>> plan should work for RTCWEB usage, but not for general. It would
>>> probably make sense to make it more generally applicable, but that is
>>> the next step in the decision process, and may need some other technical
>>> decisions before it happens.
>> I don't know how you intend the above to be parsed. Specifically, when
>> you say:
>>     "any changes for the unified plan should work for RTCWEB usage"
>>
>> Do you mean:
>>
>> 1) that the changes should be designed solely with RTCWEB usage in mind?
>> (But are still applicable in other environments that find them useful
>> and choose to adopt them.)
>>
>> Or do you mean:
>>
>> 2) that those changes should not be used in any environment other than
>> RTCWEB?
>>
>> I might be able to accept (1), but not (2).
>>
>> 	Thanks,
>> 	Paul
>>
>>
>>> Keith
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:*[e-mail] [mailto:[e-mail]] *On
>>> Behalf Of *Bernard Aboba
>>> *Sent:* 07 August 2013 00:50
>>> *To:* Christer Holmberg; mmusic
>>> *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"
>>>
>>> Christer said:
>>>
>>> "While cleaning up my MMUSIC notes today, I was listening to the audio
>>> recording, in order to get a clarification regarding what "scope is
>>> WEBRTC" really means.  However, unless I missed something, I didn't get
>>> a clear answer.
>>>
>>> Does it only cover the browser API (JSEP) or does it also cover
>>> something that can be sent out on the wire (as long as it is not SIP) by
>>> a browser?
>>>
>>> Feel free to tell me that it is a stupid question, and that the answer
>>> is very clear :)"
>>>
>>> [BA]  I actually think it is a good question :)
>>>
>>> One interpretation of "scope is WebRTC"  is that the  SDP in "Unified
>>> Plan" applies to use within  the JSEP API.    As a result, one
>>> might expect the SDP used in createOffer, setLocalDescription and
>>> setRemoteDescription to resemble that in the "Unified Plan" document.
>>> Since signaling is out of scope for WebRTC, applications that use the
>>> JSEP API might or might not use the "Unified Plan" SDP in signaling on
>>> the wire.
>>>
>>> However, "Unified Plan" includes normative references to published SDP
>>> specifications that were developed for general use, and the adoption of
>>> "Unified Plan" (or even an applicability statement within the "Unified
>>> Plan" document) doesn't change the applicability of those documents.
>>>
>>> Also, there may be some specifications that are part of the "Unified
>>> Plan" workload that may have applicability beyond WebRTC (e.g. a=group:
>>> SIMULCAST)
>>>
>>> Ultimately, I am expecting the work involved in "Unified Plan" to span
>>> multiple documents, and to clarify the applicability,  those individual
>>> documents will need to explain what they apply to (just WebRTC use or
>>> more general use).
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>