Antone Roundy wrote re the issue of DOS attacks:
I've been a bit surprised that you [Bob Wyman] haven't
been more active in taking the lead on pushing the conversation
forward and ensuring that threads addressing the issue don't die
out, given the strength of your comments on the issue in
At 08:47 05/05/20, Eric Scheid wrote:
On 19/5/05 10:41 PM, Tim Bray [EMAIL PROTECTED] wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed. (Text not
provided, we trust the editors to figure out the correct way
At 2:30 AM -0400 5/21/05, Bob Wyman wrote:
I
think it would be both wise and appropriate to provide text in a Security
Concerns section that describes the vulnerability of systems that rely on
Atom documents to this particular attack.
That's why we have signed documents, which are described
On May 22, 2005, at 3:13 AM, Martin Duerst wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed.
(Text not
provided, we trust the editors to figure out the correct way to say
this). Please indicate
Tim Bray wrote:
I think the WG basically decided to punt on the DOS scenario. -Tim
I believe you are correct in describing the WG's unfortunate
disposition towards this issue. (Naturally, I object...) In any case, given
that a significant DOS attack has been identified -- yet not
On Saturday, May 21, 2005, at 12:30 AM, Bob Wyman wrote:
Tim Bray wrote:
I think the WG basically decided to punt on the DOS scenario. -Tim
I believe you are correct in describing the WG's unfortunate
disposition towards this issue. (Naturally, I object...)
I've tried to get
On May 19, 2005, at 12:36 PM, Robert Sayre wrote:
On 5/19/05, Tim Bray [EMAIL PROTECTED] wrote:
co-chair-mode
(Text not
provided, we trust the editors to figure out the correct way to say
this).
The editors request that text be provided.
In section 4.1.1, change the bullet point that reads
Tim Bray wrote:
On May 18, 2005, at 9:11 AM, Sam Ruby wrote:
There seemed to be consensus that feeds needed something to identify
them. What there wasn't consensus on is which element should be
that identifier. The solution selected was to make none of the
identifiers required -
On 5/19/05, Sam Ruby [EMAIL PROTECTED] wrote:
Of course, breaking any link in my complicated chain of logic above
would cause the whole argument to collapse, which would be fine with me.
Maybe the requirement is useless.
If multiple atom:entry elements with the same atom:id value appear in
/ Sam Ruby [EMAIL PROTECTED] was heard to say:
| What should we do? One way to solve this is to require id *and* update
| Graham's original proposal accordingly, *and* incorporate it into the next
| (and presumably final draft).
|
| - - -
|
| That's what I meant by There is a danger of looking
On 5/19/05, Sam Ruby [EMAIL PROTECTED] wrote:
Graham Park has proposed that we loosen the existing language to
permit duplicate ids in the case where the entries have atom:source
elements which identify different URI's in self links. I support
this compromise and believe it
On 19 May 2005, at 9:38 pm, Sam Ruby wrote:
What should we do? One way to solve this is to require id *and*
update Graham's original proposal accordingly, *and* incorporate it
into the next (and presumably final draft).
The original proposal actually relied on ids:
On 19/5/05 10:41 PM, Tim Bray [EMAIL PROTECTED] wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed. (Text not
provided, we trust the editors to figure out the correct way to say
this). Please indicate
On Thursday, May 19, 2005, at 06:41 AM, Tim Bray wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed. (Text not
provided, we trust the editors to figure out the correct way to say
this). Please indicate agreement
14 matches
Mail list logo
