RE: 3xx vs RFC2518 vs redirect-ref spec

Please remove me from your list.

 

 

Christopher Gentile, Ph.D.

Executive Director, Sagemont Virtual School

 

Office:     305-867-8825

Toll Free: 877-357-0109

Cell:        954-410-8011

Fax:        305-867-6278

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com] 
Sent: Saturday, October 18, 2003 2:27 AM
To: w3c-dist-auth@w3.org
Subject: RE: 3xx vs RFC2518 vs redirect-ref spec

 

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
	>