W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2012

Re: Status of comment RC-2

From: Gregory Williams <greg@evilfunhouse.com>
Date: Tue, 25 Sep 2012 09:44:32 -0400
Cc: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-Id: <681ECE13-4BA2-495F-8A03-C4A7F5A51BF2@evilfunhouse.com>
To: "Polleres, Axel" <axel.polleres@siemens.com>
On Sep 25, 2012, at 3:41 AM, Polleres, Axel wrote:

> * 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)

I think adding any normative language about this would be a problem at this point, because it adds an implementation burden (either to implement it or fully consider why you're choosing not to), I haven't seen any real implementation concensus on this (and I don't entirely see the point of standardizing on text/plain), and because it throws off the timeline.

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

AFAIK, *nothing* would break for implementations that currently use http status messages if the spec was silent on their use.

> 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


Please note that the document currently does not "non-normatively recommend" the use of custom http status messages. It does, however, show their use in the example http traces.

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


I think using "or" language would be a huge mistake here. HTTP status messages aren't an alternative to a proper response body containing the error message (in some media type).

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


I could live with this. I assume this would mean changing some of the existing examples to not show the use of html error messages.

Received on Tuesday, 25 September 2012 13:47:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:07 UTC