W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

Re: Issues/questions regarding sections 3, 4 and 5...

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Mon, 13 Aug 2001 14:58:57 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <OFC4ABE31B.7E60B7EE-ON80256AA7.004A36A8@portsmouth.uk.ibm.com>

Hi Peter,

I'm going to skip most of the editorial points you make and comment on some
of the issues you raised:

> Section 3.1.4, the last sentence does not seem to make
> sense, it reads:
>
> "A live property is supported by a resource if that
> property has the semantics defined for that property"
>
> The property always has the semantics defined for that property.

This is a (somewhat desperate) attempt to define the supported properties.
The point is that if the property is 'live' i.e., its semantics are
enforced by the server, and those semantics are those defined by this
document, then it is a 'supported' property in the DeltaV sense.

Alternative wording is invited.

> [Issue/Editorial]
>
> Section 3.9 the specification says that when a resource
> is automatically checked out:
>
> "the DAV:checked-in property MUST be empty"
> ...

I think we have agreed that the properties should be removed (not just made
empty).

> [Issue]
>
> Section 4.3 states for CHECKIN that :
>
> "The response for a successful request MUST include a
> Location header".
>
> The only time deltav talks about the location header is
> for CHECKIN of a VCR and CHECKOUT of a working resource
> (section 9.3).  Why is this only on those methods?
> What is the use case for it (does it simply save the
> client from having to PROPFIND the DAV:checked-in?).

The Location: header is required in the response to a successful check-in
of a version-controlled resource to indicate which version was created by
the CHECKIN.  Without the Location: header there would be a race condition
between the client checking in the resource and PROPFINDing the
DAV:checked-in property with other clients that may be checking-out the
version-controlled resource or UPDATEing it, that would loose that
information.

The Location: header is required in the response to a successful CHECKOUT
of a version to indicate to the client the server defined working resource
URL.

> I ask this because the Location header is not returned
> by other methods that create resources,  eg UNLOCK etc

(UNLOCK will not create a resource)  In general, the methods that create
resources do so at user-defined URLs (e.g., PUT, MKCOL, MOVE, etc.

> for auto-versioning clients (eg when automatically
> checking in).

Auto-versioning clients, by definition would not know about any extensions
we would define for them.

> I suggest we either remove the feature or use it
> consistently eg whenever a new resource is created
> return the Location header.
>
> [Issue]
>
> Section 5.4.1 since this report is on a collection I would
> like a Depth header defined.
> Again I think we should be consistent (to avoid speical-case
> coding). Any method that gets properties of a collection
> should take a Depth header.

All REPORTs may take a Depth: header (see versioning-16 Sec. 3.6)

> [Issue]
>
> Section 5.5 defines this mechanism where OPTIONS can be
> used to find a possible location in the namespace that
> is to be used for version histories.  I assume this is so
> a client can indicate in a GUI if a collection is a
> collection of version histories or a client could choose
> not to display that part of the namespace.

That was not the motivation for providing this information.  In general,
the version histories will be maintained in server-defined URL space which
is likely to not conflict with user URLs.  The mechanism was provided to
give clients the ability to locate version histories 'from scratch'.  This
is required when clients remove all the version-controlled resources that
refer to (versions in a particular) version history.  Since without any
version-controlled resources all that remains is the version histories and
versions, which are all at server-defined URLs, they can become 'orphaned'.
This mechanism gives clients a way to find them again.

> It seems odd that this is only available for version
> histories, these are not the only resource that have
> "server-defined" URLs.  For example would the clients
> want a OPTIONS request to indicate where in the
> namespace will be used to reference versions as opposed
> to version controlled resources?
> The same arguments as in section 5.5 applies to versions,
> they may not be stored on the same server etc.

There was no attempt to refine the description of the server storage to
this level of detail.  That's not to say a particular server cannot include
such information, only that it is not required for versioning clients and
servers to interoperate.

> I also think an example of the OPTIONS method being used
> for this would be good as it is quite different from other
> uses of OPTIONS.

ACK.

> [Editorial/Issue]
>
> Reading section 5.6 it took us quite a while to decide how
> to delete the last version from a version history.
> I think the answer is "you don't" you must delete the version
> history itself in order to delete the last version.
> Did we interpret this correctly?

Yes, that is correct.  Just one of the riddles for the careful reader<g>.

> Do you think we should clarify this in the spec?

Yes.

Regards,
Tim
Received on Monday, 13 August 2001 09:59:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT