Entity tag related requirements in carddav, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

Hi,

1) Editorial: 4.1 Address Book Server

"However, clients MUST be prepared for address data on the server to 
change between the time of last synchronization and when attempting an 
update, as address book collections may be shared and accessible via 
multiple clients."

I don't think that this requires RFC2119 terminology (this applied IMHO 
to many other specs where it's overused). Simply point out that in 
absence of locking, resources can change.

"Entity tags and other features help this work."

That's true, but a bit vague. What does "other feature" refer to? Locking?

2) 6.3.2.3 Address Object Resource Entity Tag

This section duplicates ETag requirements from CalDAV which IMHO are 
controversial (see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-09.html>).

I think the language encourages implementations to either not expose 
ETags (which is clearly inferior to exposing weak etags), or to claim 
they are strong when in fact the server can't make that guarantee 
because of the way the backing storage works.

It would be interesting to know what percentage of CalDAV servers 
actually do implement this properly.

(Related discussion for CalDAV: around 
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-June/000852.html>).

Best regards, Julian

Received on Tuesday, 17 March 2009 15:00:13 UTC