Re: FW: [Entmib] Minutes from SF (fwd)

[Harald Tveit Alvestrand <harald@alvestrand.no>]

--On torsdag, april 24, 2003 10:25:02 -0400 Russ Housley 
<housley@vigilsec.com> wrote:

> Harald:
>
> > > > By the same logic, all the MAYs must be implemented or removed too.
> > > I think this is raising the bar above current practice.
> > You're probably right. But it still leaves the question of whether these
> > features are specified enough for interoperable implementations hanging.
> > Which is not a Good Thing.
> >
> > For one example of such features being tested:
> >
> > http://www.ietf.org/IESG/Implementations/http1.1-implementations.txt
> >
> > For instance, Accept-Ranges: is not a MUST or SHOULD feature.
> I think that both MUST and SHOULD requirements ought to be included in
> interoperability testing.  However, I think that MAY is going too far.
> Consider the following:
>
>          Implementations MUST support Triple-DES.
>          Implementations SHOULD support AES.
>          Implementations MAY support any other algorithms as well.
>
> I would like to see two implementations of Triple-DES and AES.  The rest
> is too open ended.
taking this a bit further...

let's say that some standard has a MUST support triple-DES, and has that 
properly specified.

It also has a MAY support DES, and assigns codepoint 5 to that. But somehow 
the spec never got around to defining whether it was DES in CBC mode or DES 
in ECB mode, and nobody has implemented it, so there's no codebase to refer 
to.

In that case, I'd claim that the specification of codepoint 5 doesn't meet 
the criteria for Draft; reserving 5 for "DES - to be specified" is OK, but 
keeping the ambiguous language in the document is not.

(ok, this example looks contrived. But if it's not implemented, we can't 
tell that it's properly specified.)

              Harald