Re: coex draft last call -- review of Section 2

> RFC 2578 says:

>    The Integer32 type represents integer-valued information between
>    -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This
>    type is indistinguishable from the INTEGER type.  Both the INTEGER
>    and Integer32 types may be sub-typed to be more constrained than the
>    Integer32 type.

> This basically tells me that INTEGER used in SMIv2 modules is indeed
> constrainted to a 32 bit value.

Umm....   I'm not sure that it does.
It says that Integer32 is contrained to a 32 bit value, and that an
Interger32 value looks just like an INTEGER value.  But reading closely,
I'm not convinced that is necessarily says that an INTEGER value *has*
to look like an Integer32 value.

It's being picky, I know, but there feels to be a little bit of
"wiggle room", which feels undesirable.


> Dave> I was under the impression that trying to assign a value of
> Dave> 4294967296 or above (i.e. 2^32) to an object of syntax INTEGER
> Dave> would be theoretically valid - but one particular implementation
> Dave> might easily choke on it, while another would be quite happy.

> I do not think this is the case nor the intention. 

I'm sure it wasn't the intention, and I'm not holding this up as an
example of Good Practise.   But I'm not 100% convinced that it's clearly
ruled out.  So I believe it would be a Good Thing to remove this
possibility as a potentially valid interpretation.
 

>                             In other words: while it is legal to
> use INTEGER in all places where you use Integer32, it does not have
> any benefits and it has the potential to mislead people. So MIB
> authors should just not do this.


<nods>
Sounds good.
I'd certainly agree that there's no sensible reason to use INTEGER
rather than Integer32.   But I'm suggesting that this might as well
be made explicit in the SMI specification.



> Dave>   Or is there something I've missed that applies a 32-bit
> Dave> limitation to apparently unconstrained INTEGER values?

> Even if INTEGER would allow values bigger than 32 bit, you would not
> be able to ship them due to the way SimpleSyntax is defined so ....


Ummm...   OK - I'll go and look at that bit again.  Thanks for the pointer.

>                                        .....  in fact
> INTEGER means Integer32 when used in SMIv2 modules.


OK - so let's say so explicitly.

Dave