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

From: Troy Cauble <[email-masked]>
Date: Wed, 3 Jan 2001 18:02:30 -0500

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