Hi Kyle,
> Hi Sylvain,
>
> Speaking as an implementer, we've shown ourselves quite willing to change
> the GData implementation to track the APP draft as it has evolved. The
> above response didn't come from me, and if you check the history of my
> messages on the Atom lists I think you'll find I've generally only cited
> the
> current GData implementation to inform the discussion, not to constrain
> it. It's important to Google that the right things be done for the long
> haul, too.
Agreed.
>
> This being said, Mark was responding to Tim's message that just changing
> the
> content-type for Atom entries was less likely to break existing
> implementations.
Funnily my comment was solely directed at Mark based on his own comment.
I'm sorry if things weren't clear enough. I didn't mean more than "what
do you mean Mark?".
>
>
>> Other server implementations should have the same issue, of course.
>>
>> So please explain me what a server currently does upon receiving an Atom
>> feed on a POST to a collection that only (app:)accept (atom:)entry(ies)?
>
>
> The GData server implementation requires a Content-Type value of
> "application/atom+xml" when POSTing or PUTting an Atom entry to a
> collection
> (for all non-media collections). It will respond with a 400 (Bad Request)
> http error on any other content type. It will also do the same if the
> request body contains an Atom feed document and not an Atom entry document.
Right and I find that abusive of the mime type already. An UA that
respects RFC 4287 and sends a feed to a collection that would state it
accepts such media-type would not understand why it gets a 400 Bad
Request (it's fairly interesting to point actually that because of that
umbrella mime type you could not use the proper 415).
>
> So without modification, the server would reject entries that use
> "application/atom.entry+xml". Even with modification, it likely still
> would need to accept requests that contain "application/atom+xml" due to
> propagation delays in clients conforming to whatever new convention is
> established. This would be contrary to the cited TAG finding [1], because
> such a server would no longer be considering the Content-Type header to be
> authoritative and would be peeking past it to the posted document. This
> seems bad. Having an ambiguous common base type ("application/atom+xml")
> and a more specific qualified type syntax ("application/atom+xml,
> type="entry|feed") avoid this ugliness and the Content-Type remains
> authoritative whether using the old or new syntax.
Agreed.
>
> It feels like we're just trying to avoid the pain of UAs having to learn
> about and use content-type qualifying attributes (like "type"). But as I
> noted in my previous message [2], I see this as inevitable if you think
> Atom
> is going to be extended in ways that might need to be UA visible, so all
> we're doing is delaying that pain (and letting more UA infrastructure be
> built up that will feel it) rather than setting ourselves on what I see as
> the right path for long-term growth. Using attributes enables evolution
> in directions that are not strictly hierarchical in nature, whereas
> continuing to evolve using only the base type/subtype does not.
>
> For that reason (mostly), I'm +1 on using "type" and -0.5 on using a new
> MIME type.
You make a good case regarding the evolution being less hierarchical.
The only thing I'd be afraid of however is that we try to put too much
semantic in the mime-type if we use the type parameter.
Thanks for your feedback.
- Sylvain
