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

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 23 Aug 2001 09:54:38 -0400

It's really late for me to get in on this discussion, but I agree with Troy:
we should really require packages to define the type as "list of type x",
where x is one of our permitted primitives.

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Monday, August 13, 2001 4:03 PM
To: Terry L Anderson
Cc: Megaco Mailing List
Subject: Re: [Megaco] Re: g/sc SigID list

Terry L Anderson wrote:
> 
> Troy Cauble wrote:
> 
> >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 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

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

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

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

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.

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

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" :)

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

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?

> --
> Waiting for the other shoe to drop but hoping its a one legged man.

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

-troy

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

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 23 Aug 2001 11:18:42 -0400

Ok. Let's put the issue of g/sc on hold and settle first the general
rule of what is allowed in the specification of package property type,
ie, what should appear after
'Type:' in the package definition.

I think we all agree that it must be unambiguously defined including how
it is encoded in both binary and text.  I think there are differences
both in what it can be and in what language to use to describe it.  Let
me try to catalog the positions.

1) it must be one of the "primitives" (e.g., String, Integer, Double,
Character, Enumeration, or Boolean), or a list of one of these.

2) it must be one of the "primitives" or a list of "elements" where
elements can be anything allowed by OCTET STRING (binary) or VALUE
(text).

3) it must be one of the "primitives" or anything allowed by OCTET
STRING (binary) or VALUE (text) (even if not a list).

4) it must be one of the "primitives" or a list of "elements" where
elements can be anything allowed by OCTET STRING (binary) or VALUE
(text) but SHOULD be a construct already defined in the syntax
specification (e.g., ServiceChangeAddress)

5)it must be one of the "primitives" or a list of "elements" where
elements can be anything allowed by OCTET STRING (binary) or VALUE
(text) but SHOULD be defined using ABNF for text and ASN.1 for binary.

Whatever we decide about these, I believe we all agree that the package
allowing lists must specify exactly what the elements are (and how they
are encoded) for the given package.

I believe that #1 is the most restrictive, #3 the least (everything
allowed by the protocol syntax rules) and #2, #4 and #5 are
intermediate.  The language of 12.1.2 and 12.2 offer little guidance and
certainly could be interpretted to allow #2, but probably not #3.  A
comment was added to ABNF by Implementors Guide item 6.80 that seems to
allow #3.

; Future types:  It is expected that packages will define types
; beyond these initial types.  Any defined types MUST fit within
; the ANBF specification of VALUE.  Specifically, 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.

A number of comments to this list seem to have assumed something like
one of the intermediate positions (or even #1).  I believe that Troy's
early suggestion was that  #1 could offer nearly all the flexibility of
#3 by simply using the type String and then defining what is in it.  One
does not even need "list of something" since that can be placed in a
single String.

I personally favor something more like #5.  I dislike putting complex
structures in a string because the format of the string needs to be
formally defined (ABNF or equivalent) and that requires a
binary-encoding stack to have a text syntax parser.

Current or draft packages most often use primitives or list of
enumeration but some require more than #1 (unless modified to use Troy's
finese), e.g,
g/sc: list of signals... (ambiguous which choice)
nasroot/naspat and nasroot/ctlnam (drafts): "ASN.1 type
TerminationIDList or ABNF type terminationIDList, depending on the
encoding in use." (essentially #5, although as defined it is not a "list
of something" using the list syntax, but structures that are themselves
lists so really a case of #3)

Some already use Troy's finese:
ind/indlist (Annex G)
Annex M.1(draft) in several

Could others indicate which of the 5 positions (or another) they favor?
I believe that we should clarify this in 12.1.2, 12.2 and the added ABNF
comments to clearly indicate which position adopt.  We can then return
to the specific case of g/sc and apply our decision.

Tom-PT Taylor wrote:

>
>
> It's really late for me to get in on this discussion, but I agree with
> Troy: we should really require packages to define the type as "list of
> type x", where x is one of our permitted primitives.
>
> > >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.
> > >
> > >2) Also, I don't see the point about specifiying that lists of one
> must be
> > >use quotedString" rule'.  But that's about the contents of the
> strings, not

--
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: Thu, 23 Aug 2001 16:07:21 -0400

> STRING (binary) or VALUE (text) (even if not a list).

Does this imply that either the "primitives" or the "non-primitives"
can be in lists?  If so, I like this one.  I think that the use of
lists should be orthogonal to whether something is "primitive" or not.

It should probably have the SHOULD qualification from #4 below.  I
would explain further with something like:

	Note that the use of the type String can encapsulate relatively 
	complex contents.  For cases where the text parsing is simple,
	it is suggested that the package reference String and not provide
	an ASN.1 encoding.  For packages requiring more complex text parsing, 
	such as those referencing ABNF from Annex B, it is suggested that 
	they not reference String and instead define an ASN.1 specific encoding.

> (text) but SHOULD be defined using ABNF for text and ASN.1 for binary.

< snip >

> binary-encoding stack to have a text syntax parser.

Even though you call this use of String "Troy's finese", I agree
that *complex* things shouldn't be done this it.

But I don't want to suggest that everything more complex than a
primitive is complex enough that an ASN.1 encoding helps.

For example, consider a package element whose contents consist of 
an integer and a keyword.  I contend that for both ASN.1 specification
and ASN.1 implementation, it's more straight forward to have trivial
String parsing equivalent to "%d %s" than to go to the bother of
defining and implementing:

Foo ::= SEQUENCE
{
	INTEGER(0..99),
	IA5String
}

-troy