- From: Chris Lilley <chris@w3.org>
- Date: Mon, 14 Jul 2003 19:58:52 +0200
- To: Paul Prescod <paul@prescod.net>
- CC: WWW-Tag <www-tag@w3.org>
On Tuesday, July 8, 2003, 8:34:13 PM, Paul wrote: PP> Content-Type: application/octet-stream; name=foo.pdf PP> My Mac tries to dispatch this to the same application I used for PP> the last application/octet-stream. That's not very useful. Its not useful if the semantic of 'application/octet-stream' is 'unknown bag of bits'. It does, unfortunately, become useful iff people apply the semantic of 'this media type specifies that the content is saved to disk'. PP> Obviously the sending machine did not know the content type of the PP> data (they usually don't because Windows tends not to remember PP> content types). Was it right to send "application/octet-stream" or PP> should it have left the header out altogether? Its not clear that leaving out the header is allowed; its also possible to interpret that as 'misconfigured' rather than 'deliberately not saying'. PP> Should my Mac have interpreted "application/octet-stream" as "I PP> don't know what this is...you can guess if you want." Yes. PP> Somewhere we lost the information that nobody knows the content PP> type and that guessing or asking the user is better than treating PP> it as if it was well-known. I'm trying to determine who made the PP> mistake. The mistake is probably in the definition of application/octetstream, which I will need to re-read with a view to what it really says about the semantics. If application/octetstream is not suitable for this, it would seem preferable to invent a new type rather than just leave a blank. A positive assertion that 'the sending software is unable to assign a media type to this content' seems more robust than a negative, lack of a label. -- Chris mailto:chris@w3.org
Received on Monday, 14 July 2003 13:58:56 UTC