Interoperability Problems due to Open Type encoding of Null types (fwd)

Bancroft Scott baos at OSS.COM
Fri Feb 2 04:35:41 EST 2001


On Fri, 2 Feb 2001, Paul E. Jones wrote:

> Manoj,
>
> Given Bancroft's role in the development of ASN.1, I'd say that whatever he
> says is probably true and most likely the intent if the text is not clear.

I have inputted this to the ASN.1 meeting that was held at the ITU-T in
Geneva January 22 - February 2, and this will be clarified in an upcoming
corrigendum.

> In any case, I would venture to guess that OSS is more widely used than any
> other ASN.1 PER encoder/decoder on the market.  While it may not be
> appropriate to call their tools the "de facto" standard, they very much are
> (no disrespect intended to anyone).  I would suggest that the text be
> clarified according to Bancroft's recommendation and that Implementers
> follow his advise, as I believe it would result in the widest possible
> interoperability.

I'm cc'ing the ITU-T ASN.1 Rapporteur, Olivier Dubuisson, and the ISO/IEC
ASN.1 Rapporteur, John Larmouth, in case they have anything to add.

Bancroft

> Paul
>
> ----- Original Message -----
> From: "Paul, Manoj" <mpaul at TRILLIUM.COM>
> To: <ITU-SG16 at mailbag.cps.intel.com>
> Sent: Thursday, February 01, 2001 3:34 PM
> Subject: Re: Interoperability Problems due to Open Type encoding of Null t
> ypes (fwd)
>
>
> > Hi All,
> >
> >   I am resending this mail as there does not seem to be a consensus on
> > the defintion of "outermost" value as defined in X.691 specification.
> > Any additional information which would help solve this issue is
> > appreciated. It will help to mitigate one of the important issues
> > affecting the interoperability across H.323 implementations.
> > thanks
> > Manoj.
> >
> > -----Original Message-----
> > From: Paul, Manoj [mailto:mpaul at TRILLIUM.COM]
> > Sent: Friday, January 19, 2001 10:21 AM
> > To: ITU-SG16 at mailbag.cps.intel.com
> > Subject: Re: Interoperability Problems due to Open Type encoding of Null
> > t ypes (fwd)
> >
> >
> > Hi Scott,
> >
> >   We agree to your interpretation for case (1). However, for case (2)
> > we believe that only Foo SEQUENCE should be considered the outermost
> > value. And since it would not generate an empty bit string, no additional
> > 0x00 octet should be added to the field-list. Why should v (NULL element)
> > also considered as outermost value in this context since it appears
> > within the extension root of Foo, isn't it?
> > -Manoj
> >
> > -----Original Message-----
> > From: Bancroft Scott [mailto:baos at OSS.COM]
> > Sent: Wednesday, January 17, 2001 8:58 PM
> > To: ITU-SG16 at mailbag.cps.intel.com
> > Subject: Re: Interoperability Problems due to Open Type encoding of Null
> > types (fwd)
> >
> >
> > On Wed, 17 Jan 2001, Manoj Paul wrote:
> >
> > > Experts,
> > >
> > >   We have come across a specific problem which has been the root
> > > cause of interoperability failures across different implementations
> > > of H.323 stack. The problem is related to the
> > >  1) Encoding and decoding of NULL data types when they appear as
> > >    extension IEs.
> > >  2) Encoding and decoding of extension IEs which have NULL as the
> > >    outermost ASN type.
> > >
> > > There have been different interpretations of the PER rules that apply
> > > to the above conditions causing interop failures at encode/decode level.
> > > Although the implementations would encode/decode (1) and (2) according
> > > to Open Type elements, some subtle differences come as mentioned below:
> > >
> > >   In case of (1), some implementations would not encode an extra 0x00
> > > octet for NULL data type and would just encode the length of the open
> type
> > > element as 0x00. This idea probably stems from the fact that a NULL
> > > data type has no encoding when they appear in the root of the ASN.1
> type.
> > > However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for
> > > such a case would be  0x01 0x00, where 0x01 is the uncosntrained length
> > > of the NULL data type encoding and 0x00 is the value of NULL data type
> in
> > > extension.
> >
> > Your understanding of the encoding is correct.
> >
> > >  In case of (2), some implementations would encode the extension IE as
> per
> > > it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for
> > > the outermost NULL data type in it's encode tree. This would change the
> > > value of length field to be appended to this open type. Whereas some
> > > implementations do add 0x00 octet for the outermost NULL data type.
> > >
> > > There appears to be a confusion as to what is meant by the "outermost"
> > > value in 10.1.3 of X.691. I would appreciate clarification on this
> > > clause as it would save a lot of interop overhead at encode/decode
> level.
> >
> > "outermost" value refers to a value of a type that is either directly
> > nested in an open type or is a complete application message unto itself.
> > For example, if you had:
> >
> >         Foo ::= SEQUENCE {
> >                 b       BOOLEAN,
> >                 v       TYPE-IDENTIFIER.&Type,
> >                 ...,
> >                 i       NULL
> >         }
> >
> >         bar  Foo ::= {b TRUE, v NULL : NULL, i NULL}
> >
> > The value of Foo, bar, is an outermost value. The value of v (NULL : NULL)
> > is encoded as an outermost value, so in this case since NULL encodes to 0
> > bits it is replaced with eight 0-bits, and this is prefixed with a length
> > of 1.  Similarly, the value of i is encoded as an outermost value, so the
> > resulting encoding in this case will have a length of 1 followed by eight
> > 0-bits.
> >
> > -------------------------------------------------------------------------
> > Bancroft Scott                               Toll Free    :1-888-OSS-ASN1
> > OSS Nokalva                                  International:1-732-302-0750
> > baos at oss.com                                 Tech Support :1-732-302-9669
> > x-1
> > 1-732-302-9669 x-200                         Fax          :1-732-302-0023
> > http://www.oss.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list