- From: Elias Sinderson <elias@cse.ucsc.edu>
- Date: Fri, 17 Oct 2003 21:29:03 -0700
- To: w3c-dist-auth@w3.org
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 Geoffrey M Clemm wrote: >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] >> >>
Received on Saturday, 18 October 2003 00:31:38 UTC