Paul,
I'm not positive, (it was in a galaxy far, far away...) I believe the
original intent behind not having 0, was so that implementations could
recognize a mal-formed or illegal value.
The usefulness of this may be debated....
jimt.
At 08:48 AM 3/6/98 -0800, you wrote:
>>----------
>>From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT]
>>A clean fix for the problem you discovered would be to allow 0 as a
>>special value in RequestSeqNum:
>>
>> RequestSeqNum ::= INTEGER (0|1..65535)
>> -- 0 reserved for XRS if the received message could not be decoded
>
>This isn't so clean. This would produce a different, non-interoperable
>encoding. For example, the value, 8, would produce an ASN.1 PER encoding
>of 8 instead of 7. The encoding syntax would stay the same (same number
>of bits, etc.), but the semantics would change (values are normalized
>differently). An alternative would be INTEGER (1..65535|65536), but even
>though normalization is now the same (1-based instead of 0-based), the
>new, reserved value, 65536, would cause a semantic decode error in an
>ASN.1 decoder still using the old range, 1..65535. I don't see any clean
>way to fix it.
>
>BTW, does anyone know why RequestSeqNum wasn't defined as INTEGER
>(0..65535) in the first place? This would have provided a much more
>natural wrap-around from 65535 to 0. Not a big deal, though. Just
>wondering.
>
>Paul Long
>Smith Micro
>
>
*************************************************************************
*** +1-503-264-8816(voice) +1-503-264-3485(fax) ***
*** jtoga(a)ideal.intel.com Intel - Hillsboro, OR. ***
*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41***
*************************************************************************
