Subject: Re: PROPPATCH Error minimization

From: [email-masked]
Date: Thu, 7 Oct 1999 17:44:37 -0400

Say we invoke PROPATCH so that it sets property1 and property2 on resourceX.

if both of these return an error, I believe we are allowed to return...

...
<HREF>resourceX</HREF>
<PROPSTAT>
   <PROP>
      <property1/><property2/>
   </PROP>
   <STATUS>HTTP/1.1 409 Conflict</STATUS>
</PROPSTAT>
...

but are we allowed to skip the PROP tag if all of the element have the same
result?...

...
<HREF>resourceX</HREF>
<PROPSTAT>
   <STATUS>HTTP/1.1 409 Conflict</STATUS>
</PROPSTAT>
...

And are we allowed to skip the PROPSTAT altogether and just return a status for
the URI?...

...
<HREF>resourceX</HREF>
<STATUS>HTTP/1.1 409 Conflict</STATUS>
...

Or even return it in the response header?

Does this change if the response code is "200 OK" rather than 4XX?

If the spec doesn't already do so, it should provide a guideline here so that
clients know all the possibilities to expect and can code for them.

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: [email-masked]
Date: Mon, 11 Oct 1999 09:24:11 -0400

Stripping the response down to just a "200 OK" from a multistatus would be
a Serious Pain.
Note: This would be a client's responsibility and the client might already
require that it first determine if there are any errors before it actually
processes them individually.  In that case, the minimization code would need
to be there anyway.  DAV4J already has this in the client code... but it's
nice to define what minimizations are allowed to deal with the code that
iterates through the errors... which might be expressed in various ways...
and perhaps some that the coder hasn't thought of... unless we limit the
possibilities.

> I'd vote against this kind of response compression.
That's 2 - 0 against minimization so far.  It sounds like both votes
are against any minimizations.

Anyone else?

---

From: [email-masked] (Tim Ellison OTT)
Date: Tue, 12 Oct 1999 09:34:48 -0400

I'll cast my vote against error minimization for the same reasons that Bill 
describes below.

Tim
 ----------
>From: WJCarpenter
>To: w3c-dist-auth
>Subject: Re: PROPPATCH Error minimization
>Date: Monday, October 11, 1999 2:14PM
>
>gs> Stripping the response down to just a "200 OK" from a multistatus
>gs> would be a Serious Pain.
>
>I thought we weren't talking about a mandatory conversion.  I can see
>how doing that could be tricky for some server set-ups.  However, I
>don't think this specific case would be much trouble for client
>implementors.  (It doesn't really simplify anything either, since the
>client has to be prepared for the non-simplified case anyhow.)
>--
>[email-masked]   (WJCarpenter)           PGP
>[email-masked]                    0x91865119
>38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
>
>

---

From: [email-masked]
Date: Tue, 12 Oct 1999 19:04:54 -0400

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

How about...

Was...

  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
operations
    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:propstat>
               <D:prop><R:DingALing/><R:Random/></D:prop>
               <D:status>HTTP/1.1 403 Forbidden</D:status>
               <D:responsedescription> The user does not have access to
   the DingALing property.
               </D:responsedescription>
          </D:propstat>

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.

Comments?

J.

---

From: [email-masked] (Tim Ellison OTT)
Date: Wed, 13 Oct 1999 11:05:36 -0400

<jason>
    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?
<jason/>

<tim>
If the server backs out changes then the 200's would become 424-Failed 
Dependency's wouldn't they?
</tim>

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

<tim>
I guess it would.  Imagine
     <set>foo
     <remove>foo
     <set>foo
Since the order of the responses is not guaranteed (i.e. error minimization 
may rearrange the propstats) I may get
     <propstat>foo & foo = Failed Dependency
     <propstat>foo = Conflict
So which of the update directives generated the conflict?
</tim>