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.
Douglas
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@trillium.com | Los Angeles, California 90025 | |Tel: +1(310)-442-9222 | U.S.A | +------------------------------+--------------------------------------+