[
Lists Home |
Date Index |
Thread Index
]
Robin Berjon wrote:
> Say you have an "alternate encoding", be it PER, BiM, or CBXML
> (let's call it Foo), and you're sending an SVG document, which
> normally travels as image/svg+xml.
I propose that the MIME type name you should use in this case
would be:
image/svg+foo
i.e. you've got an abstract type "SVG" which is encoded or
serialized according to the "foo" rules. Just as normal practice today
means that image/svg+xml is abstract type "SVG" encoded using XML
rules.
Foo, BER, PER, CBXML, and XML are all concrete encodings.
Given that +xml made sense for XML and given that there isn't anything
conceptually special about XML as an encoding type, what works for XML
probably works for other encoding rules as well. A nice attribute of
this system, documented and justified in RFC-3023, is that it
distinguishes quite well between the abstract and the concrete
syntaxes. It is, I believe, vastly superior to requiring that a new
type (such as "image/svgfoo") be defined.
> with a Content-Encoding header of "foo" (as it is
> done with gzip)?
This is addressing a different problem... Here you have
"layered" encoding which would not be the case with an image/svg+foo
(i.e. SVG encoded as foo). The analog to this would be something like
a chunk of "image/svg+xml" which was simply wrapped in foo. This is
very different from SVG encoded using the foo rules.
bob wyman
|
