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

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 4 Jan 2001 17:50:52 -0500

My mail connectivity was pretty poor for a while, though it seems to have
recovered in the past few weeks.  I'll work through my backlog gradually.
Anyway, the main problem facing binary implementors is that John Segers has
moved on, and Christian Groves is taking a well-earned vacation.  My own
ASN.1 qualifications are pretty rusty: I maintained an application based on
X.409/X.410 for several years.  That means, I suppose, that I understand the
principles but can't provide any detailed coding examples.

How many binary implementors are out there and are willing to identify
themselves to me privately or to the list?  This will give some idea of how
many people constitute a consensus when binary coding issues are being
discussed.

One other point before I address the substance of your note: Christian
Groves is editor of the official Implementor's Guide, so it won't be updated
until he gets back.  If people think we need a Megaco-originated living
document to capture stuff as we go along, I'll ask for a volunteer editor.

On the substance of the note: you raised this in the thread "OCTET STRINGs
in H.248" in November, and John Segers appeared to agree with your double
wrapping proposal, so it looks like a reasonable call.  I'll just ask why
you need the double wrapping in the simple cases like integers.  Obviously a
list needs internal structure to allow the decoder to delineate the
individual elements.

Lets start with integers and enums.  Here's a direct quotation from X.690
for these two types:

<quote>

8.3 Encoding of an integer value

8.3.1 The encoding of an integer value shall be primitive. The contents
octets shall consist of one or more octets.

8.3.2 If the contents octets of an integer value encoding consist of more
than one octet, then the bits of the first octet and bit 8 of the second
octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE - These rules ensure that an integer value is always encoded in the
smallest possible number of octets.

8.3.3 The contents octets shall be a two's complement binary number equal to
the integer value, and consisting of bits 8 to 1 of the first octet,
followed by bits 8 to 1 of the second octet, followed by bits 8 to 1 of each
octet in turn up to and including the last octet of the contents octets.
NOTE - The value of a two's complement binary number is derived by numbering
the bits in the contents octets, starting with bit 1 of the last octet as
bit zero and ending the numbering with bit 8 of the first octet. Each bit is
assigned a numerical value of 2 N , where N is its position in the above
numbering sequence. The value of the two's complement binary number is
obtained by summing the numerical values assigned to each bit for those bits
which are set to one, excluding bit 8 of the first octet, and then reducing
this value by the numerical value assigned to bit 8 of the first octet if
that bit is set to one.

8.4 Encoding of an enumerated value

The encoding of an enumerated value shall be that of the integer value with
which it is associated.
NOTE - It is primitive.

</quote>

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

I agree that the next parameter, failureCause, is underspecified as
OCTETSTRING, but the intent was to allow the application to append debugging
data.  As a result, you'll probably have to live with the ASN.1 equivalent
to an opaque data structure.

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 6:03 PM
> To: [email-masked]
> Subject: [MEGACO] PRETTY PLEASE: ASN.1 encoding of package elements
>
>
> Brian, Christion, Tom, et. al.,
> Pretty please with sugar on top,
>
> I've brought this issue up several times ("OCTET STRING"),
> but have yet to see an answer from someone who contributes
> to the Implementor's Guide, let alone something IN the
> Implementor's Guide.  Is it my breath?
>
> How will ASN.1 encoding ever get off the ground if no one
> will spec how to shove all these different package element
> types into an opaque OCTET STRING?
>
> Please specify something.  Or at least discuss it.
> -troy
>
>
>
> 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: Fri, 5 Jan 2001 13:15:04 -0500

> many people constitute a consensus when binary coding issues are being

I'm implementing both text and binary.  I'd also be interested
in hearing who has plans to implement only one or the other.

> document to capture stuff as we go along, I'll ask for a volunteer editor.

I'd settle for consensus in the group.  Especially those
going to the Feb. interop.

> list needs internal structure to allow the decoder to delineate the

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

        < quote deleted>

> GeneralCause of the Generic Error event.  Why can't you simply interpret

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.

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.

---

From: Christian Groves <[email-masked]>
Date: Tue, 16 Jan 2001 12:25:07 +1100

G'Day Troy, Tom, all,

Finally got around to putting some text together for the implementors'
guide on this. Here's what I propose. Please propose any necessary
changes.

1.1 Encoding of ASN.1 Octet String

Description:    It is ambigious how Integer, boolean etc is encoded in the
ASN.1 when OCTET STRING is used to encode properties.
Reference:      Subject: Re: OCTET STRINGs in H.248
Date: Wed, 8 Nov 2000 14:25:29 -0500
From: Troy Cauble <[email-masked]>
To:  [email-masked]
 [Begin Correction]
Section A.2 ASN.1 Syntax Specification
…
NOTE - The ASN.1 specification below contains a clause defining
TerminationIDList as a sequence of TerminationIDs.  The length of this
sequence SHALL be one, except possibly when used in contextAuditResult.
NOTE - The ASN.1 in this section uses OCTET STRING to encode values for
property parameter, signal parameter and event parameter values. The
format of these values is indicated in Annex C or the relevant package.
The format specified in Annex C or the package relates to ASN.1 BER
encoding according to the following table:

Type Specified in Package       ASN.1 BER Type
String (UTF-8)                  IA5String
Integer (4 Octet)               INTEGER
Double (8 octet signed int)     INTEGER (Note 3)
Character (UTF-8, Note 1)       IA5String
Enumeration                     ENUM
Boolean                         BOOLEAN
Unsigned Integer (Note 2)       INTEGER (Note 3)
Note 1 : Can be more than one byte
Note 2 : Unsigned integer is referenced in Annex C
Note 3 : ASN.1 BER encoding of INTEGER does not imply the use of 4
bytes.

See A.7 X.690 for definition of encoding of Octet String value.

MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=
BEGIN
…
 [End Correction]