- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Mon, 4 Oct 2010 14:17:11 -0600
- To: www-tag@w3.org
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 UTC