- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 18 Sep 2002 21:11:13 +0200
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, September 18, 2002 8:53 PM > To: 'Julian Reschke'; 'Webdav WG' > Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting > > > > > If a server that complies to RFC2518 doesn't comply to RFC2518bis, > then > > we've broken the IETF publication process, haven't we? > > I don't think that's necessarily true. I checked with my local IAB > member, and we don't think it's forbidden to upgrade a standard from > Proposed Standard to Draft Standard, even if in the process the standard > becomes somewhat more stringent in what constitutes compliance from > implementations. (He says particularly if the requirement is a SHOULD > now.) It's a difficult judgement call, and one must weigh the But it isn't a SHOULD right now. RFC2518 says: "The getetag property MUST be defined on any DAV compliant resource that returns the Etag header." So if I have an HTTP resource for which HEAD/GET wouldn't return an ETag header, it's absolutely OK not to return the DAV:getetag property. > interoperability concerns of both making and not making the change. But > in principle, it's not forbidden. > > Our ADs will certainly weigh in on this when we've hashed it out more > amongst ourselves, but in the meantime we shouldn't have to restrict > ourselves rigidly in this matter. -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 18 September 2002 15:11:47 UTC