W3C home > Mailing lists > Public > ietf-discuss@w3.org > August 2002

Interpretation of "two independent implementations"

From: Jacob Palme <jpalme@dsv.su.se>
Date: Thu, 22 Aug 2002 12:00:17 +0200
Message-Id: <p0510033cb98986414401@[]>
To: discuss@apps.ietf.org
Cc: tina-hek@dsv.su.se

Two master's students at my university is working on
testing whether MHTML would be eligible for promotion from
"proposed standard" to "draft standard".

An important issue is then what is meant by two
independent, co-working implementations. To take an extreme

MIME allows the Content-Type Multipart/alternative to
contain body parts which themselves are Multipart/
alternative, and it is thus possible to recursively include
Multipart/alternative inside Multipart/ alternative to
arbitrary depth.

Suppose then that testing of existing e-mail software
demonstrates, that there are no two independent
implementations, which are able to interoperate in handling
of Multipart/alternative nested to a higher level than,
say, 17. Must then the MIME standard, in order to become a
draft standard, say that Multipart/alternative-nesting must
be limited to 17, since this is the only functionality
which two independent implementations can inter- operate

In this extreme example, I am sure that everyone would say
that such an arbitrary nesting level should not have to be
put into a standard. But there are other less obvious
cases. As regards MHTML, the following are examples:

If no two interworking implemantions allow use of MHTML to
send a set of several linked web pages in one e-mail,
should then MHTML, if moved to draft, have to specify that
this is not allowed?

If no two interworking imlementations allow sending of HTML
messages which include a style sheet in a separate file,
must then the standard specify that this is not allowed?

The MHTML-standard says that its methodology might also be
used when sending XML or VRML, not only HTML. Must this be
removed if no such interoperable implementations are found?

The MHTML-standard contains clauses on how illegal URLs
(for example URLs containing the space character) can be
sent. Must this be removed if there are no existing
implementations that actually can send messages with URLs
containg spaces?
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
Received on Thursday, 22 August 2002 06:31:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:15 UTC