On Sat, Jun 18, 2005 at 10:43:36PM -0600, Antone Roundy wrote: > > Not all user-agents have a "MIME processor". Given the potential > complexity and messiness of composite types, I'm opposed to leaving the > door open for them, since they won't, I think, be needed by a > significant proportion of Atom users. This brings back bad memories of
But is it really necessary to FORBID using Atom for purposes that might entail using these media types? What exactly is the prohibition trying to prevent? If it's trying to prohibit anything except what the most common Atom processors are likely to understand, then we should eliminate the ability to specify arbitrary media types entirely and stick with the most common Atom uses we've already specified. If it's trying to prevent compound documents of any kind, while still allowing flexibility in selecting an appropriate "single-part" media type based on the application, then it needs to do that better. Currently it forbids compound media types but allows other more widely used and less widely known methods for including compound objects into the content. If it's trying simply to prevent the use of one class of media types for reasons not mentioned above, then I think it would help everyone to have that reason documented. At this point, I'm with the other posters in that this seems like an artificial constraint in the absense of more meaningful verbiage. > losing data. Yes, that's just one anecdote. But it's an example of > the kinds of ugliness that can spill over from one bad implementation > and mess things up for everybody. Unless there's a use case that meets Perhaps a SHOULD-level requirement should be introduced to encourage implementers to avoid multipart types since they will be unlikely to be widely supported. Maybe this should be a SHOULD-level prohibition on using arbitrary media types entirely. People SHOULD stick with the text/html/xml pseudo-types we've explicitly defined unless they have a good reason to use something else. > to keep things a little simpler within Atom feeds. If somebody really > needs composite types, they can use an extension, and user-agent > developers can decide whether to support it. This seems a little much for an extension. Specification of a piece of content is pretty fundamental to Atom. If I have to do that through an extension of my own devising, I have to wonder what I'm gaining by starting with Atom in the first place. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
