I agree with Neil that there is too much overloading of the Content-Type
field, at least as far as the top level goes. I have argued this with
Nathaniel for some time; this is perhaps the last matter of disagreement left
between us. He has reduced the number of Content-Types greatly to placate me,
but I think that SUN has hit it on the head; Content-Type is doing too much.
I too have noted that there is no real difference between audio, video,
image, and binary.
Instead of a separate Content-Class, I would rather have a hierarchy from
class to specifics using the subtype mechanism. However, I could live with
Content-Class as long as it is mandatory (= no inferences of the Content-Class
from the Content-Type). Since it's hard to do such a thing, I prefer the
hierarchy alternate. My suggestion of hierarchy:
TEXTUAL => TEXT, TEXT-PLUS, MESSAGE => subtype
MULTIPART
APPLICATION
DATA => AUDIO, IMAGE, VIDEO, BINARY => subtype
I also feel that there may be reason in the future to have further
levels, so I want to allow multiple subtypes.
I therefore want to change the BNF for Content-Type to be
ctype := "Content-Type" ":" class ["/" type *["/" subtype]] *[";" parameter]
class := "TEXTUAL" / "MULTIPART" / "APPLICATION" / "DATA"
type := "TEXT" / "TEXT-PLUS" / "MESSAGE" / "AUDIO" / "IMAGE" / "VIDEO" /
"BINARY" / "X-" token
subtype := token
parameter := token / quoted-string
token := 1*<any CHAR except SPACE, CTLs, and tspecials>
tspecial := "(" / ")" "<" / ">" / "@" / "," / ";" / ":" / "/" / "\" / <"> /
"[" / "]"
The reason for token is that there is a show-stopper here by the way that
we can't use "/" as the hierarchy delimiter without changing the definition of
the type and subtype(s). Right now they are local-part, which can include "/"
as a valid character (look at the BNF in RFC-822). While I was at it, I
removed "." from the list of tspecials, so it is possible to have token be
something like an atom. This is desirable so that we don't have things like:
foo."bar".zap
I agree with Neil that reference to "compressed" should be nuked from the
content transfer encoding.
If Neil is agreeable to retiring the Content-Description field, I'll
second it.
I believe that Content-Size should be retired. What we have now is a
wretched compromise which really isn't much good for anybody. Don't give me
the "efficiency" argument; "efficiency" is the enemy of reliability. What may
be "efficient" inside SUN is an UTTER DISASTER in the outside world. I don't
want to pick on SUN specifically since most other vendors of equally guilty of
inflicting their internal "efficiencies" upon customers who must then go to
great lengths to undo them.
The only valid reason I see for keeping Content-Size around is as a
validity check of the pre-encoded data. For this reason, if Content-Size is
kept around I propose retiring "LINES" and "ENCODED". As I have repeatedly
pointed out in past "what is a line?" messages, there is no reversible
transform between Internet lines and Unix lines. I also propose retiring BITS
as it is of marginal utility and in its place adding a new field which does
what is actually needed: the number of bits per byte.
Therefore:
csize := "Content-Size" ":" 1*DIGIT [ "/" 1*DIGIT]
The first number is the number of bytes in the original text and the second
digit is the number of bits per byte, the default being 8.
I can also deal with Content-Size being retired entirely.
The function that Neil proposes for Content-Size should be permanently
relegated to an X-mumble field, to emphasize expressly that it is NOT
supported outside of a well-controlled playground.
We can NOT be mealy-mouthed here. I understand perfectly well what SUN
and PRIME want, and I sympathize completely. But!! they MUST accept that it
can NOT work reliably in the general catanet, where body munging is a sad fact
of life. BY ALL MEANS, they should not feel as if we are constraining them
from using it internally. There is a perfectly good mechanism, the X-mumble
header lines, for doing this. We simply can not bless it for the outside
world, and we should encourage these vendors in the STRONGEST POSSIBLE TERMS
to NOT use it in customer released software.
-- Mark --