Hi,
Chapter 12 Note 1 in X.691 states
" NOTE 1 (Tutorial ALIGNED variant) Ranges which allow the encoding of
all values into one octet or less go into a minimum-sized bit-field with
no length count. Ranges which allow encoding of all values into two
octets go into two octets in an octet-aligned- bit-field with no length
count. Otherwise, the value is encoded into the minimum number of octets
(using non-negative-binary- integer or 2 s-complement-binary-integer
encoding as appropriate) and a length determinant is added. In this
case, if the integer value can be encoded in less than 127 octets (as an
offset from any lower bound that might be determined), and there is no
finite upper and lower bound, there is a one-octet length determinant,
else the length is encoded in the fewest number of bits needed. Other
cases are not of any practical interest, but are specified for
completeness."
From this, what I feel is that given the type defintion as
SomeInt ::= INTEGER (0..65535)
any variable of this type will ALWAYS be encoded into two bytes, due to
the statement "Ranges which allow encoding of all values into two octets
go into two octets in an octet-aligned- bit-field with no length count."
Regards,
Divya
>Hi,
>
>I'm curious about the following 'problem' (actually, I couldn't
>understand ITUs recommendation X.691 fully... o_O ):
>
>SomeInt ::= INTEGER (0..65535)
>
>a SomeInt ::= 10
>b SomeInt ::= 32000
>
>Now, when I encode these two variables into _byte-aligned_ PER: has
>there to be a length part everytime? i.e.:
>
> -- a:
> 00000001 00001010
> -- b:
> 00000010 01111101 00000000
>
>Or will it encoded as 2-byte number? i.e.:
>
> -- a:
> 00000000 00001010
> -- b:
> 01111101 00000000
>
>Although I'd rather like to use the last one, I think it has to be
>encoded like the first example, with lengths... or is it possible to
>force a 2-byte value explicitely? Maybe with the SIZE(2)-constraint, so
>that you can omit the length? As I tried something like this the last
>time, my compiler bailed out with a syntax error, and I think he's
>(unfortunately ;) ) right...
>
>Thanks in advance,
> Bjoern Schneider
>
>
>
>
>_______________________________________________
>ASN1 mailing list
>[EMAIL PROTECTED]
>http://lists.asn1.org/mailman/listinfo/asn1
>
SASKEN BUSINESS DISCLAIMER
This message may contain confidential, proprietary or legally Privileged information.
In case you are not the original intended Recipient of the message, you must not,
directly or indirectly, use, Disclose, distribute, print, or copy any part of this
message and you are requested to delete it and inform the sender. Any views expressed
in this message are those of the individual sender unless otherwise stated. Nothing
contained in this message shall be construed as an offer or acceptance of any offer by
Sasken Communication Technologies Limited ("Sasken") unless sent with that express
intent and with due authority of Sasken. Sasken has taken enough precautions to
prevent the spread of viruses. However the company accepts no liability for any damage
caused by any virus transmitted by this email
_______________________________________________
ASN1 mailing list
[EMAIL PROTECTED]
http://lists.asn1.org/mailman/listinfo/asn1
