Re: Only include implemented features in a draft standard

We're going around in circles. I'm going to try one more time and then I'm
going to give up.

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

Of course. You can say lots of things in a specification besides
describing features of a protocol. The point is that such conformance
specifications aren't features of the protocol.

In the case of MIME, the conformance rules require certain things of a
receiving agent. But they do not specify any new features of the MIME protocol.
For example, the conformance rules specify that receivers must be able to
handle a certain subset of text/plain. But that isn't the specification of
text/plain. The specification of MIME's ability to have types in general, text
types in particular, subtypes in general, the plain subtype of text in
particular, have this information carried in a content-type field with a given
syntqx, etc. etc. etc. are all somewhere else. It isn't the conformance
section that defines these features of the protocol.

And if there was a mixup and the definition of some aspect of a
protocol was only done in a conformance section with limited
applicability, then that would not excuse that feature from meeting
the interoperability requirements.

> But I do not quite understand
> which features are exempt in this way.

None are.

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

Yes, but the key word here is systems. Your simplistic testing of a
single operations in a limited subset of generating agents don't
suffice to be able to assert that "such and such cannot be generated".

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

Now you're talking about a very different sort of beast: How to deal with
obsolete features of a protocol that are already part of a standard that is in
widespread use. This is a completely different scenario than a new protocol on
its way up, and what we're after here is the eventual removal of all this stuff
from the standard. The only question is how to handle this removal gracefully.

In the case of DRUMS a clean break from the past was clearly impossible so
certain concessions were made. Specifically, what we're doing is allowing
the obsolete feature subset to be generated by an existing, incompliant
installed base for purposes of interoperability testing.

This isn't to say that there aren't examples where all aspects of the obsolete
syntax haven't been generated. There are. I doubt we'll have any trouble
finding generated examples of every obsolete feature, no matter how we break
down the feature list. But as you say, these will by definition not have been
generated by compliant implementations. And yes, we're allowing a sort of
exemption in this case -- not in the sense of there being no generators, but
only in the sense that such generators are incompliant. But this is only
because we're dealing with a protocol that's already widely deployed with
features we'd like to get rid of and which simply removing from the standard
was not an option.

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

See above.

				Ned

Received on Sunday, 18 June 2000 11:45:37 UTC