FW: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
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@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:
- 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.
- 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@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@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@mailbag.intel.com
participants (1)
-
Paul, Manoj