RE: New RFC2518bis draft, MOVE vs COPY

                                                                                                               
                                                                                                               
                                                                                                               


> 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
actually
> 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
(because
> > > 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
as
> 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