Draft:  draft-dusseault-caldav-12.txt
Reviewer: Joel M. Halpern [joel@stevecrocker.com]
Review Date:  Saturday 4/29/2006 5:20 PM CST
IETF LC Date: 5/24/2006

Summary: This document is almost ready for publication as a Proposed 
Standard.  There is one item that at least requires some improvement 
in the wording, and a minor matter that should be considered.


The text in section 5.3.4 on strong ETags is somewhat 
confusing.  After describing what should happen in the case of 
storing something octet-identical to the PUT, the text then says that 
"the ETag response header is undefined" when the entity stored is not 
octet identical.  My confusion is that the following phrase says that 
"a strong entity tag MUST NOT be returned in the response."  From the 
context, an ETag header is a strong entity tag.  Thus, the first 
portion says that the content or presence of an ETag header in the 
response is not defined, and the second phrase says that it MUST NOT 
be included.  That seems to constitute a pretty clear definition, 
rather than "undefined".  The text needs work.

Further, and more debatable, since this text does not talk about the 
association of the ETag, just about the returning of the ETag, the 
protocol seems to be using the returning of the ETag as a means of 
flagging whether the server changed the content.  That seems an odd 
way of indicating that information.  (Not wrong, just odd.)  Did you 
consider using an additional HTTP header to indicate this 
condition?  At a guess, the motivation for the usage is that the ETag 
does not represent the contents provided in the PUT.  And hence, the 
text is trying to say that the ETag can not be returned in the PUT 
response because it is not actually the ETag for the PUT data (but 
rather for something derived from the PUT data.)  If that is the 
intent, it is defensible, but still seems odd to this reader (who is 
neither an HTTP expert, a WebDav expert, nor an iCalendar 
expert.)   Also, if it is anticipated that this situation is likely 
to be common, then this restriction, and the concomitant extra 
transactions to get the real ETag, would seem counter-productive.


minor: Is the recurrence handling described here consistent with that 
provided by iCalendar?  If so, it would be good to say so.  If not, 
it seems necessary to talk about how the inconsistency ought to be 
addressed. (I suspect that the two are consistent, and this just 
needs a sentence saying so.)