Hugh Winkler wrote: > > The draft makes no mention of file extensions. > > "Atom Feed and Entry Documents can have different processing models > and there are situations where they need to be differentiated." > > It would be good to enumerate some of those situations, and to examine > whether processing software depending on file extensions also requires > such differentiation. If ithe processing model is different enough to > require distinction in the mime type, it's important enough to require > distinction in the file system where mime types usually are forgotten. > > Server software responsible for inserting correct Content-type header > can *possibly* set the correct value when serving a file, if the > type="entry" and type="feed" documents have distinct file extensions. > (I think this server behavior is an accident of implementation, > because I've never encountered a mime type parameter in any > "mime.types" file or in the Windows registry). > > Client software receiving a file similarly consults a mime types > registry. I do not think any client software today would correctly be > able to save the file with the correct file extension, because it > would have had to have been programmed to parse all the parameters > (including possible parameters to be defined in the future). If the > client software has this entry in its registry: > > application/atom+xml; type="entry" > > and receives a file with this header: > > Content-type: application/atom+xml; type="entry" > or this > Content-type: application/atom+xml; gdatakind="event"; type="entry" > > there's little chance existing client software will assign the correct > file extension to the saved file. > > On the other hand, if the draft assigned a new mime type to denote > entries, all existing processing software on server and client side > would correctly map content-type to file extension. > > Hugh >
Fair point but it has been extensively discussed in a previous thread and it appears that few people were keen on adding an entirely new media type. While the type parameter may not be ideal it seemed to be lest disruptive. I personally agree that a new media type would enforce the correct and native distinction between entry and feed but most people who have participated didn't feel like there was such a string requirement. - Sylvain
