Re: Only include implemented features in a draft standard

At 08.05 -0400 0-06-15, Keith Moore wrote:
>> 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 is then, obviously, an interoperability and not a
stress issue.

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?

> there are certainly MIME implementations that can produce more than
> 4 levels of multipart nestings, and there are MIME implementations
> that can parse more than 4 levels of multipart nestings.
>
> p.s. I'm a bit puzzled by your choice of this particular issue.

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.

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. 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. Does this mean that we should write in
the standard that Multipart/alternative and Content-
Location cannot be combined? Or that we should wait with
moving MHTML to draft until there are two interoperable
systems which can handle this combination?
-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Received on Thursday, 15 June 2000 14:42:19 UTC