[Top] [All Lists]

Re: New Disposition type: Inline Subordinate

2007-11-05 13:05:13

Hello 'email people'

RFC 2183 defines two basic disposition types, i.e. "inline" and "attachment".
But sometimes we need a more elaborate presentation than the existing 
types. For example, the current advertisement way in Email or Webpage is very
"evil", sometimes it is difficult for the users to distinguish the real 
from advertisement, and this is disgusting or confusing. Nowadays many email
service providers insert advertisements in the user's email. The inserted
advertisements normally are displayed at the end of the email, but sometimes 
boundary between advertisements and other real contents is not clear. So that
the recipient may be misunderstanding, the advertisements might be regarded as
the real contents the sender writes.

However, advertisement is absolutely necessary for the development of internet
and mobile applications. In order not to interfere with users much, the 
for sending advertisement kindly is needed. Email, MMS, IM and SIP messages 
use MIME as their content body, the advertisement could also be inserted into
the message body as a MIME content. Maybe a new disposition type can be 
to help users distinguish the advertisement and the real contents. Its 
is like this:

A bodypart should be marked "inline-subordinate" if it is intended to be
displayed automatically upon display of the message, but it should not block
other displayed bodyparts, e.g., bodyparts with a regular "inline" disposition
type. It is RECOMMENDED that the client render the content marked by
inline-subordinate in a separate place away from other inline contents.


OK, let's start with this notion that "advertising is absolutely necessary for
the development of internet and mobile applications". I have big problems with
this assertion, but even if I accept it as a given, it doesn't necessarily
follow that the right way to do ads is to insert them into the messages people
send as separate MIME objects. The obvious alternative is for ads to be
displayed locally by the client. Of course this doesn't provide a advertiser
with a way of getting their crap^H^H^H^Huseful and informative material in
front of the eyes of remote recipients who are pahing for their email some
other way and have no association with the service inserting the ads, but I'm a
long way from convinced that's a model we should encourage in any way, shape,
or form.

That said, having a way to tag some material in a message as requiring some
degree of separation from other material when displayed makes a certain amount
of sense. However, this specific case really isn't subordinate to the other
material in the mesage. Rather, it's a separate, secondary object. A name like
"inline-secondary" would be better IMO.

Naming aside, I'm also not convinced that defining a new disposition type for
this is the right approach. For one thing, new types won't be properly handled
by existing software and it is unlikely that handling for unknown types will
default to inline in all cases. Perhaps it would be better to make  this a
parameter. Existing implementations should simply ignore unknown parameters. So
I guess if this is going to be done I'd like to see it as a new parameter of
some sort. 

Indeed, were it not for the installed base issue it seems pretty clear to me
that this really should be handled by defining a new multipart subtype.