Subject: RE: extending the DAV: HTTP header, was: Issues from Interop/Inte rim WG Meeting

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 17 Sep 2002 09:49:58 -0400

I agree with both of Julian's points.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
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: [email-masked]
> [mailto:[email-masked]]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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 17 Sep 2002 10:40:15 -0700

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

> From: [email-masked]
[mailto:[email-masked]]
> 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
> protocol, not to extend it. Why do we need a new compliance class
then?
> And
> 2) If the spec extends how compliance classes are defined, I'd like to
see
> a

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 17 Sep 2002 20:16:00 +0200

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

> Sent: Tuesday, September 17, 2002 7:40 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Interop/Inte rim WG Meeting
>
>
>