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

RE: Comments on -12: properties, REPORT, OPTIONS

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Thu, 1 Feb 2001 15:49:06 -0800
To: <ietf-dav-versioning@w3.org>
Tim Ellison writes:
> > 2) On the flip side, if a DeltaV property is not protected, is
> > it the case that it MUST be writable using PROPPATCH, unless
> > the property definition explicitly states otherwise (of course,
> > writable assuming you have write access permissions).  In
> > particular, does a client have a guarantee that it will always
> > be able to write to, say, DAV:comment, and DAV:creator-displayname?
> If there is an unprotected property defined it is not the case that a
> client can always PROPPATCH it, since that property may not be
> supported by the server.  For example, if the server does not support
> the activity option it MUST fail an attempt to PROPPATCH the unprotected
> workspace property DAV:current-activity-set.

Sure, I agree completely.  What I was driving at was, if the server
signals that it does support the activity option, does that then
mean the server MUST allow writing to DAV:current-activity-set via

> > 3) "Note that a given property can be protected on one kind of
> > resource, but not protected on another kind of resource."
> >
> > This sounds a bit odd to me.  What examples do we have of this?
> I'm surprised that you find this odd<g>.  An example is
> DAV:predecessor-set
> which is protected on a version, and unprotected on a version-controlled
> resource.  It seems no more odd to me than the content of a resource being
> immutable on a version and mutable on a versionable resource.

Ah, OK, this does seem reasonable.  The text just hit me the wrong way.

> > 4) What are the semantics if there is an XML request body
> > for OPTIONS, and this request body does not include a
> > DAV:supported-method-set, DAV:supported-live-property-set,
> > or DAV:supported-report-set at all (i.e., what happens if
> > one or more are just plain omitted)?
> Then the corresponding response elements are 'just plain omitted'.

That makes sense, but it should be specified.  Another perfectly
reasonable response is to flag the input as a syntax error, since
it's missing an expected XML element, and this could cause
interoperability problems.

- Jim
Received on Thursday, 1 February 2001 18:49:45 UTC

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