Re: Some additional obscure questions...

["C. M. Heard" <heard@pobox.com>]

On Wed, 29 Jan 2003, Michael Kirkham wrote:
> 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.

I assume that what you mean by an "absolute OID" is an ObjectIdentifierValue
that has every component specified as a number, named number, or one of
the well-known names recognized by the SMI (i.e., ccitt, iso, and
joint-ccitt-iso) -- for instance something like { iso 3 6 1 2 1 10 }
or { iso org(3) dod(6) internet(1) mgmt(2) mib-2(1) transmission(10) }

> 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.

I assume that what you mean by a "relative OID" is an ObjectIdentifierValue
that has a leading part consisting of a DefinedValue followed by one or
more numbers or named numbers -- for instance { tranmsission 1 }

> 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.

It's also wrong, because ObjectIdentifierValue has to start with a
curly brace, as you noted above.

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

I think if you support #1 you have already gone beyond the call
of duty, and anything else is overkill.

_If_ ASN.1 rules for ModuleIdentifier apply to the IMPORTS statement
in a MIB module, then #2 is correct, subject to the proviso that the
ObjectIdentifierValue part of the ModuleIdentifier resolves to the
same value that appears in the MODULE-IDENTITY invocation of the
identified module (since the SMI specifically disallows an
ObjectIdentifierValue in between the modulereference and the
DEFINITIONS keyword).  While such usage is specifically allowed
MODULE and SUPPORTS clauses, it is a bit if a stretch to apply
it to the IMPORTS statement (as Randy has pointed out) in view of
the following words in Section 3.2, "IMPORTing Symbols":

   To reference an external object, the IMPORTS statement must be used
   to identify both the descriptor and the module in which the
   descriptor is defined, where the module is identified by its ASN.1
   module name.

So in practice users should expect to supply (and MIB parsers should be
expected to support) only the form of ModuleIdentifier that has only a
modulereference and no ObjectIdentifierValue.  The only reason ever to
supply ModuleIdentifier that consists of both a modulereference and
an ObjectIdentifierValue is when it is necessary to import from two
modules that have the same name.  And that is very rare.  For the few
times that this would be needed #1 is probably quite sufficient.

//cmh