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:
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.
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
We will either do this, or revise the text to not use the term "outermost
value".
Bancroft
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