Re: Only include implemented features in a draft standard

At 17.11 -0400 0-06-13, Keith Moore wrote:
> 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"? 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.

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?

But there may be some MIME client which actually can
generate abritrarily complex multipart structures. I have
not tested them all.
-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Received on Wednesday, 14 June 2000 12:57:30 UTC