Subject: RE: 3xx vs RFC2518 vs redirect-ref spec

From: "Julian Reschke" <[email-masked]>
Date: Sun, 19 Oct 2003 13:26:37 +0200

Lisa,

> This proposal clearly has a lot of support.  I too favour a single
> client-feature-advertisement header. However, I'd like to caution the
group
> that we won't be able to demonstrate the interoperability of this header,
> and thus we take the risk that this won't be considered a suitable feature
> to take to the next standards phase (draft standard).

If we define the following:

- A DAV: request header MAY be sent by the client indicating compliance to a
specific WebDAV feature (in the same syntax as defined for the DAV: response
header)

	*and*

- Each protocol extension must explicitly declare what sending a specific
feature token indicates

	*and*

- If there's no such definition, clients MUST not send that token (thus we
can avoid the situation where clients start enumerating all kinds of
extensions although this info is completely useless to the server)

then there shouldn't be an issue at all. RFC2518bis would just provide the
marshalling framework for other specs, and *those* would need to show
interoperability.

The first canditates for actually *using* this IMHO are

- binding spec (client indicates that it knows about new bind-loop-detected
condition in multistatus response)

and

- redirect ref spec (client indicates that it knows how to deal with
Location info in multistatus)

(side note: interestingly, both use cases are about PROPFIND response
formats).

Julian

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 20 Oct 2003 16:52:11 +0200

Hi.

Another thing we'll have to keep in mind is the possible interaction between
this header and responses that are both cacheable and vary on the value of
this request header...

Ideas:

- we could just forbid that (the value of the "Dav" request header must not
affect cacheable responses)

- clarify that whenever the "Dav" request header *does* affect a cacheable
response, the server will have to list in the "Vary" response header.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 20 Oct 2003 13:00:53 -0400

I see no reason to forbid the value of the Dav request header from
affecting cacheable responses, so if we do anything in this regard,
I'd do the clarification.

Cheers,
Geoff

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 24 Oct 2003 13:52:42 -0700

If this header can affect caching, then I think we should add

"This header MAY affect caching, therefore this header SHOULD NOT be used
on GET requests where response caching is most important."

Lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Geoffrey M Clemm
> Sent: Monday, October 20, 2003 10:01 AM
> To: [email-masked]
> Subject: Re: DAV request header, was: 3xx vs RFC2518 vs 
> redirect-ref spec
> 
> 
> 
> I see no reason to forbid the value of the Dav request header 
> from affecting cacheable responses, so if we do anything in 
> this regard, I'd do the clarification.
> 
> Cheers,
> Geoff
> 
> > this header and responses that are both cacheable and vary on the 
> > value
> of
> > this request header...
> > 
> > Ideas:
> > 
> > - we could just forbid that (the value of the "Dav" request header 
> > must
> not