- From: Jacob Palme <jpalme@dsv.su.se>
- Date: Tue, 13 Jun 2000 11:06:54 +0200
- 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 STANDARD. 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 implementations? 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