[Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
All: With Phil Rignalda's permission, I have taken over the role of editor for the Autodiscovery draft and at Lisa and Paul's suggestion I have resubmitted the draft as an **individual** submission (as opposed to a Working Group Draft). Phil has requested that his name be removed from the draft. The process for moving forward on this spec will be the same as with Atom and APP. Change proposals will need to be submitted in the form of Pace's on the wiki with a copy sent to atom-syntax. Pace's need to include spec ready text, when appropriate. When consensus emerges around a particular pace, it will get incorporated into the draft. Editorial changes need not go through this process; just post a note to the atom-syntax list and I'll make sure the change is made. - James Original Message A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Atom Feed Autodiscovery Author(s) : M. Pilgrim, J. Snell Filename: draft-snell-atompub-autodiscovery-00.txt Pages : 14 Date: 2006-11-27 This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the link element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-snell-atompub-autodiscovery-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-snell-atompub-autodiscovery-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Message/External-body; name="draft-snell-atompub-autodiscovery-00.txt": Unrecognized ___ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce
RE: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
Why is one of the normative references in draft draft-ietf-atompub-format-11 instead of RFC4287? Franklin Tse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Tuesday, November 28, 2006 00:53 To: atom-syntax; atom-protocol Subject: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt] All: With Phil Rignalda's permission, I have taken over the role of editor for the Autodiscovery draft and at Lisa and Paul's suggestion I have resubmitted the draft as an **individual** submission (as opposed to a Working Group Draft). Phil has requested that his name be removed from the draft. The process for moving forward on this spec will be the same as with Atom and APP. Change proposals will need to be submitted in the form of Pace's on the wiki with a copy sent to atom-syntax. Pace's need to include spec ready text, when appropriate. When consensus emerges around a particular pace, it will get incorporated into the draft. Editorial changes need not go through this process; just post a note to the atom-syntax list and I'll make sure the change is made. - James Original Message A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Atom Feed Autodiscovery Author(s) : M. Pilgrim, J. Snell Filename: draft-snell-atompub-autodiscovery-00.txt Pages : 14 Date: 2006-11-27 This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the link element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-snell-atompub-autodiscovery-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-snell-atompub-autodiscovery-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
Because I resubmitted the draft with no changes from its previous version. I intend to update references with the next iteration of the draft. - James Tse Shing Chi (Franklin/Whale) wrote: Why is one of the normative references in draft draft-ietf-atompub-format-11 instead of RFC4287? Franklin Tse [snip]
Re: feed id's and paged/archive feeds
Well, since you ask a leading question... I have a demo implementation of a client at: http://www.mnot.net/rss/history/ and my blog does the server side: http://www.mnot.net/blog/index.atom James Holderness has mentioned an implementation, and the Apache abdera people seem to be planning something, based on their repository. I know of other folks who are planning to integrate into products and services, but I can't disclose anything more (I'd encourage them to, of course). Anybody else? The issue we're discussing here, though, isn't about ambiguities in *this* spec, but rather in Atom itself; i.e., what does a feed ID really identify? Cheers, On 2006/11/27, at 11:06 AM, Ernest Prabhakar wrote: Hi Mark, Given all the ambiguities, are there any implementations available to test against in practice? Or even implementors planning to make the attempt? - Ernie P. On Nov 26, 2006, at 1:25 PM, Mark Nottingham wrote: Sorry, this got lost in my inbox... I think they do, although the draft is silent on it. This is one of those areas where it would have been really nice if the WG had agreed to take on FH as part of the core, rather than extension; there are lots of little ambiguities like this as a result. Cheers, On 2006/11/03, at 1:37 PM, James M Snell wrote: Mark, I cannot recall if I've asked you this in the past but... if I have a set of paged/archive feed documents all of which make up a single logical feed, do the atom:id's for each feed document have be the same? If not, how do I determine the atom:id of the logical feed? - James -- Mark Nottingham http://www.mnot.net/ -- Mark Nottingham http://www.mnot.net/
Re: Author element best practice
On Mon, 27 Nov 2006 08:39:41 +0100, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Mind you considering that RFC 4287 is very clear on what makes an Atom entry a valid one I imagine APP servers which don't have the necessary context will decide to reject the request altogether. Am I the only one pondering and worrying about what the different server implementations will respond to invalid client requests (as, for example, an invalid Atom document)? How can the client implementors be interoperable and compatible with each other and every server implementation if the specification says absolutely nothing about what to expect when something goes wrong? HTTP covers some of the possible errors one might encounter, but I believe there are several cases in APP where errors might occur that HTTP does not cover and that server implementors will treat very differently. In most server application frameworks, unhandled exceptions give the response 500 Server Error. Is that the appropriate response to give on most errors? Which errors should yield which 4xx response? Is this not an issue? How can a client tell the user how to correct something if the client have no idea what response to expect from the server? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: feed id's and paged/archive feeds
Mark Nottingham wrote: James Holderness has mentioned an implementation Snarfer added support for feed history a while back, so it doesn't recognise the new archive link relations that were added in recent versions. We probably will consider supporting them in a future release if there is significant adoption on the server side, but so far most of the major implementations I've encountered have been using one of the older variations, so we haven't had any incentive to change things yet. Regards James
Re: feed id's and paged/archive feeds
Abdera has basic support for the extension elements and the paging links (including prev-archive and next-archive). It does not yet include an implementation of the feed reconstruction algorithm but will shortly. The implementation is part of the optional extensions module. - James Mark Nottingham wrote: Well, since you ask a leading question... I have a demo implementation of a client at: http://www.mnot.net/rss/history/ and my blog does the server side: http://www.mnot.net/blog/index.atom James Holderness has mentioned an implementation, and the Apache abdera people seem to be planning something, based on their repository. I know of other folks who are planning to integrate into products and services, but I can't disclose anything more (I'd encourage them to, of course). Anybody else? The issue we're discussing here, though, isn't about ambiguities in *this* spec, but rather in Atom itself; i.e., what does a feed ID really identify? Cheers, [snip]
Re: feed id's and paged/archive feeds
Also, the MediaRSS module references it as a best practice. When I started working on it, there was interest from server-side folks as well (e.g., Six Apart); AFAIK they're just waiting for it to be finalised (it's taken a while). Cheers, On 2006/11/27, at 11:18 AM, Mark Nottingham wrote: Well, since you ask a leading question... I have a demo implementation of a client at: http://www.mnot.net/rss/history/ and my blog does the server side: http://www.mnot.net/blog/index.atom James Holderness has mentioned an implementation, and the Apache abdera people seem to be planning something, based on their repository. I know of other folks who are planning to integrate into products and services, but I can't disclose anything more (I'd encourage them to, of course). Anybody else? The issue we're discussing here, though, isn't about ambiguities in *this* spec, but rather in Atom itself; i.e., what does a feed ID really identify? Cheers, On 2006/11/27, at 11:06 AM, Ernest Prabhakar wrote: Hi Mark, Given all the ambiguities, are there any implementations available to test against in practice? Or even implementors planning to make the attempt? - Ernie P. On Nov 26, 2006, at 1:25 PM, Mark Nottingham wrote: Sorry, this got lost in my inbox... I think they do, although the draft is silent on it. This is one of those areas where it would have been really nice if the WG had agreed to take on FH as part of the core, rather than extension; there are lots of little ambiguities like this as a result. Cheers, On 2006/11/03, at 1:37 PM, James M Snell wrote: Mark, I cannot recall if I've asked you this in the past but... if I have a set of paged/archive feed documents all of which make up a single logical feed, do the atom:id's for each feed document have be the same? If not, how do I determine the atom:id of the logical feed? - James -- Mark Nottingham http://www.mnot.net/ -- Mark Nottingham http://www.mnot.net/ -- Mark Nottingham http://www.mnot.net/
Re: Author element best practice
* Asbjørn Ulsberg [EMAIL PROTECTED] [2006-11-27 20:55]: Am I the only one pondering and worrying about what the different server implementations will respond to invalid client requests (as, for example, an invalid Atom document)? How can the client implementors be interoperable and compatible with each other and every server implementation if the specification says absolutely nothing about what to expect when something goes wrong? HTTP covers some of the possible errors one might encounter, but I believe there are several cases in APP where errors might occur that HTTP does not cover and that server implementors will treat very differently. In most server application frameworks, unhandled exceptions give the response 500 Server Error. Is that the appropriate response to give on most errors? Which errors should yield which 4xx response? Is this not an issue? How can a client tell the user how to correct something if the client have no idea what response to expect from the server? I get your concern and to some extent I share it, but I’m unsure about how it could be addressed. If we assume that servers can implement wildly different feature sets and special cases, then there is a huge number of conditions which the server would need to be able to somehow signal. I don’t know how we can allow for that. A special error document XML vocabulary for those cases where the HTTP status is not granular enough would be an option. Some document making suggestions about what error status codes to use in which circumstances could also help unify expectations. But the scope of any such endeavour will be huge… Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
James M Snell wrote: The process for moving forward on this spec will be the same as with Atom and APP. No, it won't. It's not a WG document. Does the draft diverge from existing browser behavior? Do browsers implement aspects of the document differently? What problems have you seen that make standardization necessary? Without some evidence that the document serves a purpose, I'm afraid I don't see the point. - Rob P.S. -- the author affiliation information in the draft appears to be inaccurate.
Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
Robert Sayre wrote: James M Snell wrote: The process for moving forward on this spec will be the same as with Atom and APP. No, it won't. It's not a WG document. Ok, to be absolutely pedantic about it: the process will be as close as possible to that used for Atom/APP with the obvious exception that it is an individual submission and not a WG draft. Pace's to the wiki; discussion on the mailing list; Consensus calls will be posted periodically; I will be tallying the results; anyone can challenge if they feel the need; the entire process will be done out in the open. Does the draft diverge from existing browser behavior? Do browsers implement aspects of the document differently? What problems have you seen that make standardization necessary? I dunno... you're the one that that writes browser code, you tell me. You certainly seemed to think it was a good fit before. In fact, on January 19 of this year you posted [1]: I think the current draft reflects what implementations do pretty well Without some evidence that the document serves a purpose, I'm afraid I don't see the point. You seemed to think it served a purpose last January [2]. The only changes that have been made to the document since your post requesting that it be unexpired and finished is the expiration date and the name of the editor. Perhaps it's the latter change that has you wondering whether this suddenly may not be worth standardizing? [1] http://www.imc.org/atom-syntax/mail-archive/msg17716.html [2] http://www.imc.org/atom-syntax/mail-archive/msg17713.html - Rob P.S. -- the author affiliation information in the draft appears to be inaccurate. How so? Given that my volunteering to serve as the editor of this document has nothing to do with my day job it would be inappropriate and dishonest for me to associate my employers name with the work. - James
Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
James M Snell wrote: Consensus calls will be posted periodically; That's not a process I can live with. Maybe this draft would be a better fit for the WHAT-WG or the W3C. Does the draft diverge from existing browser behavior? Do browsers implement aspects of the document differently? What problems have you seen that make standardization necessary? I dunno... you're the one that that writes browser code, you tell me. I don't think it's a problem worth solving, absent any evidence to the contrary. Mozilla doesn't seem to get many bug reports on this matter. You certainly seemed to think it was a good fit before. I changed my mind later on. How so? Given that my volunteering to serve as the editor of this document has nothing to do with my day job it would be inappropriate and dishonest for me to associate my employers name with the work. We all participate in the IETF as individuals. Affiliations are a professional courtesy. -Rob
Re: Author element best practice
I personally just think it's way too early for us to really be able to say much about it. So far the APP implementations that have actually been deployed seem to work rather consistently in that I can get a single client (e.g. Abdera) to work with each with very little effort and only minor variations (e.g. different auth schemes, some require Content-Length on the post, others don't, some reject invalid entries, others don't, etc). Based on my experience thus far, I really don't think it is going to be much of a problem. - James Asbjørn Ulsberg wrote: [snip] Am I the only one pondering and worrying about what the different server implementations will respond to invalid client requests (as, for example, an invalid Atom document)? How can the client implementors be interoperable and compatible with each other and every server implementation if the specification says absolutely nothing about what to expect when something goes wrong? [snip]
