+1
Andreas Sewe 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
>
>
