Re: Only include implemented features in a draft standard

> At 19.32 -0700 0-06-16, <ned.freed@innosoft.com> wrote:
> > But the presence or absence of conformance requirements doesn't affect
> > the interoperability requirements needed to advance the standard in any
> > way, shape, or form. In order to advance MIME individual features had to
> > be tested one by one, which we did.

> This is almost what I wrote. The only difference, is that
> you are saying that what is labelled as "conformance
> requirement" and which is specified only for receipt, is by
> that labelling exempt from the inter-operability
> requirement.

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.

Suppose, for example, a protocol came long that said an implementation can
claim to be conformant even if it implements absolutely none of the protocol.
By your logic this would completely remove any need for interoperability
testing for advancement along the standards track. But this isn't what would
happen: What would happen is that we'd still make the list of protocol features
and make sure each of them interoperated between multiple implementations.

I cannot say what the IESG looked at when advancing MIME to draft, but I can
tell you that we implementors basically paid no attention at all to MIME
conformance when we did the interoperability testing for MIME moving to draft
standard. We made a list of protocol features and checked to make sure they
worked across multiple implementations. (Actually, truth be told, we did
sufficient testing for MIME to move to draft even before it came out as
proposed.)  And speaking for myself, I don't plan on treating other
protocols any differently. If there's a feature in the protocol specification
it needs to be tested for interoperability, never mind what it means
to be conformant.

> So if a standards writer wants to put into his standard
> a requirement which is only for receipt, and which thus
> cannot be interoperapility tested (since such testing
> requires both production and receipt) then the standards
> writer must label this requirement as a "conformance
> requirement" in order to be allowed to progress it to
> draft status without interoperability testing.

No, you have it exactly backwards. A specification of, say, what sorts of
display options a client should have is by definition not a specification of
a feature of a protocol. As such, it is simply wrong to call it an interoperability
requirement.

Now, I suppose it is possible that someone could get careless in a
specification and end up with a protocol feature being defined in a section
called "requirements for conformance". But that certainly isn't true in MIME:
We even went so far as to put the specification of what it means to have a
conforming MIME agent in a document totally separate from the MIME protocol
specification.

				Ned

Received on Saturday, 17 June 2000 12:39:44 UTC