W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2005

Re: BIND and live property value consistency

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 29 Jun 2005 17:14:53 +0200
Message-ID: <42C2BAED.8080808@gmx.de>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
CC: webdav <w3c-dist-auth@w3.org>

Geoffrey M Clemm wrote:
> 
> We have gone over these exact arguments many times.
> It is true that we disagree, but that disagreement is over
> a single simple point.
> 
> In particular, the authors of the BIND specification believe
> that the semantics of a live property should be defined by
> the specification that introduces that live property,
> and if those semantics of a given live property are to be
> redefined/refined/clarified, that should be done in a
> specification that obsoletes the one with the original definition.

Yes.

> A key question is whether disagreement on such a point
> from a single workgroup participant can veto a specification.

Agreed.

The other point we seem to disagree upon is that BIND should only be 
applicable to a certain class of servers that indeed can maintain the 
live properties the way many wish. I absolutely agree in that it's a 
good thing if a server behaves that way, but I also think that BIND 
shouldn't mandate that. We conceivably could do two things:

- in RFC2518bis, clarify the issues that arise because of the 
interaction between DAV:get* properties inherited from HTTP and the 
WebDAV namespace operations (for instance, state that a server must do 
post-namespace-op-cleanup of for instance DAV:getlastmodified; and also 
suggest that having strong entity tags that are unique across the 
server's whole namespace will make that unnecessary for DAV:getetag)

- define a specific profile (putting additional constraints on the 
behaviour of some of these live properties), and make that 
client-detectable (for instance through a specific DAV: header option).

Best regards, Julian
Received on Wednesday, 29 June 2005 15:15:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:08 GMT