MAIL PROTECTED] [mailto:[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 id
On Tuesday, April 19, 2005, at 12:59 PM, Bob Wyman wrote:
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 t
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 some
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 circum
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
o
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
At 6:12 PM +0200 4/19/05, Henry Story wrote:
I don't see where the consensus was by the way.
Correct. There was no consensus to remove the current wording.
And I never saw any vote on the
issue.
Correct: there was no voting, there was a consensus call. I'm not
sure how you could have missed it: P
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 goo
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 consens
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.
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
Bob Wyman wrote:
What if the two entries are both found in the same feed but have
different source feeds identified in their atom:source elements? These two
entries are clearly *from* different feeds, yet they might be found in a
single feed.
Not clearly; one or more of them might be misatt
Lenny Domnitser wrote:
> * If the IDs of two entries from different feeds are the same and the
> data is different, this can be one of two things: a DoS attack or an
> update to the entry. In either case, show the updated version without
> wiping out the old one.
What if the two entries a
Lenny Domnitser wrote:
> * If the IDs of two entries from different feeds are the same and the
> data is different, this can be one of two things: a DoS attack or an
> update to the entry. In either case, show the updated version without
> wiping out the old one.
What if the two entries ar
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 atom:sour
...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
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 poin
Doh! Seems I was very tired yesterday night...
Thomas Broyer wrote:
> [...] atom:source child element indicating the source feed's Id or URI
[...]
This already exists with atom:id and atom:link rel="self".
However, I'd go for a MUST or at least a SHOULD on the atom:source
presence in republish
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 entr
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 indic
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 w
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
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" th
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 entry metadata int
* 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
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 entry metadata into an atom:source elem
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, which
Atom supports, you have a mechanism that allow
Tim Bray wrote:
>Would the following work:
>1. A new feed-level element , any number allowed.
>
> http://www.tbray.org/ongoing/
> http://www.tbray.org/
> http://tbray.org/
I don't like this. Hopefully, I can explain why. The reason is a bit
subtle...
Tim's proposal relies on
Thomas Broyer wrote:
Tim Bray wrote:
1. A new feed-level element , any number
allowed. E.g.
http://www.tbray.org/ongoing/
http://www.tbray.org/
http://tbray.org/
http://www.textuality.com
Although this doesn't solve the DOS potential, I'd rather go for a new
atom:source child element i
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
w
Tim Bray wrote:
1. A new feed-level element , any number allowed.
E.g.
http://www.tbray.org/ongoing/
http://www.tbray.org/
http://tbray.org/
http://www.textuality.comAlthough this doesn't solve the DOS potential, I'd rather go for a new
atom:source child element indicating the source f
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:
Establis
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
Bob Wyman wrote:
Robert Sayre wrote:
You can point to an alternate feed like this
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 equivalence between the two. The "alternate"
mecha
* Bob Wyman <[EMAIL PROTECTED]> [2005-04-07 19:45]:
> I.e. if I didn't like something you published, I would simply
> publish something in my blog that had the same atom:id as
> something you had published. PubSub and other synthetic feed
> producers would then flush your post from the system and
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 th
Bob Wyman wrote:
Robert Sayre wrote:
You can point to an alternate feed like this
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 equivalence between the two. The "alternate"
mecha
/ "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 t
1:44 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
>
This seems similar to what exists in Really Simply Discoverability in the
individual element [1].
-
# 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 one
to
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 c
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
rel
42 matches
Mail list logo
