Re: should guidelines say something about NOT using IMPLIED?

[Andy Bierman <abierman@cisco.com>]

At 12:04 PM 2/6/2003 -0800, C. M. Heard wrote:
>On Thu, 6 Feb 2003, Randy Presuhn wrote:
>> IMPLIED does *NOT* put strings in alphabetical order, at
>> least not for any language I can think of.  For example, IMPLIED
>> produces this ordering:
>> 
>>    Apple
>>    Zebra
>>    aardvark

or
      Aardvark
      Apple
      Zebra

It is case-sensitive, but alphabetical.  Without IMPLIED,
the length byte forces all the strings to be alphabetized 
but primarily sorted by length.

>> 
>> In other languages the results are even more contrary to
>> human expectations, so "alphabetical order" is *not*
>> one of the benefits of using IMPLIED.
>
>Fair enough.  The question, however, is really this:  is
>IMPLIED evil enough to be NOT RECOMMENDED?  Or at least
>clearly not useful?  If that's true, it's not obvious to me,
>and I would like to be educated before I write down a rule
>against using it.  (A pointer to the appropriate mailing
>list where the issue has been discussed would be OK.)

The issue with IMPLIED is that it can only be applied to the
last component in an INDEX.  This limits future extensions.
It prevents the creation of any associated table that would 
extend the indexing scheme.  In practice, MIBs have defined
such an extension by removing the IMPLIED keyword in the
associated table.  This means an implementation cannot
reuse the code from the 'primary' table because the sort
order is different, and therefore data structures meant
to be extended are actually replicated.

In a hierarchical data model (such as SMI-DS) the IMPLIED
mechanism would severely limit the reusability and nesting
flexibility of the data structures that used it.


>Mike

Andy