W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2012

Ambiguous example for COPY in RFC 4918

From: Federico Di Gregorio <fog@dndg.it>
Date: Wed, 29 Aug 2012 12:29:26 +0200
Message-ID: <503DEF06.3050106@dndg.it>
To: w3c-dist-auth@w3.org
CC: Elena Grassi <grassi.e@gmail.com>
Dear all,

this is my first post to this list so, if this is not the correct
mailing list to discuss the topic, please, just tell me and I'll forward
it to a more appropriate forum.

We're working at a C# implementation of RFC 4918 and while most parts of
it are quite clear we found one example that, if taken with the text
preceding it, is quite puzzling. About a COPY operation with infinite
Depth and Overwrite:T the RFC says:

    9.8.4 COPY and Overwriting Destination Resources

    When a collection is overwritten, the membership of the destination
    collection after the successful COPY request must be the same
    membership as the source collection immediately before the COPY.
    Thus, merging the membership of the source and destination
    collections together in the destination is not a compliant behavior.

But the example "9.8.8 Example - COPY of a Collection" says that
"[...]Because there was an error copying R2, none of R2's members were
copied.[...]". Our understanding is that in the destination tree
/othercontainer/R2/ is still the member from the original
/othercontainer/ collection while R2 siblings in the source collection
/container/ have been copied correctly.

E.g., if we're asked to COPY




and R2 is locked, the final layout is:


Isn't this the opposite of the behaviour specified in 9.8.4? Did we
interpret the example the wrong way? What is the supposed behaviour if
the resources are as in the example above?

Thank you very much fir your time,


Federico Di Gregorio                         federico.digregorio@dndg.it
Studio Associato Di Nunzio e Di Gregorio                  http://dndg.it
           Purtroppo i creazionisti non si sono ancora estinti. -- vodka
Received on Saturday, 1 September 2012 11:43:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:45 UTC