[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some additional obscure questions...



On Wed, 29 Jan 2003, David T. Perkins wrote:

> As an "old-timer" on the SMI, I appreciate your "searching for the truth".
> But, on the other hand, it appears to me (and maybe to others), that in
> your zeal to find the truth, you are being more concerned with legalistic
> aspects of parsing small pieces of the SMI and ASN.1 definitions than
> understanding the intent of the documents.

Close.  I am (at this time) being more concerned with legalistic aspects
than the intent; not with understanding the intent.  I understand, the
intent fine, and for the most part I believe my parser/compiler is very
good at following the intent and providing warnings/errors where a module
doesn't follow it.  So my current focus is on legalistic aspects and
deciding just how bad a module can get and still be legal so that my tools
can both be as flexible AND compliant as possible.  It's no good if my
compiler accepts as valid something that isn't; but it's also no good if
it can't handle something that is technically legal, however obscure and
outside current practices it is.  Such limitations in a lot of tools are
among the reasons I undertook this project.

> Please note, and I'm sorry if it sounds like a broken record,
> that the MACRO definitions in the SMI are NOT valid ASN.1. Once
> you understand this, then I believe that it makes understanding
> the SMI easier.

I understand this fine.  This issue has nothing to do with the SMI MACRO
definitions, but with the SMI is defined as a delta from the ASN.1 specs;
in this case, specifically with regard to the IMPORTS clause.  The SMI
dosn't fully define the notation, but only says what's different from
ASN.1.  Thus if something isn't mentioned by one of those deltas,
presumably the ASN.1 rules apply, because it's not possible to intuit the
complete notation and semantics solely by reading RFC 2578.

> versions. However, there are still problems with the text of the
> current SMI. Where those problems are identified, it would
> most benefit the community of users of the SMI to document
> the problems and provide alternative fixes with the consequences
> of those fixes.

Certainly.  But it would help to be clear what the different accepted
interpretations are first, which is what I am looking for here.  I'm not
attached to any particular interpretation.  I see three possibilities,
none of which are definitively spelled out:

1. One interpretation might be that only absolute OIDs are allowed when
specifying a MODULE-IDENTITY to disambiguate the imports.  This
interpretation doesn't seem to be supported if the IMPORTS rules are taken
to be the same as in ASN.1 except for those areas that are specifically
mentioned.  This is probably the easiest for parser implementors, or
implementors of tools that resolve references at runtime, to deal with;
but also adds an extra chore (manually resolving to an absolute OID) for
the module author.

2. Another might be that absolute and relative OIDs are allowed, but there
must be at least two components (ie., no disambiguating imports via the
descriptors of the MODULE-IDENTITYs in question).  This would seem to be
the appropriate interpretation if you take the IMPORTS rules in the same
light as 1, since 'DefinedValue' is not one of the forms listed in the
'ObjectIdentifierValue' production in the ASN.1 specs.  This is probably
the easiest for a module author to work with, but more difficult for tools
that resolve references at runtime (whether a compiler or an NMS) to
implement, though still possible.

3. Another interpretation might be that any item whose value resolves to
an 'ObjectIdentifierValue' can be used in places where the
'ObjectIdentifierValue' production is used.  This is probably the easiest
for module authors to work with, but the most difficult to resolve at
runtime.  The problem of resolving references is likely equivalent to 2,
but there is added complexity in the need to refactor several of the
productions in order to resolve conflicts in an LALR(1) type parser.

Personally, I subscribe to #2 but support #3 (mostly) for flexibility.

--
Michael Kirkham
www.muonics.com