Re: [Ietf-carddav] More comments on draft-daboo-carddav-02

Julian Reschke <> Fri, 27 July 2007 12:45 UTC

Return-Path: <>
Received: from ( []) by (Postfix) with ESMTP id 7F74D8050B for <>; Fri, 27 Jul 2007 05:45:36 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id 943F9142253 for <>; Fri, 27 Jul 2007 05:44:41 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at
X-Spam-Score: -1.53
X-Spam-Status: No, score=-1.53 tagged_above=-50 required=4 tests=[AWL=0.993, BAYES_00=-2.599, SPF_PASS=-0.001, TW_NM=0.077]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zXuXfH6nTsYF for <>; Fri, 27 Jul 2007 05:44:33 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 9A53014224B for <>; Fri, 27 Jul 2007 05:44:32 -0700 (PDT)
Received: (qmail invoked by alias); 27 Jul 2007 12:44:30 -0000
Received: from (EHLO []) [] by (mp038) with SMTP; 27 Jul 2007 14:44:30 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/7hB595XL7AHQUVw02LnKlxnp+Tz8rGt9JQ8eD97 jErtyx3pZRC1Vf
Message-ID: <>
Date: Fri, 27 Jul 2007 14:44:23 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20060516 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Cyrus Daboo <>
Subject: Re: [Ietf-carddav] More comments on draft-daboo-carddav-02
References: <> <621EC11B28D625F53D50D5B9@ninevah.local>
In-Reply-To: <621EC11B28D625F53D50D5B9@ninevah.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Jul 2007 12:45:36 -0000

Cyrus Daboo wrote:
> Hi Julian,
> Thanks for your detailed comments. Sorry it took a while to respond.

No problem.

Should this threat move over to <>?

 > ...
>> In "1.5.  WebDAV for Address Books"
>>     2.  Stateless nature of protocol can result in more data being sent
>>         with each transaction to maintain per-user session across
>>         requests.
>> I guess that should either go, or be expanded a bit; the way it's worded
>> right now I don't understand it. Is this about sending state in cookies?
> I guess I am trying to make a comparison here with IMAP where server 
> state is communicated to the client during the course of a session via 
> unsolicited responses or via the IDLE mechanism. As a result clients 
> have to poll to get state changes, and right now they have to poll an 
> entire collection to find what has changed, been added or deleted 
> (though I hope the proposed collection synchronization extension will 
> help address that).
> I can certainly expand the text to describe this more in terms of having 
> to do a full re-synchronization to get state.

Sounds good.

>> In "3.  Requirements Overview"
>>     o  MUST support vCard [RFC2426] as a media type for the address
>>        object resource format;
>> Is it clear what this requirement means?
> That should be explained in a little more detail by noting that (as with 
> CalDAV) we are not restricting ourselves to a single syntax for 
> "vCard-like" data. i.e. the spec has been designed to allow other 
> variants of vCard syntax to be used (e.g. the Jabber foundation's xcard 
> or perhaps hcard). This spec, however, only requires the server to 
> support the 2426 syntax. This is described in section 5.1. Perhaps I can 
> refer to that from this bullet point?

It should be clear what "support" means here. Are there any normative 
requirements with respect to that format?

>>     o  MUST support transport over TLS [RFC2246] as defined in [RFC2818]
>>        (note that [RFC2246] has been obsoleted by [RFC4346]);
>> Note: similar text in AtomPub was rejected by IESG. See
>> <
>> rfc.section.14> for alternate proposal.
> And yet they accepted the same text in CalDAV!

Don't get me started on that (again) :-)

> I have now changed this to (which I think follows the ATOMPUB approach 
> you linked to):
> o MUST support secure transport as defined in [RFC2818] using TLS v1.0 
> [RFC2246]
>  or a subsequent standards-track version of TLS.


> ...
>> in "4.1.  Address Book Server"
>>     A WebDAV repository can advertise itself as a CardDAV server if it
>>     supports the functionality defined in this specification at any point
>>     within the root of the repository.  That might mean that address data
>>     is spread throughout the repository and mixed with non-address data
>>     in nearby collections (e.g. address data may be found in /lisa/
>>     addressbook/ as well as in /bernard/addressbook/, and non-address
>>     data in /lisa/calendars/).  Or, it might mean that address data can
>>     be found only in certain sections of the repository (e.g.
>>     /addressbooks/user/).  Address book features are only required in the
>>     repository sections that are or contain address objects.  So a
>>     repository confining address data to the /carddav/ collection would
>>     only need to support the CardDAV required features within that
>>     collection.
>> Question: when we say "can advertise", would it cause problems when a
>> server does NOT advertisue support on anything except address books (and
>> descendants)?
> Well it has to "advertise" on any resource that includes properties, 

Really? What would happen otherwise? A client can discover all these 
capabilities using PROPFIND/prop/supported-report-set (for reports) anmd 
PROPFIND/propname (for properties), right?

> ...
>> in "6.2.  Address Book Properties"
>> Make statement about behaviour with DAV:allprop exactly once here, and
>> remove it from all subsequent subsections.
> 4918 has changed the "template" used for property definitions compared 
> to 2518. I propose to revise what is in CardDAV now along those lines. 
> e.g. have "Protected" and "COPY/MOVE" items. In addition have a 
> "DAV:allprop" behavior item in the template would be good to. I would 
> prefer having it explicitly specified in each property.

Of course that's a matter of taste, but repeating the same information 
all over again is just wasting space. I'd recommend not to.

Also, I'd avoid adding the COPY/MOVE stuff; that has been *very* 
controversial when RFC4918 was written. Do you have anything interesting 
to say about COPY/MOVE?

>> in "6.2.1.  CARDDAV:addressbook-description Property"
>>     Conformance:  This property MAY be defined on any address book
>>        collection.  If defined, it MAY be protected and SHOULD NOT be
>>        returned by a PROPFIND DAV:allprop request (as defined in Section
>>        12.14.1 of [RFC2518]).  An xml:lang attribute indicating the human
>>        language of the description SHOULD be set for this property by
>>        clients or through server provisioning.  Servers MUST return any
>>        xml:lang attribute if set for the property.
>> "MAY be defined" is a confusing way to say that it's optional. The
>> language about xml:lang is kind of confusing; for instance, I can see
>> people understand this that the server should provide the property if the
>> client didn't specify it. Bad idea.
>>     Description:  If present, the property contains a description of the
>>        address book collection that is suitable for presentation to a
>>        user.  If not present, the client should assume no description for
>>        the address book collection.
>> Can we just say what it is? If it's not there, it's not there. Please
>> don't make things more complicated than they are.
> I think the concern here was to make sure server vendors reserved a slot 
> in their schema for such a property, for the case where servers had a 
> fixed schema and would not allow "arbitrary" properties to be created. 
> Is that a real concern or not? If not, then your text is certainly 
> better. If it is a concern, then we do need a statement to that effect - 
> but perhaps that can be a general statement in the requirements section, 
> and the actual property descriptions can follow your simple text.

Not sure what this means. Is this property different from any other 
optional property, such as DAV:displayname?

>> in "6.2.2.  CARDDAV:supported-address-data Property"
>>     Purpose:  Specifies what media types are allowed for address object
>>        resources in an address book collection.
>>        ...
>>     Example:
>>         <C:supported-address-data
>>            xmlns:C="urn:ietf:params:xml:ns:carddav">
>>           <C:addressbook-data content-type="text/vcard" version="3.0"/>
>>         </C:supported-address-data>
>> Why is this needed? How are media types with different parameters
>> treated (such as text/directory;profile=vcard)?
> As discussed earlier, other syntaxes for vCard-like data may be offered 
> by servers in the future, so this property identifies what a server 
> supports.

I guess you then need a definition of what it means to "support" an 
address data format.

> Note that text/vcard does not actually exist as a MIME type right now. I 
> am hoping that the vCard revision effort will lead to the introduction 
> of that type with the requirement that it be utf-8 text (similar to 
> text/calendar).

Understood. But while the only MIME type we have is

	text/directory;profile=vcard is this supposed to work exactly? How are MIME type parameters 
treated here?

> ...
>>     Clients SHOULD use the DAV:displayname property for a human-readable
>>     name of the address book.  Clients can either specify the value of
>>     the DAV:displayname property in the request body of the MKADDRESSBOOK
>>     request, or alternatively issue a PROPPATCH request to change the
>>     DAV:displayname property to the appropriate value immediately after
>>     using the MKADDRESSBOOK request.  Clients SHOULD NOT set the DAV:
>>     displayname property to be the same as any other address book
>>     collection at the same URI "level".  When displaying address book
>> In WebDAV, there is no requirement that DAV:displayname is unique in a
>> collection, and in practice, it may be hard to guarantee. Why is this
>> needed? Also, there seems to be an overlap with CARDDAV:description.
> That requirement is present to avoid confusing the user with two address 
> books that appear to have the same name but are in fact different (e.g. 
> a user may think that they have duplicate address books and go and 
> delete one on the basis that all its data is in the other).

A client that uses *only* DAV:displayname to identify items is broken. 
I'd like to leave it that way, and not complicate DAV:displayname 
handling even further.

And what's the relation to CARDDAV:description?

> ...
>> in "  Additional Preconditions for PUT, COPY and MOVE"
>>     The new preconditions are:
>>        (CARDDAV:supported-address-data): The resource submitted in the
>>        PUT request, or targeted by a COPY or MOVE request MUST be a
>>        supported media type (i.e., vCard) for address object resources;
>> This is already covered by HTTP status 415.
> A pre-condition DAV:error can include a more structured response about 
> the nature of the error, so when is it appropriate to use that as 
> opposed to a status code?

Well, in this case there is no additional information, so I think a 
plain 415 is completely sufficient.

> ...
>> in "  Address Object Resource Entity Tag"
>>     The DAV:getetag property MUST be defined and set to a strong entity
>>     tag on all address object resources.
>> Disagree; see above.
>>     Servers SHOULD return a strong entity tag (ETag header) in a PUT
>>     response when the stored address object resource is equivalent by
>>     octet equality to the address object resource submitted in the body
>>     of the PUT request.  This allows clients to reliably use the returned
>>     strong entity tag for data synchronization purposes.  For instance,
>>     the client can do a PROPFIND request on the stored address object
>>     resource and have the DAV:getetag property returned, and compare that
>>     value with the strong entity tag it received on the PUT response, and
>>     know that if they are equal, then the address object resource on the
>>     server has not been changed.
>> This basically makes it impossible to rewrite content, and still return
>> an ETag. I think this is a mistake.
> We have obviously been through all this with CalDAV. In the absence of 
> any alternative approach, I think we should stick with what CalDAV does 
> in this regard. However, a better solution to this is needed and I think 
> its time your draft gets more attention so that we can move that or 
> something similar forward to address this. I think PATCH is also going 
> to be impacted by this too.

Right. I'd prefer the spec to stay silent on this, thought. This is 
something that HTTPbis should clarify/fix, and is IMHO not up to CardDAV 
to specify (or CalDAV, for that matter).

>> 8.  Address Book Reports
>>     CardDAV servers MUST advertise support for these REPORTs on all
>>     address book collections and address object resources with the DAV:
>>     supported-report-set property defined in Section 3.1.5 of [RFC3253].
>>     CardDAV servers MAY also advertise support for these REPORTs on
>>     ordinary collections.
>> Simplify: (1) this restates what was alredy said. (2) the key here is
>> that servers may support the reports elsewhere as well, not that they can
>> *advertise* support for them, right?
> Not quite: this says that servers must follow the 3253 convention on 
> advertising the reports in DAV:supported-report-set, whereas previous 
> statements relating to supporting the reports themselves. Since we are 
> "inheriting" certain aspects of 3253's report behavior I think it is 
> import to be explicit about what is required. Perhaps this is a case 
> where we can pull the REPORT method out of 3253 and write it up as a 
> separate extension with requirements explicitly stated, then other specs 
> that need to use it could reference that.

Right. I volunteer to do so.

With respect to this spec, please avoid restating things. It would be 
completely sufficient to state once and for all that the RFC3253 
requirements of DAV:supported-report-set are inherited.

 > ...
>>     CardDAV servers are REQUIRED to support the "i;ascii-casemap" and
>>     "i;octet" collations as described in [RFC4790], and the
>>     "i;unicasemap" collation as described in
>>     [I-D.crispin-collation-unicasemap], MAY support other collations.
>> (1) I think for collations that are defined in terms of octet sequences,
>> a mapping from vcard needs to be defined (say: UTF-8). (2) Also, I don't
>> think this can be guaranteed in practice, for instance when the CardDAV
>> server just proxies.
> The collations themselves define how mapping or normalization of the 
> input data should be done. I don't think we need to state that here.

Looking at sections 5.1 and 5.7 of RFC4790, I'm tempted to say this is 
incorrect. If you use "i;octet", you simply have to state how to produce 
the octets to be compared.

 From <>:

    The protocol specification has to make sure that it is clear on which
    characters (rather than just octets) the collations are used.  This
    can be done by specifying the protocol itself in terms of characters
    (e.g., in the case of a query language), by specifying a single
    character encoding for the protocol (e.g., UTF-8 [3]), or by
    carefully describing the relevant issues of character encoding
    labeling and conversion.  In the later case, details to consider
    include how to handle unknown charsets, any charsets that are
    mandatory-to-implement, any issues with byte-order that might apply,
    and any transfer encodings that need to be supported.

And yes, that affects CalDAV as well.

>>     Clients MUST only use collations from the list advertised by the
>>     server.
>> That requirement is useless.
> Why? All it says is that clients must attempt to use only those 
> collations advertised by the server.

And if they don't, the server will reject the request. So it's useless, 
and definitively nothing that requires a RFC2119-style requirement.

>> in "8.6.  CARDDAV:addressbook-query Report"
>> All report definitions must precisely state the semantics of the Depth
>> request header.

Did you miss this one?

>>     Postconditions:
>>        (DAV:number-of-matches-within-limits): The number of matching
>>        address object resources must fall within server-specific,
>>        predefined limits.  For example, this condition might be triggered
>>        if a search specification would cause the return of an extremely
>>        large number of responses.
>> Reference definition in RFC3744.
> 3744 specifically talks about principals which are not relevant here.

Oops. In this case I'd argue you shouldn't use the condition name.

>> in "8.7.  CARDDAV:addressbook-multiget Report"
>>     Support for the addressbook-multiget REPORT is REQUIRED.
>> Why?
> multiget makes a big difference in performance.

OK, so a server that doesn't implement it will hurt itself by having to 
reply to many GET methods. I still don't see how that would justify a 
MUST level requirement, though.

>> Editorial:
>> in "Abstract":
>>     This document defines extensions to the Web Distributed Authoring and
>>     Versioning (WebDAV) protocol to specify a standard way of accessing,
>>     managing, and sharing contact information based on the vCard format.
>>     This document defines the "addressbook-access" feature of CardDAV.
>> I think it would be good to have an editorial note here pointing to the
>> vcard mailing list.
> Done.

...or the new mailing list...

 > ...

Best regards, and thanks for the feedback & changes,