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

RE: New RFC2518bis draft, MOVE vs COPY

From: Jason Crawford <ccjason@us.ibm.com>
Date: Tue, 9 Jul 2002 15:56:42 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Lisa Dusseault" <ldusseault@xythos.com>, w3c-dist-auth@w3c.org
Message-ID: <OFC3F795A7.B757C20F-ON85256BED.000C6E21@us.ibm.com>

> Maybe MOVE and COPY need to be treated differently. If a server can't
move a
> resource with it's live properties staying alive, I'd claim that it
> can't move the resource at all, and thus MOVE should fail (requiring the
> client to fall back to COPY/DELETE).
> Opinions?

I'd like to see us try this requirement for MOVE and see how much trouble
folks have complying.   I think it will require some coordination between
resource authors and server writers to insure the authors concept of
"resource" is supportable in server's implementation of MOVE.

> > > 2) If we did, the wording "octet-by-octet" doesn't make sense
> > > we're
> > > talking of property values)
> > You may be right. Do you have another suggestion?

> Just remove it. "Duplicating" a property value is well-defined, as long
> the "property value" is well-defined (which we're trying to fix).

I should then enhance the description of issue:COPY_LIVE_PROPS to make sure
that's the case after we define the properties well.   Hopefully we'll also
define the default behavior of unknown dead properties clearly enough so
that COPY/MOVE behavior is clear for them also. (PROP_ROUNDTRIP)

Phone: 914-784-7569,   ccjason@us.ibm.com
Received on Tuesday, 9 July 2002 15:59:41 UTC

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