Subject: Re: [MMUSIC] Updated MSID draft

From: Flemming Andreasen <[email-masked]>
Date: Fri, 02 May 2014 22:37:33 -0400

Hi Harald

I have taken a closer look at msid-05 and have a number of comments. I 
will list the major ones and/or what might require list discussion here 
and send you a bunch of more detailed ones in an annotated version 
off-line:

1) There are some grammar inconsistencies between the way you use token 
and (some) of the text you have. In general, it seems the length should 
be limited and the set of characters you want to allow are less than 
what token allows for.

2) Offer/Answer procedures are lacking. We need to have an O/A section 
with subsections as per RFC 3264 (for unicast) to better specify the 
overall behavior here (Generating the Initial Offer, Generating the 
Answer, Offerer Processing of the Answer, Modifying the Session)

3) There is some ambiguity as to what constitues an msid value and more 
specifically when it includes both the MediaStream identifier and the 
MediaStreamTrack and when (if ?) it doesn't.

4) Unified-plan is being referenced in a normative manner (but is listed 
as an informative reference). Since unified-plan is not expected to go 
to RFC, having a normative reference to it is problematic.

Thanks

-- Flemming

On 3/6/14, 8:25 AM, Flemming Andreasen wrote:
> I think the draft needs a bit more work in a few places (largely 
> editorial and more text on some of the procedures). I'll sign up to do 
> a pre-WGLC individual review to get you some more tangible and 
> constructive feedback on that.
>
> Thanks
>
> -- Flemming
>
>
> On 3/6/14, 8:19 AM, Harald Alvestrand wrote:
>> I have uploaded an updated msid draft, without the msid-control: 
>> section.
>>
>> As I said in the WG meeting, I think this is now uncontroversial, and
>> should be ready for WG Last Call.
>>
>> I request that the WG chairs consider whether they agree with this 
>> opinion.
>>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 04 May 2014 21:26:30 +0200

On 05/03/2014 04:37 AM, Flemming Andreasen wrote:
> will list the major ones and/or what might require list discussion
> here and send you a bunch of more detailed ones in an annotated
> version off-line:
>
> 1) There are some grammar inconsistencies between the way you use
> token and (some) of the text you have. In general, it seems the length
> should be limited and the set of characters you want to allow are less
> than what token allows for.
>

Hm. But MSID isn't an offer/answer field. It's an unilateral
declaration, and refers to no information coming from the other side.

Does it make sense to follow the offer/answer section format when the
answer doesn't depend on the offer?

>
> 3) There is some ambiguity as to what constitues an msid value and
> more specifically when it includes both the MediaStream identifier and
> the MediaStreamTrack and when (if ?) it doesn't.

Hm. Must make this clearer. The generic format has MST-identifier
optional, and the WMF usage has MST-identifier mandatory.

>
> 4) Unified-plan is being referenced in a normative manner (but is
> listed as an informative reference). Since unified-plan is not
> expected to go to RFC, having a normative reference to it is problematic.

Have to move this pointer to JSEP. I think JSEP has the necessary
targets now.

>> editorial and more text on some of the procedures). I'll sign up to
>> do a pre-WGLC individual review to get you some more tangible and

-- 
Surveillance is pervasive. Go Dark.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 06 May 2014 11:15:12 -0400

> answer doesn't depend on the offer?
It does. Even declarative SDP parameters have procedures that must be 
followed by the offerer and the answerer and we want those called out 
clearly.
> optional, and the WMF usage has MST-identifier mandatory.
The confusion is more around some of the text in the document which is 
not always clear on this (to me at least).

> Have to move this pointer to JSEP. I think JSEP has the necessary
Ok.

Thanks

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 May 2014 17:26:26 +0000

Hi,

>>> 2) Offer/Answer procedures are lacking. We need to have an O/A 
>>> section with subsections as per RFC 3264 (for unicast) to better 
>>> specify the overall behavior here (Generating the Initial Offer, 
>>> Generating the Answer, Offerer Processing of the Answer, Modifying 
>>> the Session)
> followed by the offerer and the answerer and we want those called out clearly.

I agree.

I have to admit that I was sceptical when Flemming asked me to do a similar change for the UDPTL-DTLS draft, but afterward I think it was a good thing to do.

Especially when it comes to subsequent offer/answer exchanges, it's good to have explicit text on what is allowed, and what is not.

I also did the same change for BUNDLE (which was a much bigger exercise than I initially thought :), so let me know if you need some help :)

Regards,

Christer