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

From: Terry L Anderson <[email-masked]>
Date: Wed, 31 Oct 2001 08:43:52 -0500

In trying to reach a consensus on this long debated issue so it can make it into
the
IG, I want to try to break this into two issues and offer compromises.

1. What is the value (indicated type, binary and text encoding) for the g/sc
event property?
2. What are allowed types that can be used in defining properties in packages.
The two issues are use of "list" and a comment concerning "future types" added
to Annex B by IG6.80 implying that packages might use types not in the list in
12.1.2.

1. The simplest fix for g/sc would be to return to Troy's initial suggestion:
that the type be listed as "string" but maintain the current description of how
the string is formed.  Since the string would often contain non-SafeChar's it
would most often require enclosure in quotes when used in text-encoding.

2. The issue with "list" and "future types" could be resolved by adding the
following to 12.1.2:

A package defining a property as a sub-list or requiring any other types must
define how the value is encoded in both text and binary representations.  Text
encoding must define how the value is encoded into a string (consistent with the
definition of VALUE).  The same encoding into a string may be specified for
binary encoding, but where parsing the string may be too complex without the use
of a text-parser, the binary encoding may specify an encoding into an OCTET
STRING, possibly defining this using ASN.1.

Christian Groves wrote:

> G'Day Troy,
>
> Please see my answers below.
>
> Christian
>
> Troy Cauble wrote:
> >
> > Christian Groves wrote:
> > >
> > > 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.
> >
> > 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?
>
> [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.
>
> >
> > > "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.
> >
> > Agreed.  And strictly speaking, packages should say "sub-list of X" not
> > "list of X".
> >
> > > 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.
> >
> > Agreed.
> >
> > > 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.
> >
> > 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".
>
> [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.
>
> >
> > -troy
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/megaco

--

------------------------------------------------------------
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: Wed, 31 Oct 2001 08:43:52 -0500

--

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 31 Oct 2001 08:43:52 -0500

--

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 31 Oct 2001 08:43:52 -0500

--

---

From: Troy Cauble <[email-masked]>
Date: Wed, 31 Oct 2001 10:19:30 -0500

> would most often require enclosure in quotes when used in text-encoding.

If we call it String, it's always enclosed in quotes. (Annex B.2)

> STRING, possibly defining this using ASN.1.

This doesn't appear to change anything.  Is it meant to clarify?

The multiple uses of "string" and "octet string" throughout the
document (and in your paragraph above) lead to confusion.  I'd 
prefer a clearer delineation between the defined parameter types 
and encoding mechanisms.

"OCTET STRING" is an ASN.1 ("over-the-wire") encoding mechanism.
"string (consistent with the definition of VALUE)" is the text
("over-the-wire") encoding mechanism.

"String" and "Octet String" are 2 of several H.248/Megaco defined 
parameter TYPES, which have both text and ASN.1 encoding mechanisms.

-troy

---

From: Troy Cauble <[email-masked]>
Date: Wed, 31 Oct 2001 10:19:30 -0500

-troy

---

From: Christian Groves <[email-masked]>
Date: Thu, 01 Nov 2001 04:54:09 +1100

G'Day Troy, all,

Attached is a PDF prosing changes to cover the encoding of sub-lists and
also how to encode the signal completion parameter. Terry and I sat
together to come up with these changes. Your thoughts? We hope that
these changes address the problems.

Regards, Christian

PS: Sorry about the format but it was the best way to show the changes.

---

From: Christian Groves <[email-masked]>
Date: Thu, 01 Nov 2001 04:54:09 +1100

G'Day Troy, all,

Regards, Christian

---

From: Troy Cauble <[email-masked]>
Date: Wed, 31 Oct 2001 14:27:31 -0500

> these changes address the problems.

Christian,

I have significant issues with these proposed changes.

Regarding your changes to section 12.2:

 I have no problem with the changes here to sub-list.

Regarding your changes to section E.1.2

 "String" is a 12.2 type.  "Octet String" is a proposed 12.2
 type (AVD-2127).  Both of them have text and ASN.1 encodings.

 "Type: Text (String) Binary (Octet String)"
 is defining SigID's as different *types* for text and ASN.1.
  
 This is bad.  It's analogous to saying it's an Integer in
 text and a Double in ASN.1.  We need to pick or define a 
 single TYPE for SigID, with encodings for text and ASN.1.

Regarding your changes to "H.248 Annex A ASN.1 Syntax:"

 The encoding of lists is already covered by the following.

   Value ::= SEQUENCE OF OCTET STRING

Regarding your changes to "H.248 Annex B ABNF Syntax"

 The encoding of lists is already covered by the following.

   propertyParm         = pkgdName parmValue
   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

Regarding your changes to "H.248 Annex B"

 I have no problem with striking the "Future types" reference.

-troy

---

From: Troy Cauble <[email-masked]>
Date: Wed, 31 Oct 2001 14:27:31 -0500

Christian,

  

-troy