I don't see where the consensus was by the way. And I never saw any
vote on the
issue. Like most issues one gets the impression that Atom is run on
some pretense
democracy. Some people have made up their minds for god knows what
reason, and others
are just here to follow. The more we chatter on
Henry Story wrote:
So I call for a real open vote on the issue.
You don't need to call for a vote, just ask the chairs/editors who keep
track of such matters, about the particular specification.
If you can point out to me my recollection of the consensus on that
issue is incorrect, then do so.
On 19 Apr 2005, at 18:27, Bill de hÓra wrote:
Henry Story wrote:
So I call for a real open vote on the issue.
You don't need to call for a vote, just ask the chairs/editors who
keep track of such matters, about the particular specification.
Well we need some objective way to tell what the
Henry Story wrote:
I don't see where the consensus was by the way. And I never saw any
vote on the issue. Like most issues one gets the impression that Atom
is run on some pretense democracy.
There is no voting in the IETF. Please read the beginners' documentation
found on ietf.org. Here's a
I'm in favour of allowing duplicate ids when the source-id is different
to simplify creating merged feeds, which would allow the client to
figure out what to do. Under any other circumstance, definitely not.
Graham
Ok. I am sorry. I thought I had made a really good case for a simple
argument to allow
multiple entries with the same id in a feed, and thought it had in fact
made it into the spec.
I then discovered that it still had not.
I cleazrly just have no idea how one goes around convincing this group
Just to end on a positive note, I'll +1 this suggestion by Graham.
Henry
On 19 Apr 2005, at 18:30, Graham wrote:
I'm in favour of allowing duplicate ids when the source-id is
different to simplify creating merged feeds, which would allow the
client to figure out what to do. Under any other
Bill de hÓra wrote:
I'm going to think about it some more but atm I'm not sure what you're
proposing helps against DOS.
My proposal says that things are considered the same only if found
in the same feed. This is, I believe, the only way to prevent someone from
maliciously erasing
:[EMAIL PROTECTED]
On Behalf Of Graham
Sent: Tuesday, April 19, 2005 12:30 PM
To: Henry Story
Cc: atom-syntax Syntax'
Subject: Re: call for a vote - was: One reason we have duplicates entries is
that we have duplicate feeds...
I'm in favour of allowing duplicate ids when the source-id is different
Regarding the potential for a DoS attack with stealing somebody else's
GUIDs, no special hacks [1] are needed. Any decent aggregator would
trust IDs with a grain of salt.
* If the IDs of two entries from different feeds are the same **and
the data is the same** show it in only one feed.
* If the
...only about subsets/supersets and duplicates...
Antone Roundy wrote:
@rel=subset-of
@rel=superset?
We've already got a way to handle aggregations from multiple sources.
Do we want to allow people to choose to just use a secondary-to
link to express that relationship rather than
...back in town, and ready to express opinions...
Thomas Broyer wrote:
Bob Wyman wrote:
Robert Sayre wrote:
You can point to an alternate feed like this
link rel=alternate type=some/feed href=... /
Of course, you can't have two alternates with the same media type...
Yes, you can point to an
As many are aware, the Tim Bray[1] and others have recently been
railing on the subject of duplicate entries being delivered by aggregation
services and/or search engines like PubSub, Technorati, Feedster, etc. As
unexpected as this may sound, I am quite confident that when Atom V1.0 is
Bob Wyman wrote:
Unfortunately, while RSS and Atom
both contain mechanisms to identify their HTML alternates, there isn't any
clear mechanism available to discover alternate feeds.
Without responding to the rest of the message, I'll note that this
statement is somewhat inaccurate wrt Atom. You
This seems similar to what exists in Really Simply Discoverability in the
individual api.../ element [1].
-
# api has 4 required attributes.
* preferred is a boolean and takes either true or false. The point is
to allow weblog software to list all the APIs supported, but choose which
PM
To: [EMAIL PROTECTED]
Cc: atom-syntax@imc.org
Subject: Re: One reason we have duplicates entries is that we have duplicate
feeds...
Bob Wyman wrote:
Unfortunately, while RSS and Atom
both contain mechanisms to identify their HTML alternates, there isn't
any
clear mechanism available
/ Bob Wyman [EMAIL PROTECTED] was heard to say:
| A major cause of duplicates in at least some of the existing
| services is the fact that bloggers insist on engaging in the apparently
| illogical and wasteful practice of publish multiple versions of their feeds
| and thus duplicates of
Bob Wyman wrote:
Robert Sayre wrote:
You can point to an alternate feed like this
link rel=alternate type=some/feed href=... /
Of course, you can't have two alternates with the same media type...
Yes, you can point to an alternate. However, all you are doing at
that point is establishing
Robert Sayre wrote:
Establishing equivalence only addresses a part of the problem.
Fully agree. I just wanted to point out that a part of the problem is
more solved than your post indicated.
My apologies if I made the situation sound more dire than it is.
However, even with the
On Apr 7, 2005, at 10:34 AM, Bob Wyman wrote:
Tim suggests that aggregators should be able to rely simply on
atom:id to detect duplicates. However, as has often been pointed out,
applying this rule in an intermediary like PubSub would simply make
PubSub a
marvelously efficient tool for denial of
I don't think this is within the scope of Atom or any other spec. If
you want to differentiate your others, why not invest some time in a
decent duplicate detection algorithm like Google did? This is your
problem.
Graham
On 7 Apr 2005, at 7:29 pm, Bob Wyman wrote:
Robert Sayre wrote:
Tim Bray wrote:
1. A new feed-level element atom:alt-uri-prefix, any number allowed.
E.g.
feed
linkhttp://www.tbray.org/ongoing//link
alt-uri-prefixhttp://www.tbray.org//alt-uri-prefix
alt-uri-prefixhttp://tbray.org//alt-uri-prefix
alt-uri-prefixhttp://www.textuality.com/alt-uri-prefix
Thomas Broyer wrote:
When PlanetBar and PlanetFoo republish a feed from Baz, they should
move the entry metadata into an atom:source element.
This is actually what we do at PubSub today. You may not be aware
that the atom:source element is modeled on the ps:source-feed element that
we
Thomas Broyer wrote:
Tim Bray wrote:
1. A new feed-level element atom:alt-uri-prefix, any number
allowed. E.g.
feed
linkhttp://www.tbray.org/ongoing//link
alt-uri-prefixhttp://www.tbray.org//alt-uri-prefix
alt-uri-prefixhttp://tbray.org//alt-uri-prefix
Tim Bray wrote:
Would the following work:
1. A new feed-level element atom:alt-uri-prefix, any number allowed.
feed
linkhttp://www.tbray.org/ongoing//link
alt-uri-prefixhttp://www.tbray.org//alt-uri-prefix
alt-uri-prefixhttp://tbray.org//alt-uri-prefix
I don't like this.
* Bob Wyman [EMAIL PROTECTED] [2005-04-07 22:40]:
A. Pagaltzis wrote:
But it breaks down for the aggregate feeds published by third
parties. If look at more convoluted examples, it fast turns
into web of trust territory...
You are correct -- with one caveat. If entries are signed,
Yes,
Bill de hÓra wrote:
Thomas Broyer wrote:
Bill de hÓra wrote:
Thomas Broyer wrote:
Although this doesn't solve the DOS potential, I'd rather go for a
new atom:source child element indicating the source feed's Id or
URI. When PlanetBar and PlanetFoo republish a feed from Baz, they
should move the
Thomas Broyer wrote in response to Bill de hÓra:
If an entry already has an atom:source child, you just republish
it as-is. [And, if it doesn't have an atom:source, you insert one.]
This is what was agreed, I believe, when the issue was discussed on
the list. To do anything more would
Bob Wyman wrote:
Thomas Broyer wrote in response to Bill de hÓra:
If an entry already has an atom:source child, you just republish
it as-is. [And, if it doesn't have an atom:source, you insert one.]
This is what was agreed, I believe, when the issue was discussed on
the list. To do anything more
On 8/4/05 6:17 AM, Bob Wyman [EMAIL PROTECTED] wrote:
A side benefit of having primary feeds would be that people would
be more likely to do things like include full category data in the entries
they publish rather than publishing entries into specialized feeds as the
way to indicate
On 8/4/05 6:17 AM, Bob Wyman [EMAIL PROTECTED] wrote:
The proposal I made relies on a feed making statements only about
itself. In my proposal, a feed can only say: I contain copies of these
other feeds. I am a secondary feed.
How does this prevent DOS attacks? If I could insert entries with
31 matches
Mail list logo
