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