W3C home > Mailing lists > Public > www-tag@w3.org > October 2010

mime-web-info 6.1 feedback

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Mon, 4 Oct 2010 14:17:11 -0600
To: www-tag@w3.org
Message-Id: <20101004141711.66159aff.eric@bisonsystems.net>
Overall, +1 to [1].  I support all the points raised in 6.1, except
this one:

"ask the 'applications that use this type' section to be clearer about
whether the file type is suitable for embedding (plug-in) or as a
separate document with auto-launch (MIME handler), or should always be
donwloaded."

This crosses the line from declaring the sender's intended processing,
to dictating user agent configuration.  The user agent gets to decide
whether to extract a tarball in memory and write the results to disk,
vs. write a tarball to disk for later extraction, for example.

It may seem OK to dictate that a tarball be saved, but sender intent
stops at declaring the codec, not how that codec is implemented nor when
it may be engaged.  Only the user, via interaction or configuration,
gets to dictate to the user agent how it should handle a media type
(render vs. launch vs. save, i.e. engage the codec somehow, or save the
stream).  In Opera, there's a handy right-click menu for links, which
allows the user to dictate handling to the agent without knowledge of
the media type.  Suggest:

"ask the 'applications that use this type' section to be clearer about
how each application handles the media type, whether the representation
is treated as embedded (plug-in), as a separate document with auto-
launch (MIME handler), or is always downloaded."

There's nothing wrong with discussing typical usage patterns for the
media type, only specifying them, or using language which implies that
usage patterns even can be specified by a media type.

-Eric

[1] http://www.ietf.org/id/draft-masinter-mime-web-info-00.txt
Received on Monday, 4 October 2010 20:18:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:28 GMT