- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 17 Sep 2002 20:16:00 +0200
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Lisa, I think the answer to this is that this change should be discussed *after* there's a consensus about the new header. If, as you say, the introduction of the new header requires a new conformance class, that's (to me) a strong indication that it doesn't belong into RFC2518bis. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, September 17, 2002 7:40 PM > To: 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: extending the DAV: HTTP header, was: Issues from > Interop/Inte rim WG Meeting > > > > A new compliance class was suggested at the WG meeting particularly so > that clients could rely on Ilya's solution to ask the server to return a > 401 so they could force authentication. It would also be needed if we > followed the current proposal for provision of lock tokens, to add a new > header which does not cause the request to fail. > > The intention of the text draft is that a server could advertise > compliance with 1 + bis, or with 1 + 2 + bis (or if it does not support > bis, with 1 or with 1 + 2). > > Interoperability with old clients is very important and was always kept > under consideration at the WG meeting. Changes that add new headers, > without deleting old headers or otherwise making old syntax illegal, > continue to allow servers to interoperate with old clients. > > Consensus was quite clear at the WG meeting on both these issues. I > report this to the list to make it clear that significant dissent on the > list, along with feasible alternative solutions to the problems > encountered, would be required to overturn that. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] > > On Behalf Of Clemm, Geoff > > Sent: Tuesday, September 17, 2002 6:50 AM > > To: Webdav WG > > Subject: RE: extending the DAV: HTTP header, was: Issues from > Interop/Inte > > rim WG Meeting > > > > > > I agree with both of Julian's points. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Tuesday, September 17, 2002 4:51 AM > > To: Lisa Dusseault; Webdav WG > > Subject: extending the DAV: HTTP header, was: Issues from > > Interop/Interim WG Meeting > > > > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > > Sent: Sunday, September 15, 2002 8:14 PM > > > To: Webdav WG > > > Subject: Issues from Interop/Interim WG Meeting > > > > > > ... > > > > > > - Add a new string in DAV: header to advertise support for RFC2518 > bis > > > > > > - Change the DAV: header BNF to allow coded URLs syntactically. > > > > > > ... > > > > Questions: > > > > 1) I thought that the goal for RFC2518bis is to clarify and to simply > the > > protocol, not to extend it. Why do we need a new compliance class > then? > > And > > what does it mean for an existing server? For instance, if the server > only > > implements the "simplified" form of LOCK-NULL resources, is it allowed > to > > advertise compliance class "2". IMHO, it should (otherwise > > interoperability > > with old clients may break), so why a new class then? > > > > 2) If the spec extends how compliance classes are defined, I'd like to > see > > a > > use case first. Note that advertising support for a specific live > property > > IMHO is not a valid use case, so servers doing this should be fixed > > (there's > > a better way to do it, which is adding the property to the set > reported in > > DAV:supported-live-property-set as defined in RFC3253). > > > > Julian > > > > -- > > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >
Received on Tuesday, 17 September 2002 14:25:44 UTC