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

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 23 Aug 2001 14:15:41 -0400

Thanks for creating this summary.  My interpretation of the requirements up
to now has corresponded most closely to your alternative #1, but on
re-reading section 12 I see that we have defined list and sub-list fairly
precisely (see section 12.3).  BTW we do not allow a property to be of type
"list": it is either a sub-list or a single value drawn from a given list
(an enumeration).  In any event, the list concerned is a set of identifiers
each conforming to the syntax of section 12.4.

As you point out, my NAS properties may break the rules, and I should fix
that depending on the outcome of this discussion.

In my current pass at M.1 I have been trying to be a nice guy by defining
true ASN.1 binary structures where it made sense within the announcement
specification syntax.  In the past, where I simply specified a structure for
a string, I believe I was squarely conformant to section 12, but the new
binary structures break that.  I'll have to take them out.

The structured string approach to specification of complex parameter types
works, but as you point out it is painful for an ASN.1-based implementor.
In my current reading of section 12 I don't think we have an alternative.
(I thought of structured integers for the binary side, but the limitation to
4 or 8 octets is a bit difficult.)

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 11:19 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: 'Troy Cauble'; Megaco Mailing List
Subject: Re: [Megaco] Re: g/sc SigID list

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

--
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 15:12:56 -0400

> works, but as you point out it is painful for an ASN.1-based implementor.  

As someone who's implemented text and binary parsing,
I think there will be many cases where adding some text parsing 
for a package element is as easy as or easier than adding new 
ASN.1 parsing (in an ASN.1 implementation).

The argument for ASN.1 specific package element encodings is stronger
when you can map them into ASN.1 structures that already exist
in Annex A.  Probably more to the point, referencing *existing* 
ABNF would be painful to an ASN.1 developer because of aspects
of H.248's overall approach like the flexibility of whitespace 
(including CR, LF, comments) and case insensitivity.

IIRC your package does not involve anything resembling existing
ASN.1 or ABNF structures, so I'd suggest/prefer a text based
specification encoded as a String for ASN.1.

As another example, g/sc SigID references existing ASN.1 and
ABNF structures, so a case can be made that an ASN.1 specific
implementation is efficient.  (Although there are enough 
qualifications to the references that you could argue that they
should not be considered references.)

> In
> my current reading of section 12 I don't think we have an alternative.  (I
> thought of structured integers for the binary side, but the limitation to 4
> or 8 octets is a bit difficult.)

If you're talking about ASN.1 "INTEGER", note that that
has no implications about the number of bytes.

But maybe your talking about "Integer" and "Double" in 12.1.2 ??

-troy

---

From: Christian Groves <[email-masked]>
Date: Fri, 24 Aug 2001 14:33:43 +1000

G'Day Tom and Terry,  (sorry I got a picture of a cat and mouse)

My vote is for 1) but add "Octet String" to the types.

Change Type: for sc to read "sub-list: octet string" instead of list.

"List" is not a type it is a mechanism for registering that several
enumerations belong to the same set. To my knowledge nothing has been
registered with IANA on this and I don't know that it adds any value as
we can always define enumerations in a package. My recommendation would
be to delte 12.3 to stop confusion with sub-list.

I don't think we should be too concerned with saving ASN.1 syntax
structures in all cases, H.248 Annex M.1 is a good example.

For the value of SC is would propose a sub-list:octet string solely with
the packageIds/signalIDs, the list ID we get with the SignalList ID
Parameter. This is consistent way to decode the information regardless
of text/binary.

Regards, Christian

Tom-PT Taylor wrote:
> 
> Thanks for creating this summary.  My interpretation of the
> requirements up to now has corresponded most closely to your
> alternative #1, but on re-reading section 12 I see that we have
> defined list and sub-list fairly precisely (see section 12.3).  BTW we
> do not allow a property to be of type "list": it is either a sub-list
> or a single value drawn from a given list (an enumeration).  In any
> event, the list concerned is a set of identifiers each conforming to
> the syntax of section 12.4.
> 
> As you point out, my NAS properties may break the rules, and I should
> fix that depending on the outcome of this discussion.
> 
> In my current pass at M.1 I have been trying to be a nice guy by
> defining true ASN.1 binary structures where it made sense within the
> announcement specification syntax.  In the past, where I simply
> specified a structure for a string, I believe I was squarely
> conformant to section 12, but the new binary structures break that.
> I'll have to take them out.
> 
> The structured string approach to specification of complex parameter
> types works, but as you point out it is painful for an ASN.1-based
> implementor.  In my current reading of section 12 I don't think we
> have an alternative.  (I thought of structured integers for the binary
> side, but the limitation to 4 or 8 octets is a bit difficult.)
>

---

From: Troy Cauble <[email-masked]>
Date: Fri, 24 Aug 2001 10:00:07 -0400

> My vote is for 1) but add "Octet String" to the types.

Earlier I voiced a vote for 3).  My main issue is that
IF we have package defined types, they shouldn't be tied
to sub-lists specifically.

I could easily get behind something more restrictive like 1) 
with people hiding complex objects in String (or octet string?)
if people think that is flexible enough.

> Change Type: for sc to read "sub-list: octet string" instead of list.

I can only guess that you mean the octet string text encoding 
referenced in 6.44 of the IG.  OCTET STRING has another meaning
specific to ASN.1.  

What do you mean by "ocet string"?
When would a package designer use it?
Specifically, when is it better than String?

> be to delte 12.3 to stop confusion with sub-list.

Agreed.  And strictly speaking, packages should say "sub-list of X" not
"list of X".

> structures in all cases, H.248 Annex M.1 is a good example.

Agreed.

> Parameter. This is consistent way to decode the information regardless

I'm not sure I follow you.
Are you suggesting we start with strings we've discussed before

	pkg1/sig1
	SignalList = 1 {pkg1/sig1}
	
then encode them as hexidecimal data (as per IG 6.44)?  I assume
it would be based on ASCII values.

	706B67312F73696731
	5369676E616C4C697374203D2031207B706B67312F736967317D
	
How does this help?  There were no characters illegal to
String.  You still have to parse the text after you recover
it.  I must have misunderstood your term "octet string".

-troy

---

From: Christian Groves <[email-masked]>
Date: Mon, 27 Aug 2001 14:57:31 +1000

G'Day Troy,

Please see my answers below.

Christian

> Specifically, when is it better than String?

[CHG] By OCTET STRING I mean a value that is not necessarily a textual
string. ie. 3 OCTETS that has a certain bit structure. In the text
encoding case this would typically be encoded as hexadecimal. If String
handles this for both text and binary then forget my comment.

> it.  I must have misunderstood your term "octet string".

[CHG] For the text encoding what I propose is, for signal list is:
...
	  Notify = A5555 {ObservedEvents =1234 {
                       g/sc {SigID = [pkg1/ann1, pkg2/ann2],
                             SLID = 1,
  			     Meth = TO }}
...
This shows signals Ann1 and Ann2 in Signal List 1 completing. The binary
would take the same format but be coded in binary form.