Re: [ASN1] INTEGER encoding in PER

John Larmouth Wed, 01 Sep 2004 07:44:24 -0700

The design of PER was to do a sensible balance between verbosity and ease of implementation. And also to avoid length fields whenever a fixed-length encoding was "sensible" (as in the 64K-range case). Of course, a UTF-8-style encoding for such cases would be possible if low values were likely to be most common, but would add complications. In general, PER assumes that the distribution of values in a constrained integer (in actual communication) is random - it does not attempt any form of Huffman encoding.

On the encoding of constrained integers, there are (for historical reasons) difference between aligned PER and unaligned PER, although with a constraint to a range of 64K, both encode the same way - in two octets.

For a detailed analysis of all cases, you need either the standard, OD or my book, or copies of course notes.

If I were to provide this here, I would be repeating the text of at least one of these!

Which particular cases are you unclear about?

John L


Mark Tillinghast wrote:

Is the guiding principle to reduce the total size? The first one costs you 5 octets(even though it looks right) > -- a: > 00000001 00001010 > -- b: > 00000010 01111101 00000000 > But the second one only costs you 4 octets. What about: a SomeInt ::= 10 b SomeInt ::= 12 -- a: 00000000 00001010 -- b: 00000000 00001100

Or is it simply a function of the constraint?
Does that mean that
 SomeInt ::= INTEGER (0..255)
 a SomeInt ::= 10
 b SomeInt ::= 12
   -- a:
     00001010
   -- b:
     00001100
John could you elaborate on this suspicion that I have expressed?
Log2(upper-lower+1)/8 ?

-----Original Message-----
From: John Larmouth [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 31, 2004 5:17 AM
To: Bjoern Schneider
Cc: [EMAIL PROTECTED]
Subject: Re: [ASN1] INTEGER encoding in PER


For both aligned and unaligned PER, all values of this type
with this constraint
encoding into two octets, with no length count.

John L


Bjoern Schneider wrote:
 > 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
 >
 >

--
    Prof John Larmouth
    Larmouth T&PDS Ltd
    (Training and Protocol Development Services Ltd)
    1 Blueberry Road
    Bowdon                               [EMAIL PROTECTED]
    Cheshire WA14 3LS
    England
    Tel: +44 161 928 1605               Fax: +44 161 928 8069

_______________________________________________
ASN1 mailing list
[EMAIL PROTECTED]
http://lists.asn1.org/mailman/listinfo/asn1


--
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Development Services Ltd)
   1 Blueberry Road
   Bowdon                               [EMAIL PROTECTED]
   Cheshire WA14 3LS
   England
   Tel: +44 161 928 1605                Fax: +44 161 928 8069

_______________________________________________
ASN1 mailing list
[EMAIL PROTECTED]
http://lists.asn1.org/mailman/listinfo/asn1

Re: [ASN1] INTEGER encoding in PER

Reply via email to