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

Geoff,

I think we really need to come to a conclusion here.

IMHO, marshalling something that isn't a resource property inside a
multistatus/response/propstat/prop element clearly breaks RFC2518 [1] and is
very confusing. 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.

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>


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>


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>


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?

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.

Julian

[1] <http://greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_prop>

Received on Saturday, 27 July 2002 04:22:26 UTC