- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 07 Dec 2004 18:59:59 +0100
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: Webdav WG <w3c-dist-auth@w3c.org>
Lisa Dusseault wrote: > I took 'DAV:acl' as an example because it's one we're familiar with and > we can see the consequences of error. It's other live properties I'm > worried about. > (BTW, where does RFC3744 say that? I see lots of places where 'DAV:acl' > is defined with respect to a resource and the language is fairly precise > about resources and URLs, so one might believe that this behavior is > implicit, but I can't see where it says anything about bindings.) It doesn't need to: <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.p.2> >>> I also worry that it's not enough for us to say that dead properties >>> MUST be the same value no matter which binding is addressed but live >>> properties MAY vary. We don't have a reliable way for the client to >>> tell which properties are dead and which are live. Still, I could >>> live with that. >> >> >> Well, as you just pointed out, the difference between dead and live >> properties is fuzzy. Also, the statement as proposed, sort of >> *encourages* implementers to have live properties varying by binding. >> IMHO, they shouldn't (as properties are part of the state of the >> resource or computed based on the state of a resource), and thus >> should not vary at all. My impression from earlier discussion was that >> you don't buy that point of view, so I haven't tried hard to get it >> into the spec. Should I now? >> > Even if I disagree with the conclusion -- perhaps *particularly* because > I disagree with the conclusion and others may also -- I feel strongly > that the decision should be reflected as a requirement in the > specification. However, that requires that there *is* a decision. As far as I can tell, there's currently no consensus for any specific statement. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 7 December 2004 18:00:50 UTC