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

   From: Tim_Ellison@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.

This is stated in section 2.9 (Additional PROPPATCH Semantics) so
would be redundant to state here as well.

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

I agree as well.  I will make this change, unless anyone objects.  In
particular, I will add a "report option", and require that a core
versioning server support the report option.

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

Good point.  I'll make this change.

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

Now that this is a property, there is value (i.e. you can
use Depth to get it for a whole collection in one request).

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

In case you wanted to extend this information some day with metadata
about those properties (possible with XML, not with comma separated
lists).

Cheers,
Geoff

Received on Sunday, 4 February 2001 23:15:44 UTC