Subject: Issues from Interop/Interim WG Meeting

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 15 Sep 2002 11:13:38 -0700

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.

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 17 Sep 2002 10:51:04 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, September 15, 2002 8:14 PM
> To: Webdav WG
> Subject: Issues from Interop/Interim WG Meeting
>
> ...
>
> ...

Questions:

1) I thought that the goal for RFC2518bis is to clarify and to simply the
protocol, not to extend it. Why do we need a new compliance class then? And
what does it mean for an existing server? For instance, if the server only
implements the "simplified" form of LOCK-NULL resources, is it allowed to
advertise compliance class "2". IMHO, it should (otherwise interoperability
with old clients may break), so why a new class then?

2) If the spec extends how compliance classes are defined, I'd like to see a
use case first. Note that advertising support for a specific live property
IMHO is not a valid use case, so servers doing this should be fixed (there's
a better way to do it, which is adding the property to the set reported in
DAV:supported-live-property-set as defined in RFC3253).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 17 Sep 2002 10:55:22 +0200

> and normally comes along with a location. Clarify in 2518 bis.

That's in fact a very interesting problem, which is partly solved in the
expired redirect references draft [1]. If we can come up with a similarm but
more generic format, I'm all for it. But is it reasonable to attempt to
resolve this in RFC2518bis?

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-02.
html#rfc.section.7.3>

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 17 Sep 2002 10:57:54 +0200

> ..

ETags are a good thing, correct. However, HTTP (RFC2616) doesn't require
them, RFC2518 doesn't require them, and they '*aren't* required for
interoperability. So there's no way to require them in RFC2518bis -- it
would break all servers that don't have them.

Julian