Eduard Lascu wrote:
>
> 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.
The key issue here is that BER uses 'tags'.
So each component in your sequence is/must be tagged in such a way that
they are distinguishable (does such a word exist in english?).
Hereby you can tell which of the components that are present in your
sequence, likewise when you have the extension marker, you can tell if
the component is in the root or in the extensionadditions or unknown to
your protocol.
Best regards
Egon Andersen
--
* Talura ApS * Phone: +45 43 52 50 00 *
* Baldersh�j 24 B * mailto:[EMAIL PROTECTED] *
* DK-2635 Ish�j * http://www.talura.dk *
