CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)
draft-ietf-vcarddav-carddav-10

I have balloted "yes" on this document although I hope my comments may be useful anyway.

Disadvantage #2 in section 1. drove me crazy: 

   2.  Stateless nature of protocol can result in more data being sent
       with each transaction to maintain per-user session across
       requests.

First, statelessness is a tradeoff, not a pure disadvantage: scaling and easy server-form usage vs. volume of bits. 

Second, the idea that VCARDDAV requires servers to "maintain per-user session" across requests is misleading.  There are only two pieces of information that should be maintained across requests. The first might be possibly cookies, although I don't yet know if cookie support is required.  The other thing is Digest nonces.  Both of these support user authentication or identity, so "session" is going too far. 

Third, when TLS is used, VCARDDAV does have a session that is maintained over a connection and TLS client authentication could even maintain the context.  In this deployment scenario, session maintenance is done at a different layer and thus not "required by VCARDDAV".

My first suggestion is just to remove this.  The lack of change notification drawback can stand on its own rather than being a list.

If the "stateless" drawback has to be there for some reasons, I'd rephrase it.  

	2.  Although stateless design does allow scalability (e.g. using HTTP server farms), it has a cost in transmission volume.  Some context-establishing information, typically user authorization, must be resent in each request unless an underlying and authorizing connection is maintained.
	

Second issue: 

In section 8.6.2, a Server Error status code (507) is indicated for use in cases when the server has no errors but is honouring the client's result limit request.  Does this conflate two different cases that really should be treated separately? For example, what if the client asks for their results to be limited to 500 responses but the server decides to further limit the response to 50?  The client can't tell until counting up the number of resources whether the server successfully applied the client's requested limit, or applied a cutoff of its own.

Also in this section, I believe it's ambiguous what should be returned if the client requested a REPORT response limited to X items but there were fewer than X items matching the filter.  One could imagine an implementor putting 507 in the status response to indicate "The client's limit was applied because no more than X resources were returned".  One could also imagine an implementor returning 200 OK because no results were truncated. 

My suggestion here if it's not too late, would be to consider dropping in a <VCARDDAV:results-truncated> element that is only used when there really were results truncated at either the client or the server's choice.  When this happens because of a server choice, the 507 status code is also used to alert the client.  Otherwise, a 200 OK is fine. 

I'm quite open to arguments that this is unnecessary or too late but I wanted to see if it had been considered.