Subject: [Megaco] Re: g/sc SigID list

From: Terry L Anderson <[email-masked]>
Date: Mon, 06 Aug 2001 17:21:09 -0400

This thread also terminated without a clear conclusion.  Let me try to summarize and suggest a
solution.  The issue is how to encode the value of the parameter SigID in g/sc.  The current
package reads that the type is "list", but "list" is not one of the allowed types specified in
12.1.2.  Perhaps we should correct it to read "sub-list" which is one of the allowed types, but
the question becomes "sub-list of what?" Section 12.1.2 is not very clear about the "values from
a list" (I will also suggest we address this).  The g/sc specification under possible values
would suggest that the value can be one of three types of items
1. a simple signal in pkgdName form
2. a sequential signal list
3. a single signal from a sequential signal list
or can be
4. a "list" of the above.

If we take "list" to read "sub-list" then one might interpret this to allow the following
examples in text-encoding:
SigID=[pkg1/sig1]
SigID=[SignalList=2]
SigID=[SignalList=3{pkg2/sig2}]
SigID=[pkg1/sig1,SignalList=2,SignalList=3{pkg2/sig2}]

Note the first 3 cases are sub-lists with only a single element.  But this violates the ABNF
rules since value is defined as alternativeValue which is either a VALUE or a sublist of VALUE
and VALUE is either a quotedString or 1*(SafeChar).  SafeChar does not allow  '=', '{' or '}'.

One solution suggested by Troy was to ALWAYS use quotedStrings and this seems consistent with the
comment that was added (IG 6.80) to the beginning of the ABNF

; The ABNF specification for VALUE allows a quotedString form or a
; collection of SafeChars.  The encoding of package element values into
; ABNF VALUES is specified below.  If a type's encoding allows characters
; other than SafeChars, the quotedString form MUST be used for all values
; of that type, even for specific values that consist only of SafeChars.

Since some of the values above clearly have non-SafeChars this suggests that each instance of
"VALUE" should use the quoteString form, thus our examples become:

SigID=["pkg1/sig1"]
SigID=["SignalList=2"]
SigID=["SignalList=3{pkg2/sig2}"]
SigID=["pkg1/sig1","SignalList=2","SignalList=3{pkg2/sig2}"]

So I do not believe that we need to say that the type is "String" but should change it to
"sub-list".  But since this is a bit confusing, I think it would help to point out explicitly
the fact that quotedStrings are required for text-encoding and to give examples like above.

Note that this is NOT a problem for binary encoding as sub-lists there are SEQUENCE of OCTET
STRING.  But we still need to be explicit about what goes into each OCTET STRING.  A quoted or
unquoted string or something else.  I want to argue that "using pkgdName syntax" in
binary-encoding means using the ASN.1 for pkgdName (which is an OCTET STRING) rather than using
the ABNF string definition for pkgdName. "sequential signal list syntax with correct signal list
identifier, enclosing ..." means using the ASN.1 for SeqSigList and omitting all OPTIONAL
elements for Signal (so it is just the SignalName which is pkgdName).  But since the language
used has a more obvious interpretation for text-encoding, I think it would be better to spell out
the binary-encoding case.  The easier way to express it is that it is a SignalRequest with all
OPTIONAL elements in Signal omitted, ASN.1 encoded and placed into the OCTET STRING the sequence
in PropertyParm.

I would also suggest making it explicit that even a single signal must be a one-element
sub-list rather than allowing a choice of  a single signal or a sub-list (easier to state and
parse and does not introduce confusion about the "ALL entries use quotedString" rule).

Further more, to avoid this ambiguity in future packages, I suggest that we tighten up the
language in 12.1.2 defining sub-list to explicitly say that it is a list of items of the other
listed types or of a designated element in the syntax rules.  In the binary-encoding case the
element is ASN.1 encoded and the binary result placed in the OCTET STRING.

(I am arguing for discouraging the use of ABNF defined strings as the contents of "value" in
binary encoding and rather using ASN.1 objects.)

Here is what I would put into the IG (--xxx-- means removed ++xxx++ means added):

Type: --list-- ++sub-list++

Possible values: a list of signals and/or sequential signal lists which have terminated ++(a
single signal must be indicated using a one-element sub-list)++. A signal outside of a
sequential signal list shall be identified using the pkgdName syntax without wildcarding.  An
individual signal inside of a sequential signal list shall be identified using the sequential
signal list syntax with the correct signal list identifier, enclosing the name of the specific
signal which terminated in pkgdName syntax. ++The termination of an entire
sequential signal list shall be identified by using the sequential signal list syntax with
the correct signal list identifier but omitting the bracketted signal list.  The following are
examples of SigIDs in text-encoding:

SigID=["pkg1/sig1"]
SigID=["SignalList=2"]
SigID=["SignalList=3{pkg2/sig2}"]
SigID=["pkg1/sig1","SignalList=2","SignalList=3{pkg2/sig2}"]

Note that since elements of the sub-list may contain non-SafeChar characters ALL entries in
text-encoding shall be quotedStrings.

In binary-encoding, the each element of the list shall be a SignalRequest with all OPTIONAL
elements of the enclosed Signal(s) omitted.  To indicate the termination of an entire
SignalsList, the SeqSigList shall include a zero-length SEQUENCE OF Signal. The SignalRequest
shall be ASN.1 encoded and the resulting binary placed in the OCTET STRING of value element.++

[Note that the text case could also be simplified to simply say "each element of the list is a
signalParm with all optional enclosed sigParameter lists omitted".  But the ABNF rules do not
permit the case of a signalList with bracketted list of signals (signalListParm) omitted to
indicate an entire sequential list has terminated-- in ABNF it must contain at least one.  If we
do not really need the case of the completion of an entire sequential signal list - and I am not
sure how that happens anyway, it was just allowed by the original package language) then we use
this simpler language, remove the second sentence from the binary-encoding case and the example
for this case.]

In 12.1.2 Sub-list would be changed:

Sub-list: a list of several values from a list++, where each element is either one of the other
listed types or a designated element of the syntax rules for the encoding used.  In the
binary-encoding case, the element shall be ASN.1 encoded and the resulting binary placed in the
OCTET STRING of the value element.++

> > > Troy Cauble wrote:
> > >
> > > > On the contrary, a major point of my proposal was that
> > > > calling it a "String" tells us how to encode both
> > > > text and binary.
> > > >
> > > > Several basic types (Integer, String, etc.) and their encodings
> > > > are defined and clarfified in 12.1.2, 12.2, IG 6.80 and IG 6.46.
> > > >
> > > > As long as we stick to these types, both the text and binary
> > > > encodings are defined.
> > > >
> > > > List's are handled at a higher level (alternateValue in ABNF,
> > > > PropertyParm/value "SEQENCE OF" in ASN.1).
> > > >
> > > > Hence, "List" is not a type.
> > > >
> > > > -troy
> > > >
> > > > Christian Groves wrote:
> > > > >
> > > > > I do think the encoding needs clarification, I think troys response
> > > > > below really only covers the text encoding. How would the binary
> > > > > encoding be covered? I'm all for simplicity on this one and given that
> > > > > there's been no responses I don't know if anyone has implemented this in
> > > > > a compatible way.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Terry L Anderson wrote:
> > > > > >
> > > > > > I was waiting for Troy & Brian to reach concensus or another voice joins in.  I
> > > > > > thought Troy's response about a week ago implied he would reopen the debate but
> > > > > > he hasn't.
> > > > > >
> > > > > > Troy are you giving up or do you want to try again?
> > > > > >
> > > > > > Christian Groves wrote:
> > > > > >
> > > > > > > G'Day Terry,
> > > > > > >
> > > > > > > Have you made any updates to the IG concerning this? Do we still need to
> > > > > > > thrash it out on the list?
> > > > > > >
> > > > > > > Cheers, Christian
> > > > > > >
> > > > > > > Troy Cauble wrote:
> > > > > > > >
> > > > > > > > Christian,
> > > > > > > >
> > > > > > > > Changing it to a single string sounds reasonable
> > > > > > > > but is more of a change.  I'd be happy with it,
> > > > > > > > but will others?
> > > > > > > >
> > > > > > > > My proposal is just a clarification:  "List of what?"
> > > > > > > >
> > > > > > > > -troy
> > > > > > > >
> > > > > > > > Christian Groves wrote:
> > > > > > > > >
> > > > > > > > > G'Day Troy,
> > > > > > > > >
> > > > > > > > > I guess the question I have is who would encode multiple signalIDs in
> > > > > > > > > one signal completion response? I can see the following cases are
> > > > > > > > > realistic:
> > > > > > > > > (a) Individual Signal outside of a list
> > > > > > > > > (b) Individual Signal in list
> > > > > > > > > (c) Whole list
> > > > > > > > > The whole list case is handled by the SignalListID parameter. I'm
> > > > > > > > > inclined to have g/sc(SigID) only have the signalID. This is a string.
> > > > > > > > > If you need multiple indication of signal completion you'd have multiple
> > > > > > > > > notifications.
> > > > > > > > >
> > > > > > > > > Christian
> > > > > > > > >
> > > > > > > > > Troy Cauble wrote:
> > > > > > > > > >
> > > > > > > > > > New proposal:
> > > > > > > > > >
> > > > > > > > > > Change the Type of the g/sc SigId parameter in E.1.2
> > > > > > > > > > from "list" to "string or list of strings".
> > > > > > > > > > Clarify syntax with examples below.
> > > > > > > > > >
> > > > > > > > > > Objections?
> > > > > > > > > >
> > > > > > > > > > -troy
> > > > > > > > > >
> > > > > > > > > > Troy Cauble wrote:
> > > > > > > > > > >
> > > > > > > > > > > BTW, here are some uses that I think are consistent with
> > > > > > > > > > > the syntax description in E.1.2.  Anyone care to comment?
> > > > > > > > > > > This is vague enough in E.1.2 that it should be clarified
> > > > > > > > > > > with some examples.
> > > > > > > > > > >
> > > > > > > > > > > Note that a sublist uses [] not {} according to the ABNF
> > > > > > > > > > > for alternativeValue.
> > > > > > > > > > >
> > > > > > > > > > > 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}" ]
> > > > > > > > > > >
> > > > > > > > > > > -troy
> > > > > > > > > > >
> > > > > > > > > > > Troy Cauble wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Proposal:
> > > > > > > > > > > >
> > > > > > > > > > > > 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)
> > > > > > > > > > > >    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
> > > > > > > > > > > >
> > > > > > > > > > > > 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.
> > > > > > > > > > > >
> > > > > > > > > > > > Comments?
> > > > > > > > > > > >
> > > > > > > > > > > > -troy
>
> --
> Waiting for the other shoe to drop but hoping its a one legged man.
> ------------------------------------------------------------
> 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

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
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, 13 Aug 2001 11:02:32 -0400

Terry,

I agree with the majority of your suggestion.  Two exceptions though:

1) Calling "sub-list" a "type".  A list (or array, set, queue, fifo, etc.)
is fundamentally not a type.  It's a grouping.  The elements inside have types.

I'm not objecting to using lists, or defining the type in the package (which
is what you are doing).  It's just the wording.  I want to call what you are 
defining "the type".  Specifically, in the package:
	"Type: defined below"
or
	"Type: list of elements as defined below".

(Ideally, I'd want the first form, with an additional, boolean field "List:"
in each package element definition.  But to minimize change, I'd live with
the second form.)

And in 12.1.2 and 12.2 change the notes about the "Type: sub-list" to notes
about the fact that lists can be used.  And maybe add general notes about
the possibility (& pain) of packge-defined-types.

Also, the current structure may give the impression that package-defined-types
are for use in the list form only.

2) Also, I don't see the point about specifiying that lists of one must be
encoded in list form [].  You mention 'confusion about the "ALL entries 
use quotedString" rule'.  But that's about the contents of the strings, not
lists.  I'd prefer to allow lists of one to be encoded without the [].

-troy

> > > > > > > > > > > > > level without package knowledge.

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 13 Aug 2001 12:25:56 -0400

>is fundamentally not a type.  It's a grouping.  The elements inside have types.
I am sorry Troy, but I am not sure where you are getting your definition 
of "type" to know that this is fundamentally not one.  I believe that 
the notion of "type" for package properties is defined by 12.1.2 where 
"Sub-list" is included as one of the "Type"s.  "Grouping" is not an 
H.248 defined concept.  I guess you are suggesting that "type" has a 
universal, unique definition in programming that should apply to H.248 
but I guess I am not convinced that this is true.  I believe that "type" 
for package properties is up to us to define and 12.1.2 has done this 
and includes "Sub-list".  Perhaps this  related to your desire to 
restrict these to data types in the "C" language.  But even there 
Kernighan and Richie has both "basic types" and "derived types" 
(specifically meantioning "arrays" anong the later), so I don't 
understand the difficulty of calling this a "type".

You believe that using "the type" rather than "type" helps????

>the possibility (& pain) of packge-defined-types.
I am not clear how a "note" helps rather that defining what is allowed 
in the "Type:" field in the package definition, but perhaps you can 
suggest a specific wording and the maillist can react.

>lists.  I'd prefer to allow lists of one to be encoded without the [].
I AM suggesting that "package-defined-types" (if by this you mean a 
specification of what is allowed as list elements) can be used in the 
Sub-list only.  That is all that is allowed by 12.1.2 (which I am trying 
not to change) although this restriction is not enforced in the ASN.1 or 
ABNF syntax rules.  If fact the comment added to the ABNF syntax by IG 
6.80 does refer to "future types" in a way that sounds less restrictive 
and so if we wish so generalize this and change the wording in 12.1.2 I 
have no objections, but I believe that the current text has this 
restriction.

That is why I want to make it clear that if the package defines the Type 
to be a sub-list then the value must be encoded as a list even if the 
list has length of one.  I am arguing this so because of the above 
restriction (the elements may only be permitted in a sub-list) as well 
as to make the implementation not have to parse for both forms (VALUE vs 
LSBRKT VALUE *(COMMA VALUE) RSBRKT in ABNF).  The two forms are both 
SEQUENCE in ASN.1 and so this is not so much an issue there.  A 
parameter should have one type (either simple or a sub-list, "basic" or 
"derived" in C-type language) and not allow a choice.

The additional point I made about quotedString is probably not relevant. 
It DOES apply to lists as well as strings (in the comment added by 
IG6.80)  since both use VALUE but would apply whether or not property is 
a list since it allows a list.

---

From: Troy Cauble <[email-masked]>
Date: Mon, 13 Aug 2001 16:03:28 -0400

> universal, unique definition in programming that should apply to H.248

Yes I am.  But I'm too lazy to look up a definition.  Trust me:)

> and includes "Sub-list".  

Since we get to define the meaning of words, why not use "sky" or "automobile" 
instead of the word "type"?  Because it wouldn't match the usual usage of 
those words.  Similarly, I do contend that "type" has a usual usage in
programming languages AND protocol specifications.

> Perhaps this  related to your desire to

Actually no.  K&R says

	...derived types constructed from the fundamental types in the
	following ways:
		arrays of objects of a given type,
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
		...

It does not that the word "array" by itself is a derived type.
You can't declare an array in 'C' without answering "of what?".

I'm sure that a Knuth or Aho book (neither of which are handy)
would explain that an array is a contiguous sequence of elements.
It might even say "elements of the same *type*"!

But this is going nowhere.  This is my last plea.  If no one suddenly
agrees, I am giving up the "list is not a type" fight.  I'll just 
consider it another peculiarity of H.248/Megaco.  I apologize for 
obsessing over wording.

> have no objections, but I believe that the current text has this

There is absolutely no mention of "package-defined-types" (or "future types"
or "what is allowed as list elements") in 12.1.2 !!  I can only assume you 
say that 12.1.2 currently allows them only in Sub-list because Sub-list is 
the most vague.  (That is, because the TYPE Sub-list is incomplete!)
Is this absence of specification what you're trying not to change?

I suppose that if my package only wants one element, it can specify that
the list can only be a list of one.

So below "Type: list", I'll specify what's allowed (the real type info)
*AND* that it's a list of one (not really a list)!!  

"Type: list" is getting funnier all the time.

I guess it's all in how we define the word "list" :)

> "derived" in C-type language) and not allow a choice.

I can easily give up on the encoding issue (lists always have []).
But your argument that derived types/whatever can only be in lists because
12.1.2 DOESN'T specify "what is allowed as list elements" confuses me.

There is no relationship between the CONCEPT of a list of elements and the 
CONCEPT of letting package writers define element content and format.  
Why are we linking the two here?

At least I have these email exchanges to make me smile :)

-troy