Re: COPY semantics

COPY has to depend on what you requested to copy. If its a working
resource, you should get a new, unversioned resource. If its a revision,
you should get a new unversioned resource of that revision. If its a
versioned resource, you should probably get the whole history. But that
maybe we should dissallow copy on versioned resources?



|--------+---------------------------------->
|        |          "Tim Ellison/OTT/OTI"   |
|        |          <Tim_Ellison@oti.com>   |
|        |          Sent by:                |
|        |          ietf-dav-versioning-requ|
|        |          est@w3.org              |
|        |                                  |
|        |                                  |
|        |          04/03/2000 03:15 PM     |
|        |                                  |
|--------+---------------------------------->
  >---------------------------------------------------------------------|
  |                                                                     |
  |       To:     ietf-dav-versioning@w3.org                            |
  |       cc:                                                           |
  |       Subject:     COPY semantics                                   |
  >---------------------------------------------------------------------|




(I've posed this question before, but it didn't get much discussion...)

What does COPY mean for a versioned resource?

Options might be:
(1) create a new versioned resource at the destination whose initial
revision is the same as the revision selected by the source,
(2) copy all the history of the source to a new versioned resource at the
destination,
(3) make a new unversioned resource that has looks like the selected source
(i.e., looses it's versioned status).

Then how does that differ if the selected resource is a working resource?
We disallow a working resource without a corresponding versioned resource
with at least an initial revision.
Option (1) seems the most likely candidate to me.

Tim