2006/7/6, Kyle Marvin:
Honestly, the case I'm *most* worried about clients that keep bumping
their updated value just to keep their entry at the top of (or
reoccurring in) syndicated views of the collection ordered by
updated... i.e. a form of syndication spamming. Any spec-language
that keeps the server from preventing such types of abuse is a strong
-1 in my book, making the MAY in James' PACE necessary.
It's naive to think APP clients will always play nicely with others.
APP clients are not the only one to play with publishing Atom Feeds.
There are already a lot of Atom Feeds without APP (hence APP clients)
entering into play...
Correct me if I'm wrong, but a Blogger user could already spam the
world without APP:
"How do I change the date/time of my post?"
http://help.blogger.com/bin/answer.py?answer=139
APP could also be used in "private circles" for applications where
clients *must* be able to at least tell the server/application whether
the change is "significant" or not. Whether they're directly
communicating atom:updated values or sending a significant=yes|no flag
is not really significant here, as they won't change your spam issue.
As a content aggregator, however, you could still use heuristics to
detect spams: the same entry has been "atom:updated" three times in a
day with no "material" change (from our/aggregator point of view)?
we'll ignore subsequent changes of that entry unless we detect a
"material" change (using our heuristics); four entries in the same
feed are marked as potential spams (i.e. we use our heuristics rather
than trusting the atom:updated value)? mark the whole feed.
This would be necessary anyway, because not everyone's using APP...
--
Thomas Broyer
