Re: atom dates
* fschmidt [EMAIL PROTECTED] [2007-01-10 05:40]: I implemented an atom feed as specified in RFC 2487 using the updated date element. But the dates in my feed doesn't work in atom readers like Google Reader. The second sentence seems to be contradicting the first. Did you validate your feed? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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: I-D ACTION:draft-ietf-atompub-typeparam-00.txt
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 On 1/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The application/atom+xml Type Parameter Author(s) : J. Snell Filename: draft-ietf-atompub-typeparam-00.txt Pages : 6 Date: 2007-1-2 The Atom Syndication Format (RFC 4287) defines the 'application/ atom+xml' media type to identify both Atom Feed and Atom Entry Documents. This document defines an optional 'type' parameter used to differentiate the two types of Atom documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-typeparam-00.txt -- Hugh Winkler Wellstorm Development http://www.wellstorm.com/ +1 512 694 4795 mobile (preferred) +1 512 264 3998 office
Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt
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
