Interoperability Problems due to Open Type encoding of Nulltypes (fwd)

Bancroft Scott baos at oss.com
Sat Feb 3 20:44:48 EST 2001


On Sat, 3 Feb 2001, John Larmouth wrote:

> 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?

This pertains to the fact that "outermost" value is used in X.691 but not
clearly defined.  Below I indicate that this was discussed the first week
of our meeting in Geneva and will be clarified in an upcoming corrigendum.

Bancroft
 
> 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