Subject: Re: [Ietf-carddav] More comments on draft-daboo-carddav-02
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Date: Fri, 27 Jul 2007 14:44:23 +0200
List-Id: ietf-carddav.osafoundation.org

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 <mailto:[email-masked]>?

 > ...
>> 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
>> <http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html#
>> 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.

Great.

> ...
>> 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

...how 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 "6.3.2.1.  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 "6.3.2.3.  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 <http://tools.ietf.org/html/rfc4790#section-5.1>:

    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,

Julian

From: Marc Blanchet <[email-masked]>
Date: Thu, 26 Jul 2007 17:43:32 -0500
To: [email-masked]
Subject: [Ietf-carddav] presentations today and other "wg" info

Hi,
  just started a quick web page about carddav, mostly pointers to  
charter proposal, mailing list, documents and today's bof presentations.

http://www.viagenie.ca/projects/carddav/index.html

Marc.

From: Marc Blanchet <[email-masked]>
Date: Thu, 26 Jul 2007 17:18:59 -0500
To: [email-masked]
Cc: Chris Newman <[email-masked]>
Subject: [Ietf-carddav] charter comments

my comments on charter sent by Chris (http://www1.ietf.org/mail- 
archive/web/discuss/current/msg00600.html)

...
This includes:
<MB>
An example from a customer of ours, if this may be useful to the  
charter.
* A contact database service used for sales management, where  
multiple users may access and change contacts in the database
</MB>
...

This WG will produce the following two primary outputs:

* A revision of the vCard spec (RFC 2426) likely at proposed standard
  status.  The WG will attempt to avoid adding new features, with two
  exceptions: 1. The WG may consider including other proposed  
standard vCard
  extensions (e.g., RFC 4770, RFC 2739).  2. The WG may evaluate  
extensions
  that would assist synchronization technologies (for example, a per- 
entry
  UUID or per-attribute sequence number).
<MB>
3. The WG should define a way to properly handle extensions with a  
possible central registry in an extension name space.
</MB>

* An address book access protocol leveraging the vCard data format.  The
  Internet-draft draft-daboo-carddav will be the starting point.
  The WG is explicitly cautioned to keep the base specification  
feature set
  small with an adequate extension mechanism, as failure to do so was a
  problem for previous PAB efforts (ACAP).  The WG will consider  
arguments
  of the form "feature X must be in the base feature set because ..."
  with great skepticism.

These documents will consider security implications carefully.
<MB>s/carefully//</MB>

...

<MB>
Should we have a requirement document to start with?
</MB>

Date: Thu, 26 Jul 2007 10:32:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, [email-masked]
Subject: Re: [Ietf-carddav] More comments on draft-daboo-carddav-02

Hi Julian,
Thanks for your detailed comments. Sorry it took a while to respond.

--On July 15, 2007 2:22:44 PM +0200 Julian Reschke <[email-masked]> 
wrote:

> More detailed comments on draft-daboo-carddav-02...:
>
> In general, please replace all references to RFC2518 with RFC4918.
>
> 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.

> In "2.1.  Notational Conventions"
>
>     The term "protected" is used in the Conformance field of property
>     definitions as defined in Section 1.4.2 of [RFC3253].
>
> Section 15 of RFC4918.

Fixed.

> In "2.2.  XML Namespaces and Processing"
>
>     Processing of XML by CardDAV clients and servers MUST follow the
>     rules described in [RFC2518], in particular Section 14, and Appendix
>     3 of that specification.
>
> Appendix A of [RFC4918].

Fixed.

> In "2.3.  Method Preconditions and Postconditions"
>
> Just cite RFC4918, Section 16. Note the current text is incompatible with
> RFC4918 with respect to DAV:error in DA:multistatus.

I will remove that section in its entirety as the spec will now cite 4918 
instead of 2518.

> 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?

>     o  MUST support WebDAV Class 1 [RFC2518] (note that
>        [I-D.ietf-webdav-rfc2518bis] describes clarifications to [RFC2518]
>        that aid interoperability);
>
> Should say RFC4918 Class 3.

Fixed.

>     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
> <http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html#
> rfc.section.14> for alternate proposal.

And yet they accepted the same text in CalDAV!

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.

>     o  MUST support ETags [RFC2616] with additional requirements
>        specified in Section 6.3.2.3 of this document;
>
> Nope; see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0006.html>.

More on this below...

>     o  MUST support all address book REPORTs defined in ,xref
>        target="reports"/> of this document; and
>
> (XML in draft source broken)

Fixed.

>
> 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, 
reports etc specific to this spec. So at a minimum that means address book 
collections and principal resources. And no, it should not cause clients a 
problem if it only does that.

>     The CardDAV server or repository is the canonical location for
>     address data and state information.  Clients may submit requests to
>
> Server or repository? Please be consistent. Also, what does it mean
> to be the "canonical location"? Does that rule out a CardDAV server to be
> a proxy to an LDAP server?

OK, I will tidy that up. "Cononical" is really described by the subsequent 
text in that paragraph that discusses how clients should do 
synchronization. That does not rule out a CardDAV server from being a 
"getaway" to another server - it just makes it clear to clients of CardDAV 
how they should treat the server.

>
> in "5.2.  Address Book Collection"
>
>     CardDAV defines the following new resource type for use in WebDAV
>     repositories holding vCard data.
>
> Remove that intro. Section reads completely fine without it.

Done.

>
> in "6.1.1.  Example: Using OPTIONS for the Discovery of Support for
> CardDAV"
>
>     HTTP/1.1 200 OK
>     Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
>     Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT
>     Allow: MKADDRESSBOOK, ACL
>     DAV: 1, 2, access-control, addressbook-access
>     Date: Sat, 11 Nov 2006 09:32:12 GMT
>     Content-Length: 0
>
> DAV: 1, 2, 3, access-control, addressbook-access

Fixed.

> 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.

> 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.

>
> 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.

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).

>
> in "6.3.1.  MKADDRESSBOOK Method"
>
>     Support for MKADDRESSBOOK on the server is only RECOMMENDED and not
>     REQUIRED because some address book stores only support one address
>     book per user (or principal), and those are typically pre-created for
>     each account.  However, servers and clients are strongly encouraged
>     to support MKADDRESSBOOK whenever possible to allow users to create
>     multiple address book collections to help organize their data better.
>
> ...and not required...
>
>     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).

>     collections to users, clients SHOULD check the DAV:displayname
>     property and use that value as the name of the address book.  In the
>     event that the DAV: displayname property is empty, the client MAY use
>
> ...property is not set... (this is different from being empty)

Fixed.

>     the last part of the address book collection URI as the name, however
>     that path segment may be "opaque" and not represent any meaningful
>     human-readable text.
>
>     If a MKADDRESSBOOK request fails, the server state preceding the
>     request MUST be restored.
>
> Please specify cacheability/safety/idempotence.

OK, I will need to think about that a little bit.

>        (CARDDAV:addressbook-collection-location-bad): The Request-URI
>        MUST identify a location where an address book collection can be
>        created.
>
> CARDDAV:addressbook-collection-location-valid

CARDDAV:addressbook-collection-location-ok matches the one in CalDAV. Fixed.

>        (DAV:needs-privilege): The DAV:bind privilege MUST be granted to
>        the current user.
>
> (1) It's "need-privileges"
> (<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>. (2)
> Is it really required to repeat that here? If yes, please include a
> reference to the definition in RFC3744.

Fixed the name. I will leave that in for now, but chances are if we end up 
using an extended MKCOL for this we would "inherit" this pre-condition by 
default.

>
> in "6.3.1.1.  Status Codes"
>
>        201 (Created) - The address book collection resource was created
>        in its entirety.
>
> Please specify what "in its entirety" means or drop it.

Fixed:

201 (Created) - The address book collection resource was created,
and any supplied properties values were set.

>        409 (Conflict) - A collection cannot be made at the Request-URI
>        until one or more intermediate collections have been created.
>
> This is incorrect; it is in conflict with the pre/postcondition
> definitions.

Removed.

>        415 (Unsupported Media Type) - The server does not support the
>        request type of the body.
>
>        507 (Insufficient Storage) - The resource does not have sufficient
>        space to record the state of the resource after the execution of
>        this method.
>
> If the list is not exhaustive anyway, things like 507 or 415 IMHO should
> go. The more you repeat obvious stuff, the harder it is to see what's
> being specified.

Removed.

>
> in "6.3.2.1.  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?

>        (CARDDAV:addressbook-collection-location-ok): In a COPY or MOVE
>        request, when the Request-URI is an address book collection, the
>        Destination-URI MUST identify a location where an address book
>        collection can be created;
>
> "Destination-URI"? Did you mean "The URI specified in the Destination
> header?"

Yes. Fixed.

>
> in  "6.3.2.2.  Non-Standard Properties, and Parameters"
>
> I was momentarily confused because I thought it wasn't about vCard data.
> Maybe include this in the section title?

Fixed.

>     Servers may need to enforce rules for their own "private" properties
>     or parameters, so servers MAY reject any attempt by the client to
>     change those or use values for those outside of any restrictions the
>     server may have.  Servers SHOULD ensure that any "private" properties
>     or parameters it uses follow the convention of including a vendor id
>     in the "X-" name, as described in Section 3.8 of [RFC2426], e.g.,
>     "X-ABC-PRIVATE".
>
> Just state the requirement from RFC2426, but don't add an own one.

Actually 2426 does not have a formal requirement for a vendor-id. That is 
something that ought to be fixed in any revision IMHO.

>
> in "6.3.2.3.  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.

>
> 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.

>
> in "8.3.  Searching Text: Collations"
>
>     Some of the reports defined in this section do text matches of
>     character strings provided by the client and compared to stored
>     address data.  Since vCard data is by default encoded in the UTF-8
>     charset and may include characters outside of the US-ASCII charset
>     range in some property and parameter values, there is a need to
>     ensure that text matching follows well-defined rules.
>
> Lots of motivation, not really needed here. Also, I think "default" is
> misleading, as the default for text/* is *not* UTF-8.

As per above I would like to see text/vcard be defined with utf-8 as the 
default.

>     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.

>     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.

>
> in "8.6.  CARDDAV:addressbook-query Report"
>
> All report definitions must precisely state the semantics of the Depth
> request header.
>
>     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.

>
> in "8.7.  CARDDAV:addressbook-multiget Report"
>
>     Support for the addressbook-multiget REPORT is REQUIRED.
>
> Why?

multiget makes a big difference in performance.

> -------------
>
> 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.

> With respect to DTD fragments:
>
> Please make sure they actually *are* DTD fragment, so for instance replace
>
>         <!ELEMENT addressbook-description (#PCDATA)>
>         PCDATA value: string
>
> by
>
>         <!ELEMENT addressbook-description (#PCDATA)>
>         <!-- PCDATA value: string -->

Fixed.

> in "1.  Introduction and Overview"
>
>     Address books containing contact information are a key component of
>     personal information management tools, such as email, calendaring and
>     scheduling, and instant messaging clients.  To date several protocols
>     have been used for remote access to contact data, including LDAP
>     [RFC2251], IMSP and ACAP [RFC2244], together with SyncML used for
>     synchronization of such data.
>
> Reference for IMSP? Also, expand acronyms on first usage.

Done.

> in "1.1.  IMSP"
>
> In the list (and subsequent list), please consistently end sentences with
> a dot.

Fixed.

> in "4.1.  Address Book Server"
>
>     A WebDAV repository MAY include address data in some parts of its URL
>     namespace, and non-address data in other parts.
>
> I don't think this is any kind of requirement; it just states something
> obvious. Please lowercase the MAY.

Done.

> in "5.1.  Address Object Resources"
>
>     This specification uses vCard as the default format for address or
>     contact information being stored on the server.  However, this
>     specification does allow other formats for address data provided that
>     the server advertises support for those additional formats as
>     described below.  The requirements in this section pertain to vCard
>     address data, os formats that follow the semantics of vCard data.
>
> Typo? os->or?

Fixed.

> in "6.2.2.  CARDDAV:supported-address-data Property"
>
>     Conformance:  This property MAY be defined on any address book
>        collection.  If defined, it MUST be protected and SHOULD NOT be
>        returned by a PROPFIND DAV:allprop request (as defined in Section
>        12.14.1 of [RFC2518] ).
>
>     Description:  The CARDDAV:supported-address-data property is used to
>        specify the media type supported for the address object resources
>        contained in a given address book collection (e.g., vCard version
>        3.0).  Any attempt by the client to store address object resources
>        with a media type not listed in this property MUST result in an
>        error, with the CARDDAV:supported-address-data precondition (
>        Section 6.3.2.1 ) being violated.  In the absence of this property
>        the server MUST only accept data with the media type "text/vcard"
>        and vCard version 3.0, and clients can assume that.
>
> Please check whitespace around xml2rfc <xref> elements (this repeats
> several times through the draft).

Fixed.

> in "6.3.1.2.  Example - Successful MKADDRESSBOOK request"
>
>     HTTP/1.1 201 Created Date: Fri, 22 Oct 2004 12:17:08 GMT
>     Content-Length: 0
>     Date: Sat, 11 Nov 2006 09:32:12 GMT
>     Cache-Control: no-cache
>
> Two date headers.

Fixed.

> in "6.3.2.  Creating Address Object Resources"
>
>     >> Request <<
>
>     PUT /lisa/addressbook/newvcard.vcf HTTP/1.1
>     If-None-Match: *
>     Host: addressbook.example.com
>     Content-Type: text/vcard
>     Content-Length: xxx
>
>     BEGIN:VCARD
>     VERSION:3.0
>     FN:Cyrus Daboo
>     N:Daboo;Cyrus
>     ADR;TYPE=POSTAL:;2822 Email HQ;Suite 2821;RFCVille;PA;15213;USA
>     EMAIL;TYPE=INTERNET,PREF:[email-masked]
>     NICKNAME:me
>     NOTE:Example VCard.
>     ORG:Self Employed
>     TEL;TYPE=WORK,VOICE:412 605 0499
>     TEL;TYPE=FAX:412 605 0705
>     URL:http://www.daboo.name
>     UID:1234-5678-9000-1
>     END:VCARD
>
> Please use example domain names in examples (here: EMAIL and URL).

Fixed.

>
> in "6.3.2.1.  Additional Preconditions for PUT, COPY and MOVE"
>
>     This specification creates additional Preconditions for PUT, COPY and
>     MOVE methods.  These preconditions apply:
>
>        When a PUT operation of an address object resource into an address
>        book collection occurs.
>
>        When a COPY or MOVE operation of an address object resource into
>        an address book collection occurs.
>
> List style: please make it "numbers" or "symbols"

Fixed.

> in "7.1.1.  CARDDAV:addressbook-home-set Property"
>
>      <C:addressbook-home-set xmlns:D="DAV:"
>         xmlns:C="urn:ietf:params:xml:ns:carddav">
>        <D:href>http://addressbook.example.com/bernard/addresses/</D:href>
>      </C:addk-home-set>
>
> Check the end tag.

Fixed.

-- 
Cyrus Daboo

X-From_: [email-masked]  Sun Jul 22 14:33:01 2007
Date: Sun, 22 Jul 2007 16:30:06 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Sun, 22 Jul 2007 14:30:47 +0000
Cc: [email-masked]

Julian Reschke wrote:
 > ...
>> We still don't have the ability to synchronize property values in 
>> WebDAV.  We could start designing that, but there's not a strong call 
>> to, unless we start getting confused and put data into the metadata.
> 
> That's a separate issue that should be solved. As a matter of fact, I 
> think I've got a good idea to address this and other related things, but 
> I didn't have time so far to write it down (famous last words, I know).
> ...

OK,

in the meantime I've spent some time on a proposal, see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html>.

Essentially it's based on the fact that PROPFIND/REPORT/SEARCH are safe 
methods, but that the information they provide is "off" the bookmarkable 
and cacheable web. So let's try to fix that.

A new entity header would *allow* the server to advertise that location, 
for instance 
(<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#examples>):

-----

A.1.  WebDAV Collection Membership

    In this example the client uses the WebDAV PROPFIND method ("HTTP
    Extensions for Web Distributed Authoring and Versioning", [RFC4918],
    Section 9.1) to get a list of all collection members, along with
    their DAV:resourcetype property ([RFC4918], Section 15.9):

    >>Request

    PROPFIND /collection/ HTTP/1.1
    Host: example.com
    Depth: 1
    Content-Type: application/xml

    <propfind xmlns="DAV:">
      <prop>
        <resourcetype/>
      </prop>
    </propfind>

    The response contains the requested information, plus the GET-
    Location header, identifying a separate resource which can provide
    the same information using the HTTP GET method:

    >>Response

    HTTP/1.1 207 Multi-Status
    Content-Type: application/xml
    GET-Location: <http://example.com/collection/;members>; etag="123";
                  max-age=3600

    <multistatus xmlns="DAV":>
      <response>
        <href>/collection/</href>
        <propstat>
          <prop>
            <resourcetype><collection/></resourcetype>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
    </multistatus>

    The responses provided the URL of a "gettable" resource, so when the
    client wishes to refresh the collection information, it uses that
    URI.  The response contained the entity tag for the data being
    returned, so it can make the request conditional:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "123"

    The information did not change, so the server does not need to return
    new data:

    >>Response

    HTTP/1.1 304 Not Modified

    Later on, the client tries again.  This time, however, a second
    member has been added:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "123"

    >>Response

    HTTP/1.1 200 OK
    Content-Type: application/xml
    ETag: "124"

    <multistatus xmlns="DAV":>
      <response>
        <href>/collection/</href>
        <propstat>
          <prop>
            <resourcetype><collection/></resourcetype>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member2</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
    </multistatus>

    Finally, the collection has been removed by somebody else.  The
    client tries a refresh:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "124"

    >>Response

    HTTP/1.1 404 Not Found

    Note that it may be hard to compute strong entity tags for more
    complex PROPFIND responses.  For instance, most properties depend on
    the state of the collection member, not the state of the collection
    itself, and thus the response will change even though the state of
    the collection itself did not change.

    This is why this extension leaves it to the server whether to return
    a GET-Location at all, and if so, whether to return cache validators
    along with it.

----

Feedback appreciated,

Julian

Date: Sun, 22 Jul 2007 16:30:06 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: [email-masked]

Julian Reschke wrote:
 > ...
>> We still don't have the ability to synchronize property values in 
>> WebDAV.  We could start designing that, but there's not a strong call 
>> to, unless we start getting confused and put data into the metadata.
> 
> That's a separate issue that should be solved. As a matter of fact, I 
> think I've got a good idea to address this and other related things, but 
> I didn't have time so far to write it down (famous last words, I know).
> ...

OK,

in the meantime I've spent some time on a proposal, see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html>.

Essentially it's based on the fact that PROPFIND/REPORT/SEARCH are safe 
methods, but that the information they provide is "off" the bookmarkable 
and cacheable web. So let's try to fix that.

A new entity header would *allow* the server to advertise that location, 
for instance 
(<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#examples>):

-----

A.1.  WebDAV Collection Membership

    In this example the client uses the WebDAV PROPFIND method ("HTTP
    Extensions for Web Distributed Authoring and Versioning", [RFC4918],
    Section 9.1) to get a list of all collection members, along with
    their DAV:resourcetype property ([RFC4918], Section 15.9):

    >>Request

    PROPFIND /collection/ HTTP/1.1
    Host: example.com
    Depth: 1
    Content-Type: application/xml

    <propfind xmlns="DAV:">
      <prop>
        <resourcetype/>
      </prop>
    </propfind>

    The response contains the requested information, plus the GET-
    Location header, identifying a separate resource which can provide
    the same information using the HTTP GET method:

    >>Response

    HTTP/1.1 207 Multi-Status
    Content-Type: application/xml
    GET-Location: <http://example.com/collection/;members>; etag="123";
                  max-age=3600

    <multistatus xmlns="DAV":>
      <response>
        <href>/collection/</href>
        <propstat>
          <prop>
            <resourcetype><collection/></resourcetype>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
    </multistatus>

    The responses provided the URL of a "gettable" resource, so when the
    client wishes to refresh the collection information, it uses that
    URI.  The response contained the entity tag for the data being
    returned, so it can make the request conditional:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "123"

    The information did not change, so the server does not need to return
    new data:

    >>Response

    HTTP/1.1 304 Not Modified

    Later on, the client tries again.  This time, however, a second
    member has been added:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "123"

    >>Response

    HTTP/1.1 200 OK
    Content-Type: application/xml
    ETag: "124"

    <multistatus xmlns="DAV":>
      <response>
        <href>/collection/</href>
        <propstat>
          <prop>
            <resourcetype><collection/></resourcetype>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member2</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
    </multistatus>

    Finally, the collection has been removed by somebody else.  The
    client tries a refresh:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "124"

    >>Response

    HTTP/1.1 404 Not Found

    Note that it may be hard to compute strong entity tags for more
    complex PROPFIND responses.  For instance, most properties depend on
    the state of the collection member, not the state of the collection
    itself, and thus the response will change even though the state of
    the collection itself did not change.

    This is why this extension leaves it to the server whether to return
    a GET-Location at all, and if so, whether to return cache validators
    along with it.

----

Feedback appreciated,

Julian

X-From_: [email-masked]  Mon Jul 16 21:15:07 2007
Date: Mon, 16 Jul 2007 23:13:50 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 21:14:07 +0000
Cc: Stefan Eissing <[email-masked]>, WebDAV <[email-masked]>, [email-masked]

Cyrus Daboo wrote:
> Whilst that tells you if you have a conflict, you still end up having to 
> take a guess at another resource name to use to actually save the new 
> data. Hopefully, the second guess will work.
> 
> The one benefit I have heard to the POST/ADDMEMBER approach is if the 
> server has limitations on resource names. Typically those are servers 
> that proxy their data to/from another, more rigid, system.

Yep. And that's why I think ADDMEMBER would be useful. POST just is too 
generic.

Best regards, Julian

X-From_: [email-masked]  Mon Jul 16 21:05:45 2007
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
To: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 14:02:46 -0700
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 21:03:52 +0000
Cc: WebDAV <[email-masked]>, [email-masked]

   Sure, but if you fail, you get to try again.  Better to have a way  
for the server to choose a name and tell you.  Granted, the odds are  
pretty low if you use GUIDs or something, but you still have to  
implement the logic to try again, just in case.

	-wsv

On Jul 16, 2007, at 12:23 PM, Julian Reschke wrote:

> Wilfredo Sánchez Vega wrote:
>>  This would have been useful in CalDAV; rather than having the  
>> client hope that the name it chooses isn't already in use.
>>    -wsv
>
> PUT ...
> If-None-Match: "*"
>
> ?

—
Wilfredo Sánchez - [email-masked]

X-From_: [email-masked]  Mon Jul 16 21:05:57 2007
Date: Mon, 16 Jul 2007 17:04:34 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, =?UTF-8?Q?Wilfredo_S=C3=A1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 21:05:06 +0000
Cc: Stefan Eissing <[email-masked]>, WebDAV <[email-masked]>, [email-masked]

Hi Julian,

--On July 16, 2007 9:23:46 PM +0200 Julian Reschke <[email-masked]> 
wrote:

>>   This would have been useful in CalDAV; rather than having the client
>> hope that the name it chooses isn't already in use.
>>
>>     -wsv
>
> PUT ...
> If-None-Match: "*"

Whilst that tells you if you have a conflict, you still end up having to 
take a guess at another resource name to use to actually save the new data. 
Hopefully, the second guess will work.

The one benefit I have heard to the POST/ADDMEMBER approach is if the 
server has limitations on resource names. Typically those are servers that 
proxy their data to/from another, more rigid, system.

-- 
Cyrus Daboo

Date: Mon, 16 Jul 2007 23:13:50 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: Stefan Eissing <[email-masked]>, WebDAV <[email-masked]>, [email-masked]

Cyrus Daboo wrote:
> Whilst that tells you if you have a conflict, you still end up having to 
> take a guess at another resource name to use to actually save the new 
> data. Hopefully, the second guess will work.
> 
> The one benefit I have heard to the POST/ADDMEMBER approach is if the 
> server has limitations on resource names. Typically those are servers 
> that proxy their data to/from another, more rigid, system.

Yep. And that's why I think ADDMEMBER would be useful. POST just is too 
generic.

Best regards, Julian

Date: Mon, 16 Jul 2007 17:04:34 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, =?UTF-8?Q?Wilfredo_S=C3=A1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: Stefan Eissing <[email-masked]>, WebDAV <[email-masked]>, [email-masked]

Hi Julian,

--On July 16, 2007 9:23:46 PM +0200 Julian Reschke <[email-masked]> 
wrote:

>>   This would have been useful in CalDAV; rather than having the client
>> hope that the name it chooses isn't already in use.
>>
>>     -wsv
>
> PUT ...
> If-None-Match: "*"

Whilst that tells you if you have a conflict, you still end up having to 
take a guess at another resource name to use to actually save the new data. 
Hopefully, the second guess will work.

The one benefit I have heard to the POST/ADDMEMBER approach is if the 
server has limitations on resource names. Typically those are servers that 
proxy their data to/from another, more rigid, system.

-- 
Cyrus Daboo

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
To: Julian Reschke <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Date: Mon, 16 Jul 2007 14:02:46 -0700
Cc: WebDAV <[email-masked]>, [email-masked]

   Sure, but if you fail, you get to try again.  Better to have a way =20=

for the server to choose a name and tell you.  Granted, the odds are =20
pretty low if you use GUIDs or something, but you still have to =20
implement the logic to try again, just in case.

	-wsv

On Jul 16, 2007, at 12:23 PM, Julian Reschke wrote:

> Wilfredo S=E1nchez Vega wrote:
>>  This would have been useful in CalDAV; rather than having the =20
>> client hope that the name it chooses isn't already in use.
>>    -wsv
>
> PUT ...
> If-None-Match: "*"
>
> ?

=97
Wilfredo S=E1nchez - [email-masked]

X-From_: [email-masked]  Mon Jul 16 19:24:43 2007
Date: Mon, 16 Jul 2007 21:23:46 +0200
From: Julian Reschke <[email-masked]>
To: =?windows-1252?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 19:24:06 +0000
Cc: Stefan Eissing <[email-masked]>, WebDAV <[email-masked]>, [email-masked]

Wilfredo Sánchez Vega wrote:
> 
>   This would have been useful in CalDAV; rather than having the client 
> hope that the name it chooses isn't already in use.
> 
>     -wsv

PUT ...
If-None-Match: "*"

?

Date: Mon, 16 Jul 2007 21:23:46 +0200
From: Julian Reschke <[email-masked]>
To: =?windows-1252?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: Stefan Eissing <[email-masked]>, WebDAV <[email-masked]>, [email-masked]

Wilfredo Sánchez Vega wrote:
> 
>   This would have been useful in CalDAV; rather than having the client 
> hope that the name it chooses isn't already in use.
> 
>     -wsv

PUT ...
If-None-Match: "*"

?

X-From_: [email-masked]  Mon Jul 16 18:54:33 2007
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
To: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 11:52:32 -0700
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 18:53:13 +0000
Cc: Stefan Eissing <[email-masked]>, WebDAV <[email-masked]>, [email-masked]

   This would have been useful in CalDAV; rather than having the  
client hope that the name it chooses isn't already in use.

	-wsv

On Jul 16, 2007, at 9:00 AM, Julian Reschke wrote:

> PS: I'm still not convinced that ADDMEMBER (with precise semantics  
> as opposed to POST) isn't needed in HTTP -- see <http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html 
> >.

—
Wilfredo Sánchez - [email-masked]

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
To: Julian Reschke <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Date: Mon, 16 Jul 2007 11:52:32 -0700
Cc: Stefan Eissing <[email-masked]>, WebDAV <[email-masked]>, [email-masked]

   This would have been useful in CalDAV; rather than having the =20
client hope that the name it chooses isn't already in use.

	-wsv

On Jul 16, 2007, at 9:00 AM, Julian Reschke wrote:

> PS: I'm still not convinced that ADDMEMBER (with precise semantics =20
> as opposed to POST) isn't needed in HTTP -- see =
<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html=20=

> >.

=97
Wilfredo S=E1nchez - [email-masked]

X-From_: [email-masked]  Mon Jul 16 17:52:04 2007
Date: Mon, 16 Jul 2007 13:50:23 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Julian Reschke <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 17:50:53 +0000
Cc: "Mr. Demeanour" <[email-masked]>, [email-masked], [email-masked]

Hi Lisa,

--On July 16, 2007 10:27:30 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

>> Now wouldn't it be nice if a client could check for changed
>> resources *and* get their content in a single request? That seems
>> to be something obvious missing from the multiget report.
>
> I've worked on some synch stuff and it would be even nicer to make
> replication general, not specific to CalDAV.  So I agree, and I'm happy
> Cyrus is doing some work on that.

Yes its true that its nice to be able to do all that, and the 
synchronization report extension was designed to allow that with the 
extension of using the "pseudo" properties for at least CalDAV and CardDAV.

Note however, that clients may not always want to get the data. In fact 
that could be a bad thing to do if there have been lots of changes. Since 
the client has no control over the amount of information the server would 
return, and since resource bodies may be much larger than the set of 
properties otherwise asked for, this could be a big problem on limited 
capacity devices or over slow links.

What I would expect is that a client would use the sync. report to find the 
list of changed resources and then do a series of multigets to "page" 
through the changes and update its cache making sure that each response is 
likely to be within any resource constraints it might have. So I think 
there is a need for both the sync. and multiget reports as separate 
features. Of course we could combine all these into one, but then we might 
end up with one big monster...

-- 
Cyrus Daboo

Date: Mon, 16 Jul 2007 13:50:23 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Julian Reschke <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: "Mr. Demeanour" <[email-masked]>, [email-masked], [email-masked]

Hi Lisa,

--On July 16, 2007 10:27:30 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

>> Now wouldn't it be nice if a client could check for changed
>> resources *and* get their content in a single request? That seems
>> to be something obvious missing from the multiget report.
>
> I've worked on some synch stuff and it would be even nicer to make
> replication general, not specific to CalDAV.  So I agree, and I'm happy
> Cyrus is doing some work on that.

Yes its true that its nice to be able to do all that, and the 
synchronization report extension was designed to allow that with the 
extension of using the "pseudo" properties for at least CalDAV and CardDAV.

Note however, that clients may not always want to get the data. In fact 
that could be a bad thing to do if there have been lots of changes. Since 
the client has no control over the amount of information the server would 
return, and since resource bodies may be much larger than the set of 
properties otherwise asked for, this could be a big problem on limited 
capacity devices or over slow links.

What I would expect is that a client would use the sync. report to find the 
list of changed resources and then do a series of multigets to "page" 
through the changes and update its cache making sure that each response is 
likely to be within any resource constraints it might have. So I think 
there is a need for both the sync. and multiget reports as separate 
features. Of course we could combine all these into one, but then we might 
end up with one big monster...

-- 
Cyrus Daboo

X-From_: [email-masked]  Mon Jul 16 16:46:18 2007
Date: Mon, 16 Jul 2007 18:44:56 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 16:45:20 +0000
Cc: "Mr. Demeanour" <[email-masked]>, [email-masked], [email-masked]

Lisa Dusseault wrote:
> 
> Synchronization for bodies is also better-defined than synchronization 
> for properties.  With the choice of CalDAV bodies plus multiget:
>  - clients can view just the ETags for a collection to see what bodies 
> have changed
>  - clients can ask for the bodies of the changed/new resources
>  - clients don't have to worry about synchronizing property values -- 
> property values are outside the calendaring domain, and the server's 
> business

Now wouldn't it be nice if a client could check for changed resources 
*and* get their content in a single request? That seems to be something 
obvious missing from the multiget report.

> Why not put the content or data in the body of the resource?   For 
> calendaring, that's the entire iCalendar object, even though some of the 
> iCalendar insides are structured that doesn't mean they're metadata -- 
> they *are* the data.  Non-Calendar stuff like ETag is true metadata.   
> It's a confusion in terminology (that WebDAV uses "property" for 
> metadata while iCalendar uses "property" for structured data) that 
> continually tempts us to use WebDAV metadata storage, instead of data 
> storage,  for iCalendar data.

I totally agree that the specs should treat calendar/address book 
objects as proper HTTP resources. What I was mainly complaining about 
was that the content (or parts of the content) are treated as 
"pseudo-properties" for some reports, instead of making them proper 
(computed) properties (or to change the marshalling in the report so 
that no pseudo-properties are introduced).

Everytime a spec defines a new name for a pseudo property (to be used 
where otherwise property names are allowed), that name becomes unusable 
for a true property anyway, so there's really no point at all not to 
expose that information in PROPFIND as well. Fewer special cases, please.

> We still don't have the ability to synchronize property values in 
> WebDAV.  We could start designing that, but there's not a strong call 
> to, unless we start getting confused and put data into the metadata.

That's a separate issue that should be solved. As a matter of fact, I 
think I've got a good idea to address this and other related things, but 
I didn't have time so far to write it down (famous last words, I know).

Best regards, Julian

X-From_: [email-masked]  Mon Jul 16 16:40:59 2007
Date: Mon, 16 Jul 2007 18:32:45 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 16:39:39 +0000
Cc: "Mr. Demeanour" <[email-masked]>, [email-masked], [email-masked]

Cyrus Daboo wrote:
> The problem is mapping vCard "properties" on to WebDAV "properties". We 
> had the same problem in iCalendar which is why CalDAV does not do that. 
> One issue is how to represent multiple instances of the same property - 
> in vCard/iCalendar certainly properties can appear more than once, yet 
> WebDAV only allows one property of an element type per resource. Yes you 
> could do things with list elements but it starts to get messy - so we 
> avoided it. It would also mean inventing an XML representation of the 
> data - we certainly did not want to go down that route with CalDAV at 
> the time.

But aren't you already doing that with the calendar-data pseudo 
property? It just has a bigger granularity (the whole entry, rather than 
a subset).

Best regards, Julian

Date: Mon, 16 Jul 2007 18:44:56 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: "Mr. Demeanour" <[email-masked]>, [email-masked], [email-masked]

Lisa Dusseault wrote:
> 
> Synchronization for bodies is also better-defined than synchronization 
> for properties.  With the choice of CalDAV bodies plus multiget:
>  - clients can view just the ETags for a collection to see what bodies 
> have changed
>  - clients can ask for the bodies of the changed/new resources
>  - clients don't have to worry about synchronizing property values -- 
> property values are outside the calendaring domain, and the server's 
> business

Now wouldn't it be nice if a client could check for changed resources 
*and* get their content in a single request? That seems to be something 
obvious missing from the multiget report.

> Why not put the content or data in the body of the resource?   For 
> calendaring, that's the entire iCalendar object, even though some of the 
> iCalendar insides are structured that doesn't mean they're metadata -- 
> they *are* the data.  Non-Calendar stuff like ETag is true metadata.   
> It's a confusion in terminology (that WebDAV uses "property" for 
> metadata while iCalendar uses "property" for structured data) that 
> continually tempts us to use WebDAV metadata storage, instead of data 
> storage,  for iCalendar data.

I totally agree that the specs should treat calendar/address book 
objects as proper HTTP resources. What I was mainly complaining about 
was that the content (or parts of the content) are treated as 
"pseudo-properties" for some reports, instead of making them proper 
(computed) properties (or to change the marshalling in the report so 
that no pseudo-properties are introduced).

Everytime a spec defines a new name for a pseudo property (to be used 
where otherwise property names are allowed), that name becomes unusable 
for a true property anyway, so there's really no point at all not to 
expose that information in PROPFIND as well. Fewer special cases, please.

> We still don't have the ability to synchronize property values in 
> WebDAV.  We could start designing that, but there's not a strong call 
> to, unless we start getting confused and put data into the metadata.

That's a separate issue that should be solved. As a matter of fact, I 
think I've got a good idea to address this and other related things, but 
I didn't have time so far to write it down (famous last words, I know).

Best regards, Julian

Date: Mon, 16 Jul 2007 18:32:45 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: "Mr. Demeanour" <[email-masked]>, [email-masked], [email-masked]

Cyrus Daboo wrote:
> The problem is mapping vCard "properties" on to WebDAV "properties". We 
> had the same problem in iCalendar which is why CalDAV does not do that. 
> One issue is how to represent multiple instances of the same property - 
> in vCard/iCalendar certainly properties can appear more than once, yet 
> WebDAV only allows one property of an element type per resource. Yes you 
> could do things with list elements but it starts to get messy - so we 
> avoided it. It would also mean inventing an XML representation of the 
> data - we certainly did not want to go down that route with CalDAV at 
> the time.

But aren't you already doing that with the calendar-data pseudo 
property? It just has a bigger granularity (the whole entry, rather than 
a subset).

Best regards, Julian

X-From_: [email-masked]  Mon Jul 16 16:24:17 2007
Date: Mon, 16 Jul 2007 12:22:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, "Mr. Demeanour" <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 16:23:22 +0000
Cc: [email-masked], [email-masked]

Hi Julian,

--On July 16, 2007 5:47:37 PM +0200 Julian Reschke <[email-masked]> 
wrote:

>> my own project is to implement a CalDAV server that has no DBMS
>> dependency - it's a servlet that uses exclusively the filesystem for
>> storing data. I have repeatedly run into details in the specs that would
>> have been *much* easier to implement had a database been my underlying
>> store; typically these details relate to the blurred distinction between
>> data and properties.
>> ...
>
> So let's assume that the parts of a vCard resource would be exposed as
> (potentially computed) WebDAV properties -- wouldn't the need for the
> multiget report just go away? PROPFIND would be all that's needed, then...

The problem is mapping vCard "properties" on to WebDAV "properties". We had 
the same problem in iCalendar which is why CalDAV does not do that. One 
issue is how to represent multiple instances of the same property - in 
vCard/iCalendar certainly properties can appear more than once, yet WebDAV 
only allows one property of an element type per resource. Yes you could do 
things with list elements but it starts to get messy - so we avoided it. It 
would also mean inventing an XML representation of the data - we certainly 
did not want to go down that route with CalDAV at the time.

-- 
Cyrus Daboo

X-From_: [email-masked]  Mon Jul 16 16:29:07 2007
Date: Mon, 16 Jul 2007 18:27:51 +0200
From: Julian Reschke <[email-masked]>
To: "Mr. Demeanour" <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 16:28:12 +0000
Cc: [email-masked], [email-masked]

Mr. Demeanour wrote:
> Yes, that's correct, as far as I can see.
> 
> If one did that, however, the consequence would be that the GET method
> would then become anomalous for CalDAV and CardDAV resources; the data
> that it returned would be properties masquerading as content. Similarly
> the PUT method would become obsolete, as any CalDAV or CardDAV content
> should then be set using PROPPATCH. Anyway, it seems most natural to map
> iCalendar/vCard properties to WebDAV properties, rather than to WebDAV
> content.

I think GET and PUT should just continue to do what they do today.

> I don't really see that as a terrible problem for CalDAV and CardDAV;
> GET and PUT on CalDAV/CardDAV resources could be left undefined, or
> those methods could be freed-up for other purposes. GET, in particular,
> might be used to present a rendition of the resource. The fact that GET
> is easy to cache, and PROPFIND and REPORT are not, would be quite
> consistent with that approach - returning a stale, cached version of a
> rendition would be a much less serious problem than returning stale
> (but live) property data.

You mean, like an HTML view? That can always be done using content 
negotiation, I'd say.

> This all feels a bit theoretical, though; to make all CalDAV/CardDAV
> content become instead grade-A properties would be a pretty fundamental
> change in approach, affecting five or six different RFCs, and I hesitate
> to suggest anything that radical (without working it through properly
> first!).

Sorry? It would only affect a single RFC (RFC4791), no?

Best regards, Julian

Date: Mon, 16 Jul 2007 18:27:51 +0200
From: Julian Reschke <[email-masked]>
To: "Mr. Demeanour" <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: [email-masked], [email-masked]

Mr. Demeanour wrote:
> Yes, that's correct, as far as I can see.
> 
> If one did that, however, the consequence would be that the GET method
> would then become anomalous for CalDAV and CardDAV resources; the data
> that it returned would be properties masquerading as content. Similarly
> the PUT method would become obsolete, as any CalDAV or CardDAV content
> should then be set using PROPPATCH. Anyway, it seems most natural to map
> iCalendar/vCard properties to WebDAV properties, rather than to WebDAV
> content.

I think GET and PUT should just continue to do what they do today.

> I don't really see that as a terrible problem for CalDAV and CardDAV;
> GET and PUT on CalDAV/CardDAV resources could be left undefined, or
> those methods could be freed-up for other purposes. GET, in particular,
> might be used to present a rendition of the resource. The fact that GET
> is easy to cache, and PROPFIND and REPORT are not, would be quite
> consistent with that approach - returning a stale, cached version of a
> rendition would be a much less serious problem than returning stale
> (but live) property data.

You mean, like an HTML view? That can always be done using content 
negotiation, I'd say.

> This all feels a bit theoretical, though; to make all CalDAV/CardDAV
> content become instead grade-A properties would be a pretty fundamental
> change in approach, affecting five or six different RFCs, and I hesitate
> to suggest anything that radical (without working it through properly
> first!).

Sorry? It would only affect a single RFC (RFC4791), no?

Best regards, Julian

Date: Mon, 16 Jul 2007 12:22:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, "Mr. Demeanour" <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: [email-masked], [email-masked]

Hi Julian,

--On July 16, 2007 5:47:37 PM +0200 Julian Reschke <[email-masked]> 
wrote:

>> my own project is to implement a CalDAV server that has no DBMS
>> dependency - it's a servlet that uses exclusively the filesystem for
>> storing data. I have repeatedly run into details in the specs that would
>> have been *much* easier to implement had a database been my underlying
>> store; typically these details relate to the blurred distinction between
>> data and properties.
>> ...
>
> So let's assume that the parts of a vCard resource would be exposed as
> (potentially computed) WebDAV properties -- wouldn't the need for the
> multiget report just go away? PROPFIND would be all that's needed, then...

The problem is mapping vCard "properties" on to WebDAV "properties". We had 
the same problem in iCalendar which is why CalDAV does not do that. One 
issue is how to represent multiple instances of the same property - in 
vCard/iCalendar certainly properties can appear more than once, yet WebDAV 
only allows one property of an element type per resource. Yes you could do 
things with list elements but it starts to get messy - so we avoided it. It 
would also mean inventing an XML representation of the data - we certainly 
did not want to go down that route with CalDAV at the time.

-- 
Cyrus Daboo

X-From_: [email-masked]  Mon Jul 16 16:04:15 2007
Date: Mon, 16 Jul 2007 12:02:56 -0400
From: Cyrus Daboo <[email-masked]>
To: "Mr. Demeanour" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 16:03:18 +0000

Hi Mr.,

--On July 16, 2007 4:41:22 PM +0100 "Mr. Demeanour" 
<[email-masked]> wrote:

>> Hi Mr.,
>
> Perhaps I should have signed up using a less silly email address! My
> name is Jack Cleaver. I shall alter my list registration details "soon".

Sorry, my email client has an option to auto-generate the "Hi xxx" line by 
trying to extract the first name from the From email address. Doesn't 
always work well...

>> Returning partial data is important for "low capacity" devices such
>> as mobile devices, who arguably benefit the most from multiget as
>> well.
>
> OK, I appreciate that. IME the amount of data in a single CalDAV
> resource is generally under about 3K, unless there is an essay in the
> <description> field. But I take the point.

iCalendar data for large recurrence sets with lots of overridden instances 
can grow large. Also, attachments can be included inline with iCalendar 
data so those can get (very) big.

In terms of vCard, PHOTO or SOUND properties are defined, so those can add 
a lot of data.

>> Note that parsing the data is an implementation issue, e.g. servers
>> that store the data in a database can simply implement the the
>> "partial data" aspect by doing a query for only the requested
>> parameters etc.
>
> OK; I'm aware that the majority of CalDAV servers (perhaps the majority
> of DAV servers) rely on a database, and that as a consequence, data and
> properties are all implemented as columns in a RDB, and are therefore
> logically more-or-less equivalent. But that shouldn't colour the
> approach taken by spec-writers; otherwise we will end up with specs that
> place pressure on implementors to use a RDBMS. In the extreme, we'll end
> up with specs that implicitly mandate a RDBMS.

I agree...see below.

> Declaration of interest:
> my own project is to implement a CalDAV server that has no DBMS
> dependency - it's a servlet that uses exclusively the filesystem for
> storing data. I have repeatedly run into details in the specs that would
> have been *much* easier to implement had a database been my underlying
> store; typically these details relate to the blurred distinction between
> data and properties.

Actually I have worked on several CalDAV servers to date (something like 
three) and all had slightly different approaches to storing/indexing data. 
In one case it was a pure filesystem store and all queries, partial fetches 
had to go through an iCalendar parser etc - certainly did not perform great 
but was OK for low volume personal use. Another used a pure database 
backend, that was better but still had issues. Another uses the filesystem, 
but augments that with index files for handling queries.

So I think CalDAV and CardDAV do provide the flexibility that is needed - 
but performance will be affected by choice of backend - obviously.

-- 
Cyrus Daboo

X-From_: [email-masked]  Mon Jul 16 16:01:39 2007
Date: Mon, 16 Jul 2007 18:00:12 +0200
From: Julian Reschke <[email-masked]>
To: Stefan Eissing <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 16:00:29 +0000
Cc: WebDAV <[email-masked]>, [email-masked]

Stefan Eissing wrote:
> 
> Am 16.07.2007 um 16:57 schrieb Julian Reschke:
>>> However, I do agree that this is not an ideal state of affairs. If 
>>> there is consensus in the WebDAV community to do so, I agree that we 
>>> should write up a formal extension to MKCOL that would cover all the 
>>> other MKxxx's behaviors. However, I do not believe that belongs in 
>>> CardDAV, it should be a separate extension that CardDAV can itself 
>>> leverage. I would be happy to put a spec together on that (extracting 
>>> the behaviors from the existing specs).
>>
>> I think that would be great. I think all we need is a request body 
>> (XML + mime type) that will allow to specify a set of WebDAV 
>> properties, including the resource type.
> 
> Maybe send a POST + request body to the parent collection?
> 
> POST seems to have been avoided by WebDAV to not interfere with webapps 
> using the same URIs. But those days are over.

That could work as well, but I don't see why we shouldn't use MKCOL when 
we're actually creating a collection.

Best regards, Julian

PS: I'm still not convinced that ADDMEMBER (with precise semantics as 
opposed to POST) isn't needed in HTTP -- see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html>.

Date: Mon, 16 Jul 2007 12:02:56 -0400
From: Cyrus Daboo <[email-masked]>
To: "Mr. Demeanour" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02

Hi Mr.,

--On July 16, 2007 4:41:22 PM +0100 "Mr. Demeanour" 
<[email-masked]> wrote:

>> Hi Mr.,
>
> Perhaps I should have signed up using a less silly email address! My
> name is Jack Cleaver. I shall alter my list registration details "soon".

Sorry, my email client has an option to auto-generate the "Hi xxx" line by 
trying to extract the first name from the From email address. Doesn't 
always work well...

>> Returning partial data is important for "low capacity" devices such
>> as mobile devices, who arguably benefit the most from multiget as
>> well.
>
> OK, I appreciate that. IME the amount of data in a single CalDAV
> resource is generally under about 3K, unless there is an essay in the
> <description> field. But I take the point.

iCalendar data for large recurrence sets with lots of overridden instances 
can grow large. Also, attachments can be included inline with iCalendar 
data so those can get (very) big.

In terms of vCard, PHOTO or SOUND properties are defined, so those can add 
a lot of data.

>> Note that parsing the data is an implementation issue, e.g. servers
>> that store the data in a database can simply implement the the
>> "partial data" aspect by doing a query for only the requested
>> parameters etc.
>
> OK; I'm aware that the majority of CalDAV servers (perhaps the majority
> of DAV servers) rely on a database, and that as a consequence, data and
> properties are all implemented as columns in a RDB, and are therefore
> logically more-or-less equivalent. But that shouldn't colour the
> approach taken by spec-writers; otherwise we will end up with specs that
> place pressure on implementors to use a RDBMS. In the extreme, we'll end
> up with specs that implicitly mandate a RDBMS.

I agree...see below.

> Declaration of interest:
> my own project is to implement a CalDAV server that has no DBMS
> dependency - it's a servlet that uses exclusively the filesystem for
> storing data. I have repeatedly run into details in the specs that would
> have been *much* easier to implement had a database been my underlying
> store; typically these details relate to the blurred distinction between
> data and properties.

Actually I have worked on several CalDAV servers to date (something like 
three) and all had slightly different approaches to storing/indexing data. 
In one case it was a pure filesystem store and all queries, partial fetches 
had to go through an iCalendar parser etc - certainly did not perform great 
but was OK for low volume personal use. Another used a pure database 
backend, that was better but still had issues. Another uses the filesystem, 
but augments that with index files for handling queries.

So I think CalDAV and CardDAV do provide the flexibility that is needed - 
but performance will be affected by choice of backend - obviously.

-- 
Cyrus Daboo

X-From_: [email-masked]  Mon Jul 16 15:48:57 2007
Date: Mon, 16 Jul 2007 17:47:37 +0200
From: Julian Reschke <[email-masked]>
To: "Mr. Demeanour" <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 15:47:59 +0000
Cc: [email-masked], [email-masked]

Mr. Demeanour wrote:
> ...
> my own project is to implement a CalDAV server that has no DBMS
> dependency - it's a servlet that uses exclusively the filesystem for
> storing data. I have repeatedly run into details in the specs that would
> have been *much* easier to implement had a database been my underlying
> store; typically these details relate to the blurred distinction between
> data and properties.
> ...

So let's assume that the parts of a vCard resource would be exposed as 
(potentially computed) WebDAV properties -- wouldn't the need for the 
multiget report just go away? PROPFIND would be all that's needed, then...

Best regards, Julian

Date: Mon, 16 Jul 2007 18:00:12 +0200
From: Julian Reschke <[email-masked]>
To: Stefan Eissing <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: WebDAV <[email-masked]>, [email-masked]

Stefan Eissing wrote:
> 
> Am 16.07.2007 um 16:57 schrieb Julian Reschke:
>>> However, I do agree that this is not an ideal state of affairs. If 
>>> there is consensus in the WebDAV community to do so, I agree that we 
>>> should write up a formal extension to MKCOL that would cover all the 
>>> other MKxxx's behaviors. However, I do not believe that belongs in 
>>> CardDAV, it should be a separate extension that CardDAV can itself 
>>> leverage. I would be happy to put a spec together on that (extracting 
>>> the behaviors from the existing specs).
>>
>> I think that would be great. I think all we need is a request body 
>> (XML + mime type) that will allow to specify a set of WebDAV 
>> properties, including the resource type.
> 
> Maybe send a POST + request body to the parent collection?
> 
> POST seems to have been avoided by WebDAV to not interfere with webapps 
> using the same URIs. But those days are over.

That could work as well, but I don't see why we shouldn't use MKCOL when 
we're actually creating a collection.

Best regards, Julian

PS: I'm still not convinced that ADDMEMBER (with precise semantics as 
opposed to POST) isn't needed in HTTP -- see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html>.

Date: Mon, 16 Jul 2007 17:47:37 +0200
From: Julian Reschke <[email-masked]>
To: "Mr. Demeanour" <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: [email-masked], [email-masked]

Mr. Demeanour wrote:
> ...
> my own project is to implement a CalDAV server that has no DBMS
> dependency - it's a servlet that uses exclusively the filesystem for
> storing data. I have repeatedly run into details in the specs that would
> have been *much* easier to implement had a database been my underlying
> store; typically these details relate to the blurred distinction between
> data and properties.
> ...

So let's assume that the parts of a vCard resource would be exposed as 
(potentially computed) WebDAV properties -- wouldn't the need for the 
multiget report just go away? PROPFIND would be all that's needed, then...

Best regards, Julian

X-From_: [email-masked]  Mon Jul 16 15:20:51 2007
Date: Mon, 16 Jul 2007 11:19:17 -0400
From: Cyrus Daboo <[email-masked]>
To: "Mr. Demeanour" <[email-masked]>, [email-masked]
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 15:19:43 +0000
Cc: [email-masked]

Hi Mr.,

--On July 16, 2007 4:06:30 PM +0100 "Mr. Demeanour" 
<[email-masked]> wrote:

>> What do others thinks about this?
>
> Strongly in favour - and I agree with you that it should be separate
> from the CardDAV spec.
>
> But that doesn't force you to adopt the MKADDRESSBOOK route in the
> meantime, does it?

That is true. One option would be to keep MKADDRESSBOOK in, but if the 
MKCOL extension  spec beats CardDAV to the IESG we could remove it.

>>
>> 2) multiget allows both the data and properties to be returned in one
>>  go: i.e. it is the equivalent of a GET and a PROPFIND.
>
> Not really; the CalDAV multiget requires the server to parse the
> resource body, because the client can ask for selected iCalendar
> properties. ASs it happens, I think that was a rotten idea, and multiget
> would be better-off without that feature.

Returning partial data is important for "low capacity" devices such as 
mobile devices, who arguably benefit the most from multiget as well. Note 
that parsing the data is an implementation issue, e.g. servers that store 
the data in a database can simply implement the the "partial data" aspect 
by doing a query for only the requested parameters etc.

-- 
Cyrus Daboo

Date: Mon, 16 Jul 2007 11:19:17 -0400
From: Cyrus Daboo <[email-masked]>
To: "Mr. Demeanour" <[email-masked]>, [email-masked]
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: [email-masked]

Hi Mr.,

--On July 16, 2007 4:06:30 PM +0100 "Mr. Demeanour" 
<[email-masked]> wrote:

>> What do others thinks about this?
>
> Strongly in favour - and I agree with you that it should be separate
> from the CardDAV spec.
>
> But that doesn't force you to adopt the MKADDRESSBOOK route in the
> meantime, does it?

That is true. One option would be to keep MKADDRESSBOOK in, but if the 
MKCOL extension  spec beats CardDAV to the IESG we could remove it.

>>
>> 2) multiget allows both the data and properties to be returned in one
>>  go: i.e. it is the equivalent of a GET and a PROPFIND.
>
> Not really; the CalDAV multiget requires the server to parse the
> resource body, because the client can ask for selected iCalendar
> properties. ASs it happens, I think that was a rotten idea, and multiget
> would be better-off without that feature.

Returning partial data is important for "low capacity" devices such as 
mobile devices, who arguably benefit the most from multiget as well. Note 
that parsing the data is an implementation issue, e.g. servers that store 
the data in a database can simply implement the the "partial data" aspect 
by doing a query for only the requested parameters etc.

-- 
Cyrus Daboo

X-From_: [email-masked]  Mon Jul 16 14:58:40 2007
Date: Mon, 16 Jul 2007 16:57:09 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Mon, 16 Jul 2007 14:57:31 +0000
Cc: WebDAV <[email-masked]>, [email-masked]

Cyrus Daboo wrote:
> Hi Julian,
> Thanks for your detailed review.

And thanks for the feedback!

> Note that it was actually RFC3253 that let the cat out of the bag (so to 
> speak) wrt new methods for creating collections (MKWORKSPACE and 
> MKACTIVITY). In CalDAV We chose to be consistent with that approach by 
> having MKCALENDAR, and hence CardDAV has MKADDRESSBOOK.

Understood. I think there's a small difference in that RFC3253 defined a 
generic framework for versioning -- which may be applicable to many use 
cases -- where Ca*DAV use it for a very specific business case. I'll 
admit that the border between "generic" and these ones is fuzzy, though.

> However, I do agree that this is not an ideal state of affairs. If there 
> is consensus in the WebDAV community to do so, I agree that we should 
> write up a formal extension to MKCOL that would cover all the other 
> MKxxx's behaviors. However, I do not believe that belongs in CardDAV, it 
> should be a separate extension that CardDAV can itself leverage. I would 
> be happy to put a spec together on that (extracting the behaviors from 
> the existing specs).

I think that would be great. I think all we need is a request body (XML 
+ mime type) that will allow to specify a set of WebDAV properties, 
including the resource type.

 > ...
>> Use of Reports
>>
>> Everytime a new REPORT is introduced, a new set of information is made
>> hard to cache. In some cases that may be harmless (such as when it's
>> something like a query, line in some RFC3744 reports).
>>
>> However, defining a "multiget" really seems to be a bad idea, and now
>> there are even two of those! Please take this out until it can be shown
>> that just sending a bunch of GET requests (which can take advantage of
>> caching) is not sufficient.
> 
> CalDAV has proved (to me at least) that multiget is a big win for both 
> server and  client. Perhaps other implementers can also comment.
> 
> Its a win for several reasons including:
> 
> 1) Cutting down on roundtrips. We did have discussion about why 
> pipelining is not reliable in the PATCH extension thread on the HTTP 
> list, though in this case we are only dealing with GETs.

Yes, so I don't think that these concerns apply.

> 2) multiget allows both the data and properties to be returned in one 
> go: i.e. it is the equivalent of a GET and a PROPFIND.

Understood, but this is related to the issue below: if the contents of 
the calendar/address resource would be exposed as *true* WebDAV 
property, a single PROPFIND would be sufficient.

> ...
>> Property model
>>
>> The specs avoid exposing the content of their data objects as WebDAV
>> properties. This leads to lots of workarounds, such as introducing
>> "pseudo-properties" containing the actual content
>> (CARDDAV:addressbook-data), and abuse of DAV:prop for something that is
>> not a WebDAV property. Don't do this, it requires generic WebDAV servers
>> to use lots of special cases. (WebDAV SEARCH started with pseudo
>> properties but got successfully rid of them, so this can be done).
> 
> Well CardDAV and CalDAV are special cases of a generic WebDAV server. So 
> I don't see this as being a big issue. There are reasons for doing 
> things the way they are and I will address those in more detail in a 
> follow up to your more detailed review posted to the CardDAV list.
 > ...

Looking forward to that. As this is a general WebDAV design question, 
maybe we should keep it over on this list...

Best regards, Julian

Date: Mon, 16 Jul 2007 16:57:09 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
Cc: WebDAV <[email-masked]>, [email-masked]

Cyrus Daboo wrote:
> Hi Julian,
> Thanks for your detailed review.

And thanks for the feedback!

> Note that it was actually RFC3253 that let the cat out of the bag (so to 
> speak) wrt new methods for creating collections (MKWORKSPACE and 
> MKACTIVITY). In CalDAV We chose to be consistent with that approach by 
> having MKCALENDAR, and hence CardDAV has MKADDRESSBOOK.

Understood. I think there's a small difference in that RFC3253 defined a 
generic framework for versioning -- which may be applicable to many use 
cases -- where Ca*DAV use it for a very specific business case. I'll 
admit that the border between "generic" and these ones is fuzzy, though.

> However, I do agree that this is not an ideal state of affairs. If there 
> is consensus in the WebDAV community to do so, I agree that we should 
> write up a formal extension to MKCOL that would cover all the other 
> MKxxx's behaviors. However, I do not believe that belongs in CardDAV, it 
> should be a separate extension that CardDAV can itself leverage. I would 
> be happy to put a spec together on that (extracting the behaviors from 
> the existing specs).

I think that would be great. I think all we need is a request body (XML 
+ mime type) that will allow to specify a set of WebDAV properties, 
including the resource type.

 > ...
>> Use of Reports
>>
>> Everytime a new REPORT is introduced, a new set of information is made
>> hard to cache. In some cases that may be harmless (such as when it's
>> something like a query, line in some RFC3744 reports).
>>
>> However, defining a "multiget" really seems to be a bad idea, and now
>> there are even two of those! Please take this out until it can be shown
>> that just sending a bunch of GET requests (which can take advantage of
>> caching) is not sufficient.
> 
> CalDAV has proved (to me at least) that multiget is a big win for both 
> server and  client. Perhaps other implementers can also comment.
> 
> Its a win for several reasons including:
> 
> 1) Cutting down on roundtrips. We did have discussion about why 
> pipelining is not reliable in the PATCH extension thread on the HTTP 
> list, though in this case we are only dealing with GETs.

Yes, so I don't think that these concerns apply.

> 2) multiget allows both the data and properties to be returned in one 
> go: i.e. it is the equivalent of a GET and a PROPFIND.

Understood, but this is related to the issue below: if the contents of 
the calendar/address resource would be exposed as *true* WebDAV 
property, a single PROPFIND would be sufficient.

> ...
>> Property model
>>
>> The specs avoid exposing the content of their data objects as WebDAV
>> properties. This leads to lots of workarounds, such as introducing
>> "pseudo-properties" containing the actual content
>> (CARDDAV:addressbook-data), and abuse of DAV:prop for something that is
>> not a WebDAV property. Don't do this, it requires generic WebDAV servers
>> to use lots of special cases. (WebDAV SEARCH started with pseudo
>> properties but got successfully rid of them, so this can be done).
> 
> Well CardDAV and CalDAV are special cases of a generic WebDAV server. So 
> I don't see this as being a big issue. There are reasons for doing 
> things the way they are and I will address those in more detail in a 
> follow up to your more detailed review posted to the CardDAV list.
 > ...

Looking forward to that. As this is a general WebDAV design question, 
maybe we should keep it over on this list...

Best regards, Julian

Date: Mon, 16 Jul 2007 10:35:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, [email-masked], WebDAV <[email-masked]>
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02

Hi Julian,
Thanks for your detailed review.

--On July 15, 2007 12:21:31 PM +0200 Julian Reschke <[email-masked]> 
wrote:

> The introduction of new DAV:resourcetypes however has lead to the
> introduction of new HTTP methods, with the single purpose of creating a
> WebDAV collection with a certain set of properties. I think this is an
> extremely bad idea.
>
> Now I do *not* belong to the group of people with "new method angst".
> Defining new methods that have general applicability is completely ok
> IMHO. Good examples are COPY/MOVE, some of the versioning methods, BIND
> and so on. The difference to MKCALENDAR and MKADDRESSBOOK is that these
> ones are restricted to a single application use case. So what's next?
> MKPHOTOCOLLECTION? MKMUSIKCOLLECTION?
>
> Instead, I'd suggest defining what MKCALENDAR and MKADDRESSBOOK have in
> common, and come up with a single solution to that. For instance, such as
> MKCOL using a request body that carries a set of properties, including
> the WebDAV resource type.

Note that it was actually RFC3253 that let the cat out of the bag (so to 
speak) wrt new methods for creating collections (MKWORKSPACE and 
MKACTIVITY). In CalDAV We chose to be consistent with that approach by 
having MKCALENDAR, and hence CardDAV has MKADDRESSBOOK.

However, I do agree that this is not an ideal state of affairs. If there is 
consensus in the WebDAV community to do so, I agree that we should write up 
a formal extension to MKCOL that would cover all the other MKxxx's 
behaviors. However, I do not believe that belongs in CardDAV, it should be 
a separate extension that CardDAV can itself leverage. I would be happy to 
put a spec together on that (extracting the behaviors from the existing 
specs).

What do others thinks about this?

>
> Use of Reports
>
> Everytime a new REPORT is introduced, a new set of information is made
> hard to cache. In some cases that may be harmless (such as when it's
> something like a query, line in some RFC3744 reports).
>
> However, defining a "multiget" really seems to be a bad idea, and now
> there are even two of those! Please take this out until it can be shown
> that just sending a bunch of GET requests (which can take advantage of
> caching) is not sufficient.

CalDAV has proved (to me at least) that multiget is a big win for both 
server and  client. Perhaps other implementers can also comment.

Its a win for several reasons including:

1) Cutting down on roundtrips. We did have discussion about why pipelining 
is not reliable in the PATCH extension thread on the HTTP list, though in 
this case we are only dealing with GETs.

2) multiget allows both the data and properties to be returned in one go: 
i.e. it is the equivalent of a GET and a PROPFIND.

3) It is much more efficient for a server to process a single request for a 
bunch of resources than to do separate requests. Whilst this ma admittedly 
be implementation specific, I can tell you that being able to cache certain 
things during the multiget is handy (e.g. only having to calculate the 
inherited aces that propagate down to all child resource of the same 
collection once, or being able to do a single DB query for all properties 
in one transaction rather than multiple ones for each resource).

Bottom line is I think multiget is vital to performance and should remain 
in.

That said, perhaps a more generic "multiget" behavior could be done that 
would be applicable to WebDAV as a whole. Really all multiget is is a 
PROPFIND that targets specific resources - with the one addition of the 
"pseudo" resource body property (which is the only thing that differs 
between CalDAV and CardDAV).

> Property model
>
> The specs avoid exposing the content of their data objects as WebDAV
> properties. This leads to lots of workarounds, such as introducing
> "pseudo-properties" containing the actual content
> (CARDDAV:addressbook-data), and abuse of DAV:prop for something that is
> not a WebDAV property. Don't do this, it requires generic WebDAV servers
> to use lots of special cases. (WebDAV SEARCH started with pseudo
> properties but got successfully rid of them, so this can be done).

Well CardDAV and CalDAV are special cases of a generic WebDAV server. So I 
don't see this as being a big issue. There are reasons for doing things the 
way they are and I will address those in more detail in a follow up to your 
more detailed review posted to the CardDAV list.

-- 
Cyrus Daboo

Date: Sun, 15 Jul 2007 15:38:34 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: CARDDAV:addressbook-multiget, Re: [Ietf-carddav] More comments on draft-daboo-carddav-02

Hi,

here are two changes that I would propose for 
CARDDAV:addressbook-multiget 
(<http://tools.ietf.org/html/draft-daboo-carddav-02#section-8.7>):

1) Elevate C:addressbook-data from a pseudo property to a regular 
element of the request/response format,

2) Augment the request with information that allows conditional retrieval.

Example:

Request:

  <?xml version="1.0" encoding="utf-8" ?>
    <C:addressbook-multiget xmlns:D="DAV:"
                         xmlns:C="urn:ietf:params:xml:ns:carddav">
      <C:addressbook-data>
        </C:if-none-match>
        <C:prop name="VERSION"/>
        <C:prop name="UID"/>
        <C:prop name="NICKNAME"/>
        <C:prop name="EMAIL"/>
        <C:prop name="FN"/>
        </C:addressbook-data>
      <D:href if-none-match='"23ba4d-ff11fb"'
 >/home/bernard/addressbook/vcf102.vcf</D:href>
      <D:href>/home/bernard/addressbook/vcf1.vcf</D:href>
    </C:addressbook-multiget>

Response:

    HTTP/1.1 207 Multi-Status
    Date: Sat, 11 Nov 2006 09:32:12 GMT
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:multistatus xmlns:D="DAV:"
                   xmlns:C="urn:ietf:params:xml:ns:carddav">
      <D:response>
        <D:href>/home/bernard/addressbook/vcf102.vcf</D:href>
        <D:status>HTTP/1.1 304 Not Modified</D:status>
      </D:response>
      <D:response>
        <D:href>/home/bernard/addressbook/vcf1.vcf</D:href>
        <D:status>HTTP/1.1 404 Resource not found</D:status>
      </D:response>
    </D:multistatus>

Best regards, Julian

Date: Sun, 15 Jul 2007 14:22:44 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: [Ietf-carddav] More comments on draft-daboo-carddav-02

More detailed comments on draft-daboo-carddav-02...:

In general, please replace all references to RFC2518 with RFC4918.

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? 

In "2.1.  Notational Conventions"

    The term "protected" is used in the Conformance field of property
    definitions as defined in Section 1.4.2 of [RFC3253].

Section 15 of RFC4918.

In "2.2.  XML Namespaces and Processing"

    Processing of XML by CardDAV clients and servers MUST follow the
    rules described in [RFC2518], in particular Section 14, and Appendix
    3 of that specification.

Appendix A of [RFC4918].

In "2.3.  Method Preconditions and Postconditions"

Just cite RFC4918, Section 16. Note the current text is incompatible 
with RFC4918 with respect to DAV:error in DA:multistatus.

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?

    o  MUST support WebDAV Class 1 [RFC2518] (note that
       [I-D.ietf-webdav-rfc2518bis] describes clarifications to [RFC2518]
       that aid interoperability);

Should say RFC4918 Class 3.

    o  MUST support WebDAV ACL [RFC3744];

    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 
<http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html#rfc.section.14> 
for alternate proposal.

    o  MUST support ETags [RFC2616] with additional requirements
       specified in Section 6.3.2.3 of this document;

Nope; see 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0006.html>.

    o  MUST support all address book REPORTs defined in ,xref
       target="reports"/> of this document; and

(XML in draft source broken)

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)?

    The CardDAV server or repository is the canonical location for
    address data and state information.  Clients may submit requests to

Server or repository? Please be consistent. Also, what does it mean
to be the "canonical location"? Does that rule out a CardDAV server to be
a proxy to an LDAP server?

in "5.2.  Address Book Collection"

    CardDAV defines the following new resource type for use in WebDAV
    repositories holding vCard data.

Remove that intro. Section reads completely fine without it.

in "6.1.1.  Example: Using OPTIONS for the Discovery of Support for CardDAV"

    HTTP/1.1 200 OK
    Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
    Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT
    Allow: MKADDRESSBOOK, ACL
    DAV: 1, 2, access-control, addressbook-access
    Date: Sat, 11 Nov 2006 09:32:12 GMT
    Content-Length: 0

DAV: 1, 2, 3, access-control, addressbook-access

in "6.2.  Address Book Properties"

Make statement about behaviour with DAV:allprop exactly once here, and 
remove it from all subsequent subsections.

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.

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)?

in "6.3.1.  MKADDRESSBOOK Method"

    Support for MKADDRESSBOOK on the server is only RECOMMENDED and not
    REQUIRED because some address book stores only support one address
    book per user (or principal), and those are typically pre-created for
    each account.  However, servers and clients are strongly encouraged
    to support MKADDRESSBOOK whenever possible to allow users to create
    multiple address book collections to help organize their data better.

...and not required...

    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.

    collections to users, clients SHOULD check the DAV:displayname
    property and use that value as the name of the address book.  In the
    event that the DAV: displayname property is empty, the client MAY use

...property is not set... (this is different from being empty)

    the last part of the address book collection URI as the name, however
    that path segment may be "opaque" and not represent any meaningful
    human-readable text.

    If a MKADDRESSBOOK request fails, the server state preceding the
    request MUST be restored.

Please specify cacheability/safety/idempotence.

       (CARDDAV:addressbook-collection-location-bad): The Request-URI
       MUST identify a location where an address book collection can be
       created.

CARDDAV:addressbook-collection-location-valid

       (DAV:needs-privilege): The DAV:bind privilege MUST be granted to
       the current user.

(1) It's "need-privileges" 
(<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>. (2) 
Is it really required to repeat that here? If yes, please include a 
reference to the definition in RFC3744.

in "6.3.1.1.  Status Codes"

       201 (Created) - The address book collection resource was created
       in its entirety.

Please specify what "in its entirety" means or drop it.

       409 (Conflict) - A collection cannot be made at the Request-URI
       until one or more intermediate collections have been created.

This is incorrect; it is in conflict with the pre/postcondition definitions.

       415 (Unsupported Media Type) - The server does not support the
       request type of the body.

       507 (Insufficient Storage) - The resource does not have sufficient
       space to record the state of the resource after the execution of
       this method.

If the list is not exhaustive anyway, things like 507 or 415 IMHO should 
go. The more you repeat obvious stuff, the harder it is to see what's 
being specified.

in "6.3.2.1.  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.

       (CARDDAV:addressbook-collection-location-ok): In a COPY or MOVE
       request, when the Request-URI is an address book collection, the
       Destination-URI MUST identify a location where an address book
       collection can be created;

"Destination-URI"? Did you mean "The URI specified in the Destination 
header?"

in  "6.3.2.2.  Non-Standard Properties, and Parameters"

I was momentarily confused because I thought it wasn't about vCard data. 
Maybe include this in the section title?

    Servers may need to enforce rules for their own "private" properties
    or parameters, so servers MAY reject any attempt by the client to
    change those or use values for those outside of any restrictions the
    server may have.  Servers SHOULD ensure that any "private" properties
    or parameters it uses follow the convention of including a vendor id
    in the "X-" name, as described in Section 3.8 of [RFC2426], e.g.,
    "X-ABC-PRIVATE".

Just state the requirement from RFC2426, but don't add an own one.

in "6.3.2.3.  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.

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?

in "8.3.  Searching Text: Collations"

    Some of the reports defined in this section do text matches of
    character strings provided by the client and compared to stored
    address data.  Since vCard data is by default encoded in the UTF-8
    charset and may include characters outside of the US-ASCII charset
    range in some property and parameter values, there is a need to
    ensure that text matching follows well-defined rules.

Lots of motivation, not really needed here. Also, I think "default" is 
misleading, as the default for text/* is *not* UTF-8.

    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.

    Clients MUST only use collations from the list advertised by the
    server.

That requirement is useless.

in "8.6.  CARDDAV:addressbook-query Report"

All report definitions must precisely state the semantics of the Depth 
request header.

    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.

in "8.7.  CARDDAV:addressbook-multiget Report"

    Support for the addressbook-multiget REPORT is REQUIRED.

Why?

-------------

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.

With respect to DTD fragments:

Please make sure they actually *are* DTD fragment, so for instance replace

        <!ELEMENT addressbook-description (#PCDATA)>
        PCDATA value: string

by

        <!ELEMENT addressbook-description (#PCDATA)>
        <!-- PCDATA value: string -->

in "1.  Introduction and Overview"

    Address books containing contact information are a key component of
    personal information management tools, such as email, calendaring and
    scheduling, and instant messaging clients.  To date several protocols
    have been used for remote access to contact data, including LDAP
    [RFC2251], IMSP and ACAP [RFC2244], together with SyncML used for
    synchronization of such data.

Reference for IMSP? Also, expand acronyms on first usage.

in "1.1.  IMSP"

In the list (and subsequent list), please consistently end sentences 
with a dot.

in "4.1.  Address Book Server"

    A WebDAV repository MAY include address data in some parts of its URL
    namespace, and non-address data in other parts.

I don't think this is any kind of requirement; it just states something 
obvious. Please lowercase the MAY.

in "5.1.  Address Object Resources"

    This specification uses vCard as the default format for address or
    contact information being stored on the server.  However, this
    specification does allow other formats for address data provided that
    the server advertises support for those additional formats as
    described below.  The requirements in this section pertain to vCard
    address data, os formats that follow the semantics of vCard data.

Typo? os->or?

in "6.2.2.  CARDDAV:supported-address-data Property"

    Conformance:  This property MAY be defined on any address book
       collection.  If defined, it MUST be protected and SHOULD NOT be
       returned by a PROPFIND DAV:allprop request (as defined in Section
       12.14.1 of [RFC2518] ).

    Description:  The CARDDAV:supported-address-data property is used to
       specify the media type supported for the address object resources
       contained in a given address book collection (e.g., vCard version
       3.0).  Any attempt by the client to store address object resources
       with a media type not listed in this property MUST result in an
       error, with the CARDDAV:supported-address-data precondition (
       Section 6.3.2.1 ) being violated.  In the absence of this property
       the server MUST only accept data with the media type "text/vcard"
       and vCard version 3.0, and clients can assume that.

Please check whitespace around xml2rfc <xref> elements (this repeats 
several times through the draft).

in "6.3.1.2.  Example - Successful MKADDRESSBOOK request"

    HTTP/1.1 201 Created Date: Fri, 22 Oct 2004 12:17:08 GMT
    Content-Length: 0
    Date: Sat, 11 Nov 2006 09:32:12 GMT
    Cache-Control: no-cache

Two date headers.

in "6.3.2.  Creating Address Object Resources"

    >> Request <<

    PUT /lisa/addressbook/newvcard.vcf HTTP/1.1
    If-None-Match: *
    Host: addressbook.example.com
    Content-Type: text/vcard
    Content-Length: xxx

    BEGIN:VCARD
    VERSION:3.0
    FN:Cyrus Daboo
    N:Daboo;Cyrus
    ADR;TYPE=POSTAL:;2822 Email HQ;Suite 2821;RFCVille;PA;15213;USA
    EMAIL;TYPE=INTERNET,PREF:[email-masked]
    NICKNAME:me
    NOTE:Example VCard.
    ORG:Self Employed
    TEL;TYPE=WORK,VOICE:412 605 0499
    TEL;TYPE=FAX:412 605 0705
    URL:http://www.daboo.name
    UID:1234-5678-9000-1
    END:VCARD

Please use example domain names in examples (here: EMAIL and URL).

in "6.3.2.1.  Additional Preconditions for PUT, COPY and MOVE"

    This specification creates additional Preconditions for PUT, COPY and
    MOVE methods.  These preconditions apply:

       When a PUT operation of an address object resource into an address
       book collection occurs.

       When a COPY or MOVE operation of an address object resource into
       an address book collection occurs.

List style: please make it "numbers" or "symbols"

in "7.1.1.  CARDDAV:addressbook-home-set Property"

     <C:addressbook-home-set xmlns:D="DAV:"
        xmlns:C="urn:ietf:params:xml:ns:carddav">
       <D:href>http://addressbook.example.com/bernard/addresses/</D:href>
     </C:addk-home-set>

Check the end tag.

Best regards, Julian

X-From_: [email-masked]  Sun Jul 15 10:24:42 2007
Date: Sun, 15 Jul 2007 12:21:31 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked], WebDAV <[email-masked]>
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Sun, 15 Jul 2007 10:21:53 +0000
Subject: [Ietf-carddav] Comments on draft-daboo-carddav-02

Below are some high-level comments on draft-daboo-carddav-02 
(<http://tools.ietf.org/html/draft-daboo-carddav-02>). I'm cross-posting 
this to the WebDAV and Carddav mailing lists, but will send a separate 
mail going into some other details of CardDAV just to the CardDAV 
mailing list.

The CardDAV design essentially is the same as for CalDAV, which has 
recently been approved by the IESG and been published as RFC4791. So it 
must be good, right?

Although I do agree that CalDAV solves an interesting problem, and that 
it is likely going to work in practice, it made several design decisions 
that I think hurt it with respect to acceptance, performance and 
generality. I understand that it's very tempting to just copy over the 
design; but I think it would be really good to reconsider the points below.

Overall design / new methods

Both specs use standard MIME types, and expose data through HTTP. This 
is a good thing. They also define new subclasses of WebDAV collections, 
which add some new constraints on their contents. I'm not entirely 
convinced that this is really needed, but in this case I'll trust the 
domain knowledge from the calendaring people. I'm not sure though 
whether the constraints for address books really require this.

The introduction of new DAV:resourcetypes however has lead to the 
introduction of new HTTP methods, with the single purpose of creating a 
WebDAV collection with a certain set of properties. I think this is an 
extremely bad idea.

Now I do *not* belong to the group of people with "new method angst". 
Defining new methods that have general applicability is completely ok 
IMHO. Good examples are COPY/MOVE, some of the versioning methods, BIND 
and so on. The difference to MKCALENDAR and MKADDRESSBOOK is that these 
ones are restricted to a single application use case. So what's next? 
MKPHOTOCOLLECTION? MKMUSIKCOLLECTION?

Instead, I'd suggest defining what MKCALENDAR and MKADDRESSBOOK have in 
common, and come up with a single solution to that. For instance, such 
as MKCOL using a request body that carries a set of properties, 
including the WebDAV resource type.

Use of Reports

Everytime a new REPORT is introduced, a new set of information is made 
hard to cache. In some cases that may be harmless (such as when it's 
something like a query, line in some RFC3744 reports).

However, defining a "multiget" really seems to be a bad idea, and now 
there are even two of those! Please take this out until it can be shown 
that just sending a bunch of GET requests (which can take advantage of 
caching) is not sufficient.

Property model

The specs avoid exposing the content of their data objects as WebDAV 
properties. This leads to lots of workarounds, such as introducing 
"pseudo-properties" containing the actual content 
(CARDDAV:addressbook-data), and abuse of DAV:prop for something that is 
not a WebDAV property. Don't do this, it requires generic WebDAV servers 
to use lots of special cases. (WebDAV SEARCH started with pseudo 
properties but got successfully rid of them, so this can be done).

Best regards, Julian

Date: Sun, 15 Jul 2007 12:21:31 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked], WebDAV <[email-masked]>
Subject: [Ietf-carddav] Comments on draft-daboo-carddav-02

Below are some high-level comments on draft-daboo-carddav-02 
(<http://tools.ietf.org/html/draft-daboo-carddav-02>). I'm cross-posting 
this to the WebDAV and Carddav mailing lists, but will send a separate 
mail going into some other details of CardDAV just to the CardDAV 
mailing list.

The CardDAV design essentially is the same as for CalDAV, which has 
recently been approved by the IESG and been published as RFC4791. So it 
must be good, right?

Although I do agree that CalDAV solves an interesting problem, and that 
it is likely going to work in practice, it made several design decisions 
that I think hurt it with respect to acceptance, performance and 
generality. I understand that it's very tempting to just copy over the 
design; but I think it would be really good to reconsider the points below.

Overall design / new methods

Both specs use standard MIME types, and expose data through HTTP. This 
is a good thing. They also define new subclasses of WebDAV collections, 
which add some new constraints on their contents. I'm not entirely 
convinced that this is really needed, but in this case I'll trust the 
domain knowledge from the calendaring people. I'm not sure though 
whether the constraints for address books really require this.

The introduction of new DAV:resourcetypes however has lead to the 
introduction of new HTTP methods, with the single purpose of creating a 
WebDAV collection with a certain set of properties. I think this is an 
extremely bad idea.

Now I do *not* belong to the group of people with "new method angst". 
Defining new methods that have general applicability is completely ok 
IMHO. Good examples are COPY/MOVE, some of the versioning methods, BIND 
and so on. The difference to MKCALENDAR and MKADDRESSBOOK is that these 
ones are restricted to a single application use case. So what's next? 
MKPHOTOCOLLECTION? MKMUSIKCOLLECTION?

Instead, I'd suggest defining what MKCALENDAR and MKADDRESSBOOK have in 
common, and come up with a single solution to that. For instance, such 
as MKCOL using a request body that carries a set of properties, 
including the WebDAV resource type.

Use of Reports

Everytime a new REPORT is introduced, a new set of information is made 
hard to cache. In some cases that may be harmless (such as when it's 
something like a query, line in some RFC3744 reports).

However, defining a "multiget" really seems to be a bad idea, and now 
there are even two of those! Please take this out until it can be shown 
that just sending a bunch of GET requests (which can take advantage of 
caching) is not sufficient.

Property model

The specs avoid exposing the content of their data objects as WebDAV 
properties. This leads to lots of workarounds, such as introducing 
"pseudo-properties" containing the actual content 
(CARDDAV:addressbook-data), and abuse of DAV:prop for something that is 
not a WebDAV property. Don't do this, it requires generic WebDAV servers 
to use lots of special cases. (WebDAV SEARCH started with pseudo 
properties but got successfully rid of them, so this can be done).

Best regards, Julian