Uh, has Mark spotted a dumb bug here that we should fix? Do we care
if *remote* content is of a composite MIME type? My feeling was that
we ruled out composite types in *local* content, for fairly obvious
reasons. The fix is obvious, in 4.1.3.1
"Failing that, it MUST be a MIME media type. If the "src" attribute
is not provided, i.e. the content is local, the value of the "type"
attribute MUST NOT be a composite type... "
-Tim
On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:
<atom:content type="message/rfc822"
src="http://www.example.org/lists/list/archive/12345"/>
Unfortunately, that's bad Atom. Section 4.1.3.1 of the format spec
says;
On the atom:content element, the value of the "type" attribute
MAY be
one of "text", "html", or "xhtml". Failing that, it MUST be a MIME
media type, but MUST NOT be a composite type (see Section 4.2.6 of
[MIMEREG]). If the type attribute is not provided, Atom Processors
MUST behave as though it were present with a value of "text".
where "composite type" is defined to be multipart/* and message/*. If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the "src" attribute to include the data by reference rather than by
value.
