W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

Re: Proposal for an HTTP ERR method

From: Asbjørn Ulsberg <asbjorn@tigerstaden.no>
Date: Thu, 24 Jun 2004 22:25:30 +0200
To: "Alex Rousskov" <rousskov@measurement-factory.com>, "Henry Story" <henry.story@bblfish.net>
Cc: ietf-http-wg@w3.org, "Atom Syntax" <atom-syntax@imc.org>
Message-ID: <opr938csapuvpchu@quark>

On Wed, 23 Jun 2004 12:20:58 -0600 (MDT), Alex Rousskov  
<rousskov@measurement-factory.com> wrote:

> If the bug-reporting protocol is designed to target humans, it should
> be optimized/tailored for human consumption. Henry's original premise
> was that the ERR protocol is designed to help future machines to fix
> themselves.

I think the automatic machine-fixable scenario was more a bonus to this  
proposal, not the premise. Henry needs to correct me if I'm wrong, but the  
proposal is mainly about having some standardized way to notify to a  
server that a given resource is broken. The obvious way to notify that a  
resource is broken, was for both me and Henry to ERR the actual broken  

But, you've made some points during the last posts that the entity behind  
the URI being ERRed may not be the same as the entity that served the  
broken resource in the first place. However, I'm not convinced how  
applicable this scenario is for Atom. Atom will mostly be served from  
personal weblogs, in very low-scale hosting environments. The chance of  
requesting the same resource from the same entity twice in a row is, in  
the case of Atom feeds, probably more than 95%. So first doing GET on a  
URI, and then ERR the same URI, will more than most likely send the  
request to the exact same entity twice.

But as this proposal is trying to cover more than just Atom use cases, all  
use cases must be taken into account. Your comments have been proven very  
valuable in my thoughts around this, Alex. Thanks.

Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»
Received on Thursday, 24 June 2004 16:23:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:37 UTC