Re: Why is alternate link a MUST?
On Sun, Apr 03, 2005 at 04:13:55PM -0700, Tim Bray wrote: I think link rel=self is a SHOULD, to address auto-subscriptions, one of the current #1 RSS pain points, perceived by users as a failure to interoperate. -Tim +1 James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: Why is alternate link a MUST?
Eric Scheid wrote: On 4/4/05 1:32 PM, Paul Hoffman [EMAIL PROTECTED] wrote: Not to pick on Eric; others have said things along the lines of: no offence taken. This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels. I can't think of any MUST reasons for [EMAIL PROTECTED]'self'] or [EMAIL PROTECTED]'alternate']. Then let me try and help you with that. I can think of long nights tracking down data because I didn't have way to hand systems an identifier. In the Atom 06 format there are 3 things potentially acting as identifiers for the source of an Atom feed. The one that going by the commonsense name least likely to be considered a meaningful identifier is mandatory. Sorry to offend anyone in this WG, but that's absurd. Never mind that we're creating an arbitrary distinction between feed ids and entry ids. I have very strong opinions on this: too many identifiers cause problems when it comes to system and data management -worst scenario in terms of cost are too many unreliable identifiers. For a pure client/server newsreader case I can see how this might not bite so much. For anyone passing Atom along a processing chain or heaven forbid, something like a SEDA system, not having assured easy to find identifiers is a cost. Being able to rely on the presence of an (ideally, single) identifier is a management win and an interop win. It is one of the reasons Web based systems are easy to run. Not having such a thing for Atom feeds ensures people will have to invent it especially for non-HTTP scenarios. The upfront cost of mandating either self or id is so small versus the benefit of being able to shout out something's name when something goes awry I can't believe we're even having this discussion. Anyway I've made my position clear at this point. Please make id or self mandatory. [Please don't argue on the basis that URL links aren't identifiers or names and shouldn't be treated as such; it's de jure Web architecture that they are.] cheers Bill
Re: Why is alternate link a MUST?
On 4/4/05 10:04 PM, Bill de hÓra [EMAIL PROTECTED] wrote: -1: the reasons against @self MUST are similar to the reasons against @alternate MUST. I don't understand. How are these alike? one reason against @rel='self' is that the feed may not be retrievable at all (being delivered some other way) one reason against @rel='alternate' is that there may not be any web retrievable resource. e.
Re: Why is alternate link a MUST?
On 4 Apr 2005, at 4:32 am, Paul Hoffman wrote: This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels. Right: 1. Feed level ids. By all reasonable web conventions, requesting a feed from a particular URI can be expected to only ever return one particular feed resource. Whereas, the request will also return an essentially random combination of entry resources. Entry ids are a MUST because of the latter, which doesn't apply to feeds. A separate feature of entry or feed ids is comparison and duplicate-removal across URIs. Since many users/implementers may choose not to do this due to concerns over security and potentially unexpected-behaviour, it can be described as truly optional functionality, which makes it MAY. 2. Link rel=self Subscribing to feeds is a fundamental feature, and since the whole purpose of self is to make it simple and reliable, this element is not optional, and it's reasonable to say it must be present. But I can think of a few edge cases where the service generating the XML may not know its eventual URI, and of course there may be circumstances where there isn't one. This is the only reason I can think of to omit it. Since SHOULD allows implementers to wimp out for any reason they choose, I think the appropriate wording is MUST where one exists and is known. 3. Link rel=alternate Sorry Sam, but this is truly optional as per MAY. Being able to click back to the home page is nice, but how is it an absolute requirement? Graham
PaceFeedIdOrAlternate
http://www.intertwingly.net/wiki/pie/PaceFeedIdOrAlternate Background: there seems to be some feeling that *something* should be required. Opinions vary from id should be a MUST to id is at best a MAY. While there are use cases for feeds without alternate html representations, I've been concerned that they are such outliers that the would be mostly ignored by the predominant feed producers; with the inevitable result that such feeds would be poorly handled and would therefore reflect poorly on both the authors of such feeds and the feed format itself. As this issue keeps coming up, this concern is lessening for me. Notes: this pace was written in such a way to minimize the amount of change to the existing document. It does not express a preference between the two elements. Upgrading one or both elements to a SHOULD would require a separate Pace. Upgrading the Self link to a SHOULD or MUST would require a separate Pace. - Sam Ruby
Re: Why is alternate link a MUST?
On Sunday, April 3, 2005, at 11:05 AM, Brett Lindsley wrote: Consider a feed returned as a result of a search operation (e.g. a time range). To create an alternate representation of this resource, the link must also specify the same conditions that resulted in the search results. That is, the alternate link needs to somehow embed the search conditions of the search that created the feed so the server can provide an alternate representation. One way to fix this would be to indicate in the protocol spec that the same http headers must be provided to the alternate link as those used to request the feed. If we want the link to point to something that's strictly an alternative representation of the same data, then that makes sense, but it seems to me that the link is pointing to another view into the same data stream, which could be different in more ways than just the data format. For example, following the alternate link may get you a homepage containing entries that were added after you downloaded the feed. In that case, the homepage is certainly not an alternative representation of the same data. Just as the feed or homepage contents may be different depending on when you access them, I think our definition of alternate is loose enough to allow differences based on HTTP headers.
Re: PaceFeedIdOrAlternate
I think requiring either atom:id or atom:[EMAIL PROTECTED]self] would make more sense. It's entirely conceivable that multiple feeds might exist that claim to be alternates of the same resource--for example, a full content feed vs. a summary feed; a scraped feed vs. an official feed (...in which case, the scraped feed might be a copyright violation, but that's a separate matter); a feed of the tech news entries in a blog vs. a feed of the personal entries in the same blog; etc. Requiring id or self would ensure that consumers had a somewhat reliable value to use as an identifier for each feed. Alternate, on the other hand, may not be useful as an identifier, so it really doesn't fill the same space as id, and thus it doesn't make sense to me to use those two as alternatives for filling a feed requirement. Antone On Monday, April 4, 2005, at 09:01 AM, Sam Ruby wrote: http://www.intertwingly.net/wiki/pie/PaceFeedIdOrAlternate Background: there seems to be some feeling that *something* should be required. Opinions vary from id should be a MUST to id is at best a MAY. While there are use cases for feeds without alternate html representations, I've been concerned that they are such outliers that the would be mostly ignored by the predominant feed producers; with the inevitable result that such feeds would be poorly handled and would therefore reflect poorly on both the authors of such feeds and the feed format itself. As this issue keeps coming up, this concern is lessening for me. Notes: this pace was written in such a way to minimize the amount of change to the existing document. It does not express a preference between the two elements. Upgrading one or both elements to a SHOULD would require a separate Pace. Upgrading the Self link to a SHOULD or MUST would require a separate Pace. - Sam Ruby
Re: Why is alternate link a MUST?
Antone Roundy wrote: On Monday, April 4, 2005, at 09:43 AM, Robert Sayre wrote: I can't believe people want to put these out on the open Internet without an alternate. It seems to me that the reasons for having alternate links in feeds are almost entirely based on the context in which feeds originally emerged. This isn't a good time for conjecture. I don't think any of the arguments in favor have considered the support burden such feeds will create. OTOH, the absolute worst thing to do right now would be to sit around and argue this for a week. I'm very opposed to getting inventive and making this a MAY. I'm not changing my mind, but the group will probably just define it over my objection. Happens all the time :) Robert Sayre
Re: Why is alternate link a MUST?
On Mon, Apr 04, 2005 at 11:43:38AM -0400, Robert Sayre wrote: We get to design our protocol, and we know the type of software that will be consuming a large part of the traffic. All of that software expects a feed-level link. There are use cases where that's awkward, but I can't believe people want to put these out on the open Internet without an alternate. Depends what you mean by the open Internet: what about password-protected web products? Also, there's an implication here that we don't care about making life hard for denizens of the closed Internet, giving them the choice between abusing Atom and choosing something entirely different. I have yet to hear a reason to make alternate a MUST that is compelling. That existing software (which by definition can't be an IETF Atom client) expects a link to ... some kind of HTML ... doesn't cut it for me, not least because the current atom-syntax spec doesn't require a link to some kind of HTML at all anyway. At the end of the day, I don't think it's possible to make the question is X an alternate version of Y anything other than a subjective call. As such, I don't see the value of making it a MUST - forcing to export their opinions isn't /always/ the purpose of a blog format :-) James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
PaceFeedIdOrSelf
http://www.intertwingly.net/wiki/pie/PaceFeedIdOrSelf Note that this proposal makes alternate a SHOULD, not a MAY. This is to say that if you've got an alternate, you SHOULD link to it. I don't particularly care whether that's SHOULD or MAY. === Abstract Require either a self link or an id as children of atom:feed elements. Don't require an alternate link. Rationale * From PaceFeedIdOrAlternate: A number of use cases (e.g., [WWW]subversion change logs and [WWW]email attachments) have been defined in which there is no alternate html representation. * Lacking an atom:id, the self link is the most reliable data to use as an identifier for a feed, making it a better alternative to atom:id than an alternate link. * Feeds may be the only type of internet resource that routinely have an alternate representation. While this convention arose naturally during the emergence of feed formats, no strong argument has been found for requiring this unique situation. Proposal In section 4.1.1 of atompub-format-06, change this: * atom:feed elements MUST contain at least one atom:link element with a relation of alternate. To this: * atom:feed elements SHOULD contain at least one atom:link element with a relation of alternate. And add this bullet point: * atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of self. Impacts Tools which expect feed level links (such as [WWW]Bloglines) will need to be prepared for the absense of this information.
Re: Why is alternate link a MUST?
On 4 Apr 2005, at 6:02 pm, Robert Sayre wrote: This isn't a good time for conjecture. I don't think any of the arguments in favor have considered the support burden such feeds will create. Basically none. I have no clue why you're raising this objection given all the other functionality we're adding or replacing. Links now being optional is right at the bottom of the list of changes people will have to make. Graham
Re: Why is alternate link a MUST?
Eric Scheid wrote: On 4/4/05 10:25 PM, Bill de hÓra [EMAIL PROTECTED] wrote: Anyway I've made my position clear at this point. Please make id or self mandatory. atom:id then, since atom:[EMAIL PROTECTED]'self'] could change at any point in time, and mutability is not a good attribute of an identifier. Yes, your other post convinced me that atom:[EMAIL PROTECTED]'self'] needs to be optional. cheers Bill
I-D ACTION:draft-ietf-atompub-format-07.txt
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 Atom Syndication Format Author(s) : M. Nottingham, R. Sayre Filename: draft-ietf-atompub-format-07.txt Pages : 50 Date: 2005-4-4 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.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-ietf-atompub-format-07.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-ietf-atompub-format-07.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. ftp://ftp.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt
Re: I-D ACTION:draft-ietf-atompub-format-07.txt
Some other URIs for this I-D: http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html http://atompub.org/2005/04/04/draft-ietf-atompub-format-07-from-6.diff.html Robert Sayre [EMAIL PROTECTED] wrote: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt
Re: PaceFeedIdOrSelf
Antone Roundy wrote: ... Proposal In section 4.1.1 of atompub-format-06, change this: * atom:feed elements MUST contain at least one atom:link element with a relation of alternate. To this: * atom:feed elements SHOULD contain at least one atom:link element with a relation of alternate. +1 (I just checked my two test feeds; one of which doesn't have an alternate version so currently I have to lie). And add this bullet point: * atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of self. Fine with me as well. ... Best regards, Julian
