vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?)

[Daniel Chudnov]

See below for background.  This thread seems like a lifetime ago
somehow. :)  I know I said we shouldn't revisit decisions we've already
made, but it seems best to first consider removing all mentions of
particular status codes from the normative portion of the spec.

Please vote on this whole change as a full diff; if you don't like
part of it for any reason, vote it down, and we'll amend for another
vote.

  -Dan


Proposed change:

 - Change the last para under How it works which now reads:

   "To minimize the scope of this specification, unAPI uses existing
   HTTP status codes with the meaning most appropriate for a particular
   unAPI response. See the section "Notes on HTTP status codes and error
   handling" below for a detailed summary."

   ...to instead read:

   "unAPI uses the response status codes defined in HTTP [RFC 2616] to
   indicate the success or failure of an operation.   See the section
   "Recommended HTTP status codes and error handling (non-normative)"
   below for suggestions of particularly useful status codes."

   (note: the first line is verbatim from APP.)

 - In the UNAPI (no parameters) response section, first para, remove the 
   text:

   "status code should be 200."

 - In the UNAPI?uri=URI response section, second para, remove the text:
   
   "status code should be 300 (Multiple Choices)"

 - Retitle the "Notes on HTTP status codes and error handling" to:

   "Recommended HTTP status codes and error handling (non-normative)"

   ...and rewrite its content to say:

   "unAPI defers to the response status codes already defined in HTTP
   [RFC 2616].  In particular, it is recommended that unAPI implementors
   utilize the following:

   * 300 Multiple Choices - the UNAPI?uri=URI function 

   * 404 Not Found - requests for a URI that is not available on the
   server 

   * 415 Unsupported Media Type - requests for a URI that is available
   on the server but for a format that is not available for that URI

   Note that this list is provided as a guideline to encourage consistency
   across implementations.  All HTTP status codes are relevant for any
   web resource; these status codes are particularly germane for unAPI."





Daniel Chudnov wrote, on Mon, Mar 06, 2006 at 11:00:36AM -0500:
> Xiaoming Liu wrote, on Mon, Mar 06, 2006 at 08:04:05AM -0700:
> > 
> > Thanks for catching key point for me. It's really about whether these 
> > status code are recommendation/best practice, or mandatory. I am much 
> > comfortable if we put them as recommendation, therefore not part of 
> > compliance check.
> 
> Okay, so, I think we're converging on the same point here:  we defer
> to HTTP itself, but maybe suggest a few particular codes.  Maybe the
> suggestions are even non-normative, and we don't require specific response
> codes for "unAPI compliance".
> 
> Does anyone want to take a stab at rewriting that final bit on HTTP codes?

-- 
Daniel Chudnov
Yale Center for Medical Informatics
(203) 737-5789