RE: Status of comment RC-2

Dear all,

I have no specific stake in the ground on this issue, but I would like 
to ask two questions the other way around: 

* Who would object against proceeding the way Richard sugggests?
(Noting that such normative change would imply probably 
 another LC, I am inclined to object, actually)

* Also, do we already have implementations that do use HTTP status 
messages as we suggest (which would break if we now adopt Richard's proposal?

Conequently, I see the following options (please let me know if this summary 
it correct):

------------------------------
Option 1) keep everything as-is (non-normatively recommend to 
          return error messages in the form of HTTP status messages) 
          and live with Richard's potential objection

Option 2) recommend to return error messages in the form of 
          text/plain *normatively* (that's what Richard wants, 
          but requires another LC, right?)

Option 3) describe *both* options to convey error messages 
          *informally only*, namely 
             a) return errors in the form of HTTP status messages, or 
             b) return errors in the form of text/plain
          without recommending either and putting standardization 
          of a particular behaviour to the future work items list.

Option 4) return error messages in the form of text/plain *informally only* 
          (i.e. adopting Richard's suggestion, but in a weaker form that doesn't 
           require another LC)

------------------------------

My personal votes are as follows:
 Option 1)  0
 Option 2)  -1
 Option 3)  +1 (in case we already have implementations that do use HTTP status messages)
 Option 4)  +1 (otherwise)

Best,
Axel
 

> -----Original Message-----
> From: Gregory Williams [mailto:greg@evilfunhouse.com] 
> Sent: Montag, 24. September 2012 21:11
> To: SPARQL Working Group
> Subject: Status of comment RC-2
> 
> I talked a bit with Richard Cyganiak off-list last week about 
> his outstanding comment (RC-2) regarding error messages in 
> the Protocol spec. I tried to explain the reasoning behind 
> our recent desire to use non-normative language to suggest 
> the use the HTTP status message line to indicate the type of 
> error (while otherwise leaving the format of error messages 
> un-specified). He is not happy with this approach, suggesting 
> that limitations of existing software makes the use of the 
> http status message difficult or impossible in many cases.
> 
> He is still suggesting that the protocol normatively 
> recommend (but not require) that error messages be returned 
> as text/plain, encouraging interoperability of tools that 
> need to produce and consume errors generated by endpoints.
> 
> We've talked about this before without reaching consensus. 
> Would WG members support Richard's suggested changes on 
> normatively recommending the use of text/plain errors?
> 
> thanks,
> .greg
> 
> 
>

Received on Tuesday, 25 September 2012 07:48:20 UTC