---

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