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

Julian Reschke <julian.reschke@gmx.de> Mon, 23 July 2007 10:46 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: ietf-carddav@osafoundation.org
Delivered-To: ietf-carddav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7AE1D7FFC4 for <ietf-carddav@osafoundation.org>; Mon, 23 Jul 2007 03:46:44 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C5891421FF for <ietf-carddav@osafoundation.org>; Mon, 23 Jul 2007 03:45:49 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.924
X-Spam-Level:
X-Spam-Status: No, score=-0.924 tagged_above=-50 required=4 tests=[AWL=0.398, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_FAIL=1.142]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eeu0EpG4Qkv for <ietf-carddav@osafoundation.org>; Mon, 23 Jul 2007 03:45:47 -0700 (PDT)
Received: from mail205c25.carrierzone.com (mail205c25.carrierzone.com [64.29.147.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1B4881421FD for <ietf-carddav@osafoundation.org>; Mon, 23 Jul 2007 03:45:46 -0700 (PDT)
X-Authenticated-User: master.tencoassemblies.com
Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail205c25.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6NAjfMK006452; Mon, 23 Jul 2007 10:45:45 GMT
Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Jul 2007 06:45:42 -0400
Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07232007-064521-14891.MMD@TencoAssembliesInc.local; Mon, 23 Jul 2007 06:45:21 -0400
X-From_: w3c-dist-auth-request@frink.w3.org Sun Jul 22 14:33:01 2007
X-Envelope-From: w3c-dist-auth-request@frink.w3.org
Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by mail153c25.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6MEWxcp015915 for <JTentilucci@tencoassemblies.com>; Sun, 22 Jul 2007 14:33:01 GMT
Received: from lists by frink.w3.org with local (Exim 4.50) id 1ICcSN-00007H-So for w3c-dist-auth-dist@listhub.w3.org; Sun, 22 Jul 2007 14:30:47 +0000
Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ICcSK-00006d-BL for w3c-dist-auth@listhub.w3.org; Sun, 22 Jul 2007 14:30:44 +0000
Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from <julian.reschke@gmx.de>) id 1ICcS7-0007Kv-3A for w3c-dist-auth@w3.org; Sun, 22 Jul 2007 14:30:43 +0000
Received: (qmail invoked by alias); 22 Jul 2007 14:30:19 -0000
Received: from p508FACDE.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.172.222] by mail.gmx.net (mp049) with SMTP; 22 Jul 2007 16:30:19 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/x5QUQVmrx2bjNrTLCf5oa/r40+jjfdg8n9kKDoI w/dlmYtfm8UgpX
Message-ID: <46A369EE.8050303@gmx.de>
Date: Sun, 22 Jul 2007 16:30:06 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <4699F52B.10101@gmx.de> <DA70918551A4706E579F3829@caldav.corp.apple.com> <469B8976.9040402@jackpot.uk.net> <C4E535EC204E5BF24F6076F0@caldav.corp.apple.com> <469B91A2.5000002@jackpot.uk.net> <469B9319.7090204@gmx.de> <6A114647AE869FB6B3252EDC@caldav.corp.apple.com> <9FCFEB85-5FCE-4F4A-8724-C2642E17943F@osafoundation.org> <469BA088.3060709@gmx.de>
In-Reply-To: <469BA088.3060709@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: aji.w3.org 1ICcS7-0007Kv-3A a2472bd72d7c7c0e7978f499404bdcb6
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
X-Archived-At: http://www.w3.org/mid/46A369EE.8050303@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/12746
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Resent-Message-Id: <E1ICcSN-00007H-So@frink.w3.org>
Resent-Date: Sun, 22 Jul 2007 14:30:47 +0000
X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com)
X-OriginalArrivalTime: 23 Jul 2007 10:45:42.0162 (UTC) FILETIME=[9DAC0720:01C7CD16]
Cc: ietf-carddav@osafoundation.org
X-BeenThere: ietf-carddav@osafoundation.org
X-Mailman-Version: 2.1.5
List-Id: ietf-carddav.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-carddav>
List-Post: <mailto:ietf-carddav@osafoundation.org>
List-Help: <mailto:ietf-carddav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jul 2007 10:46:44 -0000

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