On Tue, 22 Oct 91 18:49:39 -0700, Marshall Rose wrote:
Did you really mean
Content-Type := type *["/" subtype] *[";" attribute "=" value]
or did you mean:
Content-Type := type ["/" subtype] *[";" attribute "=" value]
i.e., did you mean 0 or more subtypes, or 0 or 1 subtypes?
If the former, boo-hiss on you. If the latter, fine.
Well, I guess it's boo-hiss on me.
You don't let me sneak anything by you, do you? ;-)
OK, here's why I propose 0 or more subtypes. However, I'm much more concerned
about the consolidation of the parameter syntax. If multiple-subtypes meets
with unshakable hostility, that part can be dropped. The idea is that typing
can be a hierarchy, so that a fancy version of an extant type can be subtyped,
with the idea being that a UA that only knows about the extant type can ignore
the extra subtyping and still do something reasonable, albeit not as fancy.
For example, consider this strawman:
Content-Type: AUDIO/SOUND/X-NEXT
Content-Type: AUDIO/SOUND/X-SUN
(I forget what you wanted to call this, I'll use SOUND as a fill-in). The
claim in both cases is that it satisfies the standard for SOUND. The X-mumble
here is simply an indication that this was a sound file made on a NeXT (or a
SUN) if there is any question of interpretation, this should resolve it. Or,
if there is some extra stuff in there beyond what is specified in the SOUND
definition, this would say what that stuff (which can otherwise be ignored).
It can, and would, be ignored by anyone who doesn't care.
Again, let me emphasize that this is just an off-the-cuff idea laid out here
to allow for a little bit more flexibility. What I want to avoid over
everything is the present situation where I have to recognize zillions of
different but essentially equivalent AUDIO subtypes. This applies to other
things as well.
What's really important is the consolidation of parameter. This would make it
possible to create a much better standard representation of bodies than is
currently available. It makes it much easier to parse the Content-Type
header, and eliminates the kludgy syntax for MULTIPART at a very minor cost.
Please give it serious consideration.
-- Mark --