Re: Only include implemented features in a draft standard

> At 16.58 -0400 0-06-14, Keith Moore wrote:
> >> In the example of complex MIME multipart structures, most
> >> implementations are not all all able to generate such
> >> structures. There is simply no command in the command
> >> structure of the mailer which the user can use to generate
> >> most complex multipart structures. It is not a problem of
> >> storage, but a problem of the design of the user interface.
> >> Should then such structures be part of the standard?
> >
> > no.  that would be adding a lot of complexity for little value.
> 
> The MIME standard is presently a DRAFT STANDARD. The MIME
> standard says (RFC 2046, section 5.1.2):
> 
>    It is essential that such entities be handled correctly when they are
>    themselves imbedded inside of another "multipart" structure.  MIME
>    implementations are therefore required to recognize outer level
>    boundary markers at ANY level of inner nesting.  It is not sufficient
>    to only check for the next expected marker or other terminating
>    condition.
> 
> Note that the above text in the MIME standard is specified
> as only for receipt by the words "MIME implementations are
> therefore required to recognize".  How can an IETF DRAFT
> STANDARD *ever* have a statement of that kind, with a
> requirement which is only for receipt?  Such requirements
> cannot be tested in interoperability tests, since these
> requires that some implementation can both send and
> receive. 

it's certainly true that not every protocol requirement can be 
tested by interoperability tests.   what we require is something
looser - that every protocol "feature" (where "feature" is
purposely ill-defined) be tested.  basically it's up to IESG
to decide whether the interoperability testing is adequate.

> Should it not then be forbidden for an IETF DRAFT
> STANDARD to contain any words which say that an
> implementation should do certain things at receipt, unless
> the standard also says that implementations must be able to
> generate the same structure. Is thus the above quoted
> paragraph from the MIME standard incorrect, since it
> specifies a requirement only for receipt?

no, it's correct.   some folks are indeed reluctant to put in 
requirements that are not testable on the wire, and this is sometimes
used as an argument for removing a requirement that someone thinks
is bogus.  but the truth is that we do impose such requirements from 
time to time, often for good reasons.

> When the MIME standard was advanced to DRAFT status, did you
> then check if any implementation could produce deep nestings
> of multiparts? 

no because we are doing interoperability tests, not conformance
tests.  we made sure that user agents could read multiparts sent
by other UAs - in particular that they could parse nested multiparts.   
we didn't attempt to test implementation limits, nor were we required 
to do so by IETF rules.

> 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.
 
> If no existing implementation can produce more than, say,
> 4 levels of multipart nestings, why, then, does not the MIME
> standard say that it is only valid for multipart nestings
> up to 4 levels deep?

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.

Keith

p.s. I'm a bit puzzled by your choice of this particular issue.

a MIME implementation that could only handle 0, 1, or 2 levels
of nesting would clearly be broken, as would a MIME implementation
that imposed a finite limit on the number of levels of nesting.
but a MIME implementation that can handle 2 levels and which does
not impose a finite limit can probably handle an arbitrary number
of levels (until it runs out of memory).

Received on Thursday, 15 June 2000 08:06:18 UTC