Re: feed id's and paged/archive feeds
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/
Fwd: I-D ACTION:draft-nottingham-atompub-feed-history-08.txt
Based on feedback on-list and off, this draft: 1) Explicitly state that semantics of feeds with more than one type aren't defined by this specfiication 2) Added language about duplicate entries in archived feeds, effectively moving the algorithm in the appendix into prose in that section 3) Lower-cased the SHOULD requirement that as many relations as possible should be present 4) Strengthened statements about paged feeds being lossy 5) Moved RSS2 examples to appendix to make them more obviously non- normative Diff at: http://www.mnot.net/drafts/draft-nottingham-atompub-feed-history-08- from-7.diff.html Begin forwarded message: From: [EMAIL PROTECTED] Date: 26 November 2006 12:50:01 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-nottingham-atompub-feed-history-08.txt Reply-To: [EMAIL PROTECTED] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Feed Paging and Archiving Author(s) : M. Nottingham Filename: draft-nottingham-atompub-feed-history-08.txt Pages : 17 Date: 2006-11-26 This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- history-08.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-nottingham-atompub-feed-history-08.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-nottingham-atompub-feed-history-08.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. Content-Type: text/plain Content-ID: [EMAIL PROTECTED] ___ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -- Mark Nottingham http://www.mnot.net/
Re: feed id's and paged/archive feeds
Mark Nottingham wrote: [snip] I think they do, although the draft is silent on it. [snip] Good enough for me. Also, the latest draft looks good to me. Ship it! Thanks Mark. - James
Re: Author element best practice
-1. The current spec is fine as is. It currently does not say anything about whether or not the post entry MUST be valid although that is, indeed the spirit of the spec. The spec does not say that servers MUST reject entries that are not valid. Servers are free to accept or reject entries as they see fit. No change is necessary. - James Sylvain Hellegouarch wrote: Tim Bray wrote: On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote: Say I POST an atom:entry to a collection URI, this entry does not have an atom:author If I were implementing the server, in this scenario I'd reject the post with an error message. It's hard for me to see a scenario where the author info isn't already known and not providing it is still OK. (In fact, it's hard for me to imagine a scenario in which the author info isn't already known, period.) -Tim Right. If we stretch this idea a little then, how would people feel about stating in the draft that the server MAY (SHOULD?) reject an Atom entry which would be invalid as per RFC 4287 ? I think at least a MAY would give some weigh to implementors who wish to be really strict regarding the input the allow. - Sylvain
Re: autodiscovery draft vs namespaces
Kornel, thanks for the input. In the next rev of the draft (following the initial reboot that should publish in a day or so) I'll see what I can do to clarifying some of these issues. As always, suggested spec text is helpful and encouraged. I will do my best to incorporate all editorial changes. - James Kornel Lesinski wrote: I've noticed that draft-ietf-atompub-autodiscovery-01.txt doesn't mention XML namespaces and tag prefixes. XHTML can get even more complex than memo suggests: foo:link xmlns:foo=http://www.w3.org/1999/xhtml; rel=alternate type=application/atom+xml href=bar/foo:link My suggestion is that instead of specifying all quirks of X[HT]ML syntax: * require that XML parser is used for XHTML * if document turns out not to be well-formed (which often is the case with real-world XHTML), allow HTML parsing rules used as fallback And then simply state that in XHTML link element in http://www.w3.org/1999/xhtml; namespace should be used. An example XPath expression or W3C DOM-based pseudocode might be very helpful there. BTW: in all examples attributes have always the same order. They could be shuffled to emphasise that order is not significant. --regards, Kornel Lesiński
Re: Author element best practice
James M Snell wrote: -1. The current spec is fine as is. It currently does not say anything about whether or not the post entry MUST be valid although that is, indeed the spirit of the spec. The spec does not say that servers MUST reject entries that are not valid. Servers are free to accept or reject entries as they see fit. No change is necessary. Well of course if you go from a MAY to a MUST... Anyway, I agree with most comments until now that it is not a mandatory step to add to the spec. 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. - Sylvain
