Re: Only include implemented features in a draft standard

> I think I understand this now.

I think you're getting closer, but you're not there yet.

> What IETF requires for moving a standard to draft status is
> that interoperability can be shown for every single feature
> in the standard.

This is how it is done in the applications area. Other areas tend to do
things a little differently. In particular, listing all the features and
testing them one by one may or may not be required.

> There is however no requirement that interoperability can
> be shown for any combination of two or more features in
> the standard. Note that nested multiparts can be seen
> as "a combination of the feature multipart with the
> feature multipart" two or more times.

Basically, yes, because otherwise you have a combinatoric explosion that
is impossible to test.

However, in the specific case of nested multiparts, as it happens they were
tested quite extensively before MIME moved to draft. I don't recall if they
were called out as something we had to test, but I can assure you that we had
no problem finding clients that were able to generate them and receiving agents
capable of handling such things, and we used those agents in our tests. Indeed,
the only problem I recall was that one of the agents I used in my testing -- an
X.400 gateway -- produced nested message structures in X.400 that seriously
pissed some X.400 service provider and got me into trouble.

And in actual practice multipart messages with very deep nestings often occur,
sometimes intentionally, other times as a result of certain sorts of
configuration errors. I've received messages nested several thousand levels
deep more than once. The usual error situation, in case you care, is a DSN
bounce loop that employs multipart/report.

> Also, if a standard says that a certain requirement is
> only valid for receipt, not for what is produced, then
> interoperability is not required for this particular
> feature (since interoperability testing cannot be done
> on a requirement which is only valid for receipt,
> interoperability testing requires that there is software
> to both receive and produce the tested feature).

This, I'm afraid, is totally incorrect. You are persisting in doing what you've
done from the start of this discussion -- confuse the MIME conformance
requirements with general IETF standards track interoperability requirements.
These are separate things. One applies to implementations, the other to the
MIME standard.

It was felt at the time MIME was developed that something more than the usual
interoperability testing we'd get as the document advanced was needed. In
particular, it was felt that without a set of requirements as to how MIME
messages would be handled after reception by user agents, we would end up with
things that interoperated perfectly in the sense that they were able to
generate and receive arbitrary MIME objects, but they still wouldn't handle
them in a way that was useful to an end user.

We resolved this issue by inventing the concept of MIME conformance. These
requirements spell out what we felt was minimally necessary for MIME to
actually be a useful thing to a message recipient rather than a large mess.

In retrospect we should have also carried this concept over to specifying
sending conformance requirements, but for none of the reasons you have given
here. The problem with the lack of specification of sender conformance has been
that there have been cases where user agent developers have implemented
reasonably full MIME support  on reception but continued to generate some
nonstandard format. Such an implementation can be claimed to be MIME
conformant.

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.

				Ned

Received on Friday, 16 June 2000 23:06:30 UTC