Subject: Re: ERR header (NEW ISSUE: Drop Content-Location)

From: Henry Story <[email-masked]>
Date: Sat, 2 Dec 2006 10:29:25 -0800

Very good points below. I have developed the idea following your  
final suggestion. Here is an improved sketch of how this could work.

---------8<---------------------------------
ERR /page0 HTTP
Sender: W3C
Signature: W3C signature
Conten-Type: application/rdf+n3
Cache-Control: XXX?

@prefix : <http://w3c.org/err> .
@...

<http://err.w3c.org/bug123231> a err:bugReport;
    err:initialRequest [ :method "GET";
                         :resource <http://eg.org/page0>;
                         :header "Accept: text/html"; ];
    err:response [ :header ...;
                   :body "<xml>...</xml>";
                 ];
    err:comment "the response...";
    err:relevantSpec <http://...>;
    err:relevantDiscussion <...> .
---------8<---------------------------------

So here I am thinking that the ERR method would not be implemented by  
any clients, but by specialized ERR reporting agents, owned perhaps  
by the W3C, google or other responsible bodies, that can afford a  
signature to identify themselves.

It is true that a request does not necessarily always travel the same  
route, through the same proxies. But similar bug reports will more  
often go through the same proxies than not. Perhaps one also needs a  
way to ask for proxy traversal information on a request, so that one  
can trace where the error is located?

On 29 Nov 2006, at 15:15, Joris Dobbelsteen wrote:
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Henry Story
>> Sent: woensdag 29 november 2006 23:19
>> To: Henrik Nordstrom
>> Cc: Roy T. Fielding; Anne van Kesteren; HTTP Working Group
>> Subject: Re: NEW ISSUE: Drop Content-Location
>>
> [snip]
>>
>> Could that be solved my creating a ERR method, so that clients
>> could send feedback to servers at the resource they found wanting?
>>
>> ------------------
>> ERR /page0 HTTP...
>> ...
>>
>> Your Content-Location is broken see spec xyz
>> ------------------
>>
>
> This feature was discussed before.
> See <http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/>.
> Also see <http://www.imc.org/atom-syntax/mail-archive/ 
> msg05546.html> for
> somewhere in a discussion.
>
> I personally think this is a bad idea.
>
> The most important reaon for this is that the ERR reporter *must* be
> guarenteed to have correctly implemented the specifications. Thus it
> should not contain bugs and certainly not generate incorrect reports.
> I'm also wondering how future revisions of the spec might affect  
> current
> deployments that would have such a feature.
> Unless this issue can be solved it seems an inappropriate feature.

ok. So my idea is that clients who use it should identify themselves  
with a signature. Then intermediaries can listen to those ERR  
requests from agents they trust.

>
> Other reasons against it are:
>
> (1) The issue is put by the administrator of the system, rather  
> than the
> developers of the proxy. It generates extra bandwidth and  
> administrative
> overhead for owners of web servers (massive error requests).

Ok. So perhaps it is not a good idea to place this into generalised  
clients, since they may be out of date. If one did the feature should  
never be automated (it should require human intervention)

> (2) How would you blame an specification violating system in-between,
> such as a proxy server?

Could one do this with a header on a request to trace the proxies  
through which the request went?
Perhaps also a header on the ERR call to specify that it is likely an  
intermediary problem. It may be of interest to the resource holder,  
that intermediate proxies are breaking access to his resource...

> (3) It increases server load without any likelyness of solving the
> problem anytime soon. That would be up to the implementor and their
> priorities.

Only if everyone implements it badly. And that would be easy to  
ignore. I can't imagine it getting ever as bad as SPAM email: there  
would be no economic motivation to do this.

> (4) It does not prevent specification ambiguities. This leads to dirty
> implementation hacks in the hope the spec would follow or at least
> reduce errors. The spec has a very slow release cycle, it takes at  
> least
> several months before the spec is updated.

Good point. So the body should point to the relevant specs.

> Of course there are good reasons to support it:
>
> (A) It creates more momentum to keep non-conforming servers up to  
> their,
> hopefully better, latest versions and specification conformance.
>
> My suggestion:
> An official test suite.
> Ideally it would be possible to extract the rules immediately from the
> specs. Maybe the specification should use symantics that could be
> automatically proven ;)
>
> This is just my opinion...
>
> - Joris

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 03 Dec 2006 00:42:04 +0100

> never be automated (it should require human intervention)

If that's the case, what's wrong with using email to webmaster@...?

If webmaster is ignored even from trusted sources, why do you think
authors will care about an ERR method? Or why would this be the solution
to webmaster@... being ignored?

Other efforts is working on the question of trustworthy email.

I think I have now completely lost the picture on when/why adding an ERR
method may be useful to the level that it outweights the negative
aspects or cost of deployment.

Regards
Henrik

---

From: Henry Story <[email-masked]>
Date: Sat, 2 Dec 2006 16:50:27 -0800

> If that's the case, what's wrong with using email to webmaster@...?

You may not know the email. And the service provider may not want to  
make the email public. The resource is public, why create more public  
resources?

> to webmaster@... being ignored?

The webmaster is not ignored. The problem is that it is an extra step  
to find the web master. That extra step may cost a lot more time and  
energy than the perceived value of the error that one wishes to report.

> aspects or cost of deployment.

I suppose the idea was that you know the name of the resource to  
which you did a GET, and you may not know the name of the webmaster.  
Furthermore the webmaster may not be the person in charge of the  
resource.

The idea is that the ERR method would be the most direct way to send  
a warning message to the resource itself. There is no guessing  
involved there, no danger of some intermediary resource to email  
mapping file being out of date, a more direct path to the owner of  
the resource.
For example the webmaster could just redirect all ERR messages to the  
owner of the resource. (after passing it through some filter perhaps)

Henry

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Dec 2006 10:59:35 +0100

> aspects or cost of deployment.

The interesting part (to me) is that essentially the deployment cost for 
a simple version of ERR is zero: servers that don't know it are likely 
to log it; which may be completely sufficient if the server admin 
occasionally looks at the log files.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 03 Dec 2006 15:49:43 +0100

lör 2006-12-02 klockan 16:50 -0800 skrev Henry Story:

> You may not know the email.

RFC2142

Regards
Henrik