Interoperability Problems due to Open Type encoding of Nulltypes (fwd)
John Larmouth
j.larmouth at salford.ac.uk
Sat Feb 3 16:14:45 EST 2001
Sorry folks, but the basic question seems to be buried deep in the
e-mail, and given we are hitting inter-working problems, it is clearly
important.
What actually is the issue? Was it resolved last Friday? If not, can
someone give a clear statement of the issue?
John L
Bancroft Scott wrote:
>
> 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
> > >
> >
> >
--
========================================================================
Prof John Larmouth
1 Blueberry Road, Bowdon, Altrincham, Cheshire WA14 3LS, England.
j.larmouth @ salford.ac.uk Tel: +44 161 928 1605
Fax (work): +44 161 745 8169 Tel (work): +44 161 295 5657
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
More information about the sg16-avd
mailing list