Issues from Interop/Interim WG Meeting

We had a great interop last week, IMO. Overall, servers and clients now
have much greater success, and more consistent expectations of each
other.  Progress was made on issues and recommendations for RFC2518bis
and quota draft. 

I tried to keep track of all the Interop issues and recommendations that
people thought should feed into RFC2518 bis.  I'll list all these issues
in this first email, then start more detailed discussions on some of
them in separate email.  These are in no particular order.  

Not all the reasons, justifications or scenarios for these suggestions
are given here.  To the extent that we discussed each of these, WG
meeting consensus was reached in each case.  Of course the final
resolution for each issue and the content of RFC2518 bis are fully
subject to discussion on the list.

- Be more clear more about what a client should do about various errors
that may return in a 207.   2518 could explain for each error case, what
the client might expect to do - retry a different way, give up, etc.

- Clients should accept cookies.  More on this in later email.  

- Simplify timeout definition so that it only allows one TimeType, and
no "other".

- Add a new string in DAV: header to advertise support for RFC2518 bis

- Change the DAV: header BNF to allow coded URLs syntactically.

- Error responses that must contain headers (like 302) don't contain
those headers in multistatus.  E.g. when you MOVE a collection, but one
of the collection members is redirected, a 302 would be most convenient
and normally comes along with a location. Clarify in 2518 bis.

- Be more clear in xml element definitions how they can be extended and
why. 

- Support absolute paths as well as absolute URIs in Destination header.
URI spec has token "abs_path" which would work.

- Change section 13.7 (and others?) to be perfectly clear that last
modified and etags should ONLY reflect the results of GET requests, not
property or other state changes like lock.

-  Be clear in spec that servers MUST do ETags. Explain how necessary
this is to solve the lost update problem.

-  COPY request, destination on different server: how to fail? 502

- Litmus large path names causing failure? Specify better what error to
return. 

- Close out issue on PUT creating intermediate collections.  We will
not.

- Changing ETags on LOCK?  No

- How to force authentication from clients? Ilya will propose OPTIONS
header.

- Servers must use trailing slash whenever collection URLs are returned.
Language proposed for 2518 bis

- Servers should not be allowed to withhold lock owner information from
clients. Clients control the content of this element, thus clients can
decide on sensitivity.

- LOCK on non-existent resource creates a resource.  What is
content-type?  Server defined, or use 204.

- Clients get confused if host names change; Clients expect
full/relative URLs? Dealt with in text on multistatus response

- Body in MKCOL - must be XML?, no it doesn't have to be!

- Can a single principal take out >1 shared lock?  Yes!

- Are shared write locks interoperable?  Yes-humans can decide when to
update the document that is locked with shared locks.  Automatic
processes probably shouldn't use shared locks.

- Should if and lock-token header be split up? Yes

- BODY on LOCK refresh - can client reset timeout or owner? No body. Yes
clients can refresh timeout with header, but not owner because LOCK
refresh has no body.

- Source property is "out" of bis. Proposal for authoring dynamic
content should be in another draft.

- If header should not be required in order to supply a lock token to
change a locked resource. A proposal is needed for a new header that
does not force the request to fail if the lock token is no longer
applicable. More on this in a later email.

NON-2518 ISSUE:
- Quota draft was edited. It should be reissued and go to proposed.

Received on Sunday, 15 September 2002 14:14:37 UTC