Subject: Re: [MMUSIC] ABNF in draft-ietf-mmusic-image-attributes-04

From: Tom Taylor <[email-masked]>
Date: Mon, 10 May 2010 11:21:14 -0400

The ABNF in this draft is neither verifiable nor extensible in its current form, 
but is well explained. I think it would be desirable to have consolidated ABNF 
in proper form somewhere in the document, perhaps in an appendix. Section 3.2.1 
could call itself an informal description of the syntax, with a forward 
reference to the consolidated ABNF.

Last time I made suggestions on ABNF, someone found an error :(, so I hope this 
gets checked. Here is my suggestion for the consolidated ABNF. Note that as I 
have defined it the ordering of the optional parameters is unspecified. Also, 
every number has up to four decimal places and a leading zero is required for a 
value less than 1.0000.

        image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" )
                                          1*WSP attr-list )

        ; At most one instance each of "send" and "recv" with their accompanying
        ; attribute lists.

        PT = 1*DIGIT / "*"                           ; Payload type

        attr-list = ( set *(1*WSP set) ) / "*"

        set= "[" "x=" range "," "y=" range *( "," key-value ) "]"

        key-value = ( "sar=" range ) / ; Sample aspect ratio
                    ( "par=" range ) / ; Picture aspect ratio
                    ( "q=" posreal )
                         ; Set preference value. MUST be greater than 0
                         ; and less than or equal to 1.0.

        ; Key-value may be extended with other keyword parameters.
        ; At most one instance each of sar, par, or q in a set.

        range = posreal /      ; specific value

                "[" prval1 ":" [ prstep ":" ] prval2 "]" /
                ; Set of values equal to or greater than rval1 and less than
                ; or equal to rval2, beginning with rval1 and calculating
                ; succeeding values by adding rstep. If rstep is absent its
                ; value defaults to 1.0000.

                "[" posreal 1*( "," posreal ) "]" /
                ; Set of values specified explicitly.

                "[" prval1 "-" prval2 "]"
                ; Any real value (as defined below) in the range from rval1 to
                ; rval2, where rval1 is less than rval2.

        prval1 = posreal
        prval2 = posreal
        prstep = posreal
        posreal = ["-"] 1*DIGIT ["." 1*4DIGIT]
               ; Up to four decimal places, where DIGIT is defined in [RFC5234].

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Mon, 10 May 2010 12:05:36 -0400

I see I left traces of decisions made and retracted. At first I thought I should 
allow for negative reals for future extensions, but then I thought better of it 
and renamed the various productions to emphasize that they were positive. I 
failed to add the "p" in the comments and left the minus sign in the definition 
of posreal. That has to be fixed once we've decided if this is the way we want 
the ABNF to be.

Tom Taylor wrote:
> The ABNF in this draft is neither verifiable nor extensible in its 
> current form, but is well explained. I think it would be desirable to 
> have consolidated ABNF in proper form somewhere in the document, perhaps 
> in an appendix. Section 3.2.1 could call itself an informal description 
> of the syntax, with a forward reference to the consolidated ABNF.
> 
> Last time I made suggestions on ABNF, someone found an error :(, so I 
> hope this gets checked. Here is my suggestion for the consolidated ABNF. 
> Note that as I have defined it the ordering of the optional parameters 
> is unspecified. Also, every number has up to four decimal places and a 
> leading zero is required for a value less than 1.0000.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 11 May 2010 13:03:15 +0200

Hi

So, if I understand this right, you recommend some kind of "more human readable version" of the syntax in section 3.2.1 and a separate section with the ABNF. 
I see that RFC2326bis has a separate section that deals with the ABNF, however the SDPCapNeg drafts mixes ABNF and "simple" grammar.

Is there any best practice here?. RFC2326bis is big so a separate ABNF section is probably good, imageattr is only 22 pages. 
Personally I would like to keep things as is but please try to convince me :-)

/Ingemar

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]] 
> Sent: den 10 maj 2010 18:06
> To: mmusic
> Cc: Ingemar Johansson S; Jean-Francois Mule
> Subject: Re: [MMUSIC] ABNF in draft-ietf-mmusic-image-attributes-04
> 
> I see I left traces of decisions made and retracted. At first 
> I thought I should allow for negative reals for future 
> extensions, but then I thought better of it and renamed the 
> various productions to emphasize that they were positive. I 
> failed to add the "p" in the comments and left the minus sign 
> in the definition of posreal. That has to be fixed once we've 
> decided if this is the way we want the ABNF to be.
> 
> Tom Taylor wrote:
> > have consolidated ABNF in proper form somewhere in the document, 
> > perhaps in an appendix. Section 3.2.1 could call itself an informal 
> > description of the syntax, with a forward reference to the 
> consolidated ABNF.
> > 
> >               ; Up to four decimal places, where DIGIT is 
> defined in 
> > [RFC5234].
> > 
> > Tom Taylor
> > 
> > 
> > 
> > 
> >

---

From: Tom Taylor <[email-masked]>
Date: Tue, 11 May 2010 15:59:02 -0400

My proposal actually addresses several issues. First regardless of which way we 
go, I think the ABNF should be rearranged for easier extension. What you have 
currently is this:

set= "[" "x=" range "," "y=" range [ ",sar=" range ]
              [ ",par=" range ] [ ",q=" value ] "]"

To extend that you have to rewrite it with the new parameter term(s).

On the other hand, my proposal breaks out the parameters like so:

ABNF provides a simple way to extend key-value:

key-value =/ "newparm=" range

The second issue is that your ABNF does not define the the productions value, 
value1, or value2. Thus it is incomplete. I put together one proposal, which 
allows both integers and reals with up to four decimal places. You can tinker 
with that if you wish.

Finally, your expansion of range is missing the slashes between the 
alternatives. Thus the ABNF is unparsable in its present form.

So you can fix these in place and keep your present format, if you want, but 
they really should be fixed.