RE: 3xx vs RFC2518 vs redirect-ref spec

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:

> 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:38:01 UTC