XRS RequestSeqNum can't be zero

[Paul Long]

>----------
>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