- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 21 Dec 2000 17:23:43 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Tim_Ellison@uk.ibm.com
(I.1) Get rid of DAV:must-support attribute, and instead define
tokens for use in an If header.
Done.
<tim>
Shame. I'll have to see this, but either you have LOTS of
tokens or have chosen which are 'ignoreable'. For the record
I was in favour of keeping the attribute.
</tim>
I agree that this functionality has advantages, but since it
was not critical for versioning, we decided to leave it to be
defined by some other group that really needs it.
(I.3) Add an "unknown" value for checkin-date.
The working group felt a "null" value was appropriate for this,
rather than defining an "unknown" value.
<tim>
Again, for the record, I am in favour of servers not defining
this property if they cannot provide a reasonable value for it.
(I don't know what the "null" vallue will be?)
</tim>
That's what I meant ... I should have said "omit the property", not
a "null value".
(I.4) Require that the 403/409 response body token appear as the top
level element "unless explicitly negotiated otherwise", so that
clients get predictable behavior, but later specs can allow
clients to request other behavior.
Done.
<tim>
What does 'explicitly negotiated otherwise' mean? If it means that
particular clients and servers can have an out of (protocol) band
conversation to do something else, then of course this is true; for
any number of things. I'm not sure what this statement adds.
</tim>
If you just say "MUST be the top level element", then this is violated
by any later spec that wants to allow the client to ask for it to be
elsewhere (e.g. use a header to ask that it be nested in some other
XML). So for extensibility, you need to open up this constraint in
this fashion.
(II.4) Require version-name to be XML, for internationalization.
Removed the restrictin that it be a string, but did not require it to be
XML.
<tim>
So what's a guy to do? If it is not necessarily XML it must be
handled as a String -- which means all of those <'s and &'s must
be escaped. Of course if a different client retrieves the comment
and the XML is un-escaped on the way out, it won't be internationalized
to the client's taste.
I guess that the objection to it's being XML is that the comment
is typically accessible by other (non-NLS'd) tools that would only
expect a String.
</tim>
Yes, this was just a case of "editor fatigue". I'll change this to say
that XML is required.
(II.5) Move all DAV:supported-xxx properties to the OPTIONS response.
Move all DAV:xxx-collection-set properties to the OPTIONS
response.
Done.
<tim>
Do we need DAV:supported-live-properties?
Servers are required to protect the names of all live properties
(whether they support them or not), so PROPPATCH will fail if the
property is unsupported.
Servers should not define a live property that it does not support,
and PROPFIND would return 404 Not Found.
</tim>
Since the protocol does not distinguish between dead and live properties,
a server has no way of knowing whether the PROPPATCH was to a dead
property or to a live property that it doesn't know about.
Cheers,
Geoff
Received on Thursday, 21 December 2000 17:24:38 UTC