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"? //StefanReceived on Monday, 22 April 2002 12:53:57 UTC
This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:25 UTC