On 12/13/06, Sylvain Hellegouarch <[EMAIL PROTECTED]> wrote:
> Consider GData apps. Their docs aren't clear (tsk, tsk!) about the
> use of a media type when inserting entries[1], but if they're doing it
> properly then their services should be keying off of
> "application/atom+xml", and so will break if that's changed.
>
And? Should a status quo be better on the long term?
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.
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. What he is saying is correct and this will break our
existing implementation (and any other current server impl that validates
Content-type headers). More details below.
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.
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.
Returning a 415 error code seems like the wrong option since the
media-type is perfectly valid. So what should servers do? Should they
pick-up randomly one of the entries part of the feed? How should UA deal
with the returned message?
>
>> So I'm for James' option B)
>> application/atom-entry+xml
>
> I'm -1 on that, but +1 on the type parameter.
>
I'm still +1 on the new media-type and +0.5 on the parameter type option.
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.
Cheers!
-- Kyle
[1] - http://www.w3.org/2001/tag/doc/mime-respect.html
[1] - http://www.imc.org/atom-syntax/mail-archive/msg19384.html
