Subject: allprop behaviour, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Mar 2009 13:54:53 +0100

Marc Blanchet wrote:
> Hi,
>  This is the working group last call for the following two documents:
> http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-05
> http://tools.ietf.org/html/draft-ietf-vcarddav-webdav-mkcol-03
> 
> Please provide any comments to the wg mailing list
> (mailto:[email-masked]) by March 9th 2009, 23h00 GMT.
> 
> Regards,
>  Marc and Kurt, vcarddav wg chairs

Hi,

apologies for the late feedback.

I've been going through draft-ietf-vcarddav-carddav-06, and have quite a 
few comments which I'll raise in separate emails (trying to collect 
things that belong together into single mails).

The first one is a generic comment about the properties defined in 
Section 6.2 
(<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-6.2>).

For each property, it states:

    allprop behavior:  SHOULD be returned by a PROPFIND DAV:allprop
       request.

This deviates from how every single other WebDAV extension (including 
CalDAV) has been defined. Why?

Proposal: change this to "SHOULD NOT", and also state it just once and 
for all in the introduction to Section 6.2.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Mar 2009 14:41:39 +0100

Hi,

a few comments with respect how draft-ietf-vcarddav-carddav-06 uses DTD 
fragments for defining the CardDAV related elements:

1) Section 2.2 (XML Namespaces and Processing) should be expanded to 
include statements about how the DTD fragments are to be understood, 
similar to Section 2 in draft-ietf-vcarddav-webdav-mkcol-04.

2) The XML spec reference needs to be updated to W3C.REC-xml-20081126, 
just as in draft-ietf-vcarddav-webdav-mkcol-04. (Note I'd recommend to 
use a shorter reference name, such as just "XML".

3) I had trang (<http://www.thaiopensource.com/relaxng/trang.html>) 
parse the DTD fragments for me (to do that just markup the artwork with 
the proper type of "application/xml-dtd", then use rfc2629xslt's 
extract-artwork.xslt 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork>).

A minor issue I found is that at least one element type definition 
(addressbook) appeared multiple times; this is not really a problem as 
long as they all say the same thing.

On the other hand, address-data has three different definitions (see 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-10.4>), 
depending on the context it's used in. I think this really should be 
avoided. The simplest fix for this seems to just use three distinct names.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Mar 2009 15:33:26 +0100

Hi,

in 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-7.1.1> 
the XML is not well-formed.

        <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:addressbook-home-set>

The simplest fix would be just to use an absolute path, as in

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

The same applies to Section 7.1.2.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Mar 2009 15:46:07 +0100

>  Marc and Kurt, vcarddav wg chairs

A few comments with respect to the IANA Considerations 
(<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-14>):

1) The references style, as in

   "... defined by RFC4918 [RFC4918] for ..."

looks a bit weird (artifact from a time when this document used numeric 
references?)

2) The statement:

    "All other IANA considerations mentioned in RFC4918 [RFC4918] also
    apply to this document."

is very misleading; RFC 4918's IANA Considerations talk about URI scheme 
registrations, HTTP header registrations, and HTTP status code 
registrations. None of this is relevant to CardDAV, so just drop the 
sentence.

3) I also found the statement below confusing:

   "XML: None.  Namespace URIs do not represent an XML specification."

Proposal: just state:

   "XML: None - not applicable for namespace registrations".

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Mar 2009 15:49:56 +0100

Hi,

below some comments related to the WebDAV reports defined in Section 8 
(<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8>).

1) Editorial: when referring to specific reports (not the REPORT 
method), the spec sometimes uses "report", and sometimes "REPORT". 
Please be consistent (with a preference on the lowercase variant, to 
distinguish from the actual method name).

2) WebDAV reports should be consistent in how various depths are handled 
(see RFC 3253, Section 3.6). The best way to achieve this is by exactly 
defining what the scope is for Depth == 0. If the request URI is a 
WebDAV collection, the behavior for Depth == 1 or Depth == infinity will 
follow from that. Otherwise it should be specified or ruled out (see ACL 
reports).

3) Related to that:

"As a result the "Depth" header MUST be ignored by the server and SHOULD 
NOT be sent by the client." -- 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.7>

Nope. Really :-). This is incompatible with generic report handling. 
Instead, specify the desired behavior for Depth == 0, require clients to 
set Depth == 0 or leave it out, and require servers to return status 400 
for other values (like in RFC 3744).

4) Editorial:

"The request body MUST be a CARDDAV:addressbook-multiget XML element 
(see Section 10.7, which MUST contain at least one DAV: href XML 
element, and one optional CARDDAV:address-data element as defined in 
Section 10.4."  -- 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.7>

Missing ")" after "Section 10.7".

5) It goes on saying:

"If the Request-URI is a collection resource, then the DAV:href elements 
MUST refer to resources within that collection, and they MAY refer to 
resources at any depth within the collection. As a result the "Depth" 
header MUST be ignored by the server and SHOULD NOT be sent by the 
client. If the Request-URI refers to a non-collection resource, then 
there MUST be a single DAV:href element that is equivalent to the 
Request-URI."

I think it would be simpler to define it this way:

"If DAV:href elements are present, the scope of the request is the set 
of resources identified by these elements, which all need to be members 
(not necessarily internal members) of the resource identified by the 
Request-URI. Otherwise, the scope is the resource identified by the 
Request-URI itself."

This avoids the special-casing, and gets rid of the repeated URI in the 
DAV:href element for non-collections.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Mar 2009 17:56:14 +0100

Hi,

this is somehow related to a discussion we had in July 2007 
(<http://lists.osafoundation.org/pipermail/ietf-carddav/2007-July/000018.html>):

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

As far as I recall, the feedback I got was that making them full-blown 
WebDAV properties would be both expensive, and lose flexibility. I am 
still not sure that I buy that.

But, accepting this for now, then CardDAV should really stop pretending 
that these pseudo properties are WebDAV properties in reports - it is 
really confusing, and makes implementing a generic server hard if 
something appears as a property only in specific contexts. Furthermore, 
the current specification makes it harder to re-use generic code, as it 
overloads not only the semantics, but also the syntax of DAV:prop.

Consider the use of DAV:prop in:

<C:addressbook-query xmlns:D="DAV:"
                   xmlns:C="urn:ietf:params:xml:ns:carddav">
   <D:prop>
     <D:getetag/>
     <C:address-data>
       <C:prop name="VERSION"/>
       <C:prop name="UID"/>
       <C:prop name="NICKNAME"/>
       <C:prop name="EMAIL"/>
       <C:prop name="FN"/>
     </C:address-data>
   </D:prop>
   <C:filter>
     <C:prop-filter name="NICKNAME">
       <C:text-match collation="i;unicode-casemap"
                     match-type="equals"
       >me</C:text-match>
     </C:prop-filter>
   </C:filter>
</C:addressbook-query>

-- <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.6.3>

Here, DAV:prop contains both a true WebDAV property, and a pseudo-property:

   <D:prop>
     <D:getetag/>
     <C:address-data>
       <C:prop name="VERSION"/>
       <C:prop name="UID"/>
       <C:prop name="NICKNAME"/>
       <C:prop name="EMAIL"/>
       <C:prop name="FN"/>
     </C:address-data>
   </D:prop>

That pseudo property though needs special treatment, it's *not* just an 
identifier, but an identifier augmented with parameters. There's really 
no point in putting it into a DAV:prop, as generic WebDAV XML handling 
code is not capable to use it.

So, IMHO, the right thing here is to make C:address-data a top-level 
element in the request, as in:

<C:addressbook-query xmlns:D="DAV:"
                   xmlns:C="urn:ietf:params:xml:ns:carddav">
   <D:prop>
     <D:getetag/>
   </D:prop>
   <C:address-data>
     <C:prop name="VERSION"/>
     <C:prop name="UID"/>
     <C:prop name="NICKNAME"/>
     <C:prop name="EMAIL"/>
     <C:prop name="FN"/>
   </C:address-data>
   <C:filter>
     <C:prop-filter name="NICKNAME">
       <C:text-match collation="i;unicode-casemap"
                     match-type="equals"
       >me</C:text-match>
     </C:prop-filter>
   </C:filter>
</C:addressbook-query>

This also means that the response format needs to be extended; but 
again, this is a good thing - generic code handling multistatus/propstat 
will be confused anyway, so it's *good* not to overload DAV:propstat 
with things that do not belong there.

Note that during the development of WebDAV SEARCH (RFC 5323), 
pseudo-properties were used both for request (DAV:iscollection) and 
responses (DAV:score), but fortunately we got rid of these problems 
(see, for instance, 
<http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.16.1>).

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 15 Mar 2009 14:59:40 -0400

Hi Julian,

> for all in the introduction to Section 6.2.

Changed to SHOULD NOT everywhere. Since there were several sections where 
properties are defined, I left the individual "alprop behavior" items in 
each definition.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 15 Mar 2009 22:02:48 -0400

Hi Julian,

> similar to Section 2 in draft-ietf-vcarddav-webdav-mkcol-04.

Fixed - I re-wrote section 2 to be more like the other draft. The separate 
sub-section on XML processing was removed as a result.

> use a shorter reference name, such as just "XML".

Reference updated. I am just using the xml2rfc default for <?rfc 
symrefs="yes"?>.

> 3) I had trang (<http://www.thaiopensource.com/relaxng/trang.html>) parse
> the DTD fragments for me (to do that just markup the artwork with the
> proper type of "application/xml-dtd", then use rfc2629xslt's
> extract-artwork.xslt
> <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-10.4>)
> , depending on the context it's used in. I think this really should be

Well we did have calendar-data in CalDAV do the same. I am OK with making a 
change if others think it is worth doing.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 15 Mar 2009 22:04:34 -0400

Hi Julian,

> The same applies to Section 7.1.2.

Fixed.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 15 Mar 2009 22:10:07 -0400

Hi Julian,

> looks a bit weird (artifact from a time when this document used numeric

Agreed - fixed.

> registrations. None of this is relevant to CardDAV, so just drop the

Yup that was a little odd. I have changed the section to simply:

    This document uses a URN to describe a new XML namespace conforming to
    the registry mechanism described in [RFC3688].

>    "XML: None - not applicable for namespace registrations".

Changed.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 15 Mar 2009 22:22:51 -0400

Hi Julian,

--On March 13, 2009 3:49:56 PM +0100 Julian Reschke <[email-masked]> 
wrote:

> 1) Editorial: when referring to specific reports (not the REPORT method),
> the spec sometimes uses "report", and sometimes "REPORT". Please be
> consistent (with a preference on the lowercase variant, to distinguish
> from the actual method name).

Fixed.

> defining what the scope is for Depth == 0. If the request URI is a WebDAV
> collection, the behavior for Depth == 1 or Depth == infinity will follow
> from that. Otherwise it should be specified or ruled out (see ACL
> reports).
>
> 3) Related to that:
>

Ok, so then we go with "the Depth header MUST be present and set to the 
value 0 (zero)" in all of these reports. Is that sufficient?

> 4) Editorial:
>
> "The request body MUST be a CARDDAV:addressbook-multiget XML element (see
> Section 10.7, which MUST contain at least one DAV: href XML element, and
> one optional CARDDAV:address-data element as defined in Section 10.4."
> -- <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.7>
>

Fixed.

> "If DAV:href elements are present, the scope of the request is the set of
> resources identified by these elements, which all need to be members (not
> necessarily internal members) of the resource identified by the

I have made this change. Whilst this is technically significant in that it 
changes the way things work when the multiget is targeted at a single URI, 
I don't believe I have seen anyone actually using it that way in CalDAV so 
it won't hurt to do the change here.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Mar 2009 10:39:33 +0100

Cyrus Daboo wrote:
> ...
> ...

Yep. xml2rfc's default IMHO is wrong, and results in bad readability.

Here's a replacement:

<reference anchor="XML" 
target="http://www.w3.org/TR/2008/REC-xml-20081126/">
   <front>
     <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
     <author initials="T." surname="Bray" fullname="Tim Bray">
       <organization>Textuality and Netscape</organization>
       <address>
         <email>[email-masked]</email>
       </address>
     </author>
     <author initials="J." surname="Paoli" fullname="Jean Paoli">
       <organization>Microsoft</organization>
       <address>
         <email>[email-masked]</email>
       </address>
     </author>
     <author initials="C.M." surname="Sperberg-McQueen" fullname="C. M. 
Sperberg-McQueen">
       <organization>W3C</organization>
       <address>
         <email>[email-masked]</email>
       </address>
     </author>
     <author initials="E." surname="Maler" fullname="Eve Maler">
       <organization>Sun Microsystems</organization>
       <address>
         <email>[email-masked]</email>
       </address>
     </author>
     <author initials="F." surname="Yergeau" fullname="Francois Yergeau">
       <organization/>
     </author>
     <date day="26" month="November" year="2008"/>
   </front>
   <seriesInfo name="W3C" value="REC-xml-20081126"/>
</reference>

> Well we did have calendar-data in CalDAV do the same. I am OK with 
> making a change if others think it is worth doing.

I think in the long term the right approach would be not to use DTD 
fragments anymore, and to use RelaxNG instead.

But while we're using DTDs, I absolutely recommend to use them in a way 
so that at least in theory they can be used. One alternative approach 
would be to use "ANY", and put all the remaining restrictions into prose.

That being said, it seems to me that adding more specific elements 
actually would make the vocabulary easier to understand.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Mar 2009 10:52:11 +0100

> value 0 (zero)" in all of these reports. Is that sufficient?

The default is 0 anyway (per RFC 3253). Making a requirement on the 
client doesn't make sense here; if Depth values != 0 are not supported, 
then the requirement is on the server to reject the request.

That being said: are you positively sure that the default depth handling 
defined in RFC 3253 does not apply here?

1) addressbook-query

In this case, the scope is the set of address objects contained in the 
address book collection (at the request URI), right? (*)

Thus depth != 0 would essentially mean the same thing, as recursion into 
child collections wouldn't (by definition) find any additional address 
objects. Thus, I don't see any reason to forbid it, just mention it's 
meaningless.

(*) Or is it allowed to address a specific address object?

2) multiget

Again, I think it would become clearer if you could precisely define 
what the scope for Depth 0 is. Does it include indirect child resources 
(they wouldn't be address objects, but could still report WebDAV 
properties, right?)?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Mar 2009 17:51:32 +0100

Hi,

below are some more minor issues...:

1) 6.1.1:

"In this example, the OPTIONS response indicates that the server 
supports CardDAV in this namespace, therefore the '/addressbooks/users/' 
collection may be used as a parent for address book collections as the 
extended MKCOL method is available, and as a possible target for REPORT 
requests for address book reports."

The fact that (a) the server does know about carddav, and (b) that it 
supports extended MKCOL does not necessarily mean it will be able to 
create address books everywhere below the Request-URI... If this kind of 
feature discovery is needed, then we probably need to invent something 
like DAV:supported-resource-types (and define that in ext-mkcol).

2) 6.2.2: legacy types

It would be interesting to see an example where the server also supports 
the "legacy" mime types (as they use a parameter).

3) 6.2.2: copy/move behavior

"Protected:
     MUST be protected as it indicates the level of support provided by 
the server.
COPY/MOVE behavior:
     This property value MUST be preserved in COPY and MOVE operations."

That essentially means that best-effort copy of address books is not 
allowed -- is this really intended??? I think it's not consistent with 
the behavior in other WebDAV specs (such as a copy of a version history 
resource that is also a collection). See also 6.3.2.1, 
(CARDDAV:addressbook-collection-location-ok).

4) 6.3 Creating Resources

"Address book collections and address object resources may be created by 
either a CardDAV client or by the CardDAV server."

Actually, it's always the server creating them. I believe this should 
state that creation can be *initiated* by both the server or the client.

5) 6.3.2 Creating Address Object Resources

"The request to change an existing address object resource is the same, 
but with a specific ETag in the "If-Match" header, rather than the 
"If-None-Match" header."

That suggests that an update operation *needs* If-Match. Proposal: 
rephrase to make clear it's optional, but provides protection against 
overlapping updates.

Best regards, Julian

---

From: Arnaud Quillaud <[email-masked]>
Date: Tue, 17 Mar 2009 12:00:29 +0100

I think all the points below are valid, except that CardDAV is simply 
following the approach taken by CalDAV.
Given the similarities between the 2 protocols, and given that people 
implementing one are likely to implement the other, it will be very 
confusing if we start to diverge (and it won't simplify implementations).

Arnaud Q

Julian Reschke wrote:
>> (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).
>
> But, accepting this for now, then CardDAV should really stop 
> pretending that these pseudo properties are WebDAV properties in 
> reports - it is really confusing, and makes implementing a generic 
> server hard if something appears as a property only in specific 
> contexts. Furthermore, the current specification makes it harder to 
> re-use generic code, as it overloads not only the semantics, but also 
> the syntax of DAV:prop.
>
> <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.6.3>
>
> That pseudo property though needs special treatment, it's *not* just 
> an identifier, but an identifier augmented with parameters. There's 
> really no point in putting it into a DAV:prop, as generic WebDAV XML 
> handling code is not capable to use it.
>
> again, this is a good thing - generic code handling 
> multistatus/propstat will be confused anyway, so it's *good* not to 
> overload DAV:propstat with things that do not belong there.
>
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Mar 2009 12:15:06 +0100

> confusing if we start to diverge (and it won't simplify implementations).

Well, it *is* confusing for people who haven't implemented CalDAV, but 
other WebDAV extensions, such as SEARCH (which successfully avoided 
overloading properties).

So I personally think if we need to choose between "the right way" and 
"the CalDAV way", we should choose the former (and this also applies to 
other aspecs I haven't mentioned yet, such as the requirements on ETag 
behavior).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Mar 2009 14:49:34 +0100

Hi,

looking at Section 6.3.1:

    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 extended
    MKCOL request, or alternatively issue a PROPPATCH request to change
    the DAV:displayname property to the appropriate value immediately
    after using the extended MKCOL 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
    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 not set, the client MAY
    use 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. -- 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-6.3.1>

In particular:

    ...Clients SHOULD NOT set the
    DAV:displayname property to be the same as any other address book
    collection at the same URI "level"...

I realize that this is another CalDAVism.

What I'm concerned with is that this introduces a normative requirement, 
which, in some cases, may be very expensive to implement, for instance 
if the parent collection of the address books is very large. Also, what 
is a client supposed to do when the user-assigned displayname turns out 
to be already in use? Report an error and ask the user for a different 
name???

In general, WebDAV clients can not rely on DAV:displayname being unique 
across a collection and will have to fall back to the last path segment 
if they need to present something unique to the user. Thus, violating 
the SHOULD level requirement would not cause any interop problems, and 
thus use of RFC2119 terminology is not really required. So, IMHO, the 
spec should better just *encourage* assignment of meaningful names here.

(Besiders, if this really is a problem, shouldn't it also be mentioned 
for COPY and MOVE???)

Related to this: it seems that CARDDAV:calendar-description duplicates 
information that is already contained in DAV:displayname. Compare:

"If present, the property contains a description of the calendar 
collection that is suitable for presentation to a user." 
(CARDDAV:calendar-description)

   and

"Contains a description of the resource that is suitable for 
presentation to a user." (DAV:displayname)

Is there any reason to believe that adding a new property here is really 
useful (other than consistency with CalDAV :-))?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Mar 2009 15:59:28 +0100

Hi,

1) Editorial: 4.1 Address Book Server

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

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

"Entity tags and other features help this work."

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

2) 6.3.2.3 Address Object Resource Entity Tag

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

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

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

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

Best regards, Julian

---

From: Arnaud Quillaud <[email-masked]>
Date: Tue, 17 Mar 2009 16:37:54 +0100

> other WebDAV extensions, such as SEARCH (which successfully avoided 
My feeling is that there are many more clients/servers doing CalDAV + 
CardDAV than clients/server doing CardDAV + SEARCH but of course I have 
no numbers to back that statement.

Arnaud Q
> "the CalDAV way", we should choose the former (and this also applies 
> to other aspecs I haven't mentioned yet, such as the requirements on 
> ETag behavior).
>
> Best regards, Julian
>
>

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 17 Mar 2009 11:42:17 -0400

Hi Arnaud,

> no numbers to back that statement.

I will have this as an open issue for discussion at the meeting next week.

My preference is to leave it as-is. Having done implementations of this 
(probably over half-a-dozen different varieties of clients/servers CardDAV 
and CalDAV) I really see no problem with the pseudo property - including 
starting with a base WebDAV implementation.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Mar 2009 17:27:57 +0100

Hi,

and finally (for now), here's a bag of minor issues...

1) Editorial (references)

"To date several protocols have been used for remote access to contact 
data, including Lightweight Directory Access Protocol LDAP [RFC4511], 
Internet Message Support Protocol IMSP [IMSP] and Application 
Configuration Access Protocol ACAP [RFC2244],"

Put the abbreviated terms in brackets.

"vCard [RFC2426] is a MIME directory profile aimed at encapsulating 
personal addressing and contact information about people. The 
specification of vCard was originally done by the Versit consortium, 
with a subsequent 3.0 version standardized by the IETF [RFC2426]."

I guess the first reference to RFC2426 should be removed.

"Definitions of XML elements in this document use XML element type 
declarations (as found in XML Document Type Declarations), described in 
Section 3.2 of [W3C.REC-xml-20060816]."

Just say "[XML]" :-)

2) Editorial: WebDAV properties vs vCard properties

It might be a good idea to properly explain the difference between those 
upfront, and to check in the remainder of the spec that it's always 
clear which one is meant.

3) Editorial: CARDDAV:allprop XML Element

Maybe it would avoid confusion with DAV:allprop if it was called: 
cdarddav:allcomponents (or something like that).

4) 11. Service Discovery via SRV Records

RFC2782 states that security considerations MUST be included (just 
relaying this, no idea what would need to go in here).

And that's it.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Mar 2009 13:52:44 +0100

Hi,

Werner Baumann noticed that RFC 4918 indeed *also* says:

> Purpose:
>     Provides a name for the resource that is suitable for presentation to a user.

which conflicts with

> Description:
>     Contains a description of the resource that is suitable for presentation to a user. This property is defined on the resource, and hence SHOULD have the same value independent of the Request-URI used to retrieve it (thus, computing this property based on the Request-URI is deprecated). While generic clients might display the property value to end users, client UI designers must understand that the method for identifying resources is still the URL. Changes to DAV:displayname do not issue moves or copies to the server, but simply change a piece of meta-data on the individual resource. Two resources can have the same DAV:displayname value even within the same collection.

(both in <http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.15.2>).

A description of a resource is not the same thing as the name of a 
resource. Should we record that as issue? And if we do, what would be 
the proposed resolution?

As far as I can tell, when DAV:displayname is set, it's almost always 
used as a more verbose name, but not as a description.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Mar 2009 15:23:55 +0100

Hi,

I was going through older mailing list discussions, and found an issue 
where I think we were close to consensus, but then didn't make that 
change...

In general, a server that successfully executes a MKCOL/ext request, 
doesn't need to return a detailed success response. However, the spec 
currently requires a response body with propstat elements for all 
successfully set properties.

I think we should make that OPTIONAL -- thus, for a 201 response, the 
server would be allowed to send an empty response.

BR, Julian