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

> From: [email protected]
> [mailto:[email protected]]On Behalf Of Clemm, Geoff
> Sent: Sunday, July 28, 2002 4:03 PM
> To: [email protected]
> Subject: 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.

Well, the most significant problem with this kind of marshalling is that
it's completely non-obvious, and there's no example in the spec. So again my
question to deltaV-implementors: who has REPORTs with depth != 0 currently
implemented and is compatible to RFC3253?

> Detailed response below:
>
>    From: Julian Reschke [mailto:[email protected]]
>
>    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.

RFC3253 states that for depth != 0, the response must conform to whatever
RFC2518 has to say about Multi-Status response bodies. Please don't say it
doesn't, because in that case the response format is completely undefined.

> 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".

See, and this exactly the thing that I think is wrong. There should be no
doubt whether something is a (live) property or not. To marshall something
as property because it "acts exactly like" a property conflates separate
things.

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

Wow! Do you say that by this approach RFC3253 forbids other specs to define
properties with names matching existing REPORT result elements? If this *is*
the intention, it should be made clear.

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

I absolutely feel so.

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

I think by now we can safely assume that we won't get any kind of
interoperability for these kinds of reports unless we clarify the format. I
haven't seen any server or client implementing the current RFC3253 format
yet, so I think clarifying *plus* choosing a more logical format makes a lot
of sense.

> ...