- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Tue, 25 Sep 2012 09:44:32 -0400
- To: "Polleres, Axel" <axel.polleres@siemens.com>
- Cc: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
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 +1 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?) -1 > 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. -1 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) +0.5 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. .greg
Received on Tuesday, 25 September 2012 13:47:59 UTC