Subject: Consensus call on last raft of issues

From: Tim Bray <[email-masked]>
Date: Tue, 17 May 2005 21:13:37 -0700

On behalf of Paul and myself.

Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

The volume of correspondence was unfortunately high for an IETF Last 
Call that came after a Working Group Last call.  It is quite possible, 
as always, that the co-chairs have mis-read the consensus of the group 
on one or more issues; in which case please push back.

We can work on this as long as is needed, and given the passion (and, 
in some cases, intransigence) we have seen so far, we do not expect to 
reach unanimity. When you respond to any of these readings of 
consensus, please do so with the intention of helping the chairs figure 
out whether or not we have determined consensus, not just to state an 
opinion one way or another. Thanks!

========================================================

PaceAllowDuplicateIDs

We see a bunch of +1's with an unambiguous -1 only from Duerst.  Sayre 
was negative (2005/05/05 6:41 AM) but didn't record a -1.  Parks has 
been mostly against, but a close reading of his posts make it clear 
that his issue is in large part with atom:updated, he remains convinced 
that readers desire notification of every change however minor and are 
unwilling to trust publishers' opinions as expressed in atom:updated.  
He could live with this Pace if we re-introduced atom:modified or 
inserted wording in the spec emphasizing that if multiple entries with 
the same atom:id appear in a feed, software must treat them as XXX of 
the same entry; there was lively debate as to whether XXX was 
"versions", "instantiations", or "representations".

Conclusion: The Pace is accepted.  The editors are directed to modify 
the phrase which starts "If multiple atom:entry elements..." as 
follows:

"If multiple atom:entry elements with the same atom:id value appear in 
an Atom Feed document, they describe the same entry and software MUST 
treat them as such."

================================

PaceAlternateLinkWeakening

Only one +1, not good enough, it fails.

================================

PaceBriefExample

Two +1's, seems awfully uncontroversial, verging on editorial, accepted 
unless someone shouts.

===============================

PaceCaching

Multiple -1's, it fails.

=================================

PaceCoConstraintsAreBad

Obsoleted.  Rejected.

============================

PaceContentAndSummaryDistinct

This was modified in the course of debate.  It can't be accepted 
because the +1's (and -1's too) were referring to multiple different 
wordings and there were three pretty strong -1's.

Conclusion: The editors are asked to strengthen the language in the 
draft that emphasizes the difference in intended purpose between 
content and summary.  This can be done by adding a sentence to 4.2.13 
that says "The text in atom:summary should not be identical to the text 
in atom:content or identical to the text in atom:title."

However, this might have gained consensus if it were stable.  If a 
bunch of voices get behind a single version in the next 72 hours and 
win the hearts of the -1's, the door is open.

=============================

PaceContentAndSummaryDistinct2

One each +1 and -1, hardly consensus.  Rejected.

==========================

PaceDuplicateIDWithModified

A handful of +1's, one -1. The consensus of the group against 
atom:modified months and months ago was quite strong and this is not 
enough momentum to accomplish such a major policy reversal.  Rejected.

===========================

PaceDuplicateIDWithSource
PaceDuplicateIDWithSource2

A couple of -1's, no support, rejected.

===============================

PaceEntryState

Rejected, no support.

=================================

PaceExplainDuplicateIDs

Only one +1 but once again, uncontroversial, mostly editorial, accepted 
unless someone squawks.

================================

PaceFeedIdOrAlternate

No postings.  Rejected.

=====================

PaceFeedIdOrSelf

Reworded in progress, too many -1's, rejected.

=============================

PaceNoAlternativeForFeed

Only one +1 from its author, it fails.

=============================

PaceOptionalFeedLink

Lots of +1's, moderate objections from Ruby, accepted.

==================================

PaceOptionalSummary

There is a massive amount of support, with two clear -1's.  Several of 
the +1's could see a case for a SHOULD, hence PaceTextShouldBeProvided 
(see below).  This Pace has rough consensus support and is accepted.

================================

PaceOptionalXhtmlDiv

A handful of -1's, no support, rejected.

===============================

PaceOriginalAttribute

Number of +1's and -1's approximately equal, plus Ruby pointed out some 
wording problems.  Rejected.

================================

PacePubControl

Some opposition, but out-of-scope for data format draft.  Send back for 
reconsideration in protocol context.

================================

PacePubStatusResource

Send back for reconsideration in protocol context.

================================

PaceRecommendPlainTextContent

Multiple -1's, no support, it fails.

===============================

PaceRenameImageToLogo

A handful of +1's no objections, accepted.

=================================

PaceSourceRec

One -1, not enough defense, rejected.

======================

PaceTextShouldBeProvided

+1 from Ruby, explicit -1's from Sayre and de hÓra.  However, taking 
this and PaceOptionalSummary together, it seems clear that the WG 
generally believes the following:

- Title-only feeds are OK for data where that's really all you have.
- Failing to provide summaries when they could potentially exist is 
regrettable and should be discouraged.
- There are certain classes of software which will not be able to make 
use of content-light feeds, for example full-text indexers.
- It is not acceptable for software to fail (note "fail", as opposed to 
"not make full use of") just because the summary is missing.

There is lack of consensus in the WG as to whether RFC2119 "SHOULD" is 
an appropriate level of language to use in encouraging the provision of 
summaries.

Conclusion: This Pace is rejected.  However, the editors are directed 
to include the following text in 4.2.13:

"Experience teaches that feeds which contain textual content are in 
general more useful than those which do not.  There are certain classes 
of application, for example full-text indexers, which will be unable to 
make effective use of entries which do not contain text in either 
atom:summary or atom:content.  Feed producers should be aware of these 
issues and are encouraged to include a meaningful atom:summary in 
entries lacking atom:content wherever possible.  However, the absence 
of atom:summary is not an error and software MUST NOT fail to function 
correctly as a consequence of such an absence."

=====================

Change atom:copyright to atom:rights

Two -1's but many many +1's.  Accepted.

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 May 2005 01:07:32 -0400

Tim Bray wrote:
> We can work on this as long as is needed, and given the passion (and, in 
> some cases, intransigence) we have seen so far, we do not expect to 
> reach unanimity. When you respond to any of these readings of consensus, 
> please do so with the intention of helping the chairs figure out whether 
> or not we have determined consensus, not just to state an opinion one 
> way or another. Thanks!

There is a danger of looking at changes in isolation.  I will point out 
two instances that jump out at me.  There may be more.

> been mostly against, but a close reading of his posts make it clear that 
> his issue is in large part with atom:updated, he remains convinced that 
> readers desire notification of every change however minor and are 
> the phrase which starts "If multiple atom:entry elements..." as follows:
> 

IIRC, much of this started due to an objection by Bob Wyman that 
treating atom:entries from different sources with the same atom:id as 
the same entry would cause problems for PubSub.  What ever happened to 
that objection?

Also, it seemed to me that much of the discussion centered around 
distinguishing between multiple versions.  Reintroducing modified was 
rejected, and atom:version never made it into a pace, but should there 
be some hint (perhaps non-normative) that software should look to 
atom:updated to resolve collisions?

http://www.imc.org/atom-syntax/mail-archive/msg14896.html

If feed link becomes optional, there is nothing to anchor atom:source 
elements, which relates back to Bob's objection above.

Finally, I'm not sure what the next step is, but some determination of 
consensus on extensibility (also referred to as change control) is 
needed.  There does seem to be a lot of voices in support of the 
following statement:

   Only those elements defined in IETF RFCs may use the Atom namespace

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 May 2005 01:15:49 -0400

Tim Bray wrote:
> Conclusion: This Pace is rejected.  However, the editors are directed to 
> include the following text in 4.2.13:
> 
> entries lacking atom:content wherever possible.  However, the absence of 
> atom:summary is not an error and software MUST NOT fail to function 

Much of the discussion of this pace centered around the proposed changes 
to section 4.1.2.  However, there is more to this pace.

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 18 May 2005 09:47:45 +0100

> correctly as a consequence of such an absence."

+1

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Wed, 18 May 2005 08:41:09 -0600

On Tuesday, May 17, 2005, at 11:07  PM, Sam Ruby wrote:
>> "If multiple atom:entry elements with the same atom:id value appear 
>> in an Atom Feed document, they describe the same entry and software 
>> MUST treat them as such."
>

This is the one remaining issue I'm aware of that I think we really 
need to resolve.  Until mankind evolves to the point that DOS attacks 
are no longer attempted, we need to try to protect against them.  A 
MUST here goes beyond just allowing DOS attacks, it's practically an 
invitation: copy the target entry, increment atom:updated, change a few 
critical details, publish. How can an aggregator protect against this 
without violating the spec?

An oddity this language introduces is that if the entries don't appear 
in the same Atom Feed Document, they apparently don't have to be 
treated as the same entry, but if they're aggregated together, they do. 
Going a little further, if I'm subscribed to both original feeds and an 
aggregation that includes both, then I have potentially four <entry>s 
with the same id.  Which are the same entry and which aren't?  Only the 
two in the aggregation, which really aren't, are required to be treated 
as the same.

---

From: Henry Story <[email-masked]>
Date: Wed, 18 May 2005 17:12:08 +0200

On 18 May 2005, at 16:41, Antone Roundy wrote:
>>> "If multiple atom:entry elements with the same atom:id value  
>>> appear in an Atom Feed document, they describe the same entry and  
>>> software MUST treat them as such."
>>>
>>
>> treating atom:entries from different sources with the same atom:id  
>> as the same entry would cause problems for PubSub.  What ever  
>> happened to that objection?
>>
>
> need to resolve.  Until mankind evolves to the point that DOS  
> attacks are no longer attempted, we need to try to protect against  
> them.  A MUST here goes beyond just allowing DOS attacks, it's  
> practically an invitation: copy the target entry, increment  
> atom:updated, change a few critical details, publish. How can an  
> aggregator protect against this without violating the spec?

I supposed the surest way to make it impossible to fake the id, is to  
specify that
by dereferencing the id and doing a GET (whatever the correct method  
of doing that for the
protocol happens to be) one should be able to retrieve the entry.

This I know goes against some of the hopes built into id, but I think  
that it may be that
this is the cost of working in on the web. You just can't escape REST.

> An oddity this language introduces is that if the entries don't  
> appear in the same Atom Feed Document, they apparently don't have  
> to be treated as the same entry, but if they're aggregated  
> together, they do. Going a little further, if I'm subscribed to  
> both original feeds and an aggregation that includes both, then I  
> have potentially four <entry>s with the same id.  Which are the  
> same entry and which aren't?  Only the two in the aggregation,  
> which really aren't, are required to be treated as the same.

I always thought that two entries with the same id should be treated  
as the same entry.
What makes you thing otherwise?

Henry Story
http://bblfish.net/blog/

---

From: Antone Roundy <[email-masked]>
Date: Wed, 18 May 2005 09:30:22 -0600

> protocol happens to be) one should be able to retrieve the entry.
The unlikelihood of anyone actually retrieving each entry to verify 
that it's accurate would make this method only trivially effective.

>> appear in the same Atom Feed Document, they apparently don't have to 
>> be treated as the same entry, but if they're aggregated together, 
>> they do. Going a little further, if I'm subscribed to both original 
>> feeds and an aggregation that includes both, then I have potentially 
>> four <entry>s with the same id.  Which are the same entry and which 
>> aren't?  Only the two in the aggregation, which really aren't, are 
>> required to be treated as the same.
>
Consider the following three simplified feed documents (or any two of 
them, or just the last one):

// this is the legitimate one
<feed>
	<id>http://a.com/feeda</id>
	<entry>
		<id>http://a.com/feeda/entry1</id>
		<updated>2005-01-01T05:00+00:00</updated>
		<title>I am the legitimate entry</title>
		<content type="html">&lt;a href="https://a.com/feedback.php"&gt;Use 
this form to submit your credit card number&lt;/a&gt;</content>
	</entry>
</feed>

// this one is phishing
<feed>
	<id>http://b.com/feedb</id>
	<entry>
		<id>http://a.com/feeda/entry1</id>
		<updated>2005-01-01T10:00+00:00</updated>
		<title>I am the legitimate entry</title>
		<content type="html">&lt;a href="https://b.com/feedback.php"&gt;Use 
this form to submit your credit card number&lt;/a&gt;</content>
	</entry>
</feed>

// this is an aggregation
<feed>
	<id>http://c.com/feedc</id>
	<entry>
		<source>
			<id>http://a.com/feeda</id>
		</source>
		<id>http://a.com/feeda/entry1</id>
		<updated>2005-01-01T05:00+00:00</updated>
		<title>I am the legitimate entry</title>
		<content type="html">&lt;a href="https://a.com/feedback.php"&gt;Use 
this form to submit your credit card number&lt;/a&gt;</content>
	</entry>
	<entry>
		<source>
			<id>http://b.com/feedb</id>
		</source>
		<id>http://a.com/feeda/entry1</id>
		<updated>2005-01-01T10:00+00:00</updated>
		<title>I am the legitimate entry</title>
		<content type="html">&lt;a href="https://b.com/feedback.php"&gt;Use 
this form to submit your credit card number&lt;/a&gt;</content>
	</entry>
</feed>

This is already bad enough.  Now how about if the phishing feed claims 
that it's atom:id is http://a.com/feeda.  Worse still.  With the 
current spec text, an Atom consumer that does a little extra work, 
somehow figures out that the phishing version of the entry is not the 
same as the legitimate version, and tells the user that would be 
violating the spec.

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 May 2005 12:11:23 -0400

Sam Ruby wrote:
>> consensus, please do so with the intention of helping the chairs 
>> figure out whether or not we have determined consensus, not just to 
>> state an opinion one way or another. Thanks!
> 
>> that his issue is in large part with atom:updated, he remains 
>> convinced that readers desire notification of every change however 
>> minor and are unwilling to trust publishers' opinions as expressed in 
>> atom:updated.  He could live with this Pace if we re-introduced 
>> atom:modified or inserted wording in the spec emphasizing that if 
>> multiple entries with the same atom:id appear in a feed, software must 
>> treat them as XXX of the same entry; there was lively debate as to 
>> whether XXX was "versions", "instantiations", or "representations".
>>

I guess I wrote this too quickly last night, in any case, it wasn't 
clear to Paul, so it might not be clear to others.  Off list, I offered 
the following, and Paul suggested that I post it to the list:

     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 - something I don't think has much support, and
     furthermore creates problems with the ability to cite a source.

Done!

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 18 May 2005 18:28:42 +0100

Antone Roundy wrote:

> that it's atom:id is http://a.com/feeda.  Worse still.  With the current 
> spec text, an Atom consumer that does a little extra work, somehow 
> figures out that the phishing version of the entry is not the same as 
> the legitimate version, and tells the user that would be violating the 
> spec.

I don't think this (spam, phishing) is solvable without widespread 
adoption of dsig/pki technology. More snarkily, all the people who 
complain about these things ought to consider using appropriate 
technology. We do need to make sure that Atom entries are easily signed 
tho'.

cheers
Bill

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 18 May 2005 21:35:17 +0200

> win the hearts of the -1's, the door is open.

For the reasons I argued in…

• <20050515211617.GA12134@klangraum>:
  http://www.imc.org/atom-syntax/mail-archive/msg15216.html
  
• <20050516030242.GA15343@klangraum>:
  http://www.imc.org/atom-syntax/mail-archive/msg15230.html
  
• <20050516035956.GA15580@klangraum>:
  http://www.imc.org/atom-syntax/mail-archive/msg15232.html

…which can be summarized in the following points…

• It is extremely valuable for consumers that the format allows a
  distinction between summaries/excerpts and full content, and
  this distinction should therefore be enforced within
  possibility.

• The only formally verifiable criterion that a feed producer is
  using these elements *in*correctly is if he is sticking the
  same content in both and letting aggregators worry about it. By
  merely forcing feed producers to make any choice at all, it can
  expected that they will choose correctly.

…I suggest that the proposed editorial be accepted as is, with the
sole modification of turning the informal “should not” into a
normative “MUST NOT,” ie:

    The text in atom:summary MUST NOT be identical to the text in
    atom:content or identical to the text in atom:title.

Meta-PS.: do I need to follow any formal procedures (such as
writing a pace) for consensus do be determined?

Regards,
-- 
Aristotle

---

From: David Powell <[email-masked]>
Date: Wed, 18 May 2005 21:57:35 +0100

> The consensus of the group against atom:modified months and months
> ago was quite strong and this is not enough momentum to accomplish
> such a major policy reversal. Rejected.

I don't think that this Pace has had enough discussion to be rejected
just yet - it's was only posted 2.5ish days ago.

The consensus against PaceDateModified can't be applied to
PaceDateModified2 - the -1s against PaceDateModifed were overwhelming,
but as far as I can see all of the -1s were for the reason that there
was insufficient need for PaceDateModified.

PaceDateModified was closed prior to the issue of duplicate entries
being raised. Duplicate entries create a need for atom:modified that
wasn't discussed at the time of PaceDateModified.

If this proposal is rejected, then we still have a fundamental
data-loss problem if the sequence of revisions in an archive is not
preserved.

-- 
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 18 May 2005 23:46:07 +0200

> Rejected, no support.

Wasn't it intended for the protocol spec? (though section 3.5 doesn't 
exist in protocol-04)

> A handful of -1's, no support, rejected.

Maybe it came a bit late? And I think the -1's were misinterpretations 
of the Pace.

Nonetheless, my understanding of Text Construct and "special @type 
values" or atom:content is that they aim to provide textual content, 
eventually enriched with escaped-HTML or XHTML markup. As I explained in 
my last mail in the related thread [1], (X)HTML div (or span) elements 
without any attribute (except eventual namespace declarations) have no 
mean other than grouping their content on behalf of their siblings (text 
and markup living outside the div but having the same parent/enclosing 
element). There's then no matter discarding them.

Some people might object that those "dummy" div elements can be used for 
styling (here, something like CSS; XSLT is a transformation, not really 
a stylesheet). Let's examine that special case a bit, figuring out how 
such elements (a div element with no attribute being the only child of a 
Text Construct or atom:content with type="xhtml") would then be used for 
styling.

Styling an XHTML element is possible only from outside of it (through a 
stylesheet) or with a @style attribute, but it's not what we're talking 
about. In the first case, the only solution is to embed the content in a 
document (at least adding an xml-stylesheet processing instruction) or 
process it somehow to apply it a stylesheet. Whatever mean is used, it's 
the responsibility of the application to style the XHTML content, thus 
to add dummy XHTML div wrappers if necessary. Moreover, the current spec 
states the div must be discarded, so an application would already have 
to add these dummy XHTML div wrappers. In the second case, the div has 
an attribute so it's out of scope.
Styling an Atom document and using a dummy XHTML div for that purpose is 
also out of scope as we're talking about Atom documents containing dummy 
XHTML div element that could be discarded when processed by an Atom 
Processor (which an application applying a stylesheet is not).

As I already said (in the same mail [1]), as Atom uses XML Namespaces, 
an namespace-aware XML parser is required, so "I need this div not to be 
discarded in order to carry the namespace declaration" is not an 
acceptable argument. Again, if the Atom Processor or the application 
have no mean to keep the namespace scope without a dummy div wrapper, 
it's its responsibility to add such (and, e.g. if it's a library, 
document it so that users know that what they receive is not what really 
was in the Atom document). And again, the current spec states the div 
must be discarded, so such an Atom Processor would already have to add 
such a wrapper.

For people worried about misuse of XML namespaces, I suggest adding some 
wording and examples to the spec, and I don't think the current spec 
sorts out the problem better (though not worse either).

I've asked for examples of XHTML content that would need a div without 
attribute and which would be kept part of the content, there has not 
been any answer yet.
I ask the question again: is there any reason such a div should be kept 
part of the content?
Just to make sure nobody would misinterpret the Pace, we're only talking 
about those XHTML div elements that are the single child of a Text 
Construct or atom:content with @type="xhtml" and have no attribute at 
all except namespace declarations.

Should I edit the Pace to make it reflect the above better than it 
currently does?

=====================

Last (but not least), my English is not as good as I'd want and my 
dictionary is of no help: what does really mean "recommended for closure"?
Actually, what about PaceXhtmlDivSuggestedOnly (and more accurately the 
part about inline vs. block content, which is not implied by the Pace 
name)? Do you think I should withdraw this Pace and write up a new one 
for that particular matter (say, e.g., PaceInlineVsBlockContent)?

[1] http://www.imc.org/atom-syntax/mail-archive/msg15222.html

-- 
Thomas Broyer

---

From: Antone Roundy <[email-masked]>
Date: Wed, 18 May 2005 17:10:13 -0600

>     furthermore creates problems with the ability to cite a source.
Agreed.  In a probably-vain attempt to seed a semi-organized discussion 
of the topic, let me start a list of reasons and ways to identify a 
feed.  There are weaknesses to all of the following.  I won't discuss 
those yet because I'd rather wait till the lists are more complete so 
that a decision can be made by choosing the best from among 
alternatives rather than just ranting about the drawbacks of a few of 
them and never reaching a reasoned conclusion.  Please chime in if you 
have other reasons and/or methods.

Why might someone (even if not you) want to have an identifier for a 
feed?
1) To use as or to generate a database key for the feed and its entries
2) To associate aggregated entries with the feed that they are claimed 
to have originated in
3) To verify the integrity of aggregated entries with more confidence 
than is possible simply by believing the aggregated feed's claims about 
their origins

Any others?

How might a feed be identified?
1) atom:id
2) atom:link[@rel="alternate"]
3) atom:link[@rel="self"]
4) the IRI from which it was retrieved

Any others?

----------

A comment on atom:link[@rel="self"]: Does anyone else feel that the 
current spec text doesn't fully reflect what we intended, or at least 
could be improved to make it more useful?

       3. The value "self" signifies that the IRI in the value of the 
href
        attribute identifies a resource equivalent to the containing
        element.

This text is not explicit on whether "self" points to Atom document, or 
whether it could point to any data format.  Unless it points to an Atom 
document, how is it different from "alternate"?

Was not it intended that the feed or entry be retrievable from that IRI 
(I seem to recall someone claiming that the current spec text doesn't 
say that--if I'm incorrect, just ignore this whole paragraph)?  If not, 
what is the point of having this link?  "The "atom:link" element is an 
empty element that defines a reference from an entry or feed to a Web 
resource."  Doesn't that mean that the IRI can be used for retrieval?

Was it not intended that it be the "preferred" IRI to use to subscribe 
to the feed?  If that wasn't the original intent, would that not be a 
good thing to add?  What drawbacks would there be to doing that to 
"self"'s semantics?

I'll comment on other things later.

---

From: Isofarro <[email-masked]>
Date: Thu, 19 May 2005 18:18:30 +0100

> correctly as a consequence of such an absence."

I'd urge that the wording here should also include accessibility 
concerns, especially to encourage accessible alternatives to to be 
adopted when the content is known to be inaccessible - e.g. images, 
sound files, movies, flash.

HTML for instance has a number of accessible alternatives to 
inaccessible constructs - images have a src attribute, flash and 
embedded movies allow the child of the object element to contain 
accessible alternatives to the content.

In the situation where an Atom Entry is presented to a human being, if 
one of those representations is HTML, e.g. (representing the non-textual 
content in HTML as an object element with a @src reference), then 
without the presence of accessible alternatives to inaccessible media, 
its going to be problematical, and downright impossible to generate 
accessible content for the user.

May I suggest the following addition:

"Where an Atom Entry with non-textual content is created for use by 
people - either in their browsers or screen readers, it must also 
include an equivalent accessible alternative."

 From the XML Accessibility Guidelines, Guideline 1.1 
<url:http://www.w3.org/TR/xag#g1_0>

"1.1 Provide a mechanism to explicitly associate alternatives for 
content or content fragments.
     Authors using the elements/attributes in your language must have 
the ability to provide alternatives for any content, be it images, 
movies, songs, running text, whatever."

We've got the mechanism - e.g. the summary and link elements of an Atom 
Entry, we need to highlight these uses in 4.2.13.

Thanks,
Mike

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 19 May 2005 13:45:30 -0400

> accessible alternatives to the content.

Presumably you mean "images have an alt attribute", but otherwise +1.

Note that HTML 4 and beyond *require* an alt attribute for images, but
does not similarly require non-script alternatives to script elements.
 Nor does it explicitly require accessible alternatives to embedded
media such as Flash or video; the mechanism is present and encouraged,
but ultimately optional.

Since the last time this came up on the list, I have relaxed my
position, and I am now fine with defining a feed format that
encourages, but ultimately does not require, accessible content.  Note
that inaccessible content is A Bad Thing(tm) and in some contexts
content producers will be legally or contractually obligated to
provide it, but I will not go so far as to say that the format itself
should force you to provide it.

The format spec is the proper place to STRONGLY RECOMMEND that you
provide accessible alternatives to inaccessible context (and we
already have sufficient mechanisms to provide such alternatives), but
I will no longer go so far as to call it a MUST.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 May 2005 05:41:15 -0700

>     furthermore creates problems with the ability to cite a source.

Paul and I talked this over, and while we're not sure (the email trail 
was confusing) Sam may be right; so let's find out.  Note that it seems 
pretty clear that the cost of requiring atom:id is nearly zero, since 
anyone who's generating Atom has to have an ID generator around for 
entries.  So, let's find out if Sam is right:

<co-chair-mode>
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 or disagreement with this proposition 
in the next day or two.
</co-chair-mode>

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 May 2005 12:04:38 -0700

> Presumably you mean "images have an alt attribute", but otherwise +1.

Right now our draft says:

atom:entry elements MUST contain an atom:summary element in any of the 
following cases:
...
- the atom:entry contains an atom:content that has a "src" attribute 
(and is thus empty).
- the atom:entry contains content that is encoded in Base64; i.e. the 
"type" attribute of atom:content is a MIME media type [MIMEREG] and 
does not begin with "text/" nor end with "+xml".

It seems to me that this addresses the concern, or am I missing 
something? -Tim

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 May 2005 15:36:23 -0400

On 5/19/05, Tim Bray <[email-masked]> wrote:

> (Text not
> this). 

The editors request that text be provided.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Thu, 19 May 2005 16:38:59 -0400

> entries.  So, let's find out if Sam is right:

Permit me to provide some more background.  I *think* that there is some 
desire that if the SAME entry appears in multiple places (say, 
TheServerSide, Java.net, Artima, etc.) that it not appear multiple 
times.  This specific example was called out here:

   http://www.tbray.org/ongoing/When/200x/2005/04/03/Atom-Now#p-1

I appologize for referencing something outside of the mailing list, and 
if the item I cited does not represent the consensus of the working 
group, then the following text should be removed from PaceDuplicateIDs:

   If multiple atom:entry elements with the same atom:id value appear in
   an Atom Feed document, they represent the same entry

  - - -

If, however, this above is what we desire (and I certainly support it), 
let's see what Bob's objection was:

   http://www.imc.org/atom-syntax/mail-archive/msg14470.html

In that, he said:

   The problem is, once again, that prohibiting duplicate ids provides an
   easy to use attack vector for those wishing to effectively “erase”
   entries written by another author.

Now, lets take a look again at that text from PaceDuplicateIDs:

   If multiple atom:entry elements with the same atom:id value appear in
   an Atom Feed document, they represent the same entry.

It seems to me that this does not solve the problem that Bob described. 
  More specifically, if pubsub were to republish data from 
TheServerSide, Artima, or other places, then the "erasure" that Bob 
fears would come to pass.

What's most puzzling is that it appears that PaceDuplicate IDs was 
specifically written in response to Bob's concerns:

   http://www.imc.org/atom-syntax/mail-archive/msg14731.html

What is missing in all this is the following, again from Bob's original 
statement of the problem:

   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 should be supported by the WG and
   incorporated into the Atom Draft.

This proposal seemed to have enjoyed some support, yet it did not seem 
to have made it into the current draft, despite being crucial to the 
solving the issue that PaceDuplicateIDs was designed to address. 
However, for it to work, the re-aggregator would need to have access to 
a "self" link, which is not required by the current draft.

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 at changes in 
isolation.":

   http://www.imc.org/atom-syntax/mail-archive/msg15292.html

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.

Does anybody see something that I am missing?

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 May 2005 17:02:29 -0400

> would cause the whole argument to collapse, which would be fine with me.

Maybe the requirement is useless.

"MUST treat them as such" isn't particularly meaningful, and two
atom:entry elements occuring anywhere are supposed to be describing
the same entry. When I get CCed on an atom-syntax message, some of my
email programs show two messages, and some show one. It's a
security/annoyance trade-off, and I don't see why the format should be
making that decision.

Robert Sayre

---

From: Norman Walsh <[email-masked]>
Date: Thu, 19 May 2005 17:07:35 -0400

/ Sam Ruby <[email-masked]> 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 at changes in
| isolation.":
|
|    http://www.imc.org/atom-syntax/mail-archive/msg15292.html
|
| 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.
|
| Does anybody see something that I am missing?

I have to say that the DoS issue hadn't occurred to me before Bob
raised it and I've been a bit depressed about it ever since it came
up. Is there really anything that we can do here, short of providing a
mechanism for signing entries and telling aggregators that a duplicate
is an entry with the same id and the same signature?

Seems to me if I'm unscrupulous enough to attempt DoS, I can fake all
of the required parameters.

/me shrugs

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Happiness is a how, not a what; a
http://nwalsh.com/            | talent, not an object.--Herman Hesse

---

From: Danny Ayers <[email-masked]>
Date: Thu, 19 May 2005 23:32:56 +0200

On 5/19/05, Sam Ruby <[email-masked]> wrote:

>    elements which identify different URI's in "self" links. I support

I believe it makes sense to give the notional "atoms" (entries)
individual identifiers which will be preserved globally, irrespective
of the source, irrespective of where the entries are found - so yes,
duplicate IDs in a feed seem an acceptable scenario.

I don't personally care how it's done, but a reference back from the
feed document to the URI from whence it is begetted is pretty
essential for the easier one-click subscription strategies, and should
come in handy later for aggregate-republish processing.

I think a reference back to the source (original better, intermediate
better than nothing) is also desirable to help reduce duplicate posts
appearing in any end-of-chain UI.

Take this scenario - two entries identical in every respect *except*
for their ID. Any resource on the Web may have any number of different
URIs, which suggests any entry might /potentially/ have any number of
IDs. Should the two entries be allowed in the same feed? If you change
the name of an entry, do you change its nature? Sorry, slipping,  it's
a bit late here - scratch the philosophy, ;-)

Basically I reckon duplicate IDs in a feed are ok - leave it to the
(final or intermediate) consumer to filter out if required according
to local rules/heuristics.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Thu, 19 May 2005 23:31:54 +0100

On 19 May 2005, at 9:38 pm, Sam Ruby wrote:

> update Graham's original proposal accordingly, *and* incorporate it  
> into the next (and presumably final draft).

The original proposal actually relied on ids:
http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource

Just to be clear, the idea wasn't that an entry would have a  
concatenated entry:id-source:id as its identifier. The entry:id would  
still be primary, its just multiple versions received from different  
sources could be represented.

> It seems to me that this does not solve the problem that Bob  
> described.  More specifically, if pubsub were to republish data  
> from TheServerSide, Artima, or other places, then the "erasure"  
> that Bob fears would come to pass.

I don't really believe this to be so. An aggregator can treat them as  
the same entry without having one overwrite the other. It can easily  
present to the user "Here's the version from Site A" and "Here's the  
version from Site B". That was kind of the idea of  
PaceDuplicateIDWithSource. Of course, the atom:source element is as  
fakeable as the entry's id. The only reliable origin is the URI it  
was directly fetched from.

Oh, and compulsory feed:ids are fine with me. Certainly better than  
the hybrid proposals.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 May 2005 09:47:36 +1000

> this).  Please indicate agreement or disagreement with this proposition

wth, +1

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 19 May 2005 19:45:12 -0400

> does not begin with "text/" nor end with "+xml".

I'm saying that "MUST" is probably too strong here.  I don't mind it
personally, but I don't see the case for requiring it on grounds of
interoperability.  If we keep it, the format spec should probably
mention *why* this is required, if only in passing.

Then again, if it got changed to "SHOULD", I wouldn't raise holy hell
about it.  But I'm not going to write a Pace to change it.

-- 
Cheers,
-Mark

---

From: Antone Roundy <[email-masked]>
Date: Thu, 19 May 2005 18:10:27 -0600

On Thursday, May 19, 2005, at 06:41  AM, Tim Bray wrote:
> this).  Please indicate agreement or disagreement with this 
> proposition in the next day or two.
>
Since I've already expressed my opinions on this issue, I'll be brief 
just to register my opinion in this thread.  I don't think atom:id is 
the most useful possible identifier, so this isn't my first choice.  
But if we can't agree to use a better one, it'll be better than nothing.

---

From: Isofarro <[email-masked]>
Date: Fri, 20 May 2005 06:57:27 +0100

> On 5/19/05, Tim Bray <[email-masked]> wrote:

[atom:summary and accessibility]

+1

Particulary on the first point above "atom:content that has a "src" 
attribute", "MUST" is a bit heavy handed for accesibility, since the 
"src" attribute could reference an accessible resource - like an 
external html file. Its when "src" references an inaccessible resource 
is it essential that atom:summary convey an accessible equivalent.

The second point about Base64 encoding, "MUST" or "strongly 
recommended/encouraged for the purpose of accessibility" is needed.

In respect to Mark's suggestion of mentioning why:

Perhaps "4.2.13 The "atom:summary" element" is a good place to mention 
the accessibility. As an initial suggestion, after the first paragraph of

"The "atom:summary" element is a Text construct that conveys a short
    summary, abstract or excerpt of an entry."

Insert the paragraph:

"   In cases where atom:content is Base64 encoded, or has a "src"
     attribute, the atom:summary conveys an accessible text equivalent
     to the non-text atom:content."

> about it.  But I'm not going to write a Pace to change it.

That suits me fine too.

Thanks,
Mike

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 12:19:35 +0100

The appropiate answer to this is to say comparing an id from a  
document retrieved from one URI to an id retrieved from a second URI  
is not reliable. This makes feed:ids largely useless. The primary  
use, of comparing with a previous version of a document retrieved  
from the same URI, is fine.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 20:50:00 +1000

On 21/5/05 7:47 PM, "Henry Story" <[email-masked]> wrote:

> But perhaps it is not such a problem after all, because perhaps we can have
> dereferenceable ids that allow us to move entries around. I can  think of a
> few:
> 
>1. if an entry moves the old entry position redirects to the new one.

not always possible.

>2. one creates a special redirect service to redirect ids to their
>   current location

Such things already exist in various forms. There is for example a service
which resolves DOI URIs.

>3. one creates a new URI to URL mapping protocol

blech. 

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 16:44:01 +1000

On 21/5/05 4:24 PM, "Henry Story" <[email-masked]> wrote:

> So those are just a few thoughts on the topic. It just seems that if  one
> works with the web these phishing problems seem to disappear.

all good stuff, with the exception of making atom:id dereferenceable... once
you do that you have to allow it to change (to accommodate changes in server
set up etc), and once you allow it to change it is no longer effective as an
id :-(

So, all the above, but using atom:link[@rel='self'] instead.

BTW, /feed/id is useful for other things -- primarily to help big
aggregators to realise that they are retrieving the same feed from more than
one location (eg. with and without www.)

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 02:30:30 -0400

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 addressed -- 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.

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 16:49:31 +1000

> Atom documents to this particular attack.

+1 to putting something into Security Concerns.

I'm inclined to think the DOS problem is peculiar to super-aggregators - if
any of the publishers of the feeds I've individually subscribed to and
actively monitor/read were to wake up one day and decide to be a bad actor,
I'm sure to notice something wacky and take action (excoriate them on a
blog, unsubscribe, etc).

In addition to the DOS problem, I believe there are other issues inimical to
super-aggregators, especially those that re-publish. Mostly to do with
tracking provenance, enveloping and attribution of mid-stream meta-data or
meta-content, and so on. It deserves a deeper treatment, but not in the Atom
1.0 core spec.

e.

---

From: Henry Story <[email-masked]>
Date: Sat, 21 May 2005 08:44:10 +0200

> security/annoyance trade-off, and I don't see why the format should be

+1
How you deal with different representations of entries with the same  
id is
up to the software and user's discretion. Some software may want to keep
a full history of all the representations, some may only be able to  
keep the
latest. Some users may wish to see all represenations others may wish  
to see
only some of them. The same user may have different preferences at  
different times.

The requirement of treating entries with the same id as the same does  
not add
anything more than saying that the entries are representations of the  
id resources.

Henry Story

---

From: Henry Story <[email-masked]>
Date: Sat, 21 May 2005 08:24:52 +0200

On 18 May 2005, at 17:30, Antone Roundy wrote:
>> I supposed the surest way to make it impossible to fake the id, is  
>> to specify that
>> by dereferencing the id and doing a GET (whatever the correct  
>> method of doing that for the

Perhaps not. There was a long thread a few months ago about how to  
deal with the growing
size of feeds. Using a restful method, one simple solution to the  
problem would have been to have
minimal feeds of the following form:

<feed>
     <id>http://a.com/feeda</is>
     <entry>
         <id>http://a.com/feeda/entry1</id>
         <updated>2005-01-01T05:00+00:00</updated>
     </entry>
     <entry>
         <id>http://a.com/feeda/entry2</id>
         <updated>2005-01-02T06:00+00:00</updated>
     </entry>
     <entry>
         <id>http://a.com/feeda/entry3</id>
         <updated>2005-01-03T07:00+00:00</updated>
     </entry>
</feed>

Clearly feeds like the above would only be useful if one dereferenced  
the entry ids.
A consumer of an atom feed would thus read a feed, then work out  
which of the
entries it had not yet seen or which had been modified, and then go  
and fetch the
content of those entries by dereferencing the id. In the above case  
this could be done
by doing a GET on <http://a.com/feeda/entry1> for example and retrieving

<entry>
     <id>http://a.com/feeda/entry1</id>
     <updated>2005-01-01T05:00+00:00</updated>
     <title>I am the legitimate entry</title>
     <content type="html">&lt;a href="https://a.com/ 
feedback.php"&gt;Use this form to submit your credit card number&lt;/ 
a&gt;</content>
</entry>

Of course the above saves a lot more bandwidth the larger the entry  
becomes.

>> I always thought that two entries with the same id should be  
>> treated as the same entry.
> Consider the following three simplified feed documents (or any two  
> of them, or just the last one):
>

Yes but now imagine the same thing written in the minimal format  
menitoned above:

>         <content type="html">&lt;a href="https://a.com/ 
> feedback.php"&gt;Use this form to submit your credit card  
> number&lt;/a&gt;</content>
>     </entry>
> </feed>

<!-- the original feed -->
<feed>
     <id>http://a.com/feeda</id>
     <entry>
         <id>http://a.com/feeda/entry1</id>
         <updated>2005-01-01T05:00+00:00</updated>
     </entry>
</feed>

>         <content type="html">&lt;a href="https://b.com/ 
> feedback.php"&gt;Use this form to submit your credit card  
> number&lt;/a&gt;</content>
>     </entry>
> </feed>

<!-- the phishing feed -->
<feed>
     <id>http://a.com/feedb</id>
     <entry>
         <id>http://a.com/feeda/entry1</id>
         <updated>2005-01-01T05:00+00:00</updated>
     </entry>
</feed>

>         <content type="html">&lt;a href="https://a.com/ 
> feedback.php"&gt;Use this form to submit your credit card  
> number&lt;/a&gt;</content>
>     </entry>
>     <entry>
>         <source>
>         <content type="html">&lt;a href="https://b.com/ 
> feedback.php"&gt;Use this form to submit your credit card  
> number&lt;/a&gt;</content>
>     </entry>
> </feed>

<!-- the aggregation feed -->
<feed>
     <id>http://a.com/feedc</id>
     <entry>
         <source>
             <id>http://a.com/feeda</id>
         </source>
         <id>http://a.com/feeda/entry1</id>
         <updated>2005-01-01T05:00+00:00</updated>
     </entry>
     <entry>
         <source>
             <id>http://a.com/feedb</id>
         </source>
         <id>http://a.com/feeda/entry1</id>
         <updated>2005-01-01T05:00+00:00</updated>
     </entry>
</feed>

Notice that the source of an entry is much less important in this  
situation - it
does not carry the heavy role of conveying trust. Trust is carried  
simply by the
structure of the http protocol.

Also it is clear that there is not much room for phishing here. The  
content of the
entry is retrieved in both cases by GETing <http://a.com/feeda/entry1>

So here we have a solution that:

> This is already bad enough.  Now how about if the phishing feed  
> claims that it's atom:id is http://a.com/feeda.  Worse still.  With  
> the current spec text, an Atom consumer that does a little extra  
> work, somehow figures out that the phishing version of the entry is  
> not the same as the legitimate version, and tells the user that  
> would be violating the spec.

In the above case changing the id of a feed would not be very  
interesting. The content is always
fetched by dereferencing the atom id. So a phishing feed that faked  
its id would not achieve
very much.

But just to deal with this issue, let us go a little further then and  
make the id of a feed
also dereferenceable. If the id of a feed is the url at which its  
(head) can be fetched, then
there is no way to do much harm by faking the id of one's feed.

In conclusion a minimal feed format has the following advantages:
     - saves heavily on bandwidth (because of its RESTful nature)
     - removes the whole phishing problem
     - make it very easy to understand how to generate ids

So those are just a few thoughts on the topic. It just seems that if  
one works with
the web these phishing problems seem to disappear.

Henry Story

---

From: Tim Bray <[email-masked]>
Date: Fri, 20 May 2005 17:23:22 -0700

On May 19, 2005, at 1:38 PM, Sam Ruby wrote:

... MUCH text elided ...

> However, for it to work, the re-aggregator would need to have access 
> to a "self" link, which is not required by the current draft.

I do not agree that PaceDuplicateIDs was primarily designed to address 
the DOS-attack scenario, or even pretends to ameliorate that situation. 
  I think it primarily exists to support a bunch of scenarios where, for 
different reasons, people wanted to be able to generate feeds where 
entries might appear more than once.

---

From: Tim Bray <[email-masked]>
Date: Fri, 20 May 2005 16:51:14 -0700

> The editors request that text be provided.

In section 4.1.1, change the bullet point that reads

   atom:feed elements MUST NOT contain more than one atom:id element.

to read

   atom:feed elements MUST contain exactly one atom:id element.

Plus, take the ? off the atomId in the RNC immediately above.

Editorial oversight from anyone is welcome, I'm kind of tired. -Tim

---

From: Henry Story <[email-masked]>
Date: Sat, 21 May 2005 11:47:32 +0200

> set up etc), and once you allow it to change it is no longer  

Yes. I like the idea of being able to move entries around too.

But we do have a dilemma. We have
     a- non de-referenceable id:
          - can easily be faked
            -> lack of trust which undermines its ability to identify  
anything
     b- de-referenceable id:
          - we can't move entries around
          - but we can trust the id

Imagine we have both (as we do, but in a more cumbersome format).
If we give the entry a src attribute then we could have a feed such
as the following:

<feed>
     <id>http://a.com/feeda</is>
     <entry src="http://a.com/feeda/entry1">
         <id>urn:uuid:1225c695-aaa-4ebb-aaaa-80da344efa6a</id>
         <updated>2005-01-01T05:00+00:00</updated>
     </entry>
     <entry src="http://a.com/feeda/entry2">
         <id>urn:uuid:2225c695-bbb-4ebb-aaaa-80da344efa6a</id>
         <updated>2005-01-02T06:00+00:00</updated>
     </entry>
     <entry src="http://a.com/feeda/entry2">
         <id>urn:uuid:3225c695-ccc-4ebb-aaaa-80da344efa6a</id>
         <updated>2005-01-03T07:00+00:00</updated>
     </entry>
</feed>

Then since the ids can be faked and spoofed all over the place, and
since there is no way to automatically verify the correct uses, the
amount of trust that can be placed in them to identify an entry is
minimal, close to 0, certainly a *lot* less than the dereferenceable
src uri, which will therefore inevitably take the place of the
identifier.

So in any case it seems like the dereferenceable id wins. Perhaps this
is just something in the architecture of the web that we have to work
with.

But perhaps it is not such a problem after all, because perhaps we can
have dereferenceable ids that allow us to move entries around. I can  
think
of a few:

     - if an entry moves the old entry position redirects to the new  
one.
     - one creates a special redirect service to redirect ids to  
their current
       location
     - one creates a new URI to URL mapping protocol

Henry Story

---

From: Henry Story <[email-masked]>
Date: Sat, 21 May 2005 14:35:05 +0200

>> 3. one creates a new URI to URL mapping protocol

     I agree, but the question is whether they do their work better than
the one we are trying to give to a non de-refrenceable atom:id.

     I like the intent behind atom:id. But I don't think one can just  
hope
that things work out the way we would want them to.  For the moment  
there
is a  worry that the atom:id gear is just decoration, a magical place  
holder
for properties we would like something to have, but have no idea how  
to achieve.

If there are other solutions, it would be nice to hear of them in  
more detail.
I have heard that signatures could help resolve the problem. Perhaps  
we should
get a security expert to give some advice on a solution like that.

Henry Story

---

From: Henry Story <[email-masked]>
Date: Sat, 21 May 2005 14:51:34 +0200

On 21 May 2005, at 13:19, Graham wrote:
> The appropriate answer to this is to say comparing an id from a  
> document retrieved from one URI to an id retrieved from a second  
> URI is not reliable. This makes feed:ids largely useless. The  
> primary use, of comparing with a previous version of a document  
> retrieved from the same URI, is fine.
>
> Graham

That makes sense. But then it only gives one a very limited ability  
to move an entry from one place
to another. If the entry has to be located in the same feed, then  
presumably that means that it
would be difficult to move the entry from one domain to another.

Or is the following a necessary sequence for moving an entry from one  
domain to another:
  1. Entry e_id1 is referred to in feed f1 on domain d1 where it has  
location d1:loc1
  2. e_id1 is placed on domain d2 at d2:loc2
  3. feed f1 now points to d2:loc2 as the new location of e_id1
  4. e_id1's new representation in domain d2 somehow points to its  
new trusted feed f2
     also located on d2

It is complicated, but I suppose it could work.

Henry Story

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 14:06:22 +0100

> would be difficult to move the entry from one domain to another.

The feed becomes a redirect and the aggregator can reliably compare  
ids across the old and new addresses. Not hard.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Sat, 21 May 2005 08:44:14 -0600

On Saturday, May 21, 2005, at 12:30  AM, Bob Wyman wrote:
> disposition towards this issue. (Naturally, I object...)

I've tried to get discussion of this moving a few times with very 
little success.  Honestly, I've been a bit surprised that you 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 the past and the obvious 
significance to your business.  In the flurry of discussion of various 
issues that's been going on recently, I can't remember whether you've 
stated a specific opinion on the best way to solve the problem or not, 
and if so, whether it has been affected at all by discussion or related 
changes that have occurred since it's original expression.  Perhaps 
you, who are probably in a better position than any of us to speak from 
experience on how to deal with this, could refresh our memories of 
specifically what you think the best solution is.

---

From: Martin Duerst <[email-masked]>
Date: Sun, 22 May 2005 19:13:01 +0900

>> this).  Please indicate agreement or disagreement with this proposition

+1 here too.    Regards,   Martin.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 May 2005 18:15:38 -0700

At 2:30 AM -0400 5/21/05, Bob Wyman wrote:
>I

That's why we have signed documents, which are described fully in the 
document already. It is fine to add text to the signatures section 
explaining why they are useful against this attack, and a short 
mention in the Security Considerations section pointing back to that 
one.

Please note that every format that the IETF has ever come out with 
that isn't inherently signed has either this exact problem or one 
very close to it. The fact that the format document specifies a 
signing mechanism in the document itself instead of in a companion 
document that is read by only 25% of the implementers is a giant leap 
forward.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Tim Bray <[email-masked]>
Date: Sun, 22 May 2005 21:42:23 -0700

> +1 here too.    Regards,   Martin.

<co-chair-mode>Having reviewed the commentary over the last three  
days, I observe a couple of +1's, a few "not my favorite approach but  
OK", and no objections.   I see rough consensus in favor of making  
atom:id a compulsory child of atom:feed.</co-chair-mode>
  -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 23 May 2005 18:35:12 -0400

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 the past
> and the obvious significance to your business. ... Perhaps 
> you, who are probably in a better position than any of us to speak
> from experience on how to deal with this, could refresh our memories
> of specifically what you think the best solution is.
	Yes, this issue is very important to us at PubSub and should be very
important to others as well. However, as I've learned from other recent
discussions, my viewpoint is not commonly held in this Working Group. Thus,
what I've been trying to do is pick carefully the issues that I work on. For
instance, I've put a great deal of effort into multiple ids since that
allows us the freedom to either work out proprietary solutions to the DOS
problem on our own or allows us to punt the problem forward to the
end-users' aggregators if we can't come up with a decent solution. 
	Clearly, the best solution here would be for folk to use signatures.
But, that is going to take either a great deal of work to get adopted or
something really creative (and simple)... The history of attempts to get
signatures used does not make pleasant reading... We are putting effort into
working out methods to make signatures more acceptable to the community and
I hope to have some proposals soon... If we successful (wish us luck!) that
will at least provide a solution for some people...
	Basically, it doesn't make sense for me to keep demanding that
people deal with issues that they clearly don't want to address. I've been
mentioning the DOS problem for months now and getting nowhere. So, the
reason I'm not pushing harder is that it is clear that implementable
work-arounds will be more useful than never agreed-to "solutions"...

		bob wyman