Subject: Re: PRETTY PLEASE: ASN.1 encoding of package elements

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 5 Jan 2001 15:40:06 -0500

I see the point: we actually have specified a syntax (OCTETSTRING), and my
note proposed that we should ignore that specification and do what the
particular situation requires.  I was going to suggest that we do the right
thing and take your third alternative, but I've had another thought:
double-wrapping allows packages to specify property values containing
multiple components, possibly of differing types.  I'm not sure we want that
generality, but that's a separate debate.

More below.

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 1:15 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
[snip]
>
> Why double wrap?  I'll contrast it with the obvious alternatives.
>
> Alt. 1:
> BER encoding the actual type *INSTEAD OF* the OCTET STRING.
> The drawback with this approach is that a decoder generated
> from the Annex A syntax will not work.  It will be looking
> for an OCTET STRING tag, but will see an Integer tag or
> some other tag and fail.  (Fail in a way that the rest of
> the message will not be decoded.)  The generated code will
> have to be hand hacked to handle this.
>
> Of course even with double wrapping, more steps would be needed
> to decode the OCTET STRING to the real value.  But this could
> be done elsewhere.  And it's much more straightforward if an
> implementation gets a message using a package it doesn't
> support -- it can finish the message, just not read some of
> the unsupported values.
>
> I think an ASN.1 syntax that doesn't actually generate
> working code is a problem.
>
> Alt 2:
> Cast your integers (or whatever) to OCTET STRINGs and
> encode them as OCTET STRINGS.
> The problem here is the usual byte ordering stuff.
>
> Alt 3:
> Replace the appropriate OCTET STRINGs in the ASN.1 syntax
> with CHOICE statement containing all the types specified
> in 12.1.2 and 12.2.
> I proposed this in an earlier thread.  This is what I would
> have suggested had I been involved earlier.  But now I prefer
> minimal changes to the document.
>
>
> >
> > Lets start with integers and enums.  Here's a direct
> quotation from X.690
> > for these two types:
>
>       < quote deleted>
>
>
> >
> > To take a specific example, look at the Base Package (Annex
> E.1), parameter
> > GeneralCause of the Generic Error event.  Why can't you
> simply interpret
> > this as
> >
> >    generalCause ::= CHOICE
> >    {    nr [1] INTEGER,
> >         ur [2] INTEGER,
> >          etc.
> >    }
>
> You don't want to lay out a CHOICE structure to hold
> different *values*.
> This is analagous to creating a C union of many constant integers,
> instead of an integer that holds many values.

[PTT]
Told you I was rusty.  Now that I look at Annex A I see that I should have
put this way:

        generalCause ::= GeneralCause

        GeneralCause ::= ENUMERATED
        {    nr(1),
             ur(2),
             etc.
        }

>
> Even if this was correct, it doesn't address the real issue:
> How would we put it in an OCTET STRING?
>
> Thanks,
> -troy
>
> P.S.  Another big ASN.1 issue was brought up by Richie Wu here:
> http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind0012&
L=MEGACO&P=R161 .
> Basically, the ASN.1 EventParameter and SigParameter constructs
> are missing a way to specify the relation (=, !=, <, >, range,
> sublist, & alternatives) between the parameter and it's value list.
> These correspond to the text constructs eventOther and sigOther which
> utilize parmValue.  I believe this will require a change to the ASN.1
> spec.  It could look very similar to the extraInfo component of
> PropertyParm.

[PTT]
Anyone want to specify corrected ASN.1, or should I have a go?

> >
> > Troy Cauble wrote:
> > >
> > > Brian, Christian, Tom, et. al.,
> > >
> > > Can we please nail down how to ASN.1 encode/decode
> > > package elements?
> > >
> > > Double-wrapping has been discussed in the group a
> > > couple of times, but I haven't seen it in the
> > > Implementor's Guide or otherwise "approved".
> > >
> > > Double-wrapping refers to BER encoding an object,
> > > taking the resulting octets, and encoding them
> > > as OCTET STRING.
> > >
> > > In the H.248 case, it would mean BER encoding a package
> > > element based on it's type as defined in the package.
> > > Then encoding the BER output as the OCTET STRING in
> > > the H.248 protocol.
> > >
> > > If we agree on that much, we still need to specify the
> > > proper BER encoding type for each package element type.
> > > I propose the following:
> > >
> > >   Package Type
> > > (12.1.2 or 12.2)                     ASN.1 BER
> > > ===================                  =========
> > > String (UTF-8)                       IA5String
> > > Integer (4 octet)                    INTEGER
> > > Double (8 octet signed int)          INTEGER (***)
> > > Character: (UTF-8, *)                IA5String
> > > Enumeration:                         ENUM
> > > Boolean:                             BOOLEAN
> > > Unsigned Integer: (**)               INTEGER (***)
> > >
> > > *    Can be more than one byte.
> > > **   Unsigned integer is referenced in Annex C.
> > > ***  My understanding of ASN.1 is that INTEGER does not
> > >      imply 4 bytes.  It'll use whatever's needed.
> > >
> > > -troy
> >

---

From: Troy Cauble <[email-masked]>
Date: Mon, 8 Jan 2001 09:16:10 -0500

> Tom-PT Taylor wrote:

> Anyone want to specify corrected ASN.1, or should I have a go?

For consistency with the PropertyParm, I would propose the following:

   -- In EventParameter, value is a SEQUENCE OF octet string.
   -- When sent by an MGC the interpretation is as follows:
   -- empty sequence means CHOOSE
   -- one element sequence specifies value
   -- If the sublist field is not selected, a longer sequence means
   -- "choose one of the values" (i.e. value1 OR value2 OR ...)
   -- If the sublist field is selected,
   -- a sequence with more than one element encodes the value of a
   -- list-valued property (i.e. value1 AND value2 AND ...).
   -- The relation field may only be selected if the value sequence
   -- has length 1.  It indicates that the MG has to choose a value
   -- for the property. E.g., x > 3 (using the greaterThan
   -- value for relation) instructs the MG to choose any value larger
   -- than 3 for property x.
   -- The range field may only be selected if the value sequence
   -- has length 2.  It indicates that the MG has to choose a value
   -- in the range between the first octet in the value sequence and
   -- the trailing octet in the value sequence, including the
   -- boundary values.

   EventParameter ::= SEQUENCE
   {
        eventParameterName              Name,
        value                           Value,
        extraInfo       CHOICE
                {
                        relation        Relation,
                        range           BOOLEAN,
                        sublist         BOOLEAN
                } OPTIONAL,
   }

   -- In SigParameter, value is a SEQUENCE OF octet string.
   -- When sent by an MGC the interpretation is as follows:
   -- empty sequence means CHOOSE
   -- one element sequence specifies value
   -- If the sublist field is not selected, a longer sequence means
   -- "choose one of the values" (i.e. value1 OR value2 OR ...)
   -- If the sublist field is selected,
   -- a sequence with more than one element encodes the value of a
   -- list-valued property (i.e. value1 AND value2 AND ...).
   -- The relation field may only be selected if the value sequence
   -- has length 1.  It indicates that the MG has to choose a value
   -- for the property. E.g., x > 3 (using the greaterThan
   -- value for relation) instructs the MG to choose any value larger
   -- than 3 for property x.
   -- The range field may only be selected if the value sequence
   -- has length 2.  It indicates that the MG has to choose a value
   -- in the range between the first octet in the value sequence and
   -- the trailing octet in the value sequence, including the
   -- boundary values.

   SigParameter ::= SEQUENCE
   {
        sigParameterName                Name,
        value                           Value,
        extraInfo       CHOICE
                {
                        relation        Relation,
                        range           BOOLEAN,
                        sublist         BOOLEAN
                } OPTIONAL,
   }

-troy