W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2003

RE: 3xx vs RFC2518 vs redirect-ref spec

From: Lisa Dusseault <lisa@xythos.com>
Date: Sat, 18 Oct 2003 00:26:38 -0700
To: <w3c-dist-auth@w3.org>
Message-ID: <002501c39549$2b05d6a0$f8cb90c6@lisalap>
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: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Elias Sinderson
Sent: Wednesday, October 15, 2003 3:41 PM
To: w3c-dist-auth@w3.org
Subject: Re: 3xx vs RFC2518 vs redirect-ref spec


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


Elias


Geoffrey M Clemm wrote:



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 

Julian wrote on 10/14/2003 09:53:30 AM:

> 
> > 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
> 
Received on Friday, 17 October 2003 15:27:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:05 GMT