+1
On 1/11/07, Andreas Sewe <[EMAIL PROTECTED]> wrote:
Sylvain Hellegouarch wrote: > Hugh Winkler wrote: >> The draft makes no mention of file extensions. >> >> 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). > > 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. The OP has a (different) point, though: Recommending distinct file extensions for "application/atom+xml; type=entry" and application/atom+xml; type=feed" is worthwhile. If, e.g., the mime.types shipped with Apache already contains appropriate entries, this would aid the fast adoption of the new, parameterized "application/atom+xml". Hence it would be worthwhile to include file extension recommendations in the I-D. Regards, Andreas
