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
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-fo
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 id
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
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 ad
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 o
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
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 orig
This is very convincing to me.
Henry
On 4 Apr 2005, at 18:22, 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.
Feeds are the only kind of resource on the internet that I'm aware
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
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.
Feeds are the only kind of resource on the internet that I'm aware of
that routinely have alternate representations. Thinking about it from
that di
Paul Hoffman wrote:
At 11:59 PM -0400 4/3/05, Robert Sayre wrote:
If none of them are MUST, there is no social recourse when tracking
down problems or seeking social understanding. Where did this feed
come from? Who makes alternates? What's this all about?
Good, we're making progress.
Not really
How about a [EMAIL PROTECTED]"homepage"] for feeds that actually have a
home page to point to. By the same reasoning, [EMAIL PROTECTED]"alternate"]
would exist if the feed actually had an alternate representation. Both
of these would be MAY. This would be consistent with how the spec
currently tre
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 alte
On Sunday, April 3, 2005, at 05:16 PM, Robert Sayre wrote:
Tim Bray wrote:
Well, yeah, but when they do the half-hour's coding it's going to
cost them to start supporting Real IETF Atom 1.00 (tm), they can do
an extra 3 minutes and if there's no , they don't make the
subscription clickable.
I d
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 concern
On 4 Apr 2005, at 4:59 am, Robert Sayre wrote:
If none of them are MUST, there is no social recourse when tracking
down problems or seeking social understanding. Where did this feed
come from?
Well, things don't just appear, do they:
If it arrived over HTTP: You should know, you requested it. Fro
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 parti
At 11:59 PM -0400 4/3/05, Robert Sayre wrote:
If none of them are MUST, there is no social recourse when tracking
down problems or seeking social understanding. Where did this feed
come from? Who makes alternates? What's this all about?
Good, we're making progress. You're aiming at the "to limit
On Apr 3, 2005 11:59 PM, Robert Sayre <[EMAIL PROTECTED]> wrote:
>
> Paul Hoffman wrote:
>
> >
> > What is the technical reasons for the SHOULDs and MUSTs? Where is the
> > interoperability issues within the protocol (not with readers that don't
> > know what the protocol looks like)? What are t
I do think also that there are plenty of use cases suggesting that
alternate might not be always available. However in that context where
there's no feasible alternate, it would be extremely useful to know
you can count on atom:id. If not, what else can you rely on to track
your "content" as it fl
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
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.
e.
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 re
Eric Scheid wrote:
On 4/4/05 9:04 AM, "Bill de hÓra" <[EMAIL PROTECTED]> wrote:
Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or
atom:id is lifted to MUST. If either are lifted to must I'm 0 on
downgrading @alternate. At that stage @alternate doesn't matter a whole lot.
-1
On Sun, Apr 03, 2005 at 04:13:55PM -0700, Tim Bray wrote:
> I think 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
--
/---
26 matches
Mail list logo
