Re: live props on a VCR

   From: "Lisa Dusseault" <lisa@xythos.com>

   I hadn't considered this before, but now that I am, I'm not sure
   it's wise to send depth headers on the REPORT method.  My three
   (somewhat related) worries:

   1) Lack of clear model: Although depth makes sense when we're
   dealing with well-modelled collections and resources, the model
   here is less clear.  A REPORT on a "baseline" may well give a bunch
   of information on the baseline and the things the baseline is
   involved in.  Is that depth infinity?  Does depth 1 make sense?  A
   REPORT request could target the whole server (e.g. a report asking
   for all orphaned resources).  A REPORT request could target
   something more ephemeral like "all baselines in this collection"
   which is not the same thing as depth infinity on the collection.
   It's not like a GET or a MKCOL where there's a clear model of the
   resource being targetted.

Yes, we do need to make it clear that Depth on a REPORT just means
running that report on every member of the request collection (just
like PROPFIND).  A baseline is not a collection, so a Depth header has
no effect on a request on a baseline (other than possibly changing the
response status to a 207).

So I believe a Depth REPORT has a clear model, but that we need to add
a sentence to the protocol to make it unambiguous.

   2) Multiple targets of REPORT:  E.g. "merge-preview-report" in deltav draft
   10.  What would depth header mean on this request?  The "target" of the
   report is not a single resource or collection, but a combination of some
   things being merged into other things.  When a combination of things is
   specified in the request, the depth header is ambiguous.  It could apply to
   any, all, or none.

Here as well, the merge-preview-report is just applied separately to
each member of the request collection.  This is a well-defined
operation.

On the other hand, your question did highlight the fact that MERGE
handles the Depth header somewhat specially, when logically, it
doesn't have to.  It probably is worth cleaning this up, by defining
MERGE with a Depth header to be just a MERGE applied to each member of
the request collection.

   3) REPORT on specific kind of resource: it seems that even when a
   report targest only one resource, it's often a resource of a very
   particular kind.  For example, one could have a report which only
   made sense for a baseline, or a report which only made sense for a
   versioned resource.  If depth: 1 or depth: infinity were specified,
   what about items within that depth that aren't the right kind of
   resource for this kind of report?

That's the same as any other Depth operation.  If you do a Depth
PROPFIND, some of the resources may not support the requested
properties.  Or if you do a Depth LABEL, some of the resources may not
support the LABEL request.  The DAV:propstat tells you what
happened for a particular resource.

   Thus, I'd suggest a good justification for requiring "depth" on
   REPORT.

Greg provided a good example.  You want to issue a property report on
every member of a collection.

   If it turns out a depth modifier is required, we should consider
   whether:

   - it might be better just to define appropriate reports as always
   being depth infinity (e.g. "report to me on all orphaned resources"
   would always cover an entire server or at least a major section of
   it)

I'd like to keep Depth to just mean what it means in 2518, namely,
apply this operation to every member of the collection.

    - it might be better to include a "depth" modifier _inside_ the report
   request body, so that the requester can be very clear about what resources
   the depth modifier applies to.

You could have depth-like modifies in the argument list, but I believe
that doesn't decrease the utility of the Depth header with its standard
semantics.

Cheers,
Geoff

Received on Monday, 18 December 2000 18:26:11 UTC