- From: Keith Moore <moore@cs.utk.edu>
- Date: Wed, 29 May 2002 22:20:35 -0400
- To: Rob Lanphier <robla@real.com>
- cc: Tim Bray <tbray@textuality.com>, "www-tag@w3.org" <www-tag@w3.org>
I'd like to suggest a different architectural tack - Errors should be detectable by, or communicated to, the party that is in the best position to fix them. It seems obvious, yet most networked applications fail this criterion. This implies that errors in content (improper formatting, bad links, etc) need to be reported to the source of that content. (how to do this in HTTP is left as an exercise...) If the error is also reported to the recipient of that content, that's fine, and it may be useful to inform the recipient that because the content contains detectable errors it might not be properly displayed, etc. But by itself it won't have any significant effect. Of course, it's also possible that the recipient's client has a software bug which causes it to misinterpret legal and properly-labelled content as an error and to report it. Servers would quickly learn to identify the broken clients (assuming those clients identified themselves accurately), and ignore their error reports (or adapt their content). Keith
Received on Wednesday, 29 May 2002 22:21:23 UTC