Re: Gen-ART review of draft-ietf-webdav-bind-23

[Geoffrey M Clemm]

"McCann Peter-A001034" <pete.mccann@...> wrote on 05/29/2009 12:41:47 PM:
> I have been selected as the General Area Review Team (Gen-ART) reviewer
> for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-webdav-bind-23
> Reviewer: Pete McCann
> Review Date: 29 May 2009
> IETF LC End Date: 28 May 2009
> IESG Telechat date: unknown
>
> Summary: Ready for publication as Experimental.  I had a few minor
>          questions that might just be a result of my own lack of
>          understanding.
>
> Major issues:
>
> Minor issues:
>
> Section 2.3:
>    If because of multiple
>    bindings to a resource, more than one source resource updates a
>    single destination resource, the order of the updates is server
>    defined.
> Are you trying to say that a Request-URI can map to more than one
> resource?  I didn't think this was possible.

This is the scenario where the source collection, S, contains two bindings to two distinct resources (S/a->R1 and S/b->R2), while the destination collection D contains two bindings to the same resource (D/a->R3 and D/b->R3).  If you copy S to D, then after the copy, it is up to the server whether R3 has the same content as R1 or R2.

So it is a case of two bindings to the same resource, not a single URI being mapped to more than one resource (which as you say, is impossible).

>    If a COPY request would cause a new resource to be created as a copy
>    of an existing resource, and that COPY request has already created a
>    copy of that existing resource, the COPY request instead creates
>    another binding to the previous copy, instead of creating a new
>    resource.
> This confused me a bit, but after reading the examples in the next
> section I think I understand what is intended here: do you mean that
> if the resource graph pointed at by the Request-URI itself has multiple
> bindings to the same resouce, that resource is only copied once by
> the COPY operation?

Yes.

> Nits/editorial comments:
>
> Abstract:  s/insure/ensure/

Agreed.

Cheers,
Geoff

[Julian Reschke]

Geoffrey M Clemm wrote:

>  > Please resolve these comments along with any other Last Call comments
>  > you may receive.
>  >
>  > Document: draft-ietf-webdav-bind-23
>  > Reviewer: Pete McCann
>  > Review Date: 29 May 2009
>  > IETF LC End Date: 28 May 2009
>  > IESG Telechat date: unknown
>  >
>  > Summary: Ready for publication as Experimental.  I had a few minor
>  >          questions that might just be a result of my own lack of
>  >          understanding.
>  >
>  > Major issues:
>  >
>  > Minor issues:
>  >
>  > Section 2.3:
>  >    If because of multiple
>  >    bindings to a resource, more than one source resource updates a
>  >    single destination resource, the order of the updates is server
>  >    defined.
>  > Are you trying to say that a Request-URI can map to more than one
>  > resource?  I didn't think this was possible.
>
> This is the scenario where the source collection, S, contains two
> bindings to two distinct resources (S/a->R1 and S/b->R2), while the
> destination collection D contains two bindings to the same resource
> (D/a->R3 and D/b->R3).  If you copy S to D, then after the copy, it is
> up to the server whether R3 has the same content as R1 or R2.
>
> So it is a case of two bindings to the same resource, not a single URI
> being mapped to more than one resource (which as you say, is impossible).

Furthermore, we have added an example for this case in draft 24; see
<http://tools.ietf.org/html/draft-ietf-webdav-bind-24#section-2.3.2>.

>  >    If a COPY request would cause a new resource to be created as a copy
>  >    of an existing resource, and that COPY request has already created a
>  >    copy of that existing resource, the COPY request instead creates
>  >    another binding to the previous copy, instead of creating a new
>  >    resource.
>  > This confused me a bit, but after reading the examples in the next
>  > section I think I understand what is intended here: do you mean that
>  > if the resource graph pointed at by the Request-URI itself has multiple
>  > bindings to the same resouce, that resource is only copied once by
>  > the COPY operation?
>
> Yes.
>
>  > Nits/editorial comments:
>  >
>  > Abstract:  s/insure/ensure/
>
> Agreed.

(Fixed in -24 as well).

Best regards, Julian