W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: PROPPATCH Error minimization

From: <ccjason@us.ibm.com>
Date: Tue, 12 Oct 1999 19:04:54 -0400
To: w3c-dist-auth@w3.org
Message-ID: <85256808.007E5D9F.00@D51MTA03.pok.ibm.com>

It looks like "everyone" is against error response minimization for PROPPATCH.
Can we get this listed in the spec?

How about...


  8.2.1 Status Codes for use with 207 (Multi-Status)

   The following are examples of response codes one would expect to be
   used in a 207 (Multi-Status) response for this method.  Note,
   however, that unless explicitly prohibited any 2/3/4/5xx series
   response code may be used in a 207 (Multi-Status) response.

Insert before the first paragarph....

    The response to a PROPPATCH SHOULD always be 207 (Multi-Status).  No error
    minimization should be performed... even if all of the set and remove
    succeeded.  This even applies to 200 (OK) response codes.

I said SHOULD and not MUST because of protocol situations... like the resource
isn't found.  Am I correct?  Or is it *always* going to be Multistatus?

The problem I have with the above phrasing is that it might make it sounds like
the following
error minimization isn't allowed and I suspect it is...

               <D:status>HTTP/1.1 403 Forbidden</D:status>
               <D:responsedescription> The user does not have access to
   the DingALing property.

Are we prepared to eliminate this minimization?  (I am.)

Also note... if we say there is no minimization... that means even if the
PROPPATCH had to back out everything due to one error, the response will still
need to list all those 200's along with the single error that occured.  Does it
sound fine to outlaw the elmination of those 200's?

And a tangent...

Also, we don't say if a proppatch request can set a property several times.  I
guess it's implicit that it can.  That does make for somewhat more complex
server response generating code... unless we're going to allow each properties
to generate more than one response if altered multiple times.


Received on Tuesday, 12 October 1999 19:00:39 UTC

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