- From: Cullen Jennings <fluffy@cisco.com>
- Date: Sun, 27 Nov 2005 05:32:34 -0800
- To: Julian Reschke <julian.reschke@gmx.de>, WebDav <w3c-dist-auth@w3.org>
- CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Some people have been advocating a profile approach. I am simply trying to figure out if there are a large contingent of applications for both profiles. I have heard many applications (much more than just file system) that would not be impacted by no strong ETags so I am convinced that group is large, what I am looking for is what are the applications in the other group that don't care if they get back a weak or strong ETag? Let me a related questions to client implementers? On the phone call the other day, knowledgeable server implementers seemed to imply that the right solution for clients that got bag a weak ETag but needed a strong one was to poll the server until they got back a strong one. Does any client do that? On 11/26/05 1:04 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > Cullen Jennings wrote: >> >> I have heard that this is wanted for applications other than a file system. >> Right now I was sort of looking for examples of applications that did not >> want to use this. > > I think in this case the question needs to be rephrased: what would > these clients prefer? > > 1) keeping the spec as is, meaning that there aren't any guarantees > about this behaviour > > 2) changing the spec to mandate this, leading > > 2a) to some servers claiming to support this, but failing to do so > (non-compliant implementations), or > > 2b) to some servers stopping to support WebDAV altogether. > > I'd also like to point out again that there is a class of resources that > simply can't support strong ETags (for instance, WebDAV interfaces to > XML-Infoset-based databases). Thinking of this, even the SHOULD that we > have somewhere else in the spec is a very bad decision, and everybody > should understand that this makes it impossible to maintain WebDAV > interfaces to certain classes of resources (this is likely to be raised > during IETF last call, so we better make sure the problem is understood). > > Best regards, Julian
Received on Sunday, 27 November 2005 13:32:59 UTC