At 1998-10-30 14:53, Keith Moore wrote:
My understanding of top-level types is that image, audio & video indicate
what the stream encodes, whereas text (and perhaps message) indicate how
the stream is encoded. For instance, 'text/vnd.abc' encodes audio, but is
encoded in text.
no, that's not how it's intended to work. for all cases, the top-level
content-type describes the underlying content, not the encoding.
the content-transfer-encoding field describes the encoding.
CTE is actually a whole separate encoding layer that I'm not even
considering at this point.
CTE encoding of octet-streams as other octet-streams is entirely
orthogonal to MIME encoding of images, audio, video, etc. as
octet-streams.
I tried to explain this formally in an earlier post. Here's an attempt to
explain my exegesis of RFC 2046 metaphorically. Think of it as a layer
cake:
----------Media----------
Content-Type
----------Octets---------
Content-Transfer-Encoding
----------Octets---------
MIME, Transport, etc.
'Content-Type' and 'Content-Transfer-Encoding' are layers of cake
representing protocols, lines with hyphens are layers of jam or frosting
representing data-types.
First of all, I'm only interested in the top 'Content-Type' layer:
----------Media----------
Content-Type
----------Octets---------
It's my contention that for text/* types, you can always slice this cake
halfway and insert 'text' jam between the two slices:
----------Media----------
text/whatever
----------Text-----------
charset
----------Octets---------
...but that the 'Media' frosting on top can be anything at all:
----------Audio----------
text/vnd.abc
----------Text-----------
charset
----------Octets---------
...whereas 'audio', 'image' and 'video' types describe the top layer of
frosting:
----------Audio----------
audio/aiff
----------Octets---------
Make sense?
--
Ashley Yakeley, Seattle WA