- 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 PROPPATCH? > > 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