Next message: Jim Amsden/Raleigh/IBM: "Re: Versioning TeleConf ... 2pm-3pm EST"
Message-Id: <200009121142.HAA02976@tux.w3.org>
Date: Tue, 12 Sep 2000 07:41:31 -0400
To: ietf-dav-versioning@w3.org
From: "Jim Amsden/Raleigh/IBM" <marjorie@us.ibm.com> (by way of "Ralph R. Swick" <swick@w3.org>)
Subject: [Moderator Action] RE: Versioning TeleConf Agenda, 8/11/00 (Monday) 2pm-3pm EST
[freed from spam trap -rrs]
Date: Mon, 11 Sep 2000 20:46:37 -0400 (EDT)
To: ietf-dav-versioning@w3.org
Message-ID: <OF5327DCF5.E29D6A4E-ON85256958.000155CC@raleigh.ibm.com>
From: "Jim Amsden/Raleigh/IBM" <marjorie@us.ibm.com>
Some clarifications in <jra> tags below.
All changes to WebDAV that are identified in the versioning spec need to be
raised to the WebDAV working group through its mailing list. Ideally this
would be done through internet drafts proposing each of the extensions. For
expedience, we can distribute the versioning spec to the WebDAV working
group highlighting the new WebDAV semantics. Wouldn't hurt to get the
WebDAV working group involved in versioning too. This may not be exactly in
concert with IETF policy though. We need to be sensitive about this.
Participating: Boris Bokowski (OTI), Jim Doubek (Macromedia), Tim Ellison
(IBM),
Jim Amsden (IBM), Geoff Clemm (Rational).
The following issues were raised:
- JA: Do we need the new Rationale section?
(I'm happy to delete it, but it was requested at the last DeltaV meeting.)
<jra>
I'm happy to leave it in, but we have a Goals document that we reference
that this was copied from. This seems unnecessary and redundant. In
particular, there are some potentially contentious items in the bullet
lists that do not need to be addressed in the protocol spec directly.
</jra>
- JA: Should the pictures use URL's instead of names like "V1", "V2".
Geoff made the point that you are severely limited with what you can
do with ASCII art (and passed the buck back to Jim saying that if he
wanted to redo the ASCII art, we could look at the result and see
whether there was a net improvement.
<jra>
Geoff agreed to treat V1, etc. as diagram labels explained in the text.
Example server generated URLs can be shown there.
</jra>
- JA: Do we really need DAV:version-name (aren't reserved labels by the
server sufficient)?
(I'm happy to delete it, but it was requested at the last DeltaV meeting.)
<jra>
I was saying that since DAV:version-name has no semantics other than
uniqueness (in particular it does not have label semantics), then
DAV:version can play exactly the same role.
</jra>
- BB: Shouldn't DAV:version-name be added to the DAV:version-tree-report.
Sure.
- JA: Why is Overwrite:update needed (isn't Overwrite:T sufficient)?
A good example is copying a new value into a working resource. With
Overwrite:T,
the working resource would first be deleted, and thus a COPY with
Overwrite:T
would not update the working resource (but rather delete it, and create a
new
resource). We could redefine Overwrite:T, but this would be clearly
incompatible with the 2518 definition.
I'll add some more text to the Overwrite section to motivate this
extension.
<jra>
It was my understanding that the delete semantics of COPY were
unintentional and that BIND semantics clarified the semantics of COPY. I
don't think we should introduce a new non-boolean value to an existing
Boolean header to address this problem. Simply stating that a server is
free to determine how the COPY is implemented, and explaining any
limitations or additional semantics added by versioning, should be
sufficient.
</jra>
- JA: the new 4xx response body values
<jra>
This looks like a LOOOOONG disucssion that I hate to see introduced in
versioning. If this is a general WebDAV problem, the WebDAV spec and
working group should address it. There are too many potential consequences
of this design to include it at this late date. Let's run our of 4xx status
codes first.
</jra>
- JA: PROPFIND
<jra>
Doesn't PROPFIND on a version selector have to return all properties (live
or dead) of both the version selector and the target version?
</jra>
- JA: LOCK
<jra>
LOCK with a Target-Selector header should have exactly the same semantics
as LOCK on a version selector without a Target-Selector. Its the target
that gets locked. Labels aren't locked as they are properties, not part of
the URL. If we don't define this, we may regret it later.
</jra>
We didn't have time to address these topics today. Jim: please mail
something
to the mailing list on what you had in mind for these three topics.
- JD: In the "Baselines" section, most references to "workspace" should be
"collection"
(since you now baseline a collection, not just a workspace).
Will fix.
- BB: The ordering of the predecessor-set of a version is not guaranteed to
match
that of the working resource from which it was created.
Will fix.
- JD: Would like to have something said about what happens when you try to
update
a live property of a version or version selector.
In general, as with all live properties, the answer to this depends upon
the
semantics
of the particular live property. I just took a look at the document to see
where we
would put such a statement, but everywhere I looked, I already had made the
point by
indicating that the semantics only applied to *dead* properties. So I'm
inclined to
just leave it as is. JimD: Perhaps you could send me the sentence you
would
like to see
added, and where you would want to see it. Does anyone else feel such a
statement
is needed?
- BB: Would like to let the client control whether or not a working
resource
is checked
out in place (as is required in a workspace) or not.
I will add a "DAV:here" and a "DAV:not-here" option to CHECKIN. If
DAV:here
is specified,
the CHECKOUT MUST be done in place (as is done in a workspace). If
DAV:not-here is
specified, the CHECKOUT MUST NOT be done in place. If neither is
specified,
the server
can chose whether to CHECKOUT in place or not.
<jra>
If not-here is specified, where is the resource checked out?
</jra>
Note: With this option, it seems to make sense to have the
"auto-set-target"
behavior of CHECKIN only applies to working resources that were checked out
in place, and then to get rid of the DAV:hidden option to CHECKIN, since it
doesn't make much sense to use DAV:hidden on a working resource that was
checked out in place.
- BB: Want OPTIONS response to indicate whether VERSION-CONTROL is
automatically
applied to newly created versionable resources.
Will do.
- JA: Need quote marks on the attribute values for "unknown".
Will fix.
- JA: Do we really need the unknown attribute?
Without this (or something like this), a client cannot tell a server that
it
must
not ignore a particular part of the request (ignoring is the default
behavior for
unknown XML element types).
<jra>
HTTP specifies clients should use OPTIONS to determine what a server can
do, and then not ask it to do things it doesn't support. This is a new
paradigm which might raise some red flags. I don't mind the concept, but I
don't think we absolutely need it, and might want to be prepared to take it
out if there are lots of objections.
</jra>
And that's all we had.
A quick poll of those on the conference call did not surface any desire to
defer last call. I'll get out an 8.1 draft this week, so everyone can
review
the changes resulting from this call.
If you can think of any reason why we should not go to last call this
month,
please speak up now!
Cheers,
Geoff