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

RE: IETF-51 DeltaV WG meeting minutes

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Tue, 14 Aug 2001 13:07:49 +0100
To: Peter Raymond <Peter.Raymond@merant.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <OF32375D2F.4F9E4D06-ON80256AA8.0041AE9A@portsmouth.uk.ibm.com>
Peter Raymond <Peter.Raymond@merant.com> wrote:

> In the meeting notes you sent we said:
> - Remove DAV:ok as a defined value for the check-out fork and check-in
> fork, and just leave the DAV:forbidden and DAV:discouraged values.
> should just check for these flags.  This means that forking is ok if the
> value is empty (or DAV:ok).
> - Similarly, an empty value for DAV:auto-version means that there is no
> auto-versioning happening for that resource.
> This seems counter to the conversations on empty properties and removing
> properties.  Rather than having empty values do you think it's a good
> idea to remove the DAV:auto-version, DAV:checkout-fork, DAV:checkin-fork
> properties to indicate no auto-versioning and that forking is allowed?

[I was only minuting what was said in the meeting<g>]  But I agree that the
empt property value and the missing property should both be interpreted as
you say.  The server implementation would simply look for (in forking) the
DAV:discouraged or DAV:forbidden tags and react accordingly if they are
found.  Ignoring other tags such as DAV:ok and DAV:foobar will provide
future extensibility.  Clearly those tags will not be found if the property
value is empty.

> This would allow a supported-live-property set to indicate if forking
> or auto-versioning is enabled.

Servers will report the live properties as supported even if they are not
currently set on the resource (assuming the server really does support them
of course).  So inclusion in the DAV:supported-live-properties-set will not
help distinguish between unset and empty properties.

> I guess I am not sure when it's best to have empty properties, versus
> removing the property (pros and cons of both).  But one thing I do know
> is that it would be good if we were consistent in the spec.

I think it is sufficient for the spec to state what it means when the
property includes a given value, without having to distinguish between
missing and empty properties.  However, to make the document readable and
unambiguous I support the (purely editorial) change to refer to the
properties being removed.

> Can you remember if there was some reason why we said the property
> would be empty as opposed to being removed?

I don't think that there is any distinction to be made.

Received on Tuesday, 14 August 2001 08:09:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC