pl rfr to 'ASN1_Complete' booklet's
3.1
So for example, a SEQUENCE OF value with an iteration count of zero would
encode with an L of zero. Similarly a SEQUENCE, all of whose elements were
optional, and which in an instance of communication were all missing, would
again encode with an L of zero.
3.13 Handling of OPTIONAL and DEFAULT elements in sequence and set
There are no problems caused by OPTIONAL (the use of tags makes it
unambiguous what has been included and what has not). However, in the case
of DEFAULT, BER leaves it as a sender's option whether to omit a default
value (implying possibly complex checking that it is the default value), or
whether to encode it anyway! The TLV approach was designed to make handling
of OPTIONAL easy. No surprises here. The handling of DEFAULT again raises
issues of
encoder's options and problems in distinguished/canonical encoding rules.
"Eduard Lascu"
<elascu@ibigro To: <[EMAIL PROTECTED]>
up.com> cc:
Sent by: Subject: [ASN.1] Encoding of a sequence
with
owner-asn1@oss optional and default data members in BER
.com
04/02/02 11:27
PM
Please respond
to asn1
Hi everybody,
I have two questions regarding the ISO/IEC 8825-1 standard. More precisely,
I am interested in finding out how BER (Basic Encoding Rules) treats a
sequence (structure) that has optional data members or data members that
can
have the default value.
Paragraph 8.9.3 says that:
" 8.9.3 The Encoding of a data value may, but need not, be present for a
type which was referenced with the keyword "OPTIONAL" or the keyword
"DEFAULT". If present, it shall appear in the encoding at the point
corresponding to the appearance of the type in the ASN.1 definition."
My understanding of this is that a structure that has a couple of data
fields that are optional or with the default value can choose to encode
them
or not. In case it encodes them everything is fine, but how will be
signaled
in the encoding that the fields were not in fact encoded.
Let's think of a structure:
Some_structure SEQUENCE {
Field_1 INTEGER (0..255),
Field_2 INTEGER (0..255) DEFAULT {0},
Field_3 INTEGER (0..100) OPTIONAL,
Field_4 INTEGER (0..100) DEFAULT {1},
Field_5 INTEGER (0..255) OPTIONAL
}
Now let's think to an instance of this structure:
an_Instance = { 3, 0, N/A, 2, 5 };
This has
- its first field set to 3;
- the second one is set to 0 which is the default value for that
field;
- the third field has a value without importance;
- the fourth one has a value of 2, which is different than the
default
value;
- and the last field set to 5, which is important for the current
context.
According to the standard, only fields 1, 4 and 5 should always be encoded,
whereas fields 2 and 3 can miss.
Now my question is how will I know which fields were encoded and which were
skipped when I decode this structure and see that only three integers were
encoded.
The reason I ask this is because I also work with OER (Octet Encoding
Rules)
which is an emerging standard and that one attaches to each structure a
special field, which is called "Preamble". This is basically a bit-map that
tells you which field was encoded and which was skipped. In the above case,
the preamble would have been a 5-bit string equal with 10011 (1 for present
field and 0 for skipped field). When the object is decoded, one can see
that
fields 2 and 3 are missing and knowing the structure can conclude that
field
2 had the default value and field 3 was optional.
My second question is related to the way BER treats the extension marker
fields, if it treats them at all. Extension markers are special fields that
allow structures to evolve from one version to another. All the newer
fields
are enclosed with a pair of extension markers and because of that, every
application that only knows the old version of the object will still be
able
to decode the information. Does BER anything like that?
Best regards,
Eddie Lascu
IBI Group
230 Richmond St. W., 5th Floor
Toronto ON
M5V 1V6
Tel. (416) 596-1930 x205
Fax. (416) 596-0644
NOTE: This e-mail message and attachments may contain privileged and
confidential information. If you have received this message in error,
please immediately notify the sender and delete this e-mail message.
