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

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

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 1 Feb 2001 11:09:11 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569E6.003D46B4.00@d06mta07.portsmouth.uk.ibm.com>


> Properties:
>
> In Section 1.5.2:
>
> 1) "A protected property cannot be updated with a PROPPATCH
> request."
>
> This this is a requirement, I recommend changing the "cannot"
> to a "MUST NOT" since that is the intent of the text, and "MUST
> NOT" has a specific meaning according to RFC 2119.

I agree.

> 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.

> 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.

> REPORT:
>
> REPORT doesn't fit in Section 23.  REPORT is a new, complex
> method that predominantly extends the capabilities of RFC 2518,
> rather than clarifying existing capabilities in 2518. So far,
> REPORT is only used in this draft, hence though it may have
> utility broader than just the DeltaV draft, so far there aren't
> any additional users.  It may make sense, at some point in the
> future, to include this in the Distributed Authoring specification.
> But for now, having it in a section titled "Clarifications and
> Extensions to RFC 2518" is a bit strange -- the *entire*
> specification could be labeled extensions to 2518.  Additionally,
> sometimes people view appendicies as being non-normative -- do
> you want to send the message that you can safely ignore
> implementing REPORT?  The definition of REPORT can be placed
> elsewhere in the specification, and just note that the authors
> recommend it be incorporated into a revision of RFC 2518, due
> to its potentially broad utility.

I agree with your observations for this editorial change that I'll leave up
to the authors to resolve.

> OPTIONS:
>
> Section 23.6:
>
> 1) I think it makes sense to keep things open for additional
> OPTIONS extensions.  So, I would rephrase this as, if you
> include an XML request body with OPTIONS, here is what it means,
> and it must include the following XML element.  Right now
> you're cutting off all possible future extension to OPTIONS
> that doesn't use XML, and that is overcontraining.

Agreed.

> 2) I'm not sure why the "supported-method-set" capability
> is present, since it duplicates the existing functionality
> of OPTIONS, specifically the Allow header.  If the example
> in 23.6.1 were correct, it would highlight this.
>
> The correct *response* for the example in 23.6.1 is:

<<snip>>

> So, the same information is in the Allow header, and the
> supported-method element.  IMO, there is no clear advantage
> to duplicating this capability.

Agreed.

> 3) Within supported-live-property-set, and supported-report-set,
> why not marshall the live properties, and reports, as comma
> separated lists?  It has the dual advantage of being more compact,
> and easier to read. DeltaV clients must have the ability to
> parse comma separated lists, so it's not like this is a huge
> imposition.

The values used to be comma separated lists, and I don't remember why
somebody asked for the change.

> 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'.


Tim
Received on Thursday, 1 February 2001 06:10:07 GMT

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