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

From: "Julian Reschke" <[email-masked]>
Date: Tue, 14 Oct 2003 15:53:30 +0200

> OK,
>
> so we probably should put it onto the issues list (so that it doesn't get
lost).

Here's a proposal for the issues list:

Issue DAV_REQUEST_HEADER

RFC 2518 provides a mechanism (the "DAV" response header) for a server to
indicate to a client that it supports a specific WebDAV option (e.g. "1",
"2", "version-control", etc.), but there is no complementary mechanism for a
client to indicate to a server that it understands a specific WebDAV option.
This becomes an issue when a WebDAV extension (or revision) needs to change
response formats in a way that possibly break existing clients. Detecting
client features based on a single, well-defined request header will work
better than (for instance) relying on custom headers (specified by each
extension) or "User-Agent".

Suggested resolution: allow the use of the "DAV" header as a request header,
with the same set of values that are defined for the "DAV"
response header.

Regards, Julian

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 14 Oct 2003 13:23:12 -0400

I support this addition to RFC2518bis.

I believe it is a key mechanism needed for servers to properly support
the various current (and future) WebDAV extensions.

Cheers,
Geoff

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 15 Oct 2003 09:28:40 +0200

+1.

Am Dienstag, 14.10.03, um 19:23 Uhr (Europe/Berlin) schrieb Geoffrey M

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 15 Oct 2003 07:20:37 -0700

+1

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Stefan Eissing
> Sent: Wednesday, October 15, 2003 12:29 AM
> To: [email-masked]
> 
> 
> +1.
>

---

From: Elias Sinderson <[email-masked]>
Date: Wed, 15 Oct 2003 15:40:48 -0700

I agree, let's add this to 2518bis - the proposed mechnism is simple and 
easy for developers to understand.

Elias

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 18 Oct 2003 00:26:38 -0700

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).  
 
I see no problem with defining the exact same header in the redirect spec
(or another), with a note that other extensions are encouraged to use the
same header.  Since this community is very good about reusing this kind of
solution, I'm not worried that its location will be a problem.  It's much
like the DeltaV preconditions/postconditions framework which has already
been reused by ACL and others without needing to modify 2518.
 
If there's still consensus to add to 2518bis specifically, let me know
(individually is fine) and I'll add it to the document.
 
Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elias Sinderson
Sent: Wednesday, October 15, 2003 3:41 PM
To: [email-masked]
Subject: Re: 3xx vs RFC2518 vs redirect-ref spec

Elias

Geoffrey M Clemm wrote:

Cheers, 
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 17 Oct 2003 15:35:47 -0400

I would like to see it added specifically to 2518bis.

I believe that there will be plenty of time between now and when
2518bis goes to the IESG for a sufficient number of clients and
servers to add in the DAV request header (and if there is one
feature that is unlikely to introduce an interoperability problem,
this is probably it :-).

Cheers,
Geoff

Lisa wrote on 10/18/2003 03:26:38 AM:

> 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). 
> 
> I see no problem with defining the exact same header in the redirect
> spec (or another), with a note that other extensions are encouraged 
> to use the same header.  Since this community is very good about 
> reusing this kind of solution, I'm not worried that its location 
> will be a problem.  It's much like the DeltaV 
> preconditions/postconditions framework which has already been reused
> by ACL and others without needing to modify 2518.
> 
> If there's still consensus to add to 2518bis specifically, let me 
> know (individually is fine) and I'll add it to the document.
> 
> Lisa

> On Behalf Of Elias Sinderson

> I agree, let's add this to 2518bis - the proposed mechnism is simple
> and easy for developers to understand.
> 
> 
> Elias
> 
> 
> Geoffrey M Clemm wrote:
>

---

From: Elias Sinderson <[email-masked]>
Date: Fri, 17 Oct 2003 21:29:03 -0700

I agree, the best approach would be to specify the basic DAV request 
header mechanism in 2518bis. The other WebDAV specs can then define 
additional values, thereby indicating other client capabilities. The 
logic behind the DAV request header seems straightforward enough to 
allow for interoperable implementations before 2518 moves to the draft 
standard phase.

Regards,
Elias