W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

Re: Unknown content types

From: Chris Lilley <chris@w3.org>
Date: Mon, 14 Jul 2003 19:58:52 +0200
Message-ID: <75000961.20030714195852@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:59 UTC