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
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
32 matches
Mail list logo
