RE: [ASN.1] Numeric String PER encoding

[Patel, Avinkumar V (Avinkumar)]

Prof John,
Lets say, I have this pattern,

Stationnumber ::=NUMERICSTRING;

There is no constraint on definition of NUMERICSTRING
Now I am sending value of Stationnumber = 34567
I mean to say Stationnumber has 5 characters.
So, How would you encode this in bit value in Octet Aligned encoding.


Your books say "no of reduction needed for better encdoing" of NumericString
is 3 bits.( I think that for not octet aligned encoding). So I calculated
(according to x.691 formula) for Octet aligned encoding, that gave me 4
bits.
So what I understand is accoding to x.691 definition I have to encode
NUMERICSTRING in 4 bits if it doesn't have any constrain.
But if I am doing Octet Aligned encoding for this value than it will encode
this 5 charaters in 20 bits.
( like L: 00000101 C: 0011 0100 0101 0110 0111 )
 So that means I have to put 4 bit pedding at the end for Octet alignment,
But that is not going to be understand by decoder.
So actually How this string would be written in Bit format.


Thanks,
Avin


-----Original Message-----
From: John Larmouth [  <mailto:[EMAIL PROTECTED]>
mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 17, 2000 1:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [ASN.1] Numeric String PER encoding


I am sure both Olivier's and my book spell this out pretty thoroughly -
not to mention the Standard (which ***hopefully*** will soon be
available for free on the Web).

The important issue is whether the NumericString type has a
"PER-visible" effective alphabet constraint restricting it to the four
characters "3", "4", "5", and "6".  If it does, then each character will
encode in just two bits and your whole string will take ten bits.
Whether there is a length field, and of what sort, depends on any
effective length constraint that has been applied to the type.

It is a general comment on the queries that come up on this list that
ASN.1 encodings (and **particularly** PER encodings) depend on the
**type definition** (with any constraints) far more than on the actual
value being encoded.

The point is that a receiver knows the type definition, but hasn't got
clue about the value being sent, so it has to be possible to determine
the value from the encoding using *only* knowledge of the type
definition (and any constraints on the type), as this is the only
"shared knowledge" between the sender and the receiver.

So when someone says "how do I encode xyz", they need to say "value xyz
of type definition pqr" to ask a meaningful question.

PER, and any other encoding rule, would be a bust specification if the
decoding of the encoding of a value required more knowledge than the
type definition of the encoded value, and the encoding rule definition
being employed.

On the other-hand, some (I won't mention the dirty word) mindless
encoding systems assume almost zero shared knowledge between encoder and
decoder, resulting in extremely verbose encodings (a situation which is
aggravated by the use fo a character-based rather than a binary
encoding).

PER assumes a necessary and sufficient shared knowledge, resulting in
robust but efficient encodings.

End of sermon!

John L

========================================================================
                          Prof John Larmouth
   1 Blueberry Road,  Bowdon,  Altrincham,  Cheshire WA14 3LS,  England.
     j.larmouth @ salford.ac.uk              Tel: +44 161 928 1605
        Fax (work): +44 161 745 8169  Tel (work): +44 161 295 5657
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -