Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 2 Mar 2017 22:40:52 +0100

2017-02-09 0:09 GMT+01:00 Flemming Andreasen <[email-masked]>:
> This is to announce a 2 week WGLC on the  draft:
>
>     https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-07.txt

Hi, the draft shows as example:

   a=rid:1 pt=97 send
   a=rid:2 pt=98 send
   a=rid:3 pt=97 recv

but according to https://tools.ietf.org/html/draft-ietf-mmusic-rid-09
it seems that "direction" (send/recv) should be placed *before*
"pt=xx":

a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...

The ABNF grammar confirms this:

https://tools.ietf.org/html/draft-ietf-mmusic-rid-09#section-10

So may be the example SDPs in draft-ietf-mmusic-sdp-simulcast-07 are wrong?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 2 Mar 2017 22:43:57 +0100

> a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...

In fact, pt=xx seems to be yet another "param".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 03 Mar 2017 10:56:58 -0500

> In fact, pt=xx seems to be yet another "param".

That purported BNF is really bizarre, since it generates the clearly
incorrect form:

   a=rid:<rid-id> <direction> <restriction>=<value><restriction>=<value>

A correct description is:

   a=rid:<rid-id> <direction> ( pt=<fmt-list> | <restriction>=<value> ) *( ; <restriction>=<value> )

The problem is that BNF doesn't allow you to directly specify what you
want to say:  (1) pt is like a parameter, but if it's present, it must
be first, and (2) there must be at least one pt or restriction.  And
there's no simple construction for "a list of one or more X's separated
by Y's".

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 3 Mar 2017 17:41:46 +0100

> there's no simple construction for "a list of one or more X's separated

Understood. But, anyhow, the a=rid lines in
draft-ietf-mmusic-sdp-simulcast-07 are wrong, right?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Mar 2017 14:06:01 -0500

> So may be the example SDPs in draft-ietf-mmusic-sdp-simulcast-07 are wrong?

It appears that all the examples of this in section 6.6.1 are wrong, 
while the examples elsewhere are ok.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Mar 2017 14:07:40 -0500

Dale,

> That purported BNF is really bizarre, since it generates the clearly

IIUC you are commenting on the ABNF in draft-ietf-mmusic-rid-08, not in 
draft-ietf-mmusic-sdp-simulcast-07, right?

>    a=rid:<rid-id> <direction> <restriction>=<value><restriction>=<value>

I'm not seeing how the ABNF generates that.

>    a=rid:<rid-id> <direction> ( pt=<fmt-list> | <restriction>=<value> ) *( ; <restriction>=<value> )

ISTM the ABNF in the draft is equivalent to what you have written. 
(Though yours is clearer.)

Meanwhile, the ABNF of draft-ietf-mmusic-sdp-simulcast-07 does some 
small problems:

1) it allows either one or two 'sc-str-list's. I presume this is so you 
can have both send and recv lists, but it also allows two send lists or 
two recv lists.

2) it references rid-identifier from draft-ietf-mmusic-rid-08, but that 
isn't defined there. I guess it means to reference rid-id.

3) this syntax defines the syntax of the entire attribute, including 
"a=" and the separation between attribute name and value. We are trying 
to get away from that as part of the cleanup in rfc4566bis. (Because 
people keep getting it wrong, so that it doesn't match with the generic 
syntax of an attribute.)

I suggest a better syntax for this would be:

    sc-value     = sc-send [SP sc-recv] / sc-recv [SP sc-send]
    sc-send      = "send" sc-str-list
    sc-recv      = "recv" sc-str-list
    sc-str-list  = SP sc-alt-list *( ";" sc-alt-list )
    sc-alt-list  = sc-id *( "," sc-id )
    sc-id-paused = "~"
    sc-id        = [sc-id-paused] rid-id
    ; SP defined in [RFC5234]
    ; rid-id defined in [I-D.ietf-mmusic-rid]

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 06 Mar 2017 14:50:11 -0500

Paul Kyzivat <[email-masked]> writes:
>> Inaki Baz Castillo <[email-masked]> writes:

What I'm commenting on is this line way back in the innermost quoted
message

>>>> a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...

which was in turn quoted from draft-ietf-mmusic-rid-09.

In BNF-like notations, "..." means "repetition of the preceding thing",
which I took to mean repetition of "<restriction>=<value>".  Although
that's probably not the correct interpretation, and rather it means
repetition of "<value>".

> (Though yours is clearer.)

What I don't see is why mmusic-rid-09 requires the pt restriction to be
in first position.  I'm not read into it, but it seems that there's no
semantic reason why it must be first, and it makes the grammar messier
to force it to be so.  Without that restriction, you could just say

>>    a=rid:<rid-id> <direction> <restriction>=<value> *( ; <restriction>=<value> )

and allow pt to be one of the <restriction>s.

Dale

---

From: Bo Burman <[email-masked]>
Date: Mon, 13 Mar 2017 07:48:58 +0000

Dale,

The "a=rid" line syntax you are quoting from -mmusic-rid-09 below is not the formal definition and it is therefore not meant to interpret formally, specifically not the "..." at the end, but only meant to provide an example. The text in -mmusic-rid-09 just above that quoted line also refers to section 10 for the formal definition. ISTM that the formal definition is entirely correct, not lacking the ";" between rid parameters that formal interpretation of "..." would imply:

   rid-syntax        = "a=rid:" rid-id SP rid-dir
                       [ rid-pt-param-list / rid-param-list ]

   rid-id            = 1*(alpha-numeric / "-" / "_")

   alpha-numeric     = < as defined in {{RFC4566}} >

   rid-dir           = "send" / "recv"

   rid-pt-param-list = SP rid-fmt-list *(";" rid-param)

   rid-param-list    = SP rid-param *(";" rid-param)

   rid-fmt-list      = "pt=" fmt *( "," fmt )

   fmt               = < as defined in {{RFC4566}} >

   rid-param         = rid-width-param
                       / rid-height-param
                       / rid-fps-param
                       / rid-fs-param
                       / rid-br-param
                       / rid-pps-param
                       / rid-bpp-param
                       / rid-depend-param
                       / rid-param-other

<definition continues with defining the individual rid-param components>

It is probably unfortunate that the quoted "a=rid" line is not 100% compliant ABNF, but I don't see the point in having (different) formal definitions in two places in the document and the text already says that this is not the formal definition.

/Bo
(as individual)

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Dale R. Worley
> Sent: den 6 mars 2017 20:50
> To: Paul Kyzivat <[email-masked]>
> Cc: [email-masked]
> Subject: [MMUSIC] Definition of a=rid in draft-ietf-mmusic-rid-09 (was WGLC on draft-ietf-mmusic-sdp-simulcast-07)
> 
> >>>> but according to
> >>>> https://tools.ietf.org/html/draft-ietf-mmusic-rid-09
> > IIUC you are commenting on the ABNF in draft-ietf-mmusic-rid-08, not
> > in draft-ietf-mmusic-sdp-simulcast-07, right?
> >
> >>    a=rid:<rid-id> <direction>
> >> <restriction>=<value><restriction>=<value>
> >
> What I'm commenting on is this line way back in the innermost quoted message
> 
> In BNF-like notations, "..." means "repetition of the preceding thing", which I took to mean repetition of
> "<restriction>=<value>".  Although that's probably not the correct interpretation, and rather it means repetition of
> "<value>".
> 
> What I don't see is why mmusic-rid-09 requires the pt restriction to be in first position.  I'm not read into it, but it seems
> that there's no semantic reason why it must be first, and it makes the grammar messier to force it to be so.  Without that
> restriction, you could just say
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bo Burman <[email-masked]>
Date: Mon, 13 Mar 2017 11:45:26 +0000

Agree that examples in 6.6.1 are wrong; will be corrected in -08.

/Bo
(as individual)

> From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: den 3 mars 2017 20:06
> To: [email-masked]
> Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07
> 
> It appears that all the examples of this in section 6.6.1 are wrong, while the examples elsewhere are ok.
> 
> 	Thanks,
> 	Paul
>

---

From: Bo Burman <[email-masked]>
Date: Mon, 13 Mar 2017 14:48:53 +0000

Paul, thanks for good comments,

Please see my responses inline.

/Bo
(as individual)

> Sent: den 3 mars 2017 20:08
> To: [email-masked]
> IIUC you are commenting on the ABNF in draft-ietf-mmusic-rid-08, not in draft-ietf-mmusic-sdp-simulcast-07, right?
> 
> Meanwhile, the ABNF of draft-ietf-mmusic-sdp-simulcast-07 does some small problems:
> 
> 1) it allows either one or two 'sc-str-list's. I presume this is so you can have both send and recv lists, but it also allows two
> send lists or two recv lists.
[BoB] That is to allow for having both send and receive directions on the same line, because use of multiple lines are not defined (section 6.2 says "The meaning of including multiple "a=simulcast" lines in a single SDP media description is undefined, MUST NOT be used by implementations of this specification and any additional 'a=simulcast' lines beyond the first in a media description MUST be ignored if received"). The current ABNF thus allows listing the same direction twice, but this is explicitly disallowed by text in section 6.2 ("each direction MUST NOT occur more than once on the same line").

> 
> 2) it references rid-identifier from draft-ietf-mmusic-rid-08, but that isn't defined there. I guess it means to reference rid-
> id.
[BoB] Yes, this should be aligned; to be included in -08.

> 
> 3) this syntax defines the syntax of the entire attribute, including "a=" and the separation between attribute name and
> value. We are trying to get away from that as part of the cleanup in rfc4566bis. (Because people keep getting it wrong, so
> that it doesn't match with the generic syntax of an attribute.)
> 
[BoB] OK, that works and is a more clear description of what was already intended. I can make that change in -08. 

>     sc-str-list  = SP sc-alt-list *( ";" sc-alt-list )
[BoB] Is there any specific reason you include SP as first part of sc-str-list? I would think it clearer to have SP as separator in sc-send and sc-recv definitions.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Mar 2017 10:56:18 -0400

Bo,

> [BoB] Is there any specific reason you include SP as first part of sc-str-list? I would think it clearer to have SP as separator in sc-send and sc-recv definitions.

Either way works. This way it is only specified once. Its really a 
matter of taste.

	Thanks,
	Paul