FW: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)

[Paul, Manoj]

 Hi All,

   Following text contains further clarification on encoding rules
for NULL ASN.1 data types. This might be useful for implementors
in general.
thanks
Manoj Paul.

-----Original Message-----
From: Bancroft Scott [mailto:baos at oss.com]
Sent: Thursday, March 01, 2001 6:46 PM
To: Paul, Manoj
Cc: Olivier DUBUISSON; John Larmouth; Jean-Paul LEMAIRE
Subject: RE: Interoperability Problems due to Open Type encoding of Null
t ypes (fwd)


On Thu, 1 Mar 2001, Paul, Manoj wrote:

> Hi Bancroft,
>
>   Thanks for your clarification. I now understand outermost value
> as a value nested in an Open Type (TYPE-IDENTIFIER.&Type). I actually
> began to get into this loop
> when i was encoding an "extension addition" as open type (for ex, an
> extension addition in a SEQUENCE). For ex
>
> example ::= SEQUENCE
> {
>   a   BOOLEAN,
>    ...,
>   b CHOICE
>   {
>     b1  NULL,
>     b2  NULL
>   }
> }
> Now when I encode the value of "b", I would apply the rules of Open
> Type encoding. I choose one of the Nulls, say b2. Which of the following
> you think is a correct encoding:
>
> 1) Does b2 qualify as an outermost value and since it does not produce any

> encode bits, I need to encode a 0x00 octet for it with the bit-fields of
> "b", and
> then octet align to generate complete encoding. And add this total length
> before this octet aligned bit field.
>
> 2)  b and not b2 is the outermost value, and since b generates a
> non-empty bit string, we just add pad bits, add length. So no
> additional 0x00 octet for b2.

2 is correct.

> The above example is closest to what I am trying to understand. The
> problem is that clause "10.1.3" does not state definition of
> "outermost value". After your clarification, I do understand it as the
> value nested in an Open Type. But besides this definition, is there
> any other meaning of Outermost value also (like the last embedded
> codepoint in an information element which is after the extension
> marker).

What do you mean by "codepoint" in this context?

> My $0.02 is to make the definition of outermost value
> explicit in X.691. Your assistance is greatly appreciated.

We will either do this, or revise the text to not use the term "outermost
value".

Bancroft


> warm regards
> Manoj Paul.
>
> -----Original Message-----
> From: Bancroft Scott [mailto:baos at oss.com]
> Sent: Wednesday, February 28, 2001 4:37 PM
> To: Paul, Manoj
> Cc: Olivier DUBUISSON; John Larmouth; Jean-Paul LEMAIRE
> Subject: RE: Interoperability Problems due to Open Type encoding of Null
> t ypes (fwd)
>
>
> On Wed, 28 Feb 2001, Paul, Manoj wrote:
>
> >  Hi Bancroft,
> >
> >    A few weeks back there was a discussion on the SG16 mailing
> > list about the meaning of Outermost value. You had given the
> > clairification on this term with the following example.
> >
> >
> > > > "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.
> >
> > I have a doubt about this and would highly appreciate if you could
> > help me with that. In the example above, I assume that bar is being
> > encoded as an Open type value.
>
> No, not at all as an Open type value.  It is being encoded as an outermost
> value, which means that after encoding it is padded to be an integral
> number of 8 bits long.
>
> > You mentioned that each type which is directly nested in the Open type
> > should be considered as an Outermost value.
>
> Correct.
>
> > By that logic, b,v and i should be encoded as per the outermost value
> > rules.  Is that true?
>
>
> No.  b is not directly nested in an open type value.  The *contents*
> of v is encoded as an outermost value because it is to be nested in
> the Open type, v.  i is encoded as an outermost value because the rules
> for encoding extension additions mandates it.
>
> > Does that mean that "b" which resuls in a non-empty bit string need to
> > be octet aliged?
>
> No.  Indeed, "b" would never be octet aligned because of the extensibility
> marker that will always occur immediately in front of it (and because it
> is not encoded as an outermost type).
>
> > In the encoding above, you also mentioned that v should result in
> > 0x01, 0x00 octets. But why should we encode the length for v, since it
> > is not encoded as an open type itself.
>
> The *contents* of v is encoded as an outermost type, meaning that it is
> padded to an octet boundary.  v itself is encoded as an Open type, meaning
> that a length is always prefixed to its value (i.e., always prefixed to
> its *contents* by virtue of encoding v).
>
> > Shouldn't it just be 0x00?
>
> No, not at all.
>
> Consider the case where you have the following and maybe you will see
> the rationale why it was designed this way.  Suppose we have:
>
>       ObjSet TYPE-IDENTIFIER ::= {...}
>
>         Bar ::= SEQUENCE {
>                  b       TYPE-IDENTIFIER.&id ({ObjSet}),
>                  v       TYPE-IDENTIFIER.&Type ({ObjSet}{@b}}
>       }
>
>
>       Zoo ::= SEQUENCE {
>               j       Bar,
>               k       INTEGER
>       }
>
> If an implementation did not know all the information objects in ObjSet
> (a common occurrence in many types of applications) then it would be
> impossible for such a receiving implementation to know how many bytes
> to skip over to get to k if v were not encoded with a length prefix.
>
> > I will really appreciate your help on this since no where this
> > clarification is available.
>
> In my previous email I spelled out the pertinent clauses where the
> proper encoding is defined.  Which did you find unclear.  Your feedback
> would be much appreciated so that we can improve the documentation.
>
> -------------------------------------------------------------------------
> 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