Re: Scope of application/* media types (was: Protocol changes in draft-allbery-usefor-usepro-00)

[Ned Freed <[e-mail]>]

> > > I can't think of an example of how application/news-groupinfo could be
> > > dangerous.  It's nothing but a bit of text giving a newsgroup name and a
> > > description.  In and of itself, it has no force, power, or action
> > > whatsoever.

> > Application types are intended to cause applications to be invoked, with
> > possible side effects.

> Could you provide a reference for this?  I don't see this statement in RFC
> 2046.

That's likely because the invokation of applications is an implementation
artefact rather than a core feature of MIME. In particular, some (but by no
means all) handle different media types through an application dispatch
mechanism. RFC 1343 even defines a specific format to use for such information
- the so-called mailcap format. This is, however, an informational RFC, not a
standard, and not only is there no requirement that such a mechanism be used,
lots of implementations don't work this way.

> The closest that it has is:

>    The "application" media type is to be used for discrete data which do
>    not fit in any of the other categories, and particularly for data to
>    be processed by some type of application program.  This is
>    information which must be processed by an application before it is
>    viewable or usable by a user.

> "To be processed" is far from saying that reception of an application type
> will cause an application to be invoked.  application/octet-stream is an
> obvious counter-example to this interpretation.

Right. Furthermore, there's nothing that says video, image, audio, message or
model types are exempt from processing and the generation of side effects. For
that matter, it may be reasonable in some cases to handle text types by
dispatching to an external application, e.g., in a voice mail system.

> Our case falls into the general scope ("discrete data which do not fit in
> any of the other categories") but not fully into the specific one ("data
> to be processed by some type of application program").  Our media types
> are actually text/* types; the only reason why they're not declared as
> such is because text/* comes with baggage involving CTEs that we can't
> accept.  Declaring them as application/* is in essence a hack around the
> MIME object structure, although unfortunately a necessary one.

Yes, and while there have been various proposals to define an additional
top-level type or types to deal with the baggage associated with text, none of
them have received much support so far.

				Ned