Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt
+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
Re: Type parameter implementation
Sorry posting this message. I found a thread or two that gave me some clarity. I just added a type to my APP implementation, so maybe it will help to clarify the I-D. Thanks! Eric On 1/9/07, Eric Larson [EMAIL PROTECTED] wrote: Would someone mind posting a use case for this draft? I am not really sure I understand what it really does to make things easier for clients. Also, I apologize if this isn't the correct list for this question. Thanks! Eric On 1/9/07, James M Snell [EMAIL PROTECTED] wrote: I've added very preliminary support for it to Abdera. Nothing major, just a bit that detects the root node and outputs the media type according and a bit that checks to see if the media type specifically identifies an entry. Once we're a bit further down the path towards finalizing the spec, I'll add support to the server component for checking the type. - James Sylvain Hellegouarch wrote: Hi folks, Wth the first version of the type parameter draft [1] recently released by James, I was wondering if implementors had started implementing it either in their Atom consumer or APP server/client? Or is it to be considered too soon? - Sylvain [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-typeparam-00.txt
Re: Type parameter implementation
Would someone mind posting a use case for this draft? I am not really sure I understand what it really does to make things easier for clients. Also, I apologize if this isn't the correct list for this question. Thanks! Eric On 1/9/07, James M Snell [EMAIL PROTECTED] wrote: I've added very preliminary support for it to Abdera. Nothing major, just a bit that detects the root node and outputs the media type according and a bit that checks to see if the media type specifically identifies an entry. Once we're a bit further down the path towards finalizing the spec, I'll add support to the server component for checking the type. - James Sylvain Hellegouarch wrote: Hi folks, Wth the first version of the type parameter draft [1] recently released by James, I was wondering if implementors had started implementing it either in their Atom consumer or APP server/client? Or is it to be considered too soon? - Sylvain [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-typeparam-00.txt
