Re: Only include implemented features in a draft standard

> > > If you did not check this, how can then the
> > > standard include a paragraph like the one quoted above,
> > > since the statement requires any level of multipart nesting,
> > > but since this has not been interoperability tested?

> > you appear to be confusing interoperability tests with conformance or
> > stress tests. conformance / stress tests can sometimes be useful but
> > we're not required to do them in order to advance a document.

> I do not understand this. If a system is designed so that
> it cannot produce deep levels of multipart nestings, then
> no interoperability can be demonstrated for such nestings.

This would only be true if it was the case that there was no system anywhere
capable of producing deep levels of multipart nestings. And this is not
the case.

Were we to insist that as a condition of interoperability testing all systems
be able to produce all possible protocol features, then most of the protocols
we have would have to be removed from the standards track.

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.

> This is then, obviously, an interoperability and not a
> stress issue.

Nope, it is nothing of the sort.

> Conformance would be if you test whether a single system
> can receive and correctly handle any kind of manually
> constructed complex MIME multipart nestings. But since IETF
> requires *interoperability* and not *conformance*, such a
> test would not be acceptable as a basis for writing in the
> standard that any level of nesting should be supported. So
> the statements in the MIME standard that ANY level of
> multipart nesting should be supported is *not* supported by
> *interoperability* tests. Should such a statement then be
> in a DRAFT STANDARD, if IETF requires that a DRAFT STANDARD
> should only describes features which work in
> *interoperability* tests?

I've already pointed out that deeply nested multiparts are frequently generated
*in* *practice* and have been shown to interoperate, not once but over and over
and over again.

> Sorry, maybe my example was not well chosen. It chose this
> example because it is such a basic feature of MIME, which I
> believe everyone agrees should be there, that you should
> support multipart nesting to any level. But maybe my
> example was wrong, in that there actually are two
> independent implmentations which can produce arbitrarily
> deep nestings.

There are dozens of such implementations. Indeed, it hard to write a
MIME-compliant user agent that can't generate them. (They call it forwarding
with a cover note...)

> The reason I am raising these issues is the issue of whether
> we should start a process of moving the MHTML standard from
> proposed to draft. The testings made by two students show
> that all the systems tested were only able to produce some
> very simple combinations of use of MHTML, and that no system
> was able to generate more complex combinations.

I'm sorry, but I'm very skeptical of this claim. Perhaps they were unable
to produce such things as a result of a single, simple, obvious operation. But
I'll bet that very complex objects indeed can be produced if they work at
it a bit.

< And what I
> am wondering if is this should mean that we should change
> the MHTML standard, when moving to draft, by describing the
> simple combinations which systems actually do generate, and
> say that the standard only applies to these simple combina-
> tions. For example, the students found that systems are able
> to receive and generate Content-Location, and are able to
> receive and generate Multipart/alternative with HTML in one
> branch and plain text in the other branch. But no two systems
> seems to be able to receive and generate a combination of
> these two features.

Now you are no longer talking about individual protocol features, you are
instead talking about combination of features. Trying to elaborate every
possible combination isn't required, and should not be.

I also have to again say I'm skeptical of this claim that such things cannot be
produced. Maybe I'm missing something here, but why can't you first create a
multipart/related with some program that likes to produce such things, and then
have another agent that does downgrade/alternative packaging produce the outer
multipart/alternative wrapper? I know for a fact that agents of the latter type
exist (I wrote one), and you've already asserted that there is no shortage of
agents of the former type.

> Does this mean that we should write in
> the standard that Multipart/alternative and Content-
> Location cannot be combined?

No.

> Or that we should wait with
> moving MHTML to draft until there are two interoperable
> systems which can handle this combination?

No.

				Ned

Received on Sunday, 18 June 2000 02:42:38 UTC