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

Only include implemented features in a draft standard

From: Jacob Palme <jpalme@dsv.su.se>
Date: Tue, 13 Jun 2000 11:06:54 +0200
Message-Id: <v04210101b56abadd91d8@[]>
To: IETF Applications Area Discussion List <discuss@apps.ietf.org>
One of the major IETF rules is that a DRAFT STANDARD may
only contain features which have been implemented in two
implementations with an independent code base, and which
can co-work using the standard. This rule often causes the
number of features in a standard to be reduced, when the
standard progresses from PROPOSED STANDARD to DRAFT

Two students at Stockholm University have, as their
master's thesis, made a test of how some mail clients
support the MHTML standard (see
http://towards/jpalme/ietf/mhtml-test/intro.html ).
They have found that some features in MHTML are supported
by some implementations. But implementations often support
a feature of MHTML only in certain common simple ways.
Should a draft standard really describe such a feature in
its full, unlimited shape, even if no existing mail client
supports this? As a simple example (not taken from their
report), the MIME standard allows unlimited recursion
through multiparts of any kind inside multiparts of any
kind to any level. Suppose an investigation showed that
there were no two different implementations, who were able
to exchange data with more than three recursive
multipart-inside-multipart levels? Should then the draft
standard really say that the standard supports unlimited
recursion, when this might not be supported by any existing

These problems are especially large at the production
side. Even if an implementation is actually able to
receive and interpret complex format, it is often not
able to produce this format. And interoperability
testing requires, of course, both an agent which can
produce a format and an agent which can receive it.
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
Received on Tuesday, 13 June 2000 05:05:23 UTC

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