Re: [VCARDDAV] Pseudo-properties in reports, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}

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:
> 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
>
>
>
>
> _______________________________________________
> VCARDDAV mailing list
> VCARDDAV@ietf.org
> https://www.ietf.org/mailman/listinfo/vcarddav

Received on Tuesday, 17 March 2009 11:01:12 UTC