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
