Re: multipart/alternative extension

• From: Keith Moore <moore@cs.utk.edu>
• Date: Sun, 06 May 2001 18:04:49 -0400
• To: Jacob Palme <jpalme@dsv.su.se>
• cc: discuss@apps.ietf.org
• Message-Id: <200105062204.SAA19037@astro.cs.utk.edu>

> In general, if an existing feature is implemented badly, IETF
> prefers to use a new name for the new feature, in order to
> avoid clashes with old implementations. Examples of this is
> Errors-To:,
> Return-Receipt-To:,
> Read-Receipt-To:,
> X-Confirm-reading-to:,
> Return-Receipt-Requested,
> Register-Mail-Reply-Requested-By:

these aren't persuasive examples.  many of them shouldn't have been
in the message header in the first place - and those that were 
appropriate in the message header were never well defined.

in other words, the problem was not that the spec for these features
was poorly written or badly implemented - the problem was that the
spec was never written and/or never received any kind of public review
in the first place.

multipart/alternative is light-years ahead of any of these.

Keith

Received on Sunday, 6 May 2001 18:05:24 UTC