Subject: Close PaceErrVerb

From: Robert Sayre <[email-masked]>
Date: Thu, 26 Aug 2004 13:23:46 -0400

Now that PaceServiceError uses its own HTTP method, the only substantive 
differences are:

* payload
* whether error requests must be sent to the requestURI

PaceServiceError could easily be adjusted to accommodate either of these 
requirements, and is more thoroughly specified in almost every area they 
have in common.

Unless someone steps forward offering to complete PaceErrVerb, we should 
close it.

Robert Sayre

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 22:16:13 +0200

> * whether error requests must be sent to the requestURI

I still think PaceErrVerb is more RESTful in the way that the erronous  
resource is the one that is being ERRed upon, but the ErrorURI might of  
course be the same URI as the resource.

I think PaceErrVerb is simpler. No ErrorURI, just a method. ERR the  
erronous resource, and you're done. Add an explanatory request body if you  
want to say something more in your ERR.

> requirements, and is more thoroughly specified in almost every area they  

That's something I can agree with. PaceServiceError is much better  
specified, but a bit more complicated to implement. If we could try to  
implement some of PaceErrVerb's simpleness into PaceServiceError, I would  
be very happy. I'm also not sure if I like the GRUMBLE method. ;-)

> Unless someone steps forward offering to complete PaceErrVerb, we should  

I'm not against closing it if we agree on doing some changes in  
PaceServiceError. Those changes could probably be discussed off-list,  
unless everyone is interested in the discussion(?).

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Robert Sayre <[email-masked]>
Date: Fri, 27 Aug 2004 17:02:32 -0400

Asbjørn Ulsberg wrote:

>> Now that PaceServiceError uses its own HTTP method, the only 
>> substantive  differences are:
>>
>> * payload

ErrorURI is not required to be the same URI as the original request 
because this is not a realistic requirement for a large proportion of 
Atom deployment scenarios. Also, note that a second URI is likely more 
robust than sending a request to the resource that is known to be 
misconfigured.

> 
>> Unless someone steps forward offering to complete PaceErrVerb, we 
>> should  close it.
> 
> 
> PaceServiceError.

PaceServiceError has just recently incorporated an "ErrVerb". You can 
examine the numerous contributions from this list in the Notes and 
Discussion sections [0]. You may also wish to examine the precedents 
cited there: Pingback, Mozilla, and ebXML. If you're still interested, 
you can examine the 158 edits that the Pace has undergone[1].

I'm not saying the Pace is finished or even acceptable in principle. 
However, note that the only two contentious issues we've managed to be 
somewhat productive on (so far) are PaceSimpleResourcePosting and 
PaceServiceError.

Robert Sayre

[0] 
http://www.intertwingly.net/wiki/pie/PaceServiceError#head-70440046a3dc2e079f23ee1c57dfa76669b732aa
[1] http://www.intertwingly.net/wiki/pie/PaceServiceError?action=info

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 13:18:17 +0200

On Fri, 27 Aug 2004 17:02:32 -0400, Robert Sayre <[email-masked]>  
wrote:

> Atom deployment scenarios.

But could ErrorURI be the same as the original request's URI by default,  
then? So you have three layers of URI's, in this order of precendence:

   1. The original request's URI
   2. The URI in <link rel="service.error">
   3. The URI in the HTTP header 'X-Atom-Error'.

I also find it better to give this order of precedence than to say that  
«if X is different from Y, a report MUST NOT be sent».

If the HTTP header always has higher precedence than the two other URI's,  
it doesn't matter what the others are, and you don't have to compare them  
and do lots of other complex stuff. Just find the URI with the highest  
precedence and GRUMBLE that one.

> Also, note that a second URI is likely more robust than sending a
> request to the resource that is known to be misconfigured.

Yes, that's probably true.

> you can examine the 158 edits that the Pace has undergone[1].

I have, and I still think it needs some improvements to be simpler. Other  
than that, it's good. We can probably close PaceErrVerb.

On a side note: Why do you use the word «SHALL» instead of «SHOULD» some  
places? I know they mean the same (also by RFC 2119 terms), but isn't  
«SHOULD» more used and known to people? I also find that «SHOULD» reads  
better in the places you've used «SHALL».

   The request SHALL be a GRUMBLE. No other methods are currently
   specified for this URI.

could be rewritten to

   The request to the ErrorURI SHOULD be a GRUMBLE. No other methods
   are currently specified for this URI.

It would also be useful to mention the HTTP method «GRUMBLE» in all places  
where «request» is mentioned. E.g.:

   If the Atom Document violates any validity constraints of the
   Atom Format Specification, a request(5.6.3) SHOULD be sent to
   the ErrorURI.

could be:

   If the Atom Document violates any validity constraints of the
   Atom Format Specification, a GRUMBLE request (5.6.3) SHOULD be
   sent to the ErrorURI.

Just to make it clearer that it is the GRUMBLE method that should be used  
in all error requests.