- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 13 Jun 2001 23:16:06 -0400
- To: ietf-dav-versioning@w3.org
Yes, this issue was raised and debated a couple of IETF's ago, and the consensus was that the implementation burden on a server to support versioned dead properties was not sufficient to introduce a major source of interoperability problems (i.e. clients that expected to be able to version properties would not interoperate effectively with servers that did not, and vica versa). Note that the server defines the versioning behavior of any server defined (and therefore, live) properties, so a server is certainly free to make all of its server defined properties non-versioned. Cheers, Geoff -----Original Message----- From: John Hall [mailto:johnhall@evergo.net] My goals are in providing basic versioning for customers that do not need elaborate features, but not getting in the way of more sophisticated clients envisioned in the full DeltaV spec. This is probably a land mine, but I thought I'd try. I do not like the idea of versioning properties. My customers are interested in versioning content, not properties. Mutable global properties are just fine, beyond those properties specifically defined in DeltaV as per-version (like comment and label). So my first suggestion would be to modify the VERSION-CONTROL feature so that someone could turn versioning for content on seperately from versioning of properties. Your sophisticated clients would know up front if they hit our server and we didn't support property versioning. They could then warn their version-aware users. I've thought of some other expedients, most of which Lisa shot down for a variety of reasons. But why can't we make it optional? If your clients want to get huffy and not deal with a lowly server that doesn't version properties then so be it.
Received on Wednesday, 13 June 2001 23:11:01 UTC