Appears that way. +1 to making composite types in remote content legal.
Another question while we're discussing this part of the spec (stemming
from the XML Enc discussion): currently there appears to be no language
about what should happen if an Atom processor encounters a content media
type that it doesn't understand. Should it ignore the content? Does it
report an error? Should it try to process the content somehow (e.g.
defer to some external processor)?
Tim Bray wrote:
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.
