Subject: RE: ABNF syntax query

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 9 Jul 2001 11:57:56 -0400

I must have been asleep

I don't remember a discussion of making SigId a string.
Why?  It's a list.  That should be sufficient.

Brian

> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Monday, July 09, 2001 11:35 AM
> To: Troy Cauble
> Cc: [email-masked]
> Subject: Re: ABNF syntax query
> 
> 
> 
> 
> Troy Cauble wrote:
> 
> > Sarika,
> >
> > This Annex M element is type String, which requires double quotes
> > as of IG 6.80.
> >
> > This is a GOOD THING, since it encapsulates the new syntax
> > at a level that allows stacks that DON'T support the package
> > to parse the message down to the level of that string.
> >
> > (Allowing packages to introduce new syntax that isn't encapsulated
> > like this would be extremely bad, breaking valid parsers.)
> >
> > That said, the use of quotedString within the varvalue syntax
> > will cause a nested double quote issue and needs to be fixed.
> >
> > Terry,
> >
> > I recently brought this concept up with respect to Annex E.1.2
> > SigID, asking that it be clarified to be type String (which
> > requires double quotes via IG 6.80).  I think there was a
> > consensus, but no one spoke up and said it was going in the IG.
> 
> It was on my list to review.  I reread the thread and I believe your
> proposal was that the type of g/sc SigID be "string or list 
> of strings"
> and the syntax be clarified using the following examples.
> 
> 1.Reporting a signal outside of sequential signal list:
> > SigID="pkg1/sig1"
> >
> > 2.Reporting a  signal inside a sequential signal list:
> > SigID="SignalList = 1 {pkg1/sig1}"
> >
> > 3.Reporting a  list of signals outside of sequential signal list:
> > SigID=[ "pkg1/sig1" , "pkg2/sig2" ]
> >
> > 4.Reporting a  list of signals inside a sequential signal list:
> > SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ]
> >
> > 5.Reporting a list of both signals and sequential signal lists:
> > SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}",
> > "SignalList = 2 {pkg4/sig4}" ]
> 
> There were only a couple of responses.  Christian suggested 
> restricting
> the type to be simply string (suggesting cases 3-5 are not 
> really needed)
> and so would include ONLY #1,2 of your examples plus he 
> suggested the case
> of all  signals in a list, presumably:
> 
> Reporting all signals in a sequential signal list:
> SigID="SignalList=1"
> 
> Is this acceptible to all?  Or if we only support a single id 
> should the
> three examples be:
> 
> 1. Reporting a signal outside of sequential signal list:
> SigID="pkg1/sig1"
> 
> 2. Reporting a signal inside a sequential signal list,
> SignalList=1{pkg1/sig1, pkg2/sig2}:
> SigID="pkg1/sig1"
> (i.e., no mention of list name)
> 
> 3. Reporting all signals in a list, SignalList=1{pkg1/sig1, 
> pkg2/sig2}:
> SigID="1"
> 
> with corresponding simplification of text.
> 
> I believe your original proposal of "string or list of 
> strings" is closer
> to the original intent but I also agree with Christian that the
> flexibility may be more than needed.  I'd like to hear opinions about
> three proposals:
> 
> 1. type: string or list of strings, with your 5 examples
> 2. type: string with your examples 1 & 2 plus "SignalList=1"
> 3. type: string with my 3 examples, using a single ID in quotes.
> 
> 
> >
> >
> > -troy
> >
> > Sarika Gupta wrote:
> > >
> > > Hi,
> > > In H248 Annex M draft "Advanced Audio Server Package"
> > > the ABNF syntax has been specified explicitely for the
> > > Announcemnt paramter of Play signal given below
> > >
> > > "announcement = LBRKT segSpec *( COMMA segSpec ) RBRKT
> > >                         ; LBRKT, RBRKT, COMMA are as
> > > defined in H.248 Annex B.
> > >
> > > ; The segSpec identifies the content of an individual
> > > segment
> > > segSpec = (
> > >                           ( sid *( COMMA embed) )
> > >                            ; reference to a
> > > provisioned segment spec followed by zero or more
> > >                            ; embedded variable value
> > > specifications
> > >                          / variable
> > >                   )"
> > >
> > > where as the ABNF for param value defined in H248 is
> > >
> > > "parmValue            = (EQUAL alternativeValue/
> > > INEQUAL VALUE)
> > >  alternativeValue     = ( VALUE
> > >                                 / LSBRKT VALUE *(COMMA 
> VALUE) RSBRKT
> > >                          ; sublist (i.e. A AND B AND
> > > ...)
> > >                                 / LBRKT VALUE *(COMMA VALUE) RBRKT
> > >                                  ; alternatives (i.e. A 
> OR B OR ...)
> > >
> > >                                 /  LSBRKT VALUE COLON 
> VALUE RSBRKT )
> > >                                  ; range"
> > >
> > > So if we send a Play signal for announcement paramter
> > > its value will be filled using standard signal value
> > > format. So how the announcement ABNF format will map
> > > to the param Value
> > > ABNF format.
> > >
> > > Regards
> > > Sarika
> > >
> > > ____________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> > > or your free @yahoo.ie address at http://mail.yahoo.ie
> 
> --
> ------------------------------------------------------------
> Terry L Anderson              mailto:[email-masked]
> Tel:908.582.7013   Fax:908.582.6729
> Lucent Technologies/INS/Voice Over IP Access Networks
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> 
>

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 09 Jul 2001 12:25:02 -0400

Troy originally raised the question Jun 13, pointing out that sec 12.1.2 and
12.2 defining allowable types for Properties and Parameters do not include
list and that the syntax for list conflicts with the description with nested
braces.  I'll include his arguement:

> > > Change the Type of the g/sc SigId parameter in E.1.2
> > > from "list" to "string".
> > >
> > > Argument:
> > >
> > > Sections 12.1.2 and 12.2 define allowable types
> > > for Properties and Parameters, including "String"
> > > and "Sub-list".
> > >
> > > Annex E.1.2 (g/sc) defines parameter SigID as
> > > being a "list" and references a complex syntax for
> > > that "list" which includes nested braces.
> > >
> > > This specific syntax conflicts with the established
> > > syntax for a list.
> > >
> > >    parmValue            = (EQUAL alternativeValue/ INEQUAL VALUE)
> > >                           / LSBRKT VALUE *(COMMA VALUE) RSBRKT
> > >                             ; sublist (i.e. A AND B AND ...)
> > >                             ; alternatives (i.e. A OR B OR ...)
> > >                           / LSBRKT VALUE COLON VALUE RSBRKT )
> > >                             ; range
> > >
> > > If the type is redefined as "String", double quotes
> > > will be required (IG 6.80).  Within that quotedString,
> > > the syntax could stay as defined.
> > >
> > > Besides the fact that this syntax is in direct conflict
> > > of the ABNF specification,  I think it is unreasonable
> > > to allow a package to define a complex syntax to be
> > > embedded directly in a VALUE without quoting.  Parsers
> > > should be able to parse the message down to the VALUE
> > > level without package knowledge.
> > >

---

From: Troy Cauble <[email-masked]>
Date: Mon, 09 Jul 2001 13:26:25 -0400

> Why?  It's a list.  That should be sufficient.

List of what?  "List" doesn't really convey any type information.

Don't say "signal", "signal" is not a type either.

-troy