RE: Marshalling Depth > 0 responses for REPORTs, WAS: Replacing t he Label header with a DAV:labeled-version report

Summary of the issue:

Julian would like to move the marshalling of Depth REPORT responses
from the DAV:prop node in a DAV:response to a new DAV:report-result
node in the DAV:response.

Summary of my response:

RFC3253 states that the marshalling is in the DAV:prop node, and
we should not change that unless there is some significant problem
with that marshalling.  I see no such problem, and therefore vote
to leave the spec as it is.

Detailed response below:

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   IMHO, marshalling something that isn't a resource property inside a
   multistatus/response/propstat/prop element clearly breaks RFC2518
   [1] and is very confusing.

I disagree on both counts.

RFC2518 says nothing about a REPORT method, so the response format of
a REPORT method cannot break RFC2518.  We have already concluded that
in earlier threads that each method effectively introduces a new DTD
for any XML elements in the response body.

So that leaves the question of whether it is "confusing".  I agree
that it is desireable to have consistent DTD's for a standard XML
element, across all methods (preferably even across request and
response bodies).  But the only difference between a "report result"
and a "live property value" is that a report can take arguments that
modify the result ("value") of that report for a given resource.  In
particular, a report that has a default value for omitted arguments
acts exactly like a "live property".

So in the interest of keeping the DTD's of standard XML elements
consistent, I believe it is desireable to avoid having a standard
report result XML element be the same as a standard property value XML
element, to avoid having significantly different DTD's for the same
standard XML element.  This is what is indicated in RFC3253 by having
the report result appear in the same context (i.e. under a DAV:prop
element) as property values.

   If this behaviour really was intended by RFC3253 then it was
   extremely hard to discover because there's not a single example in
   the spec where this actually happens.

I see no other possible interpretation for the statement in 3.6:

"The DAV:prop element of a DAV:response for a given resource MUST
contain the requested report for that resource."

I'm happy to add an example in the next version of the spec, if
you feel this needs to be clarified.

   My proposal would be to put the report result below the response element,
   and to assign it a new name, such as:

   <response>
     <href>...</href>
     <status>...</status>
     <report-result>...</report-result>
   <response>

We could do so, but this violates 3253, which requires the report
to be placed in the DAV:prop element.  I agree that this is a 
reasonable alternative marshalling, and if we didn't have 3253
saying otherwise, I'd be pretty happy to do it either way, but
I'd like to only change 3253 for serious problems.

   Related question of the day: what's the response format for the
   version-tree report with depth: 1 applied to a collection that
   itself is not versioned but contains one version controlled member?

   For depth 0 I'd expect:
   409 CONFLICT
   with
   <error xmlns="DAV:"><supported-report/></error>

Sounds right.


   So for depth 1 one would get:
   207 MULTISTATUS
   <multistatus xmlns="DAV:">
     <response>
       <href>/collection/</href>
       <status>HTTP/1.1 409 Conflict</status>
       <responsedescription><error><supported-report/>
         </error></responsedescription> </response>
     <response>
       <href>/collection/a</href>
       <propstat>
	 <prop>
	 ...now what?...
	 </prop>
	 <status>HTTP/1.1 200 OK</status>
       </propstat>
     </response>
   </multistatus>

Yes.

   RFC3253 seems to indicate that the <prop> element for the version
   controlled member must return the requested report. The format for
   the version-tree report defines a multistatus response body. So
   would the <prop> element contain another <multistatus> sub-tree?

Yes.

   Question to other implementors: who has implemented all of
   RFC3253's REPORTs for depths != 0 (where allowed) and feels that
   the format is well understood? I certainly don't feel so.

Clarifying the format is fine with me.  Changing it without
compelling motivation would not.

Cheers,
Geoff

Received on Sunday, 28 July 2002 10:03:16 UTC