PER ASN Encode of Open type elements

Douglas Clowes dclowes at OZEMAIL.COM.AU
Wed Apr 7 19:33:02 EDT 1999

1) Assuming that the likely range of values extends beyond 255 and is
uniformly distributed, it is more likely that the length to encode is
greater than 127 any way.

2) If you start with the assumption that the len will be greater than 127,
reserve two bytes for the len, and it turns out to be less, the cost of
moving the "less than 127" bytes down a byte is not likely to be very high.

The "obvious" solution would be to encode the type into the buffer after
two reserved bytes and if you don't get enough, move a few down.


At 16:03 1999-04-07 -0700, Manoj Paul wrote:
>  We would like to seek opinion about the PER ASN encoding of
>  open type elements (such as extension additions in sequence/choice
>  etc.). Such an encoding requires unconstrained length "len" to be
>  appended before the actual field-list of open type element, where
>  "len" is the number of octets in open type element field list encoding.
>  There seem to be the following ways to achieve this:
>  a) Keep encoding the open type element and when it's encoding is
>  finished, count the number of octets in it's encoded value and
>  add that before the encoded value as unconstrained length.
>  b) Just parse through open type element encode rules and find the
>  number of octets it will need. Encode this number as unconstrained
>  length and then do the acutal encode of the open type element value.
>  Implementing (a), on most systems might be expensive, as it will
>  need writing "len" value somewhere in the middle of the message.
>  (b) is also not desirable from performance point of view as it needs
>  double parse.
>  Encoding "len" value less than 16K (which it mostly will) as
>  uncostrained length requires two bytes. But X-691 also says that
>  this length should be encoded in one byte if it is less than
>  127. Is it conforming to X-691, if length value less than 127 is also
>  encoded in two bytes? That way, we know that whatever be the
>  overall number of octets in encoded open type element field list,
>  we will encode "len" in two octets and keep a place holder for
>  these twp bytes before actually encoding the open type value. These
>  "len" octets can then be written to contain  unconstrained
>  length of open type value. This procedure will save the inefficiencies
>  mentioned in (a) and (b) above. But then the catch being if
>  length less than 127 can be encoded in two octets.
>  best regards
>  Manoj Paul.
>|Manoj Paul                    |  Trillium Digital Systems, Inc       |
>|Member of Technical Staff     |  12100 Wilshire Blvd #1800           |
>|E-mail:mpaul at     |  Los Angeles, California 90025       |
>|Tel: +1(310)-442-9222         |  U.S.A                               |

More information about the sg16-avd mailing list