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