Re: Only include implemented features in a draft standard

At 09.19 -0700 0-06-17, <ned.freed@innosoft.com> wrote:
> You keep coming back to this notion that a conformance
> specification can somehow defeat the interoperability
> requirements. This just isn't true. A protocol can say
> what it likes about what it means for an implementation to
> be conformant. But this has no effect on interoperability 
> requirements at all.

I am just trying to understand the IETF rules for moving a
standard from proposed to draft status.

I do understand that the base requirement is still, that
moving a standard from proposed to draft requires that
there are two implementations based on different code base
which can interoperate using every feature in the standard.

And I do now understand that this rule is only valid for
every single feature, not for any combination of features,
and not for an arbitrary number of recursive application of
the same feature.

But I still have the impression that there are exemptions
from this, that there are certain things you can say in a
standards document which is exempt from the
interoperability requirement. But I do not quite understand
which features are exempt in this way.

In particular, how can a standard ever specify a
requirement only for receipt, if all requirements must be
interoperability tested? Surely interoperability testing
requires that systems can both receive and generate a
certain format?

For example, the drums msgfmt document has a list of things
you should be able to receive but should not generate (the
obsoleted features section). How can the contents of that
section be interoperability tested? Exactly why is such a
section allowed, even though it cannot be interoperability
tested? Is it because the section is labelled "obsolete",
because the section is labelled "for receipt only" or why?

At 23.18 -0700 0-06-17, <ned.freed@innosoft.com> wrote:
> Take ICMP as an example from an entirely different area.
> ICMP defines a bunch of different sorts of messages, quite
> a few of which are only used in very specific
> circumstances. There are lots of agents that generate ICMP
> packets that have no need to ever generate certain sorts
> of ICMP messages. It it then appropriate to claim that
> these features of ICMP don't interoperate merely because
> some agents cannot produce them? I think not.

The interoperability requirement is not for all
implementations, only for two different implementations
based on a different code base. So my understanding is that
there must be at least two different ICMP implementations
which can send and receive every single ICMP message, and
which can interoperate when handling this message, but it
is not necessarily required that every implementation can
handle every ICMP message, not even that there are two
implementations which can handle all the ICMP messages in
just those two implementations.
-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Received on Sunday, 18 June 2000 06:13:51 UTC