Subject: ABNF syntax query

From: Sarika Gupta <[email-masked]>
Date: Mon, 9 Jul 2001 11:26:28 +0100 (BST)

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

---

From: Troy Cauble <[email-masked]>
Date: Mon, 09 Jul 2001 09:37:38 -0400

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.

-troy

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 09 Jul 2001 11:35:27 -0400

> 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.

--
------------------------------------------------------------
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: Troy Cauble <[email-masked]>
Date: Mon, 09 Jul 2001 13:36:10 -0400

> 3. type: string with my 3 examples, using a single ID in quotes.

Any of these is acceptable to me, since they all use type String
and solve the parsing issue.

I have no insight into whether or not a list capability is 
needed.

-troy

---

From: Sarika Gupta <[email-masked]>
Date: Fri, 13 Jul 2001 07:18:31 +0100 (BST)

Hi,
Then how do we fix the "nested double quote issue".
Can we introduce some type of escape character for
this  or if we can change the format for the varvalue
, I mean instead of taking quotes as the delimiters
can we have some other delimiters as <>. But
introducing a escape character would be a better idea
since that will fix the issue for future also.
Please suggest what to do asap.

Thanks&Regards
Sarika

--- Troy Cauble <[email-masked]> wrote: > 
> >                            ; embedded variable
> value