W3C home > Mailing lists > Public > ietf-discuss@w3.org > June 2000

Re: Only include implemented features in a draft standard

From: Keith Moore <moore@cs.utk.edu>
Date: Wed, 14 Jun 2000 16:58:21 -0400
Message-Id: <200006142058.QAA11215@astro.cs.utk.edu>
To: Jacob Palme <jpalme@dsv.su.se>
cc: IETF Applications Area Discussion List <discuss@apps.ietf.org>
> > however the examples you cited are not the sort of things that one
> > usually discovers in interoperability tests.  most MUAs do have
> > some limitations on storage, for instance, so it is not reasonable
> > to expect an MUA to be able to handle an arbitrarily nested
> > MIME document, just as it is not reasonable to expect an MUA or message
> > store to handle a message of arbitrary size.  I'm not saying that
> > such limitations never cause problems, but I don't think the interoperability
> > test mechanism is a good means of detecting/preventing such problems.
> Do you by "interoperability test" mean "test if each application
> can handle what the other implementations generate"? 

yes, this is what the IETF interoperability tests require.

there is no requirement for implementations to undergo conformance testing or 
to pass any kind of stress test.  

this was a deliberate and carefully considered decision.  
conformance tests are expensive, and they don't tell you much about 
your ability to interoperate with other implementations..

> If so, you
> are including only what the different implementations are able
> to produce. And most implementations can only produce a small
> subset of what a standard allows. Our tests on MHTML implemen-
> tations show that existing mailers only use a small subset of
> very simple variants of usage of the MHTML standard.

the trick is to document those variants. then when MHTML goes
to DS, see if those variants are the only ones that have multiple

> 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.

Received on Wednesday, 14 June 2000 16:58:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:00 UTC