- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: 2002年4月22日 18:53:34 +0200
- To: "Lisa Dusseault" <ldusseault@xythos.com>
- Cc: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
- Message-Id: <7BBFC815-5611-11D6-9959-00039384827E@greenbytes.de>
Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault: > [...] > > To bring our "agenda" up-to-date, here's what I think the largest and > hardest issues are for RFC2518 bis: > - Whether/how to change the If header rules and syntax > - Whether/how to change the source property definition > > Although the If header has been shown to be interoperable in its > simplest > form with locktokens, it hasn't been shown to be interoperable in > its more > advanced forms or with ETags. The source property has not had any > demonstrated interoperability to my knowledge. If headers with ETags do not add any value to the protocol. For GET rfc2616 already defines If-Match and friends. Since the ETag only captures content changes (property changes have undefined effect on ETags), IF headers for ETag lack a use case. Having never encountered a client using them, I propose to drop ETags in IF headers. The remaining "more advanced" features of IF I can think of are: - not - use of URIs with locktokens URIs with locktokens are in use by us (both server and client). Does anyone have a use case for "Not"? //Stefan
Received on Monday, 22 April 2002 12:53:57 UTC