Subject: Re: ABNF semantics

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jan 2001 15:48:34 -0500

> 1. Do these two types of ABNF expressions always have the
> same semantics in
> RFC3015? If so, can someone provide a rationale for the two
> different yet
> equivalent expressions, e.g., are the LBRKTs sometimes needed to
> disambiguate the grammar?
>         LBRKT [ x ] LBRKT
>         [ LBRKT x LBRKT ]
We tried to be consistent about when you needed the null brackets, using
them
only when we thought we needed to.

>
> 2. Are these two modem-descriptor examples equivalent? If so,
> why the two
> syntaxes?
>         md=v90
>         md[v90]
I think you slipped a couple tokens.
The productions are:
 modemDescriptor      = ModemToken (( EQUAL modemType) /
                          (LSBRKT modemType *(COMMA modemType) RSBRKT))
                          [ LBRKT NAME parmValue
                         *(COMMA NAME parmValue) RBRKT ]
Notice that there are two parens after ModemToken and RSBRKT.
There are two parts to the descriptor.  One, or a list of modemTypes,
and a set of parmValues.
So, you don't use md[v90].
You can use md=v90, md=v90[9600], md{v90,v32}, or md{v90,v32}[9600]

>
> 3. I assume that the following alternativeValue expressions are all
> equivalent to each other, correct?
>         5
>         [5]
>         {5}
>         [5:5]
Yes

>
> 4. The ABNF for secondEventParameter refers to "EmbedSig",
> which is not
> defined. Therefore I assume it should be "embedSig", which is
> defined. A
> simple typo.
ABNF definitions are not case sensitive per RFC2234
But we should fix this.

Brian

---

From: Paul Long <[email-masked]>
Date: Fri, 12 Jan 2001 15:25:51 -0600

Brian,

Thanks for the response!

1. Okay, so there is no semantic difference between "{ }" (nothing in
between brackets) and "" (no brackets at all).
2. Sorry, I confused LSBRKT and LBKRT. I should've asked whether these are
equivalent:
        md=v90
        md{v90}
3. nc
4. Oh, so ABNF is case insensitive with regard to both the character set
that is parses and the character set that expresses the syntax. Gotcha. I'm
used to ASN.1.

Paul

-----Original Message-----
From: Media Gateway Control (megaco)
[mailto:[email-masked]]On Behalf Of Rosen, Brian
Sent: Friday, January 12, 2001 2:49 PM
To: [email-masked]
Subject: Re: ABNF semantics

Yes

Brian

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jan 2001 16:52:59 +1100

G'Day Brian and Paul,

This doesn't seem to be an emotive issue so I don't think there's much
need to make all the updates in the implementors' guide. So i'll just
add a comment (see below) to capture the intention that the ABNF should
be equivalent to RFC2234.

1.7 ABNF Case Sensitivity

Description:     The current ABNF is not case sensistive as per RFC2234.
The ABNF should be.
Reference:      Subject: Re: ABNF semantics
Date: Fri, 12 Jan 2001 15:48:34 -0500
From: "Rosen, Brian" <[email-masked]>
To: [email-masked]
 [Begin Correction]
This will be fixed in H.248v2.
[End Correction]

Cheers, Christian

---

From: Paul Long <[email-masked]>
Date: Mon, 15 Jan 2001 11:28:11 -0600

Christian,

The normative text clearly indicates that the current ABNF is correct
(despite my inability to see this initially :-) .

        B.2/RFC3015: "The protocol syntax is presented in ABNF according to
RFC2234."
        2.1/RFC2234: "NOTE: Rule names are case-insensitive ... The names
<rulename>, <Rulename>, <RULENAME> and <rUlENamE> all refer to the same
rule."

Therefore, we probably don't need to explain this issue. However, if for no
other reason than consistency in style, the syntax should probably be fixed.
How about this alternative to what you proposed?

1.7 embedSig/EmbedSig

Description:     Although correct, "EmbedSig" should be replaced with
"embedSig" in order to be stylistically consistent and therefore avoid
confusion.
Reference:      Subject:      ABNF semantics
Date:         Sun, 31 Dec 2000 12:05:20 -0600
Reply-To: [email-masked]
From: Paul Long <[email-masked]>
Organization: ipDIalog, Inc.
To: [email-masked]
[Begin Correction]
   secondEventParameter = ( embedSig / KeepActiveToken / eventDM /
                            eventStream / eventOther )
[End Correction]

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Media Gateway Control (megaco)
[mailto:[email-masked]]On Behalf Of Christian
Groves
Sent: Sunday, January 14, 2001 11:53 PM
To: [email-masked]
Subject: Re: ABNF semantics

G'Day Brian and Paul,

Cheers, Christian

---

From: Michael Brown <[email-masked]>
Date: Mon, 15 Jan 2001 15:09:46 -0500

While I agree with the description of the intended use of the productions in
item #2 to express a single modem type or a list of modem types, the syntax
suggested by Paul is actually allowed by the ABNF. That is, the production of:

does allow for specifying md[v90] since the production allows for 0 repetitions
of the construct, (COMMA modemType), between the LSBRKT and RSBRKT .

Also, there is a slight problem with the example where the use of Left and
Right SBRKT are reversed with Left and Right BRKT . The example given reads:

"You can use md=v90, md=v90[9600], md{v90,v32}, or md{v90,v32}[9600]"

I believe it should be:

You can use md=v90, md=v90{9600}, md[v90,v32], or md[v90,v32]{9600}

Michael

---

From: Christian Groves <[email-masked]>
Date: Tue, 16 Jan 2001 11:54:21 +1100

G'Day Paul,

Again i'll add your suggestion. I hope EmbedSig is the only example of
this as my first suggestion was a way of minimising documentation.

Cheers, Christian