Best New Trade Show Display by Opera Portables, Inc. adv

opera at localhost.net opera at localhost.net
Thu Feb 1 19:07:51 EST 2001


 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



More information about the sg16-avd mailing list