From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]
"Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
> > To avoid confusion the server is required to disallow setting
> > resource properties that are defined in the specification but
> > are not supported (i.e. a PROPPATCH of DAV:checked-in on a
> > DeltaV-compliant versionable resource MUST fail).
> It does not say so in the spec. In fact, I think it would
> be unwise to say so in the spec.
You're right, I can't find that statement any longer in the spec.
Tim: In this case, your memory wins out over your eyesight (:-).
In particular, look at the following PROPPATCH postcondition:
(DAV:cannot-modify-unsupported-property): An attempt to modify a
property defined by this document whose semantics are not enforced by
the server MUST fail. This helps ensure that a client will be
notified when it is trying to use a property whose semantics are not
supported by the server.
> Imagine a server which complies to DeltaV in regard to
> supported-*-set, but does not implement DeltaV resource
> types. This server could allow a PROPPATCH on DAV:checked-in.
> If you call such a resource versionable would depend
> on the supported-method-set then, not on the
> supported-property-set.
I think allowing properties to be set in the DAV: namespace that do not
have the semantics defined in the DAV protocols is extremely dangerous.
I agree. Although I do not believe this thread matters for the
DeltaV protocol (the DeltaV protocol explicitly forbids this kind
of redefinition), I believe this thread does matter for WebDAV
future evolution (to ensure that other extensions do not violate
this principle).
> I think that is a valid case, since you cannot couple
> supported-*-set to implementation of DeltaV resource types.
> supported-*-set has to be a feature that can be used by
> other (orthogonal) extensions as well in the future.
But we can require that those other extensions have compatible
semantics. An explicit registration of property names with IANA would
be an appropriate path to take here.
Cheers,
Geoff