RE: Only include implemented features in a draft standard

> Two different implementations must be able to correctly parse obsolete
> messages.  Implementations should never generate those messages.  The
> easiest way to do the test (and hopefully every MUA vendor will do this) is
> simply to telnet to port 25 and feed in the obsolete message from the
> example.  Thus, the obsolete section would be interoperability tested if
> both implementations produced the same parsed message.  There is no
> requirement for interoperability on generation, and in fact, MUAs are
> required NOT to generate such messages.

And of course this again begs the question of what it means to have a generator
of a given protocol feature. As I pointed out before, while you may not
be able to get a set of GUI MUAs to generate deeply nested multiparts in
one go, such things do get generated quite regularly.

In the case of the obsolete stuff in DRUMS I would agree that this is
reasonable. Although I suppose that in the abstract sense we'd be better off
simply removing any obsolete feature that has never been used. But this amounts
to proving a negative about the installed base, which is impossible.

And as a practical matter, finding real examples of all the obsolete
stuff in DRUMS is likely going to prove to be depressingly easy.

But in the case of a new protocol, while the extreme situation of having
nothing but hand-created examples of a single isolated feature is probably
sufficient to meet the letter of the interoperability testing requirements, one
can argue that a feature that's demonstrably been shown to not be used other than in
testing isn't worth having and should probably be removed from the protocol.
But you're right in saying this isn't required for a move to draft.

There's also a slippery slope here should we start trying to figure out what
constitutes a legitimate "generator". For example, there are several
implementations of what you might call "MIME object generators" out there.
These are things that take one or more objects and put them in a MIME
structure. The ones I'm familiar with can be used to build basically arbitrary
MIME structures with only a few commands. Is such a thing a generator? Where do
we draw the line?

Personally, I draw the line by not worrying this issue on this basis at all.
When we move something from proposed to draft or from draft to full it makes
sense to review the list of features not only from the perspective of "does
this interoperate" but also from the perspective of "do we really need this".
The former is required by the process and if not met, of course justifies the
removal of a protocol feature. The latter isn't required but isn't prohibited
either, and can and has been used to remove unnecessary complexity from various
protocols.

And this is especially true of the move to full standard. A good example here
is multipart/parallel. There were several agents capable of sending and
receiving it back when MIME was moved to draft. But other, more powerful
constructs appear to have taken its place, and nobody bothers with it much any
more. 

This was pointed out back when MIME recycled at draft, and at the time I
pointed out that the requirements for moving to draft had been met in full, and
so it should stay in. I still believe this to be true for draft standard. But
what about moving to full standard? I'm not sure multipart/parallel meets the
requirements for full standard. Perhaps it should be moved to a separate,
informational document at this point, should we ever get to moving MIME to full
standard...

				Ned

Received on Sunday, 18 June 2000 12:32:49 UTC