Re: [Ietf-carddav] Comments on draft-daboo-carddav-02

[Julian Reschke <[e-mail]>]

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