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

On 2 Dec 2006, at 15:42, Henrik Nordstrom wrote:

> lör 2006-12-02 klockan 10:29 -0800 skrev Henry Story:
>
>> 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)
>
> 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?


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

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.

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

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

>
> Regards
> Henrik

Received on Sunday, 3 December 2006 00:50:36 UTC