> In the ANSI MAP specification there are unsigned types as included
> below. How should I map these in ASN.1?
>
> The intention is to reclaim the high bit to use as value. Given
> presence of these types in this document I'm sure there is an
> accepted way of doing this however I coukldn't turn up anything.
>
> An example from TIA/EIA-41-D:
>
> QulificationInformationCode ::= [17] IMPLICIT Unsigned Enumerated
>
> The length is one octet and the values are given as:
>
> Bits H G F E D C B A Value Meaning
>
> 0 0 0 0 0 0 0 0 0 Not used.
> 0 0 0 0 0 0 0 1 1 No information.
> 0 0 0 0 0 0 1 0 2 Validation only.
> 0 0 0 0 0 0 1 1 3 Validation and profile.
> 0 0 0 0 0 1 0 0 4 Profile only.
>
> 0 0 0 0 0 1 0 1 5 -+ Reserved. Treat the same as
> ... through | value 3, Validation and
> 1 1 0 1 1 1 1 1 223 -+ profile.
>
> 1 1 1 0 0 0 0 0 224 -+ Reserved for TIA/EIA-41 protocol
> ... through | extensions. If unknown, treat
> 1 1 1 1 1 1 1 1 255 -+ the same as value 3, Validation
> and profile.
>
>
> -Vance
>
>
> 6.5.3.14. Unsigned Enumerated
>
> An Unsigned Enumerated value that is limited in range to
> non-negative values including zero. For the purposes of
> this Standard, the sign bit is considered part of the
> unsigned enumerated value. This type cannot be expressed
> as an ASN.1 ENUMERATED type, because an ENUMERATED type is
> encoded as an INTEGER which always uses the sign bit.
>
> An Unsigned Enumerated value may be extended in future
> releases.
>
> The length of a fixed length Unsigned Enumerated value may
> not be extended in future releases.
It's a different answer if the values are to be encoded like BER or like
PER. I would guess it's like BER, with tags and lengths, so perhaps you
should pay more attention to attention to the section for BER.
BER
===
Try INTEGER with named values. It's perhaps not as convenient as
ENUMERATED since you're going to have to figure out the 2's complement
form of the larger numbers by yourself, but it will work.
QulificationInformationCode ::= [17] IMPLICIT INTEGER {
notUsed (0),
noInformation (1),
validationOnly (2),
validationAndProfile (3),
profileOnly (4),
reserved5 (5),
.....
reserved254 (-2),
reserved255 (-1)
}
I'll leave the other (6-253) reserved values to you to figure out.
There is another, but in my opinion, more complicated, method involving
ECN (Encoding Control Notation). With ECN, you could specify that
ENUMERATED types are always encoded as unsigned values.
PER
===
PER will encode an ENUMERATED type just like you want it to, not as a
signed integer, as long as you list all 256 values. PER would
otherwise map the values to other values in an effort to limit the number
of possibilities and therefore the number of bits needed.
QulificationInformationCode ::= [17] IMPLICIT ENUMERATED {
notUsed (0),
noInformation (1),
validationOnly (2),
validationAndProfile (3),
profileOnly (4),
reserved5 (5),
.....
reserved254 (254),
reserved255 (255)
}
Again I'll leave the remaining (6-253) reserved values to you.
> 6.5.3.15. Unsigned Integer
>
> An integer that is limited in range to non-negative values
> including zero. For the purposes of this Standard, the sign
> bit is considered part of the Unsigned Integer value. This
> type cannot be expressed as an ASN.1 INTEGER type, because
> an INTEGER always uses the sign bit.
In PER, this is easy. All you do is provide a constraint, for instance,
UnsignedInteger ::= INTEGER (0..256)
For BER, I can't think of an easy way aside from using ECN.
If you have multiple cases where TIA/EIA-41-D is close to BER, but not
exactly, it would pay to develop an ECN to, in effect, create your own
encoding rules. Let me know privately if you wish to discuss this further.
=====================================================================
Conrad Sigona Voice Mail : 1-732-302-9669 x400
OSS Nokalva Fax : 1-419-831-5035
[EMAIL PROTECTED] My direct line : 1-315-845-1773
