The key problem I have with the ;type=param is that it's optional and likely to be ignored by a good number of implementations (which ends up buying us nothing in terms of interop). A separate media type is less ideal but has greater practical value in that it addresses the problem immediately.
- James Andreas Sewe wrote: > 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 > >
