[Mibble-users] Wrong constraints

[Karl Weber]

Hi,
Hi Per,

I am no ASN.1 expert, so I cannot tell whether the following is an error, but 
according to my understanding of the X.208 I suppose so.

As an example I am referring to the definition of the type symbol RowStatus in 
the MIB SNMPv2-TC, which has the SYNTAX

RowStatus ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
[...]
    SYNTAX       INTEGER {
                     -- the following two values are states:
                     -- these values may be read or written
                     active(1),
                     notInService(2),
                     -- the following value is a state:
                     -- this value may be read, but not written
                     notReady(3),
                     -- the following three values are
                     -- actions: these values may be written,
                     --   but are never read
                     createAndGo(4),
                     createAndWait(5),
                     destroy(6)
                 }

If I follow the Type and Value references mibble creates, I get the following 
(I will explain the output of my test program below)

TYPE-SYMBOL  RowStatus
 MIB-T TEXTUAL-CONVENTION [SnmpTextualConvention] {- - -} «- - -»
 ... REFERS       : null
 ... STATUS       : current
 ... DISPLAY_HINT : null
 ... SYNTAX       :
  MIB-T INTEGER [IntegerType] {[UNIVERSAL 2]} «- - -» -- is primitive
   VALUE-SYMBOL active
    --- MIB_VALUE and MIB_TYPE of VALUE-SYMBOL active
    MIB-V Number [Number«Integer»] >1<
   VALUE-SYMBOL notInService
    --- MIB_VALUE and MIB_TYPE of VALUE-SYMBOL notInService
    MIB-V Number [Number«Integer»] >2<
   VALUE-SYMBOL notReady
    --- MIB_VALUE and MIB_TYPE of VALUE-SYMBOL notReady
    MIB-V Number [Number«Integer»] >3<
   VALUE-SYMBOL createAndGo
    --- MIB_VALUE and MIB_TYPE of VALUE-SYMBOL createAndGo
    MIB-V Number [Number«Integer»] >4<
   VALUE-SYMBOL createAndWait
    --- MIB_VALUE and MIB_TYPE of VALUE-SYMBOL createAndWait
    MIB-V Number [Number«Integer»] >5<
   VALUE-SYMBOL destroy
    --- MIB_VALUE and MIB_TYPE of VALUE-SYMBOL destroy
    MIB-V Number [Number«Integer»] >6<
   MIB-COMPOUND-CONSTRAINT
    MIB-VALUE-CONSTRAINT
     MIB-V Number [Number«Integer»] >1<
    MIB-VALUE-CONSTRAINT
     MIB-V Number [Number«Integer»] >2<
    MIB-VALUE-CONSTRAINT
     MIB-V Number [Number«Integer»] >3<
    MIB-VALUE-CONSTRAINT
     MIB-V Number [Number«Integer»] >4<
    MIB-VALUE-CONSTRAINT
     MIB-V Number [Number«Integer»] >5<
    MIB-VALUE-CONSTRAINT
     MIB-V Number [Number«Integer»] >6<

Mibble creates a VALUE-SYMBOL for every >identifier< (as it is called in 
section 14.1 of the X.208 Recommendation) explicitly listed in the SYNTAX of 
the type definition of RowStatus. Furthermore, it adds a compound constraint, 
restricting the value set of the RowStatus type to the values listed, thus 
effectively creating a subtype of INTEGER. Is this correct?

14.3 of the X.208 Recommendation says

The "NamedNumberList" is not significant in the definition of a type. It is 
used solely in the value notation specified in paragraph 14.9.

NamedNumberList occurs in the production

IntegerType ::=

        INTEGER |
        INTEGER { NamedNumberList }

NamedNumberList  ::=

        NamedNumber |
        NamedNumberList, NamedNumber

NamedNumber ::=

        identifier(SignedNumber) |
        identifier(DefinedNumber)

[...]

So, according to X.208, the value set of the type RowStatus contains the 
values 7, 8, 9, ... as well. This is in contrast to the enumerated type, 
which might be more appropriate here, since the semantics of a RowStatus of 8 
is not defined and does not make sense. 

So, from a practical point of view, the compound constraint does seem to make 
sense here, although it is not conforming to the standard. 

Such a constraint might, on the other hand, hurt in other cases. -- If someone 
is using the type and value information to implement automatic type checking.

By the way, Olivier Dubuisson is a little more explicit in chapter 10.3 of his 
book on ASN.1 as to this point.

Regards,

Karl