John Panzer wrote:
If I recall, I believe this is because some people wanted to be
able to package multiple pieces of content together in a single
entry, and other people did not want to have to imply a
requirement for MIME multipart parsing as pat of the Atom
format specification.
Ugh. Sometimes I just don't get these decisions. Since when does allowing
something imply that it is REQUIRED? Following that reasoning, any MIME type
that isn't expressly forbidden is now REQUIRED to be supported.
Of course that's insane. Implementers will decide which MIME types to
support based on market needs, as has always been the case (cf. email
clients and newsreaders). With Atom, however, composite MIME types have been
(quite unnecessarily IMO) excluded from their list of choices.
A. Pagaltzis wrote:
The right thing, I *think*, would have been for Atom Format to
say that an Atom processor MAY decode envelopes (translation:
don’t hold your breath), and for Atom Protocol to say the server
MUST NOT decode envelopes (translation: if I ship a
message/rfc822 payload, the server simply stores it as such).
Agreed. If you're worried about an implied requirement you can always add a
warning: "Feed producers should be aware that Atom Processors may not
process all such types. In particular an Atom Processor is not required to
process composite types." Or something to that effect.
That way you've explicitly covered your ass while leaving the format open to
the needs of the market. If a feed producer decided they absolutely had to
use a composite type in the atom:content, a non-supporting processor could
still fallback to the summary (since that is REQUIRED when the type isn't
text or xml).
IMHO.
Regards
James
