Registration of MIME media type MESSAGE/DISCLAIMER

Thu Mar 26 16:38:30 CET 2009

> Hi Bjorn,

> I did not read carefully then, though I'm in the process of writing a RFC, here goes the answers to you queries:

> A example message:

> Content-Type: Message/Disclaimer;
> Disclaiming-Domain= Microsoft.com; Disclaimer-Action: Prepend; Department-Identification= Finance;      boundary="--sample boundary"

> ----sample boundary
> Content-Type: multipart/mixed;             boundary="--first boundary"

> This is a multi-part message in MIME format.

> ----first boundary
> Content-Type: multipart/alternative;      boundary="--second boundary"

> ----second boundary
> Content-Type: text/plain;
>               charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable

> <the plain text disclaimer goes here>

> ----second boundary
> Content-Type: text/html;
>         charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable

> <HTML version of Disclaimer goes here along with CID for usage of Images as defined in RFC 2392>

> --second boundary--
> --first boundary--
> --sample boundary--

While I cautiously support defining a means to have identifiable disclaimer
text in messages, this is not the way to do it. For starters, this needs to be
under the multipart top-level type, not the message top-level type. Putting it
under message violates the MIME design principle that newly defined composite
structures must go under multipart so that existing MIME readers will be able
to process the ocntent without havingt to be modified.

Putting this under message also arguably violates at least one MIME
requirement, section 4.1 of RFC 4288, which forbids registration of types that
are a "collection of separate entities of another type".

Second, the structure you're using looks wrong to me. You have this:

    message/disclaimer
     multipart/mixed
      multipart/alternative

I suggest that this should instead be:

    multipart/disclaimer
     multipart/mixed
     multipart/alternative

More generally, multipart/disclaimer would be defined as a container with
two parts, the first containing the regular message content and the second
contains any disclaimers attached to the message content. Either or both 
of these parts can themselves be multiparts.

Another issue with all this is what you have here is a very general mechanism -
possibly too general. Do we really need the ability to have complex composite
disclaimer sections added to messages? Or would a simpler means of labelling a
single part as a disclaimer be sufficient?

The obvious simpler mechanism would be to define a content-disposition
value of "disclaimer".

One argument in favor of the simpler mechanism is that getting any of this
deployed at this late date is going to be quite difficult, and the simpler
the mechanism is the more likely people will be able to add support for it.

I personally have no strong feeling as to what's appropriate, but I do think
all the alternatives need to be considered.

> In simple terms, the disclaimer media subtype is intended to sanitize the
> handling of message disclaimer and avoid duplicates and organize them in a
> better way as advancements in Email clients and server demand in clear as
> well as rich messages, that catches the attention of the reader.

> Disclaimer content apart from its purpose/usage it is simply a extension of
> message body and has all the properties and norms of a message body.

No it doesn't. There's a difference between encapsulating an entire
message and encapsulating the content of a message. The former calls
for a message subtype, the latter does not.

				Ned