Next message: Geoffrey M. Clemm: "Re: Three questions, and a paean to Perforce"
Message-ID: <53803ECFD77B0148A3D834341960E9FA4F8D56@red-msg-18.redmond.corp.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
To: "'Clemm, Geoff'" <gclemm@Rational.Com>, "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
Date: Mon, 8 May 2000 15:36:21 -0700
Subject: RE: draft-ietf-deltav04.5 now available
Here are some comments from my reading of 4.5:
- 2.1: Don't we use the VERSION method to make a rsource
versioned?
- 2.3: I think we should make this section more clear. I
think there is a point we want to make, but I think that
people who didn't live through this "discussion" won't
get it.
- 3.3: I don't think we should do this -- it will impact
down-level clients by seeing a type they don't understand.
We should add a new property to indicate it is versioned.
- 3.3.2: you are missing hyphens in the ELEMENT definition.
- 3.3.4: It isn't "linear" -- it is exclusive/non-exclusive
or reserved/un-reserved that we are talking about.
- 3.3.4: Servers must be allowed to fail changes to this
property if there is a general server policy that would be
violated.
- 3.4.3: I wish we could separate the linear successor from
the merge successors.
- 3.4.4: See 3.4.3
- 3.5.2: See 3.4.3
- 4.1: I hope "label" doesn't include workspaces -- I'd prefer
to see them separate.
- 4.1: I don't get the use of "none" -- seems wrong as a "target"
modifier -- send this request nowhere? :-)
- GENERAL: The examples should be more realistic (better headers, etc.)
- 5.4.1: We need to include the new methods, e.g., VERSION.
- 6.1: It seems wrong to be able to make a resource versioned if
someone else has an exclusive lock on it.
- 6.1: Didn't we use to have a depth header on the VERSION method?
- 6.2.1: I would prefer to see this be a separate method. Also, if
this sepecifies a label, we should allow a depth header.
- 6.2.2: Removing a label? How? Seems wrong to use a "none" target
- 6.2.2: We should allow a depth header on setting labels.
- 6.3: It seems wrong to allow a checkout of an exclusively locked
item. Some clients may not be able to deal with this and the
changes will be lost. We should at least have an option to fail
if locked, maybe?
- 6.3: See previous comment about DAV:linear.
- 6.3: We should have a body for the request... to allow the user
to indicate reserved/unreserved, etc.
- 6.4: We should have a DAV:checkout tag that wraps the body so that
we can more easily add new tags.
- 6.5: What does it mean to delete a working resource? Is this an
"UNCHECKOUT"?
- 6.6.2: This doesn't feel like it should be required for core? Is
it optional?
- 7.1: In reading this it is really wierd to make a workspace a
versioned resource. I understand the desire to re-use concepts,
but it is strange that I "checkout" a revision of a versioned
resource and get a versioned resource not a working resource. I
think we should separate Workspaces and Baselines to use different
methods so that the concepts are separate.
- 7.1: Geoff had asked that we think about whether or not it makes
sense to think of activities as branches. I believe they are
separate. I can evision branches w/o activities as well as a
branch with interlaced activities. I think we should keep these
concepts separate.
- 8.1: Why wouldn't you initially populate the workspace with
SET-TARGET?
- 8.1: Last paragraph: I think this is very complex to require all
advanced servers to support these semantics.
- 8.3: I have a problem with sever merging... I think it is OK for
us to have a method to indicate a client-side merge, but having
the server do merges takes us to a complex place. How can a client
discover what has been merged? What if the client doesn't want
the server to do any merge? I think the MERGE method should be
meta-data only -- not content.
- 8.3: Can SET-TARGET cause merge conflicts? This space can be
very messy to do in a fully interopable way.
- 8.5: I'm not sure what is meant by a "versioned collection". Does
changing the contents create a new version? If so, then I think
we need to consider an intermediate level. That is, I should be
able to have a "versioned collection" that tracks its properties
and changes to them, but not necesarrily its children.
- 9.1.1: Why is this in advanced and not core?
- 9.2.2: See previous comment re: merge
- 9.3.2: We talked about removing this last week?
- 9.3.7: I'm not sure I understand what this property is for...
- 9.4.2: I think this needs to be optional -- I can see server
supporting activities, but this is more complex.
- 10.1: Why don't we fold this header into Target-Selector?
- 12.3: It isn't clear how I merge between two workspaces.
- 13.1: I don't think I understand what this report is for? Is
it required or optional?
- 13.2: Can this report be optional?
- 13.3: Shouldn't this be just like the MERGE method in terms of
the data that can be passed?
- 13.3: Can this report be optional?
- 13.4: Can this report be optional?
- 13.5.1: I think we should clean up the XML. For example, in
the response, I would think something more like:
<D:repository-report>
<D:activity>
<D:href>...</D:href>
</D:activity>
</D:repository-report>
so that you can request multiple items.
Chris
-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]
Sent: Tuesday, May 02, 2000 9:10 AM
To: DeltaV (E-mail)
Subject: draft-ietf-deltav04.5 now available
www.webdav.org/deltav has been updated to point to this draft.
This contains just a few updates based on recent email traffic.
In particular, "unreserved checkouts" have been added to advanced
versioning.
I did make a name change from "default workspace" to "request workspace",
since this simplified the text by removing the need to keep saying "if there
is not explicit Workspace header, the default workspace is used". Now
everything just says "the request workspace is used", and the term "request
workspace" is defined to mean "the workspace in the Workspace header,
or if none, a default workspace allocated by the server".
Cheers,
Geoff