James M Snell wrote:
Actually, for the form "application/atom+xml;type=entry" it's more
likely that browsers will completely ignore the type param as they do
currently.
Well, if a browser ignores a media type's parameters, it will have to
face the consequences: In the case of "application/atom+xml;type=entry"
it would get "application/atom+xml" which means 'either an Atom Feed or
Entry Document'; if it cannot handle Atom Entry Documents without
breaking, it does not properly implement RFC 4287. But your point that
*current* browsers silent discard a "type" parameter on
"application/atom+xml" is moot anyway since the *current* Atom RFC
specifies no such parameter.
That being said, an *optional* type parameter offers the cleanest
solution to distinguishing between the following three cases:
1) Either an Atom Feed or Entry Document
2) An Atom Feed Document
3) An Atom Entry Document
If RFC 4287 had defined separate media types for the latter two cases,
we wouldn't have this problem, of course: "Accept:
application/atomfeed+xml, application/atomentry+xml" would cover the
first case just fine.
But since the RFC sadly doesn't I am extremely reluctant to either
deprecating the use of "application/atom+xml" for Atom Entry Documents
or to introducing three media types overall when an optional parameter
suffices.
So, James, what is wrong with "application/atom+xml;type=[entry|feed]"?
(A slim majority on this list seems to prefer it over defining separate
media types.)
Regards,
Andreas Sewe
