Subject: Observations on the "error" discussion

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 4 Nov 2004 10:40:04 -0800

Wearing my "I am not an implementor" hat:

1) Most people seem to like the idea of an Atom error reporting 
facility, although some don't because they think it will never get 
used.

2) It is not clear whether or not this should be Atom-specific. Even 
the erstwhile W3C liaison to the IETF suggests that maybe the IETF 
making a generic change to HTTP for all error reporting is OK.

3) The reasons for wanting to reuse POST or invent a new verb are 
deeply religious, where "religion" is defined as a mixture of "my 
family has always done it this way", "bad things just might happen if 
you do it a different way", and "I'll ignore the fact that the other 
way has worked just fine in different environments". That certainly 
resembles how religion (and national politics...) works where I'm 
from.

Wearing my co-chair hat:

Given the vehemence of the arguments of the last day, I propose that 
consensus on *how* to do error reporting is not possible in the short 
term. Feel free to argue the "new verb" question ad nauseam (minus 
the pre-adolescent comments like calling people "mental"), but maybe 
don't expect your arguments to settle anything right now. And there 
are other open issues in the work rotation.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Danny Ayers <[email-masked]>
Date: Thu, 4 Nov 2004 20:13:24 +0100

Hi Paul,

Your summary of the situation seems reasonable. Most people to seem
generally in favour of the idea, but the implementation is causing the
heat. Much of the discussion has been along the lines of hypothetical
"it will work/it won't work". If the Paces get dropped we'll never
know. So why don't we set things up to try it? - both Paces accepted
for next draft, with the proviso that it will be revisited after a
reasonable trial period. (I personally believe PaceErrVerb to be
unlikely to work, but am willing to be convinced).

Cheers,
Danny.
-- 

http://dannyayers.com

---

From: Walter Underwood <[email-masked]>
Date: Thu, 04 Nov 2004 11:40:09 -0800

--On Thursday, November 04, 2004 10:40:04 AM -0800 "Paul Hoffman / IMC" <[email-masked]> wrote:
>
> 1) Most people seem to like the idea of an Atom error reporting facility,
> although some don't because they think it will never get used.

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

It is important to be able to figure out the feed software and version,
so we can say the AtomBrainCreature 13.1 is busted and get the word out.
But that requires notifying the implementor, not the publisher.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 4 Nov 2004 12:23:46 -0800

[[ Now wearing my advocacy hat ]]

>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...").

>But that requires notifying the implementor, not the publisher.

Overall comments:

I don't see reporting errors to the senders as enabling social 
pressure. To me, it is alerting senders that they software that they 
are using, which they probably didn't write (unless they are a 
subscription service), is emitting bad data. That gives the user a 
few options, such as alert the vendor, change software, and so on.

It *is* new ground, and I think it's good new ground. It lets Atom 
emitters know whether or not they are being good Atom citizens. It 
(hopefully) cleans things up early so that reader vendors have fewer 
features that they need to be bug-compatible with. Those are very 
positive, I think.

If the Atom emitter doesn't care, it is trivial for them not to 
listen, and trivial for them not even to tell receivers how to tell 
them something they aren't going to listen to. If they do care, even 
mildly, having a standard way of hearing about the errors is good. It 
will certainly make tech support for the developers of emitter 
software easier.

--Paul Hoffman, Director

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 04 Nov 2004 21:45:40 +0100

> publicising them, not telling the publisher (who might not care).

Telling the publisher would probably help in 50% of the cases. Maybe more.  
However, the actual number of cases it helps in isn't essential. What is  
essential is that it helps.

Having 100% wellformed and valid producing systems would of course be  
best, but until we have that, we need to take other measures to fix the  
situation. Maybe even Six Apart can implement the error mechanism into  
Movable Type so that ERR requests are routed to them after a local  
analysis, so they can improve their tool centrally.

None of this is possible without an ERR mechanism. We could of course just  
continue down the endless road of lobbying for better tools, but until we  
reach the end of that road (which we never will), all other paths are  
worth exploring.

> so we can say the AtomBrainCreature 13.1 is busted and get the word out.

Do you take the responsibility to publish this information centrally  
somewhere? Or do you want an automated mechanism that sends some sort of  
error report directly to the software vendor?

> But that requires notifying the implementor, not the publisher.

We need to notify both, but first and foremost the publisher -- it's his  
feed that's broken.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Martin Duerst <[email-masked]>
Date: Fri, 05 Nov 2004 12:33:53 +0900

At 03:40 04/11/05, Paul Hoffman / IMC wrote:

 >2) It is not clear whether or not this should be Atom-specific. Even the 
erstwhile W3C liaison to the IETF suggests that maybe the IETF making a 
generic change to HTTP for all error reporting is OK.

Just some clarifications, assuming you are referring to my message
at http://www.imc.org/atom-syntax/mail-archive/msg11139.html.

- Looking up 'erstwhile' at http://www.m-w.com/cgi-bin/dictionary
   gives 'former, previous'. Together with Dan Connolly, I'm actually
   the *current* liaison from the W3C to the IETF.

- The statement was not made with my liaison hat on. I'm participating
   in this WG just for myself. If I ever make a statement as a liaison,
   I'll say so (but I'd probably talk directly to people in the IAB and
   the IESG in this case).

- I wasn't commenting on the desirability of a generic change to HTTP,
   but only on where such a change might happen, assuming it was desirable.

- This was based on past history and current status of the HTTP spec
   (an IETF Draft Standard, not a W3C Recommendation), and not on any
   assumptions one way or another about what the two mentioned parties
   might want to do.

You can guess for yourself whether I wrote *this* mail with my liaison
hat on (because as a liaison, I have to make sure comments I make are
not misunderstood to come from W3C as such) or as an individual (because
as an individual, I have to make sure my comments as an individual
are understood as such, and correctly). Take your pick :-).

Regards,    Martin.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 4 Nov 2004 19:57:40 -0800

>   the *current* liaison from the W3C to the IETF.

Yuck. I've been using that word wrong for thirty years. And I've been 
corrected by a Swiss. :-)

>   I'll say so (but I'd probably talk directly to people in the IAB and

Noted.

>   but only on where such a change might happen, assuming it was desirable.

Understood.

>   assumptions one way or another about what the two mentioned parties

I'll talk about the general topic this week at the IETF meeting. I'm 
sure the WebDAV folks can speak to it as well.

>are understood as such, and correctly). Take your pick :-).

The Swiss are known for their interesting hats....

--Paul Hoffman, Director

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 5 Nov 2004 00:18:13 -0800

> 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/>

---

From: Danny Ayers <[email-masked]>
Date: Fri, 5 Nov 2004 12:04:29 +0100

On Fri, 5 Nov 2004 00:18:13 -0800, Roy T. Fielding <[email-masked]> wrote:

For example, a
> the HTTP server, to fix the problem?

A popular view is that end users don't care about data errors, they
simply want the information. An impact of this has been the
development of 'liberal' parsers. Yes, quite a few people on this list
saw some benefit in flagging errors to the end user, but I'm sure we
will see plenty of clients that silently ignore errors. But even if
errors are flagged, what is the end-user expected to do, especially
when they can still read the feed data thanks to cleaning heuristics?

> software and post a "hall of shame" web page that explains the errors.

Sure. But these kind of techniques are already available for RSS (e.g.
Syndic8). Yet there are still plenty of applications that (usually
intermittently) deliver ill-formed data.

Because there are other techniques doesn't mean the technique being
proposed isn't desirable.

> its own reads.

Do we have evidence of that in the context of syndication?  I suspect
that the vast majority of errors are above the HTTP level. Most
clients ignore the XML mime RFC, but assuming they've guessed a
workable encoding they can tell if the XML is ill-formed or not.

> of differentiating between broken feeds and features that are simply

Separate issue. We do need to sort out versioning so that a client can
tell the difference between a broken feed and a different version.

> why the feed is broken.  

Depends on the nature of those logs. If the information appears in a
prominent place in the content management system, the right people
will see it.

> Third, it is a waste of bits. 

Quite the opposite. If the error isn't reported, then the publisher
will continue to serve bad data to the million clients indefinitely.
Even if it takes a billion reports before something is done, thats
still bless wasteful than open-ended junk distribution.

> source of feed errors may have no relation to the feed source.

If they are supplied in a reasonably functional architecture, then the
errors won't be occurring en route. Again, do with have evidence that
this is the likely case in syndication?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 05 Nov 2004 14:56:22 +0100

> sure the WebDAV folks can speak to it as well.

I hope you can summarize the discussion on the list after the meeting. It  
would be especially interesting to hear what the WebDAV folks has to say  
about the issue.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Nov 2004 15:01:10 +0100

Asbjørn Ulsberg wrote:
> 
> On Thu, 4 Nov 2004 19:57:40 -0800, Paul Hoffman / IMC 
> <[email-masked]>  wrote:
> 
> I hope you can summarize the discussion on the list after the meeting. 
> It  would be especially interesting to hear what the WebDAV folks has to 
> say  about the issue.

As far as I can tell, many of the "WebDAV folks" (Greg, Lisa, Stefan, 
myself) are following this list anyway.  If the question was: "is there 
any significant problem defining new HTTP methods?", then my answer is: 
"none at all".

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Danny Ayers <[email-masked]>
Date: Fri, 5 Nov 2004 15:16:12 +0100

> any significant problem defining new HTTP methods?", then my answer is:

How about "is there any significant problem getting those new methods
adopted and deployed to the extent that they are available to the
majority of Web users?"

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Nov 2004 15:33:10 +0100

> adopted and deployed to the extent that they are available to the

As far as I can tell, there is no such problem. The most popular web 
servers (Apache/moddav, IIS) implement WebDAV, and clients are available 
for Windows/Linux/OS-X. Occasionally we hear of people having trouble 
with broken proxies, but as far as I can tell, this is really rare nowadays.

Best regards, Julian

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 05 Nov 2004 16:13:54 +0100

On Fri, 05 Nov 2004 15:01:10 +0100, Julian Reschke <[email-masked]>  
wrote:

> myself) are following this list anyway.

True.

> If the question was: "is there any significant problem defining new
> HTTP methods?", then my answer is: "none at all".

Ah, brilliant. Thanks.

---

From: Mark Baker <[email-masked]>
Date: Fri, 5 Nov 2004 10:21:27 -0500

Big +1 to all points.

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 5 Nov 2004 11:34:58 -0800

On Nov 5, 2004, at 3:04 AM, Danny Ayers wrote:
> simply want the information.

That would obviously depend on the nature of the error and how it
impacts the information.  I don't know of anyone who thinks silent
acceptance of errors is a good thing.  I did not suggest something
stupid like a pop-up box that interrupts the user and asks that
they confirm that the server's software sucks -- there are many
ways to indicate an error such that it won't even be noticed by
those users who don't care.

   <http://www.w3.org/TR/webarch/#error-handling>

> An impact of this has been the

The first end-user is almost always the author of the feed in question,
particularly when new software is deployed.

> proposed isn't desirable.

No, it just means it isn't needed.  The technique is undesirable
for other reasons.

> workable encoding they can tell if the XML is ill-formed or not.

No, we don't have "evidence" of that in syndication -- we only have
experience that can be drawn upon from 11 years of deploying services
on top of HTTP.  Generally speaking, sending an HTTP server an error
message means it will be read either by no one or by the HTTP server
maintainer, not the application maintainer.  I know that for a fact
because I wrote one of the first log analyzers (wwwstat) and have
dealt with Apache httpd users since day one, and not once have I ever
encountered an application developer that quoted from the error_log
(even when the documentation specifically says to look there first).

> this is the likely case in syndication?

Proxies are hard to do right.  I am not aware of any HTTP proxies
in current use that do not introduce errors to the stream under
some circumstances, in spite of the specifications being stable
for six years now.

Cheers,

---

From: Robert Sayre <[email-masked]>
Date: Fri, 05 Nov 2004 14:54:57 -0500

If it won't work, that's cool. But let's not pretend we are choosing an 
alternative solution. We are choosing Broken. That's fine.

A couple points:
1.) Weblog software doesn't typically make use of the server's logs, so 
this is not creating work for the sysadmin.
2.) There's no reason the responses couldn't be cached. Hearing from one 
client is enough (the Pace doesn't specify a request body).

Other points in the email seem plenty valid.

*exits superhighway

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Fri, 5 Nov 2004 21:57:20 +0100

> (even when the documentation specifically says to look there first).

Sure, and I very much respect your contributions in the field. But the
kind of error reporting being suggested is a move away from server
logs, much more under the application maintainer's nose. Your comments
here seem to presuppose that error reporting will primarily be
concerned with problems at the transport level. I believe current
syndication practice would suggest that most problems are going to be
within the XML - I'd like to hear Sam's opinion on this (with his
feed-validator-author's hat on).

But overall I don't think any of the possible problems you highlighted
signal any systematic flaw with error reporting of the kind under
discussion. It might not work, but then feed quality is a real issue,
and IMHO anything that may help should be worth a try.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Sam Ruby <[email-masked]>
Date: Fri, 05 Nov 2004 17:45:19 -0500

> feed-validator-author's hat on).

The largest classes of errors deal with escaping and encoding - and 
incorrect content type.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Fri, 05 Nov 2004 15:55:12 -0800

On Nov 5, 2004, at 12:18 AM, Roy T. Fielding wrote:

(lots of stuff ... )

> Sending feedback to the HTTP server is a bad idea.

(lots more stuff ... )

While I grant the force of Roy's arguments, I have two points of 
disagreement.  First, my experience of feed errors does not accord with 
his hypotheses; they are often in places that can be deterministically 
detected by a client and helpful feedback provided.

Second, and this is crucial, the error reporting is completely at the 
discretion of the server.  The server can, if and only if it chooses, 
provide a ServiceError URI.  If so, it's presumably ready to get 
reports and will do something more useful than dump them into 
logs/error_log.

If it's getting too many complaints to handle, or the complaints are 
malformed and not a source of useful information, all it needs to do is 
stop providing the URI and it'll stop getting them.  (Although in 
either of these cases, they are probably usefully diagnostic of 
problems in the system that would benefit from someone's attention).  
By Roy's analogy with WebDAV, if there is widespread deployment of 
clients that (a) are incorrect in their intepretation of the spec and 
(b) are prone to griping voluminously at ServiceError URIs, then 
servers will stop providing ServiceError URIs.  If not, some will 
provide them and this will be helpful in shaking errors out of the 
system.

To summarize, this *could* be misused, and it *could* be a source of 
high-volume irritation, but if it's clear that it can always be turned 
off by the server, then I think the benefit exceeds the (possible) 
cost. -Tim

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 5 Nov 2004 17:13:46 -0800

On Nov 5, 2004, at 3:55 PM, Tim Bray wrote:
> disagreement.  First, my experience of feed errors does not accord 
> with his hypotheses; they are often in places that can be 
> deterministically detected by a client and helpful feedback provided.

I wouldn't disagree with that -- my point was that sending it in an
automated HTTP message means it will go to the wrong person.

> reports and will do something more useful than dump them into 

How is that configured?  Is it an httpd config setting, a script 
setting,
or data within the feed heading?  Is it somewhere that a webmaster
supporting several thousand feeds is going to be able to control?
How does that tie in to managing a separate resource per feed for
the purpose of accepting error notifications.  How does that information
get to the right person who can fix the software?  How is that 
consistent
with other folks claiming that the notification contains no data on
what the error was, let alone how to fix?  How many web servers do you
know of that allow anyone on the Internet to write unknown amounts of
data to a location somewhere other than a controlled logs directory?

As opposed to, for example, just encouraging readers to send a friendly
comment to the person whose writing is being syndicated.

Quite frankly, I find this whole discussion to be rather silly.
Keep it simple and you will succeed -- bog it down with a bunch of
questionable features and people like me won't even bother to
read the specification (and I read quite a few more than the average
software developer).

Someone who is concerned about the quality of their feed will test
that feed with clients that can point out errors, assuming there exist
client authors who don't have MSIE disease and are advised that
showing errors is a good thing.

Someone who doesn't care about the quality of their feed will neither
test it nor enable something like ServiceError.

The only thing that automated error reporting accomplishes is to make
the protocol harder to completely implement, while encouraging a bunch
of well-meaning authors to waste bits by sending error URIs for feeds
that they already know are valid.

Anyway, I've said my bit and feel no more need to elaborate.  I won't
implement it.

....Roy

---

From: Lucas Gonze <[email-masked]>
Date: Fri, 5 Nov 2004 15:26:24 -1000 (HST)

Speaking as a publisher who cares a lot about valid output, I'd much 
prefer an error checking service that gave me reports via a feed. 
Accepting reports from user software is likely to create a mess and eat up 
resources.

- Lucas