Big +1 to all points.
On Fri, Nov 05, 2004 at 12:18:13AM -0800, Roy T. Fielding wrote:
>
> On Nov 4, 2004, at 12:23 PM, Paul Hoffman / IMC wrote:
> >At 11:40 AM -0800 11/4/04, Walter Underwood wrote:
> >>I object for a different reason.
> >>
> >>It seems to me that it is trying to enable a social pressure on feeds
> >>that don't meet the standard. I think this is new ground for a
> >>protocol
> >>standard. Usually, implementation validation is a separate phase, and
> >>not
> >>part of normal operation.
> >>
> >>I know we are all really tired of busted HTML and XML, but this
> >>doesn't
> >>seem like it solves the problem. Getting rid of bad feeds requires
> >>publicising them, not telling the publisher (who might not care).
> >
> >I see a conflict between your first sentence ("It seems to...") and
> >your last ("Getting rid of...").
>
> I don't -- Walter's comment is spot-on. If we want folks to fix bad
> software, then include a UI requirement that the recipient include
> or render an indication that the feed is broken. For example, a
> headline
> that says "Received feed contained errors due to SOFTWARE THAT SUCKS
> or temporary communication errors." Guess how long it will take for
> the real maintainer of that feed, not the poor dudes trying to support
> the HTTP server, to fix the problem?
>
> Another method of doing the same thing is to simply test the bad
> software and post a "hall of shame" web page that explains the errors.
>
> Sending feedback to the HTTP server is a bad idea. First, feed errors
> are more likely to be caused by bad client software that mishandles
> its own reads. If Microsoft's Web Folders sent an error every
> time it received a WebDAV message that it considers to be an "error"
> (i.e., every message it received from a standards-compliant server),
> WebDAV would never have made it to proposed standard.
>
> Should we encourage Atom 0.3 clients to send an error message whenever
> they receive a Atom 1.0 feed? How about when 1.0 clients receive a 1.1
> feed? What on earth makes people think that client software is capable
> of differentiating between broken feeds and features that are simply
> unknown to that client?
>
> Second, the people who read error logs are not the people who care
> why the feed is broken. People who manage web servers have a tendency
> to delete software that results in large error logs and then forbid
> reinstallation of any *similar* software in the future. Their job
> is to maintain business critical functions, not play hand-maiden to
> a bunch of bloggers. Automated error reporting is a great way to
> discourage companies from deploying Atom.
>
> Third, it is a waste of bits. If a feed is broken, it might be useful
> for one client to report that fact to the owner of the feed (not the
> web server). It is never appropriate for all clients to report the
> error, since clients frequently outnumber servers by 10,000:1 and
> sometimes millions to one. When I receive 10,000 lines in an error log,
> I don't evaluate the range of potential options for other software -- I
> simply turn the reporting option off and/or delete the software that
> caused it.
>
> Finally, if feeds are supplied in a reasonably efficient architecture
> that can take advantage of hierarchy and proxies, then the actual
> source of feed errors may have no relation to the feed source.
> If a company like AOL installs a broken proxy that corrupts the data
> stream in a minor way, do we think it is a good idea for the
> 50 million clients behind those proxies to suddenly start sending
> feed error requests to every origin's report URI? And, no, this
> can't be solved by requiring that the reporting URI be a hop-by-hop
> header field, since those proxies aren't HTTP/1.1 compliant anyway.
>
> In short, there are many reasons that HTTP does not already contain
> such an error reporting feature, and none of them are due to not
> considering it as an option. If the road to hell is paved with good
> intentions, then automated error reporting is surely a superhighway.
>
> If we want to ensure that feeds work, then insist that the client
> software display error indicators around broken feed data, thereby
> providing both sufficient information to the feed owner and a
> warning to the client's owner that they might not be reading the
> true source. That is sufficient to cause people who care to report
> the problem, assuming the author doesn't notice it immediately,
> and does not cause the Internet harm in the process.
>
> Given that, deciding which method to use is irrelevant. Furthermore,
> use of "X-..." as a prefix for a header field name in a specification
> is contrary to the meaning of those names in MIME, and therefore
> forbidden in a standards-track proposal. In any case, HTTP doesn't
> use that lame method of indicating private header fields because of
> the many times that damn fools have released public software that uses
> X-prefixes, even though the only reason X-prefixes are supposed
> to be safe from collisions is because they are not allowed to be
> standardized! Go figure.
>
>
> Cheers,
>
> Roy T. Fielding <http://roy.gbiv.com/>
> Chief Scientist, Day Software <http://www.day.com/>
>
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
