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: Tue, 13 Jun 2000 17:11:08 -0400
Message-Id: <200006132111.RAA00854@astro.cs.utk.edu>
To: Jacob Palme <jpalme@dsv.su.se>
cc: IETF Applications Area Discussion List <discuss@apps.ietf.org>

If at the time a document is a candidate to be advanced to Draft
(or perhaps Full) standard, it can be shown that the implementations 
which claim to implement a particular feature do so incompletely,
I think it would be reasonable to either wait before advancing the
document to Draft until fully featured implementations are produced 
or to amend the Draft Standard version of the specification to 
reflect the omission of the less-than-fully-implemented feature.
(depending on the nature of the feature).  in either case it might
make sense to amend the specification to more precisely specify
what is required of a conforming implementation.

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.

when such problems do occur, I do think that it would be worthwhile to 
document those problems and make suggestions for improvements - if
not in an RFC, then perhaps on an IETF web page.    I'd very much like
to see some sort of "implementors notes" document series be established
for such purposes.  

Received on Tuesday, 13 June 2000 17:11:35 UTC

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