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

From: Shiv Kumar <[email-masked]>
Date: Thu, 4 Jan 2001 12:31:19 +0530

Hi,

 I believe that the decoder at the receiving end should be aware of the data
type of the package element.
So basically, it should have a package database from where it finds the data
type to typecast the
received  OCTET STRING to.
 The same is applicabe for text encoding too. The decoder needs to know whether
to convert
the received text string to an integer/float or just treat it as a character
string.

 BTW, is anyone willing to come up with some examples of binary encoded messages
?  Maybe in the
lines of one of the sample call flows mentioned in merged_01.txt.  The binary
interop would surely gain
from this excercise !

Regards
Shiv

---------------

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: Shiv Kumar <[email-masked]>
Date: Thu, 18 Jan 2001 16:40:27 +0530

Hi

Just to confirm, what the following text suggests is that we do double-wrapping
,  right ?
We encode the parameter value depending on the data type and then wrap it with
the tag for OCTET STRING, just as Troy had been suggesting in the intial mails?
Please correct me if I am wrong.

Regards
Shiv

---------------

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]

Troy Cauble wrote:
>
> Tom-PT Taylor wrote:
> >
> > 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.
>
> I'm implementing both text and binary.  I'd also be interested
> in hearing who has plans to implement only one or the other.
>
> > 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.
>
> I'd settle for consensus in the group.  Especially those
> going to the Feb. interop.
>
> > 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.
>
> 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.
>
> 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.
>
> > >
> > > Troy Cauble wrote:
> > > >