XRS RequestSeqNum can't be zero

[Jim Toga]

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 at 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 at ideal.intel.com              Intel - Hillsboro, OR.        ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41***
*************************************************************************