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.


> -----Original Message-----
> From:
> 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
> rim WG Meeting
> I agree with both of Julian's points.
> Cheers,
> Geoff
> -----Original Message-----
> From: Julian Reschke []
> 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:
> > []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
> >
> > - 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
> protocol, not to extend it. Why do we need a new compliance class
> And
> what does it mean for an existing server? For instance, if the server
> implements the "simplified" form of LOCK-NULL resources, is it allowed
> 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
> a
> use case first. Note that advertising support for a specific live
> 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 -- -- tel:+492512807760

Received on Tuesday, 17 September 2002 13:41:56 UTC