FW: Check-in policy
Tim Ellison OTT (Tim_Ellison@oti.com)
Wed, 08 Dec 1999 09:48:36 -0500
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: geoffrey.clemm@rational.com (Geoffrey M. Clemm),
Message-ID: <1999Dec08.094500.1250.1410522@otismtp.ott.oti.com>
Date: Wed, 08 Dec 1999 09:48:36 -0500
Subject: FW: Check-in policy
From: Tim_Ellison@oti.com (Tim Ellison OTT)
3.6.2 DAV:checkin-policy
...
2) The DTD allows for ANY element as a checkin-policy. The spec should
state what a server should do if it does not support the checkin policy,
and which are mandatory.
<gmc/>
I'd be inclined to say that a server MUST fail an attempt to set
a checkin-policy that cannot be provided for that working resource
(one reason for which would be that the server does not support
that checkin policy at all).
If nobody disagrees, I'll make this update to the protocol.
Note: An alternative would be to say that any checkin-policy can be
set, and only require that checkin-policy be verified at CHECKIN time.
This makes life easier for servers, but is less friendly to clients.
<tim>
Would this be the only property with a mutable enumerated value? I can't
think of any others, though I suspect we at least have some boolean props.
The reason that I ask is that this policy would set a precedence that we
should endevour to maintain for consistency, and in general failing early
may not be possible (for example, if it is data related.)
However, since I can't think of a counter example, I'll agree!
</tim>