From w3c-dist-auth-request@listhub.w3.org Wed Apr 9 09:31:16 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7040B1A0380 for ; Wed, 9 Apr 2014 09:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22sFQFvmgi3f for ; Wed, 9 Apr 2014 09:31:12 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 251C91A032E for ; Wed, 9 Apr 2014 09:31:11 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1WXvN8-0002Ng-DM for w3c-dist-auth-dist@listhub.w3.org; Wed, 09 Apr 2014 16:29:10 +0000 Resent-Date: Wed, 09 Apr 2014 16:29:10 +0000 Resent-Message-Id: Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WXvN7-0002My-VC for w3c-dist-auth@listhub.w3.org; Wed, 09 Apr 2014 16:29:10 +0000 Received: from smtp.andrew.cmu.edu ([128.2.157.37]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WXvN5-0005lr-CP for w3c-dist-auth@w3.org; Wed, 09 Apr 2014 16:29:09 +0000 Received: from localhost.localdomain (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s39GSdfk009135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Apr 2014 12:28:39 -0400 Message-ID: <53457537.8040205@andrew.cmu.edu> Date: Wed, 09 Apr 2014 12:28:39 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: WebDAV Content-Type: multipart/alternative; boundary="------------070102000200060809090905" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.9.161819 X-SMTP-Spam-Clean: 27% ( SXL_IP_DYNAMIC 3, BODY_SIZE_10000_PLUS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BAT_BOUNDARY 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FW_1LN_BOT_MSGID 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 27% X-Scanned-By: MIMEDefang 2.74 on 128.2.157.37 Received-SPF: none client-ip=128.2.157.37; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu X-W3C-Hub-Spam-Status: No, score=-3.6 X-W3C-Hub-Spam-Report: AWL=-3.315, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272 X-W3C-Scan-Sig: maggie.w3.org 1WXvN5-0005lr-CP 9dc43861d199acf388cb524f528b99f5 X-Original-To: w3c-dist-auth@w3.org Subject: WebDAV PUSH based on RFC 6202 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13418 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: This is a multi-part message in MIME format. --------------070102000200060809090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, The Calendaring and Scheduling Consortium (CalConnect) is looking at ways to have a server "push" changes made to a calendar/addressbook collection out to a client. There are already a few proprietary mechanisms in place for doing so, but we would like to come up with something standard that would be relatively simple to implement for both clients and servers and would be applicable to any DAV collection. One idea that we are toying with is to leverage the existing DAV:sync-collection REPORT and HTTP long-polling . I spent a few hours coding up a prototype version of HTTP long-polling and HTTP streaming for DAV:sync-collection REPORTs in my server which I describe below. We (CalConnect) are considering using this approach or something similar as a starting point and we are interested in any/all feedback from the larger DAV community, including: * Is this approach sane, is there a better way, or is any type of push via HTTP a hopeless endeavor? * Will this approach (or anything similar) break in the face of intermediaries? * Will existing HTTP/DAV stacks be able to handle long-polling and/or streaming? * Should the server advertise its ability to long-poll and/or stream for the client to discover or simply leave it up to the client try one or both and see what the server does, as is the case in my implementation below? Long-polling: For long-polling, I leveraged the HTTP Prefer header and its 'wait' preference as a way for the client to tell the server that it wants to long poll. If the client doesn't specify a DAV:sync-token (initial sync) or if there have been changes since the specified token, then the server will respond immediately. Otherwise, it will only respond if a change is detected or when the timeout expires, whichever comes first. In the case of a delayed response, I issue a 100 (Continue) provisional response with a Preference-Applied header to notify the client that the server is indeed long-polling as requested. This provisional response may or may not be necessary. In my implementation I wait 1 sec less than specified to account for processing time so I don't go over what the client expects. Streaming: The client can request streaming behavior by simply including an Accept header with the 'multipart/mixed' media type (I chose this subtype for lack of something better - we could use the existing x-mixed-replace or create our own). The client can also specify a timeout for the streaming using the same 'wait' preference as used for long-polling. In the absence of a client-requested timeout, the server will continue to add body parts until the client disconnects or the server hits some internal timeout. Because a multipart response allows for an epilogue following the final delimiter, a client can't just rely on the delimiters to detect the end of the response. Therefore, the server MUST use either chunked TE or close the connection following the multipart response. In my example below, I close-delimit the response for better readability. FWIW, I think the same holds true for multipart/byteranges responses. In my implementation I include a Content-Length header in the body-part headers so the client can detect the end of the XML body without looking for the trailing delimiter (mainly because the trailing delimiter doesn't appear until the next body part). Examples: Here is an example of long-polling with 3 requests (I added superfluous Date headers to show the timing). The first request returns immediately due to a pre-existing change, the second returns upon detecting a subsequent change some 95 sec later, and the third times out after 3 min. REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 Host: localhost Date: Wed, 30 Oct 2013 18:11:11 GMT Content-Type: application/xml Content-Length: 260 Prefer: return=minimal, wait=180 http://cyrusimap.org/ns/sync/1368011844-354 1 HTTP/1.1 207 Multi-Status Date: Wed, 30 Oct 2013 18:11:11 GMT Vary: Accept-Encoding, Brief, Prefer Preference-Applied: return=minimal, wait=180 Content-Type: application/xml; charset=utf-8 Content-Length: 421 /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics HTTP/1.1 200 OK http://cyrusimap.org/ns/sync/1368011844-355 REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 Host: localhost Date: Wed, 30 Oct 2013 18:11:12 GMT Content-Type: application/xml Content-Length: 260 Prefer: return=minimal, wait=180 http://cyrusimap.org/ns/sync/1368011844-355 1 HTTP/1.1 100 Continue Date: Wed, 30 Oct 2013 18:11:12 GMT Preference-Applied: wait=180 HTTP/1.1 207 Multi-Status Date: Wed, 30 Oct 2013 18:12:47 GMT Vary: Accept-Encoding, Brief, Prefer Preference-Applied: return=minimal, wait=180 Content-Type: application/xml; charset=utf-8 Content-Length: 375 /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics HTTP/1.1 404 Not Found http://cyrusimap.org/ns/sync/1368011844-356 REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 Host: localhost Date: Wed, 30 Oct 2013 18:12:48 GMT Content-Type: application/xml Content-Length: 260 Prefer: return=minimal, wait=180 http://cyrusimap.org/ns/sync/1368011844-356 1 HTTP/1.1 100 Continue Date: Wed, 30 Oct 2013 18:12:48 GMT Preference-Applied: wait=180 HTTP/1.1 207 Multi-Status Date: Wed, 30 Oct 2013 18:15:47 GMT Vary: Accept-Encoding, Brief, Prefer Preference-Applied: return=minimal, wait=180 Content-Type: application/xml; charset=utf-8 Content-Length: 202 http://cyrusimap.org/ns/sync/1368011844-356 Here is the same sequence of events utilizing streaming with a timeout: REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 Host: localhost Date: Wed, 30 Oct 2013 18:11:06 GMT Content-Type: application/xml Content-Length: 260 Prefer: return=minimal, wait=180 Accept: multipart/mixed http://cyrusimap.org/ns/sync/1368011844-354 1 HTTP/1.1 207 Multi-Status Connection: close Date: Wed, 30 Oct 2013 18:11:06 GMT Vary: Accept-Encoding, Brief, Prefer Preference-Applied: return=minimal, wait=180 Content-Type: multipart/mixed; boundary="localhost-29378-1383156666-1025603243" This is a message with multiple parts in MIME format. --localhost-29378-1383156666-1025603243 Date: Wed, 30 Oct 2013 18:11:06 GMT Content-Type: application/xml; charset=utf-8 Content-Length: 421 /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics HTTP/1.1 200 OK http://cyrusimap.org/ns/sync/1368011844-355 --localhost-29378-1383156666-1025603243 Date: Wed, 30 Oct 2013 18:12:47 GMT Content-Type: application/xml; charset=utf-8 Content-Length: 375 /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics HTTP/1.1 404 Not Found http://cyrusimap.org/ns/sync/1368011844-356 --localhost-29378-1383156666-1025603243 Date: Wed, 30 Oct 2013 18:14:05 GMT Content-Type: application/xml; charset=utf-8 Content-Length: 202 http://cyrusimap.org/ns/sync/1368011844-356 --localhost-29378-1383156666-1025603243-- End of MIME multipart body. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------070102000200060809090905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

The Calendaring and Scheduling Consortium (CalConnect) is looking at ways to have a server "push" changes made to a calendar/addressbook collection out to a client.  There are already a few proprietary mechanisms in place for doing so, but we would like to come up with something standard that would be relatively simple to implement for both clients and servers and would be applicable to any DAV collection.

One idea that we are toying with is to leverage the existing DAV:sync-collection REPORT and HTTP long-polling.  I spent a few hours coding up a prototype version of HTTP long-polling and HTTP streaming for DAV:sync-collection REPORTs in my server which I describe below.  We (CalConnect) are considering using this approach or something similar as a starting point and we are interested in any/all feedback from the larger DAV community, including:
  • Is this approach sane, is there a better way, or is any type of push via HTTP a hopeless endeavor?
  • Will this approach (or anything similar) break in the face of intermediaries?
  • Will existing HTTP/DAV stacks be able to handle long-polling and/or streaming?
  • Should the server advertise its ability to long-poll and/or stream for the client to discover or simply leave it up to the client try one or both and see what the server does, as is the case in my implementation below?

Long-polling:

For long-polling, I leveraged the HTTP Prefer header and its 'wait' preference as a way for the client to tell the server that it wants to long poll.  If the client doesn't specify a DAV:sync-token (initial sync) or if there have been changes since the specified token, then the server will respond immediately.  Otherwise, it will only respond if a change is detected or when the timeout expires, whichever comes first.  In the case of a delayed response, I issue a 100 (Continue) provisional response with a Preference-Applied header to notify the client that the server is indeed long-polling as requested.  This provisional response may or may not be necessary.  In my implementation I wait 1 sec less than specified to account for processing time so I don't go over what the client expects.

Streaming:

The client can request streaming behavior by simply including an Accept header with the 'multipart/mixed' media type (I chose this subtype for lack of something better - we could use the existing x-mixed-replace or create our own).  The client can also specify a timeout for the streaming using the same 'wait' preference as used for long-polling.  In the absence of a client-requested timeout, the server will continue to add body parts until the client disconnects or the server hits some internal timeout.  Because a multipart response allows for an epilogue following the final delimiter, a client can't just rely on the delimiters to detect the end of the response.  Therefore, the server MUST use either chunked TE or close the connection following the multipart response.  In my example below, I close-delimit the response for better readability.  FWIW, I think the same holds true for multipart/byteranges responses.  In my implementation I include a Content-Length header in the body-part headers so the client can detect the end of the XML body without looking for the trailing delimiter (mainly because the trailing delimiter doesn't appear until the next body part).

Examples:

Here is an example of long-polling with 3 requests (I added superfluous Date headers to show the timing).  The first request returns immediately due to a pre-existing change, the second returns upon detecting a subsequent change some 95 sec later, and the third times out after 3 min.

REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:11 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-354</D:sync-token>
  <D:sync-level>1</D:sync-level>
  <D:prop/>
</C:sync-collection>

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:11:11 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 421

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
    <D:propstat>
      <D:prop/>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
</D:multistatus>



REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:12 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
  <D:sync-level>1</D:sync-level>
  <D:prop/>
</C:sync-collection>

HTTP/1.1 100 Continue
Date: Wed, 30 Oct 2013 18:11:12 GMT
Preference-Applied: wait=180

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:12:47 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 375

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
    <D:status>HTTP/1.1 404 Not Found</D:status>
  </D:response>
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>



REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:12:48 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
  <D:sync-level>1</D:sync-level>
  <D:prop/>
</C:sync-collection>

HTTP/1.1 100 Continue
Date: Wed, 30 Oct 2013 18:12:48 GMT
Preference-Applied: wait=180

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:15:47 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 202

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>



Here is the same sequence of events utilizing streaming with a timeout:

REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:06 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180
Accept: multipart/mixed

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-354</D:sync-token>
  <D:sync-level>1</D:sync-level>
  <D:prop/>
</C:sync-collection>

HTTP/1.1 207 Multi-Status
Connection: close
Date: Wed, 30 Oct 2013 18:11:06 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: multipart/mixed; boundary="localhost-29378-1383156666-1025603243"

This is a message with multiple parts in MIME format.

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:11:06 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 421

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
    <D:propstat>
      <D:prop/>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:12:47 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 375

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
    <D:status>HTTP/1.1 404 Not Found</D:status>
  </D:response>
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:14:05 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 202

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243--

End of MIME multipart body.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------070102000200060809090905-- From w3c-dist-auth-request@listhub.w3.org Wed Apr 9 09:38:08 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B731A03DC for ; Wed, 9 Apr 2014 09:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J48DeUG6zVIF for ; Wed, 9 Apr 2014 09:38:04 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 75F1F1A0380 for ; Wed, 9 Apr 2014 09:38:04 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1WXvUv-0004lv-4U for w3c-dist-auth-dist@listhub.w3.org; Wed, 09 Apr 2014 16:37:13 +0000 Resent-Date: Wed, 09 Apr 2014 16:37:13 +0000 Resent-Message-Id: Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WXvUu-0004lH-4C for w3c-dist-auth@listhub.w3.org; Wed, 09 Apr 2014 16:37:12 +0000 Received: from mailhost.stpeter.im ([207.210.219.225] helo=stpeter.im) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WXvUo-0000Qr-Jn for w3c-dist-auth@w3.org; Wed, 09 Apr 2014 16:37:12 +0000 Received: from aither.local (unknown [66.191.14.77]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4E34B40352; Wed, 9 Apr 2014 10:36:45 -0600 (MDT) Message-ID: <5345771C.9090909@stpeter.im> Date: Wed, 09 Apr 2014 09:36:44 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ken Murchison , WebDAV References: <53457537.8040205@andrew.cmu.edu> In-Reply-To: <53457537.8040205@andrew.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=207.210.219.225; envelope-from=stpeter@stpeter.im; helo=stpeter.im X-W3C-Hub-Spam-Status: No, score=-0.3 X-W3C-Hub-Spam-Report: RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1WXvUo-0000Qr-Jn ce61dafd91d797d7911bd6e7e3f04024 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV PUSH based on RFC 6202 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13419 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: http://tools.ietf.org/id/draft-hildebrand-webdav-notify-00.txt On 4/9/14, 9:28 AM, Ken Murchison wrote: > All, > > The Calendaring and Scheduling Consortium (CalConnect) is looking at > ways to have a server "push" changes made to a calendar/addressbook > collection out to a client. There are already a few proprietary > mechanisms in place for doing so, but we would like to come up with > something standard that would be relatively simple to implement for both > clients and servers and would be applicable to any DAV collection. > > One idea that we are toying with is to leverage the existing > DAV:sync-collection REPORT > and HTTP long-polling . I > spent a few hours coding up a prototype version of HTTP long-polling and > HTTP streaming for DAV:sync-collection REPORTs in my server which I > describe below. We (CalConnect) are considering using this approach or > something similar as a starting point and we are interested in any/all > feedback from the larger DAV community, including: > > * Is this approach sane, is there a better way, or is any type of push > via HTTP a hopeless endeavor? > * Will this approach (or anything similar) break in the face of > intermediaries? > * Will existing HTTP/DAV stacks be able to handle long-polling and/or > streaming? > * Should the server advertise its ability to long-poll and/or stream > for the client to discover or simply leave it up to the client try > one or both and see what the server does, as is the case in my > implementation below? > > > Long-polling: > > For long-polling, I leveraged the HTTP Prefer header > and its 'wait' > preference as a way for the client to tell the server that it wants to > long poll. If the client doesn't specify a DAV:sync-token (initial > sync) or if there have been changes since the specified token, then the > server will respond immediately. Otherwise, it will only respond if a > change is detected or when the timeout expires, whichever comes first. > In the case of a delayed response, I issue a 100 (Continue) provisional > response with a Preference-Applied header to notify the client that the > server is indeed long-polling as requested. This provisional response > may or may not be necessary. In my implementation I wait 1 sec less > than specified to account for processing time so I don't go over what > the client expects. > > Streaming: > > The client can request streaming behavior by simply including an Accept > header with the 'multipart/mixed' media type (I chose this subtype for > lack of something better - we could use the existing x-mixed-replace or > create our own). The client can also specify a timeout for the > streaming using the same 'wait' preference as used for long-polling. In > the absence of a client-requested timeout, the server will continue to > add body parts until the client disconnects or the server hits some > internal timeout. Because a multipart response allows for an epilogue > following the final delimiter, a client can't just rely on the > delimiters to detect the end of the response. Therefore, the server > MUST use either chunked TE or close the connection following the > multipart response. In my example below, I close-delimit the response > for better readability. FWIW, I think the same holds true for > multipart/byteranges responses. In my implementation I include a > Content-Length header in the body-part headers so the client can detect > the end of the XML body without looking for the trailing delimiter > (mainly because the trailing delimiter doesn't appear until the next > body part). > > Examples: > > Here is an example of long-polling with 3 requests (I added superfluous > Date headers to show the timing). The first request returns immediately > due to a pre-existing change, the second returns upon detecting a > subsequent change some 95 sec later, and the third times out after 3 min. > > REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 > Host: localhost > Date: Wed, 30 Oct 2013 18:11:11 GMT > Content-Type: application/xml > Content-Length: 260 > Prefer: return=minimal, wait=180 > > > > http://cyrusimap.org/ns/sync/1368011844-354 > 1 > > > > HTTP/1.1 207 Multi-Status > Date: Wed, 30 Oct 2013 18:11:11 GMT > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal, wait=180 > Content-Type: application/xml; charset=utf-8 > Content-Length: 421 > > > > > /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics > > > HTTP/1.1 200 OK > > > http://cyrusimap.org/ns/sync/1368011844-355 > > > > > REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 > Host: localhost > Date: Wed, 30 Oct 2013 18:11:12 GMT > Content-Type: application/xml > Content-Length: 260 > Prefer: return=minimal, wait=180 > > > > http://cyrusimap.org/ns/sync/1368011844-355 > 1 > > > > HTTP/1.1 100 Continue > Date: Wed, 30 Oct 2013 18:11:12 GMT > Preference-Applied: wait=180 > > HTTP/1.1 207 Multi-Status > Date: Wed, 30 Oct 2013 18:12:47 GMT > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal, wait=180 > Content-Type: application/xml; charset=utf-8 > Content-Length: 375 > > > > > /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics > HTTP/1.1 404 Not Found > > http://cyrusimap.org/ns/sync/1368011844-356 > > > > > REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 > Host: localhost > Date: Wed, 30 Oct 2013 18:12:48 GMT > Content-Type: application/xml > Content-Length: 260 > Prefer: return=minimal, wait=180 > > > > http://cyrusimap.org/ns/sync/1368011844-356 > 1 > > > > HTTP/1.1 100 Continue > Date: Wed, 30 Oct 2013 18:12:48 GMT > Preference-Applied: wait=180 > > HTTP/1.1 207 Multi-Status > Date: Wed, 30 Oct 2013 18:15:47 GMT > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal, wait=180 > Content-Type: application/xml; charset=utf-8 > Content-Length: 202 > > > > http://cyrusimap.org/ns/sync/1368011844-356 > > > > > Here is the same sequence of events utilizing streaming with a timeout: > > REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 > Host: localhost > Date: Wed, 30 Oct 2013 18:11:06 GMT > Content-Type: application/xml > Content-Length: 260 > Prefer: return=minimal, wait=180 > Accept: multipart/mixed > > > > http://cyrusimap.org/ns/sync/1368011844-354 > 1 > > > > HTTP/1.1 207 Multi-Status > Connection: close > Date: Wed, 30 Oct 2013 18:11:06 GMT > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal, wait=180 > Content-Type: multipart/mixed; > boundary="localhost-29378-1383156666-1025603243" > > This is a message with multiple parts in MIME format. > > --localhost-29378-1383156666-1025603243 > Date: Wed, 30 Oct 2013 18:11:06 GMT > Content-Type: application/xml; charset=utf-8 > Content-Length: 421 > > > > > /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics > > > HTTP/1.1 200 OK > > > http://cyrusimap.org/ns/sync/1368011844-355 > > > --localhost-29378-1383156666-1025603243 > Date: Wed, 30 Oct 2013 18:12:47 GMT > Content-Type: application/xml; charset=utf-8 > Content-Length: 375 > > > > > /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics > HTTP/1.1 404 Not Found > > http://cyrusimap.org/ns/sync/1368011844-356 > > > --localhost-29378-1383156666-1025603243 > Date: Wed, 30 Oct 2013 18:14:05 GMT > Content-Type: application/xml; charset=utf-8 > Content-Length: 202 > > > > http://cyrusimap.org/ns/sync/1368011844-356 > > > --localhost-29378-1383156666-1025603243-- > > End of MIME multipart body. > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > From w3c-dist-auth-request@listhub.w3.org Wed Apr 9 09:46:14 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83F1A03DE for ; Wed, 9 Apr 2014 09:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKYooNtu3JXn for ; Wed, 9 Apr 2014 09:46:09 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C42A11A03D1 for ; Wed, 9 Apr 2014 09:46:09 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1WXvcc-0003Cs-2F for w3c-dist-auth-dist@listhub.w3.org; Wed, 09 Apr 2014 16:45:10 +0000 Resent-Date: Wed, 09 Apr 2014 16:45:10 +0000 Resent-Message-Id: Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WXvcb-0003Bu-Ks for w3c-dist-auth@listhub.w3.org; Wed, 09 Apr 2014 16:45:09 +0000 Received: from smtp.andrew.cmu.edu ([128.2.157.37]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WXvca-0006Nu-Db for w3c-dist-auth@w3.org; Wed, 09 Apr 2014 16:45:09 +0000 Received: from localhost.localdomain (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s39Gijkm010451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Apr 2014 12:44:46 -0400 Message-ID: <534578FD.5070504@andrew.cmu.edu> Date: Wed, 09 Apr 2014 12:44:45 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Saint-Andre , WebDAV References: <53457537.8040205@andrew.cmu.edu> <5345771C.9090909@stpeter.im> In-Reply-To: <5345771C.9090909@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.9.163620 X-SMTP-Spam-Clean: 27% ( SXL_IP_DYNAMIC 3, BODY_SIZE_10000_PLUS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 27% X-Scanned-By: MIMEDefang 2.74 on 128.2.157.37 Received-SPF: none client-ip=128.2.157.37; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu X-W3C-Hub-Spam-Status: No, score=-3.5 X-W3C-Hub-Spam-Report: AWL=-3.258, RP_MATCHES_RCVD=-0.272 X-W3C-Scan-Sig: maggie.w3.org 1WXvca-0006Nu-Db 289ccf4f0333ee4a3b8a9907fd4b8c15 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV PUSH based on RFC 6202 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13420 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: I wasn't aware of this draft. Do you feel that this approach is superior, and if so, would be consider resurrecting the draft? On 04/09/2014 12:36 PM, Peter Saint-Andre wrote: > > http://tools.ietf.org/id/draft-hildebrand-webdav-notify-00.txt > > > On 4/9/14, 9:28 AM, Ken Murchison wrote: >> All, >> >> The Calendaring and Scheduling Consortium (CalConnect) is looking at >> ways to have a server "push" changes made to a calendar/addressbook >> collection out to a client. There are already a few proprietary >> mechanisms in place for doing so, but we would like to come up with >> something standard that would be relatively simple to implement for both >> clients and servers and would be applicable to any DAV collection. >> >> One idea that we are toying with is to leverage the existing >> DAV:sync-collection REPORT >> and HTTP long-polling . I >> spent a few hours coding up a prototype version of HTTP long-polling and >> HTTP streaming for DAV:sync-collection REPORTs in my server which I >> describe below. We (CalConnect) are considering using this approach or >> something similar as a starting point and we are interested in any/all >> feedback from the larger DAV community, including: >> >> * Is this approach sane, is there a better way, or is any type of push >> via HTTP a hopeless endeavor? >> * Will this approach (or anything similar) break in the face of >> intermediaries? >> * Will existing HTTP/DAV stacks be able to handle long-polling and/or >> streaming? >> * Should the server advertise its ability to long-poll and/or stream >> for the client to discover or simply leave it up to the client try >> one or both and see what the server does, as is the case in my >> implementation below? >> >> >> Long-polling: >> >> For long-polling, I leveraged the HTTP Prefer header >> and its 'wait' >> preference as a way for the client to tell the server that it wants to >> long poll. If the client doesn't specify a DAV:sync-token (initial >> sync) or if there have been changes since the specified token, then the >> server will respond immediately. Otherwise, it will only respond if a >> change is detected or when the timeout expires, whichever comes first. >> In the case of a delayed response, I issue a 100 (Continue) provisional >> response with a Preference-Applied header to notify the client that the >> server is indeed long-polling as requested. This provisional response >> may or may not be necessary. In my implementation I wait 1 sec less >> than specified to account for processing time so I don't go over what >> the client expects. >> >> Streaming: >> >> The client can request streaming behavior by simply including an Accept >> header with the 'multipart/mixed' media type (I chose this subtype for >> lack of something better - we could use the existing x-mixed-replace or >> create our own). The client can also specify a timeout for the >> streaming using the same 'wait' preference as used for long-polling. In >> the absence of a client-requested timeout, the server will continue to >> add body parts until the client disconnects or the server hits some >> internal timeout. Because a multipart response allows for an epilogue >> following the final delimiter, a client can't just rely on the >> delimiters to detect the end of the response. Therefore, the server >> MUST use either chunked TE or close the connection following the >> multipart response. In my example below, I close-delimit the response >> for better readability. FWIW, I think the same holds true for >> multipart/byteranges responses. In my implementation I include a >> Content-Length header in the body-part headers so the client can detect >> the end of the XML body without looking for the trailing delimiter >> (mainly because the trailing delimiter doesn't appear until the next >> body part). >> >> Examples: >> >> Here is an example of long-polling with 3 requests (I added superfluous >> Date headers to show the timing). The first request returns immediately >> due to a pre-existing change, the second returns upon detecting a >> subsequent change some 95 sec later, and the third times out after 3 >> min. >> >> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >> Host: localhost >> Date: Wed, 30 Oct 2013 18:11:11 GMT >> Content-Type: application/xml >> Content-Length: 260 >> Prefer: return=minimal, wait=180 >> >> >> > xmlns:C="urn:ietf:params:xml:ns:caldav"> >> http://cyrusimap.org/ns/sync/1368011844-354 >> 1 >> >> >> >> HTTP/1.1 207 Multi-Status >> Date: Wed, 30 Oct 2013 18:11:11 GMT >> Vary: Accept-Encoding, Brief, Prefer >> Preference-Applied: return=minimal, wait=180 >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 421 >> >> >> >> >> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >> >> >> >> HTTP/1.1 200 OK >> >> >> http://cyrusimap.org/ns/sync/1368011844-355 >> >> >> >> >> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >> Host: localhost >> Date: Wed, 30 Oct 2013 18:11:12 GMT >> Content-Type: application/xml >> Content-Length: 260 >> Prefer: return=minimal, wait=180 >> >> >> > xmlns:C="urn:ietf:params:xml:ns:caldav"> >> http://cyrusimap.org/ns/sync/1368011844-355 >> 1 >> >> >> >> HTTP/1.1 100 Continue >> Date: Wed, 30 Oct 2013 18:11:12 GMT >> Preference-Applied: wait=180 >> >> HTTP/1.1 207 Multi-Status >> Date: Wed, 30 Oct 2013 18:12:47 GMT >> Vary: Accept-Encoding, Brief, Prefer >> Preference-Applied: return=minimal, wait=180 >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 375 >> >> >> >> >> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >> >> HTTP/1.1 404 Not Found >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> >> >> >> >> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >> Host: localhost >> Date: Wed, 30 Oct 2013 18:12:48 GMT >> Content-Type: application/xml >> Content-Length: 260 >> Prefer: return=minimal, wait=180 >> >> >> > xmlns:C="urn:ietf:params:xml:ns:caldav"> >> http://cyrusimap.org/ns/sync/1368011844-356 >> 1 >> >> >> >> HTTP/1.1 100 Continue >> Date: Wed, 30 Oct 2013 18:12:48 GMT >> Preference-Applied: wait=180 >> >> HTTP/1.1 207 Multi-Status >> Date: Wed, 30 Oct 2013 18:15:47 GMT >> Vary: Accept-Encoding, Brief, Prefer >> Preference-Applied: return=minimal, wait=180 >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 202 >> >> >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> >> >> >> >> Here is the same sequence of events utilizing streaming with a timeout: >> >> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >> Host: localhost >> Date: Wed, 30 Oct 2013 18:11:06 GMT >> Content-Type: application/xml >> Content-Length: 260 >> Prefer: return=minimal, wait=180 >> Accept: multipart/mixed >> >> >> > xmlns:C="urn:ietf:params:xml:ns:caldav"> >> http://cyrusimap.org/ns/sync/1368011844-354 >> 1 >> >> >> >> HTTP/1.1 207 Multi-Status >> Connection: close >> Date: Wed, 30 Oct 2013 18:11:06 GMT >> Vary: Accept-Encoding, Brief, Prefer >> Preference-Applied: return=minimal, wait=180 >> Content-Type: multipart/mixed; >> boundary="localhost-29378-1383156666-1025603243" >> >> This is a message with multiple parts in MIME format. >> >> --localhost-29378-1383156666-1025603243 >> Date: Wed, 30 Oct 2013 18:11:06 GMT >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 421 >> >> >> >> >> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >> >> >> >> HTTP/1.1 200 OK >> >> >> http://cyrusimap.org/ns/sync/1368011844-355 >> >> >> --localhost-29378-1383156666-1025603243 >> Date: Wed, 30 Oct 2013 18:12:47 GMT >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 375 >> >> >> >> >> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >> >> HTTP/1.1 404 Not Found >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> >> >> --localhost-29378-1383156666-1025603243 >> Date: Wed, 30 Oct 2013 18:14:05 GMT >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 202 >> >> >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> >> >> --localhost-29378-1383156666-1025603243-- >> >> End of MIME multipart body. >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> > -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From w3c-dist-auth-request@listhub.w3.org Wed Apr 9 10:59:22 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4EF1A02F4 for ; Wed, 9 Apr 2014 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbgDGbtckt1J for ; Wed, 9 Apr 2014 10:59:18 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 28A201A02D4 for ; Wed, 9 Apr 2014 10:59:18 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1WXwl2-0005Vs-CB for w3c-dist-auth-dist@listhub.w3.org; Wed, 09 Apr 2014 17:57:56 +0000 Resent-Date: Wed, 09 Apr 2014 17:57:56 +0000 Resent-Message-Id: Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WXwl1-0005VD-Uc for w3c-dist-auth@listhub.w3.org; Wed, 09 Apr 2014 17:57:55 +0000 Received: from mailhost.stpeter.im ([207.210.219.225] helo=stpeter.im) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WXwl0-0004BI-5t for w3c-dist-auth@w3.org; Wed, 09 Apr 2014 17:57:55 +0000 Received: from aither.local (unknown [66.191.14.77]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7BF2240352; Wed, 9 Apr 2014 11:57:32 -0600 (MDT) Message-ID: <53458A0B.9080309@stpeter.im> Date: Wed, 09 Apr 2014 10:57:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ken Murchison , WebDAV References: <53457537.8040205@andrew.cmu.edu> <5345771C.9090909@stpeter.im> <534578FD.5070504@andrew.cmu.edu> In-Reply-To: <534578FD.5070504@andrew.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=207.210.219.225; envelope-from=stpeter@stpeter.im; helo=stpeter.im X-W3C-Hub-Spam-Status: No, score=-0.3 X-W3C-Hub-Spam-Report: RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1WXwl0-0004BI-5t b4ed73da323cd5f07808e352481fc91f X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV PUSH based on RFC 6202 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13421 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: [resend to list] Well, I mention this Internet-Draft mostly to show that people have been thinking about this problem for at least 10 years. You could use XMPP for such notifications, although it might depend on what kinds of endpoints you're trying to support (e.g., do they or can they do XMPP). Other options are technologies like pubsubhubbub. There are also lots of proprietary technologies for such notifications, although of course we don't want anything proprietary. However IMHO long polling is not the best approach these days - we wrote RFC 6202 mostly to say that long polling is a bad idea and that it's better to use WebSockets instead (RFC 6455). But WebSockets only gives you "TCP for the Web" and you'd need to define some kind of application over WebSocket in order to get anything done (examples are SIP over WebSocket, XMPP over WebSocket, etc.). Peter On 4/9/14, 9:44 AM, Ken Murchison wrote: > I wasn't aware of this draft. Do you feel that this approach is > superior, and if so, would be consider resurrecting the draft? > > > On 04/09/2014 12:36 PM, Peter Saint-Andre wrote: >> >> http://tools.ietf.org/id/draft-hildebrand-webdav-notify-00.txt >> >> >> On 4/9/14, 9:28 AM, Ken Murchison wrote: >>> All, >>> >>> The Calendaring and Scheduling Consortium (CalConnect) is looking at >>> ways to have a server "push" changes made to a calendar/addressbook >>> collection out to a client. There are already a few proprietary >>> mechanisms in place for doing so, but we would like to come up with >>> something standard that would be relatively simple to implement for both >>> clients and servers and would be applicable to any DAV collection. >>> >>> One idea that we are toying with is to leverage the existing >>> DAV:sync-collection REPORT >>> and HTTP long-polling . I >>> spent a few hours coding up a prototype version of HTTP long-polling and >>> HTTP streaming for DAV:sync-collection REPORTs in my server which I >>> describe below. We (CalConnect) are considering using this approach or >>> something similar as a starting point and we are interested in any/all >>> feedback from the larger DAV community, including: >>> >>> * Is this approach sane, is there a better way, or is any type of push >>> via HTTP a hopeless endeavor? >>> * Will this approach (or anything similar) break in the face of >>> intermediaries? >>> * Will existing HTTP/DAV stacks be able to handle long-polling and/or >>> streaming? >>> * Should the server advertise its ability to long-poll and/or stream >>> for the client to discover or simply leave it up to the client try >>> one or both and see what the server does, as is the case in my >>> implementation below? >>> >>> >>> Long-polling: >>> >>> For long-polling, I leveraged the HTTP Prefer header >>> and its 'wait' >>> preference as a way for the client to tell the server that it wants to >>> long poll. If the client doesn't specify a DAV:sync-token (initial >>> sync) or if there have been changes since the specified token, then the >>> server will respond immediately. Otherwise, it will only respond if a >>> change is detected or when the timeout expires, whichever comes first. >>> In the case of a delayed response, I issue a 100 (Continue) provisional >>> response with a Preference-Applied header to notify the client that the >>> server is indeed long-polling as requested. This provisional response >>> may or may not be necessary. In my implementation I wait 1 sec less >>> than specified to account for processing time so I don't go over what >>> the client expects. >>> >>> Streaming: >>> >>> The client can request streaming behavior by simply including an Accept >>> header with the 'multipart/mixed' media type (I chose this subtype for >>> lack of something better - we could use the existing x-mixed-replace or >>> create our own). The client can also specify a timeout for the >>> streaming using the same 'wait' preference as used for long-polling. In >>> the absence of a client-requested timeout, the server will continue to >>> add body parts until the client disconnects or the server hits some >>> internal timeout. Because a multipart response allows for an epilogue >>> following the final delimiter, a client can't just rely on the >>> delimiters to detect the end of the response. Therefore, the server >>> MUST use either chunked TE or close the connection following the >>> multipart response. In my example below, I close-delimit the response >>> for better readability. FWIW, I think the same holds true for >>> multipart/byteranges responses. In my implementation I include a >>> Content-Length header in the body-part headers so the client can detect >>> the end of the XML body without looking for the trailing delimiter >>> (mainly because the trailing delimiter doesn't appear until the next >>> body part). >>> >>> Examples: >>> >>> Here is an example of long-polling with 3 requests (I added superfluous >>> Date headers to show the timing). The first request returns immediately >>> due to a pre-existing change, the second returns upon detecting a >>> subsequent change some 95 sec later, and the third times out after 3 >>> min. >>> >>> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >>> Host: localhost >>> Date: Wed, 30 Oct 2013 18:11:11 GMT >>> Content-Type: application/xml >>> Content-Length: 260 >>> Prefer: return=minimal, wait=180 >>> >>> >>> >> xmlns:C="urn:ietf:params:xml:ns:caldav"> >>> http://cyrusimap.org/ns/sync/1368011844-354 >>> 1 >>> >>> >>> >>> HTTP/1.1 207 Multi-Status >>> Date: Wed, 30 Oct 2013 18:11:11 GMT >>> Vary: Accept-Encoding, Brief, Prefer >>> Preference-Applied: return=minimal, wait=180 >>> Content-Type: application/xml; charset=utf-8 >>> Content-Length: 421 >>> >>> >>> >>> >>> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >>> >>> >>> >>> HTTP/1.1 200 OK >>> >>> >>> http://cyrusimap.org/ns/sync/1368011844-355 >>> >>> >>> >>> >>> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >>> Host: localhost >>> Date: Wed, 30 Oct 2013 18:11:12 GMT >>> Content-Type: application/xml >>> Content-Length: 260 >>> Prefer: return=minimal, wait=180 >>> >>> >>> >> xmlns:C="urn:ietf:params:xml:ns:caldav"> >>> http://cyrusimap.org/ns/sync/1368011844-355 >>> 1 >>> >>> >>> >>> HTTP/1.1 100 Continue >>> Date: Wed, 30 Oct 2013 18:11:12 GMT >>> Preference-Applied: wait=180 >>> >>> HTTP/1.1 207 Multi-Status >>> Date: Wed, 30 Oct 2013 18:12:47 GMT >>> Vary: Accept-Encoding, Brief, Prefer >>> Preference-Applied: return=minimal, wait=180 >>> Content-Type: application/xml; charset=utf-8 >>> Content-Length: 375 >>> >>> >>> >>> >>> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >>> >>> HTTP/1.1 404 Not Found >>> >>> http://cyrusimap.org/ns/sync/1368011844-356 >>> >>> >>> >>> >>> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >>> Host: localhost >>> Date: Wed, 30 Oct 2013 18:12:48 GMT >>> Content-Type: application/xml >>> Content-Length: 260 >>> Prefer: return=minimal, wait=180 >>> >>> >>> >> xmlns:C="urn:ietf:params:xml:ns:caldav"> >>> http://cyrusimap.org/ns/sync/1368011844-356 >>> 1 >>> >>> >>> >>> HTTP/1.1 100 Continue >>> Date: Wed, 30 Oct 2013 18:12:48 GMT >>> Preference-Applied: wait=180 >>> >>> HTTP/1.1 207 Multi-Status >>> Date: Wed, 30 Oct 2013 18:15:47 GMT >>> Vary: Accept-Encoding, Brief, Prefer >>> Preference-Applied: return=minimal, wait=180 >>> Content-Type: application/xml; charset=utf-8 >>> Content-Length: 202 >>> >>> >>> >>> http://cyrusimap.org/ns/sync/1368011844-356 >>> >>> >>> >>> >>> Here is the same sequence of events utilizing streaming with a timeout: >>> >>> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >>> Host: localhost >>> Date: Wed, 30 Oct 2013 18:11:06 GMT >>> Content-Type: application/xml >>> Content-Length: 260 >>> Prefer: return=minimal, wait=180 >>> Accept: multipart/mixed >>> >>> >>> >> xmlns:C="urn:ietf:params:xml:ns:caldav"> >>> http://cyrusimap.org/ns/sync/1368011844-354 >>> 1 >>> >>> >>> >>> HTTP/1.1 207 Multi-Status >>> Connection: close >>> Date: Wed, 30 Oct 2013 18:11:06 GMT >>> Vary: Accept-Encoding, Brief, Prefer >>> Preference-Applied: return=minimal, wait=180 >>> Content-Type: multipart/mixed; >>> boundary="localhost-29378-1383156666-1025603243" >>> >>> This is a message with multiple parts in MIME format. >>> >>> --localhost-29378-1383156666-1025603243 >>> Date: Wed, 30 Oct 2013 18:11:06 GMT >>> Content-Type: application/xml; charset=utf-8 >>> Content-Length: 421 >>> >>> >>> >>> >>> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >>> >>> >>> >>> HTTP/1.1 200 OK >>> >>> >>> http://cyrusimap.org/ns/sync/1368011844-355 >>> >>> >>> --localhost-29378-1383156666-1025603243 >>> Date: Wed, 30 Oct 2013 18:12:47 GMT >>> Content-Type: application/xml; charset=utf-8 >>> Content-Length: 375 >>> >>> >>> >>> >>> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >>> >>> HTTP/1.1 404 Not Found >>> >>> http://cyrusimap.org/ns/sync/1368011844-356 >>> >>> >>> --localhost-29378-1383156666-1025603243 >>> Date: Wed, 30 Oct 2013 18:14:05 GMT >>> Content-Type: application/xml; charset=utf-8 >>> Content-Length: 202 >>> >>> >>> >>> http://cyrusimap.org/ns/sync/1368011844-356 >>> >>> >>> --localhost-29378-1383156666-1025603243-- >>> >>> End of MIME multipart body. >>> >>> -- >>> Kenneth Murchison >>> Principal Systems Software Engineer >>> Carnegie Mellon University >>> >> > > From jorgecardoso@copetel.com.ar Fri Apr 11 05:51:54 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87931A0250; Fri, 11 Apr 2014 05:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.728 X-Spam-Level: ** X-Spam-Status: No, score=2.728 tagged_above=-999 required=5 tests=[BAYES_95=3, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U1n9mUMCofV; Fri, 11 Apr 2014 05:51:54 -0700 (PDT) Received: from mail.copetel.com.ar (mail-03.copetel.com.ar [190.9.0.9]) by ietfa.amsl.com (Postfix) with ESMTP id AE1FF1A0245; Fri, 11 Apr 2014 05:51:45 -0700 (PDT) Received: from mail.copetel.com.ar (localhost [127.0.0.1]) by mail.copetel.com.ar (Postfix) with ESMTPA id C4927260B96; Fri, 11 Apr 2014 09:46:45 -0300 (ART) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_e39bdb131aaeaea4c22a49c94da04bd6" Date: Fri, 11 Apr 2014 18:16:45 +0530 From: jorgecardoso To: undisclosed-recipients:; Subject: uwaga Reply-To: mdhsb@outlook.com Mail-Reply-To: mdhsb@outlook.com Message-ID: <1fca20d376aede97aa26a2c2679fce1e@copetel.com.ar> X-Sender: jorgecardoso@copetel.com.ar User-Agent: Roundcube Webmail/RCMAIL_VERSION --=_e39bdb131aaeaea4c22a49c94da04bd6 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Biuro Promocji pojawiły Microsoft wiadomości e-mail dziewięćset tysięcy dolarów. Wyślij dane, nazwisko, numer telefonu i kraj --=_e39bdb131aaeaea4c22a49c94da04bd6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Biuro Promocji pojawi=C5=82y Microsoft wiadomo=C5=9Bci e-mail dziewi=C4= =99=C4=87set tysi=C4=99cy dolarów. Wy=C5=9Blij dane, nazwisko, numer= telefonu i kraj

--=_e39bdb131aaeaea4c22a49c94da04bd6-- From w3c-dist-auth-request@listhub.w3.org Tue Apr 15 07:10:08 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3391A0318 for ; Tue, 15 Apr 2014 07:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVRhdDCMaYqS for ; Tue, 15 Apr 2014 07:10:03 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A8AC91A01D4 for ; Tue, 15 Apr 2014 07:10:03 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1Wa41i-00042D-Uz for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Apr 2014 14:07:54 +0000 Resent-Date: Tue, 15 Apr 2014 14:07:54 +0000 Resent-Message-Id: Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1Wa41i-00041U-DD for w3c-dist-auth@listhub.w3.org; Tue, 15 Apr 2014 14:07:54 +0000 Received: from daboo.name ([173.13.55.49]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Wa41h-0007dv-D6 for w3c-dist-auth@w3.org; Tue, 15 Apr 2014 14:07:54 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2CC07631838F; Tue, 15 Apr 2014 10:07:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAvaY7sjxnbV; Tue, 15 Apr 2014 10:07:21 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id C73DA6318379; Tue, 15 Apr 2014 10:07:18 -0400 (EDT) Date: Tue, 15 Apr 2014 10:06:05 -0400 From: Cyrus Daboo To: Peter Saint-Andre , Ken Murchison , WebDAV Message-ID: <11FDB0DF307670D516D54629@caldav.corp.apple.com> In-Reply-To: <53458A0B.9080309@stpeter.im> References: <53457537.8040205@andrew.cmu.edu> <5345771C.9090909@stpeter.im> <534578FD.5070504@andrew.cmu.edu> <53458A0B.9080309@stpeter.im> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2467 Received-SPF: none client-ip=173.13.55.49; envelope-from=cyrus@daboo.name; helo=daboo.name X-W3C-Hub-Spam-Status: No, score=-3.8 X-W3C-Hub-Spam-Report: AWL=-3.125, RP_MATCHES_RCVD=-0.652 X-W3C-Scan-Sig: lisa.w3.org 1Wa41h-0007dv-D6 08b8260fbfa88ca8a335b36eb0bb0efc X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV PUSH based on RFC 6202 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13422 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Hi Peter, --On April 9, 2014 at 10:57:31 AM -0700 Peter Saint-Andre wrote: > Well, I mention this Internet-Draft mostly to show that people have been > thinking about this problem for at least 10 years. You could use XMPP for > such notifications, although it might depend on what kinds of endpoints > you're trying to support (e.g., do they or can they do XMPP). Other > options are technologies like pubsubhubbub. There are also lots of > proprietary technologies for such notifications, although of course we > don't want anything proprietary. However IMHO long polling is not the > best approach these days - we wrote RFC 6202 mostly to say that long > polling is a bad idea and that it's better to use WebSockets instead (RFC > 6455). But WebSockets only gives you "TCP for the Web" and you'd need to > define some kind of application over WebSocket in order to get anything > done (examples are SIP over WebSocket, XMPP over WebSocket, etc.). So the big issue here of course is that nothing has happend to standardize a general solution to push, so we do have proprietary solutions. There are really two parts to what we would like to do here: 1) Recognizing that multiple proprietary solutions exist today, clients currently have to "probe" a server (or use hard-coded defaults based on hostnames) to determine which one is actually supported. What would be better is if there was a standard way for servers to advertise support for any type of push protocol. That could simply be specific DAV header items, or a WebDAV property that enumerates what is supported (be it proprietary or any new standard approach). 2) Some client folks have expressed interest in having a base "minimum to implement" standard push protocol that would suffice for at least desktop-based clients (recognizing that the mobile environment is a lot trickier to deal with - though of course no less important these days). The initial thought we had was to go the route of IMAP's IDLE command - i.e., make use of the existing protocol to provide an in-band solution. Long-polling with the WebDAV sync REPORT would seem like the best fit for that approach - but operational concerns with that obviously come into play. Now, if the time is ripe for the IETF to tackle the push problem in a more generic way, then lets do that - but I'm not optimistic given the past history and the current diversity of proprietary solutions. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Thu Apr 17 02:48:15 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F68F1A030E for ; Thu, 17 Apr 2014 02:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.274 X-Spam-Level: X-Spam-Status: No, score=-9.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYbrSEL3Fz2g for ; Thu, 17 Apr 2014 02:48:11 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6761A02F4 for ; Thu, 17 Apr 2014 02:48:10 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1Waita-0000GN-4y for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Apr 2014 09:46:14 +0000 Resent-Date: Thu, 17 Apr 2014 09:46:14 +0000 Resent-Message-Id: Received: from jessica.w3.org ([128.30.52.49]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WaitR-000098-JV for w3c-dist-auth@listhub.w3.org; Thu, 17 Apr 2014 09:46:05 +0000 Received: from www-data by jessica.w3.org with local (Exim 4.72) (envelope-from ) id 1WaitR-0001kD-HR for w3c-dist-auth@listhub.w3.org; Thu, 17 Apr 2014 09:46:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WaaGn-00060r-4r for w3c-dist-auth@listhub.w3.org; Thu, 17 Apr 2014 00:33:37 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WaaGm-0006mm-46 for w3c-dist-auth@w3.org; Thu, 17 Apr 2014 00:33:37 +0000 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 904C72097D for ; Wed, 16 Apr 2014 20:33:15 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 16 Apr 2014 20:33:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=mesmtp; bh=5cFYNbyvS0XuvQmM1HtGCMl RWkY=; b=kouRYkEIGfR5tC9aADrUN2F1AH4+UrzR91C/Af/XKcRXJyzAsCjxW+G zRjYGuqVuxQzevDuC/wigq3jg1zpiJTFqpM3IYpZjEN64RDz/V2OAfI2Xxw+k1eP RQ6E5/FhX85yLQN5D6YOg4nLBJZajZpwbOatWtmIIFMhD+4pcO/U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:content-type:content-transfer-encoding; s=smtpout; bh=5 cFYNbyvS0XuvQmM1HtGCMlRWkY=; b=nWlr3NlelYbv6KYs+IW2GY+LFqOZEXYTN EFqTVAfqqaCAevngvrsZ19IXQbm/04+ayOCzqjjBGHP4+xZ3XwluyPzknpVIrMgh lOupCR/pJ2/YMi0LUJmpwHy+yzVLRmFEV3k9CtugWTBiNweTyzAyttVpWKyJny6O lPrLdMhWwU= X-Sasl-enc: PQCX1xD+OLGFylQKPaNW7BVFoqZXqd5d3968xsJrxiY4 1397694795 Received: from evertbook3.local (unknown [174.113.250.108]) by mail.messagingengine.com (Postfix) with ESMTPA id 3CB55C00005; Wed, 16 Apr 2014 20:33:15 -0400 (EDT) Message-ID: <534F214E.60501@evertpot.com> Date: Wed, 16 Apr 2014 20:33:18 -0400 From: Evert Pot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: vcarddav@ietf.org, w3c-dist-auth@w3.org, contacts-pc-l@lists.calconnect.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=66.111.4.29; envelope-from=me@evertpot.com; helo=out5-smtp.messagingengine.com X-W3C-Hub-Spam-Status: No, score=-0.8 X-W3C-Hub-Spam-Report: DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1WaaGm-0006mm-46 efa67d0c5ad3e1ab3a30d8b7555b1cf0 X-caa-id: 2de7603682 X-Original-To: w3c-dist-auth@w3.org Subject: WebDAV Collection Sharing Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13424 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Hi All, At CalConnect, we are looking to standardize a way for users to share Address Book and Calendar collections with each other. As of right now, there's a specification to enable this for Calendars, written by Cyrus Daboo. This is currently already implemented by a wide range of both clients and servers. The specification consists of two parts, and can be found here: http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-sharing.txt http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-notifications.txt On a very high level, this specification operates as follows: * A user (owner of a calendar) invites a number of people, by email address using a POST method on a calendar collection. * The invitee receives a notification-resource in a notification- collection with the invite inforomation. * The invitee can then choose to accept or reject the invitation with a second POST request. * The owner of the calendar receive a reply in his/her notification collection. * If the invitee accepted in the invite, the calendar now also appears in the invitees calendar home. This all works pretty well. Recently we've started talking about implementing something similar for CardDAV, allowing users to also share Address Books. Rather than creating both a Card- and CalDAV document for this, we felt that it may make sense to create something that effectively describes "WebDAV Collection Sharing" in general. We felt that there could be a wider interest for this, as many modern file-sharing services use a similar (but non-standard) systems to achieve the same thing. One issue that did pop up, is that there is some overlap with what BIND does (rfc5842), but we're not using it. A few reasons for this is: * Due to the invite-based system, the server is responsible for creating the binding. * WebDAV properties may not be shared across instances. A user can give his/her instance of a calendar a different displayname, without affecting the original. * In some cases, properties should be shared. A calendar-timezone property should be updated across instances for consistency. * Specifically relating to calendars: even resources within the calendar may vary depending on the accessed instance. We'd love to hear your feedback and concerns about this. Regards, Evert Pot From w3c-dist-auth-request@listhub.w3.org Thu Apr 17 02:48:17 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4471A02F4 for ; Thu, 17 Apr 2014 02:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASUtza-wQ8MO for ; Thu, 17 Apr 2014 02:48:13 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C73AC1A001F for ; Thu, 17 Apr 2014 02:48:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1WaitS-0000Ak-3Q for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Apr 2014 09:46:06 +0000 Resent-Date: Thu, 17 Apr 2014 09:46:06 +0000 Resent-Message-Id: Received: from jessica.w3.org ([128.30.52.49]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WaitQ-000070-SM for w3c-dist-auth@listhub.w3.org; Thu, 17 Apr 2014 09:46:04 +0000 Received: from www-data by jessica.w3.org with local (Exim 4.72) (envelope-from ) id 1WaitQ-0001jr-Q0 for w3c-dist-auth@listhub.w3.org; Thu, 17 Apr 2014 09:46:04 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WaQkG-0006uj-Nm for w3c-dist-auth@listhub.w3.org; Wed, 16 Apr 2014 14:23:24 +0000 Received: from wmauth3.doit.wisc.edu ([144.92.197.226] helo=smtpauth3.wiscmail.wisc.edu) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_MD5:16) (Exim 4.72) (envelope-from ) id 1WaQkD-0003Ru-Py for w3c-dist-auth@w3.org; Wed, 16 Apr 2014 14:23:24 +0000 MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4400700NCTM600@smtpauth3.wiscmail.wisc.edu> for w3c-dist-auth@w3.org; Wed, 16 Apr 2014 09:22:55 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.16.141516, SenderIP=0.0.0.0 Received: from [127.0.0.1] (boson.doit.wisc.edu [128.104.17.84]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N4400I00NY4GM30@smtpauth3.wiscmail.wisc.edu>; Wed, 16 Apr 2014 09:22:52 -0500 (CDT) Message-id: <534E923A.6020404@wisc.edu> Date: Wed, 16 Apr 2014 09:22:50 -0500 From: Jesse Thompson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 To: w3c-dist-auth@w3.org Cc: tc-push-l@lists.calconnect.org References: <53457537.8040205@andrew.cmu.edu> In-reply-to: <53457537.8040205@andrew.cmu.edu> Received-SPF: pass client-ip=144.92.197.226; envelope-from=jesse.thompson@wisc.edu; helo=smtpauth3.wiscmail.wisc.edu X-W3C-Hub-Spam-Status: No, score=-0.7 X-W3C-Hub-Spam-Report: RP_MATCHES_RCVD=-0.652, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1WaQkD-0003Ru-Py db2af1728131beda8defe925f21539b6 X-caa-id: 2737b3bbb6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [tc-push-l] WebDAV PUSH based on RFC 6202 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13423 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: I chimed in on this conversation on the tc-push-l@lists.calconnect.org list. Cyrus asked me to post my comments here. (I tried to refactor content from multiple messages for context, but I apologize if it is still a bit jumbled - and for top posting) I don't have much knowledge in implementing push/realtime HTTP other than installing various web clients on top of Ejabberd using XEP-0206 (XMPP over BOSH) and deciding not to use XEP-0025 (Jabber XMPP Polling at UW-Madison. http://xmpp.org/extensions/xep-0206.html http://xmpp.org/extensions/xep-0025.html Otherwise, what I am saying is based on what I have read or what others have told me, so take it with a grain of salt. I suggested looking at the work being done on websockets for XMPP. Not that XMPP should be used as the protocol, but rather that they might have documented some of the same hurdles you are trying to overcome. http://tools.ietf.org/html/draft-ietf-xmpp-websocket-02 From my standpoint as a calendar server administrator, I shudder to think of the impact of having tens of thousands of clients keeping connections open to my main Apache preforking servers. The root of my recommendation is not to say whether long polling is better or worse than web sockets, but rather to suggest the option to have the clients make these long running requests to a secondary URI. This would allow server administrators to handle those request with a web server specifically optimized for that type of connection. In response to Brad, who brought up the topic of what data is sent over the websocket, I said that I would consider it an implementation detail as to what information (and how much) to send over the web socket connection vs. telling the client to sync via the normal connection. The people I know who have implemented realtime web apps generally ditch the idea of long polling because it doesn't scale. They use web sockets, but they have clients connect on a different connection than the main web server that is serving normal requests. Not all web servers are non-blocking/asynchronous, so you might not be able/willing to completely replace existing web servers and downstream reverse proxy servers. The 2-web server strategy allows you to add in push capabilities while remaining backwards compatible, as well as segregate load. If your web sockets server becomes overloaded, clients should be able to fall back on the non-push capabilities. For an example, I know the guys that built https://www.thegamecrafter.com/ Their main web servers are not handling any of the web sockets connections. But their application is still capable of pushing real time updates. They accomplish this by having the client (javascript) maintain a connection to https://www.firebase.com/ to receive those updates. Firebase is an example of a cloud hosting service for realtime apps. It allows you to outsource the realtime/push capabilities of your apps. I don't know if something like that would be appropriate for calendaring, but it might be an instructive exercise to proof-of-concept leveraging this type of solution for your work on tc-push. It might at least lead you to the answers to the questions your were asking. Anyway, I hope this is helpful information. -- Jesse Thompson Technical Consultant - Messaging Productivity and Collaboration Solutions Division of Information Technology University of Wisconsin–Madison On 4/9/2014 11:28 AM, Ken Murchison wrote: > All, > > The Calendaring and Scheduling Consortium (CalConnect) is looking at > ways to have a server "push" changes made to a calendar/addressbook > collection out to a client. There are already a few proprietary > mechanisms in place for doing so, but we would like to come up with > something standard that would be relatively simple to implement for both > clients and servers and would be applicable to any DAV collection. > > One idea that we are toying with is to leverage the existing > DAV:sync-collection REPORT > and HTTP long-polling . I > spent a few hours coding up a prototype version of HTTP long-polling and > HTTP streaming for DAV:sync-collection REPORTs in my server which I > describe below. We (CalConnect) are considering using this approach or > something similar as a starting point and we are interested in any/all > feedback from the larger DAV community, including: > > * Is this approach sane, is there a better way, or is any type of push > via HTTP a hopeless endeavor? > * Will this approach (or anything similar) break in the face of > intermediaries? > * Will existing HTTP/DAV stacks be able to handle long-polling and/or > streaming? > * Should the server advertise its ability to long-poll and/or stream > for the client to discover or simply leave it up to the client try > one or both and see what the server does, as is the case in my > implementation below? > > > Long-polling: > > For long-polling, I leveraged the HTTP Prefer header > and its 'wait' > preference as a way for the client to tell the server that it wants to > long poll. If the client doesn't specify a DAV:sync-token (initial > sync) or if there have been changes since the specified token, then the > server will respond immediately. Otherwise, it will only respond if a > change is detected or when the timeout expires, whichever comes first. > In the case of a delayed response, I issue a 100 (Continue) provisional > response with a Preference-Applied header to notify the client that the > server is indeed long-polling as requested. This provisional response > may or may not be necessary. In my implementation I wait 1 sec less > than specified to account for processing time so I don't go over what > the client expects. > > Streaming: > > The client can request streaming behavior by simply including an Accept > header with the 'multipart/mixed' media type (I chose this subtype for > lack of something better - we could use the existing x-mixed-replace or > create our own). The client can also specify a timeout for the > streaming using the same 'wait' preference as used for long-polling. In > the absence of a client-requested timeout, the server will continue to > add body parts until the client disconnects or the server hits some > internal timeout. Because a multipart response allows for an epilogue > following the final delimiter, a client can't just rely on the > delimiters to detect the end of the response. Therefore, the server > MUST use either chunked TE or close the connection following the > multipart response. In my example below, I close-delimit the response > for better readability. FWIW, I think the same holds true for > multipart/byteranges responses. In my implementation I include a > Content-Length header in the body-part headers so the client can detect > the end of the XML body without looking for the trailing delimiter > (mainly because the trailing delimiter doesn't appear until the next > body part). > > Examples: > > Here is an example of long-polling with 3 requests (I added superfluous > Date headers to show the timing). The first request returns immediately > due to a pre-existing change, the second returns upon detecting a > subsequent change some 95 sec later, and the third times out after 3 min. > > REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 > Host: localhost > Date: Wed, 30 Oct 2013 18:11:11 GMT > Content-Type: application/xml > Content-Length: 260 > Prefer: return=minimal, wait=180 > > > > http://cyrusimap.org/ns/sync/1368011844-354 > 1 > > > > HTTP/1.1 207 Multi-Status > Date: Wed, 30 Oct 2013 18:11:11 GMT > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal, wait=180 > Content-Type: application/xml; charset=utf-8 > Content-Length: 421 > > > > > /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics > > > HTTP/1.1 200 OK > > > http://cyrusimap.org/ns/sync/1368011844-355 > > > > > REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 > Host: localhost > Date: Wed, 30 Oct 2013 18:11:12 GMT > Content-Type: application/xml > Content-Length: 260 > Prefer: return=minimal, wait=180 > > > > http://cyrusimap.org/ns/sync/1368011844-355 > 1 > > > > HTTP/1.1 100 Continue > Date: Wed, 30 Oct 2013 18:11:12 GMT > Preference-Applied: wait=180 > > HTTP/1.1 207 Multi-Status > Date: Wed, 30 Oct 2013 18:12:47 GMT > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal, wait=180 > Content-Type: application/xml; charset=utf-8 > Content-Length: 375 > > > > > /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics > HTTP/1.1 404 Not Found > > http://cyrusimap.org/ns/sync/1368011844-356 > > > > > REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 > Host: localhost > Date: Wed, 30 Oct 2013 18:12:48 GMT > Content-Type: application/xml > Content-Length: 260 > Prefer: return=minimal, wait=180 > > > > http://cyrusimap.org/ns/sync/1368011844-356 > 1 > > > > HTTP/1.1 100 Continue > Date: Wed, 30 Oct 2013 18:12:48 GMT > Preference-Applied: wait=180 > > HTTP/1.1 207 Multi-Status > Date: Wed, 30 Oct 2013 18:15:47 GMT > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal, wait=180 > Content-Type: application/xml; charset=utf-8 > Content-Length: 202 > > > > http://cyrusimap.org/ns/sync/1368011844-356 > > > > > Here is the same sequence of events utilizing streaming with a timeout: > > REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 > Host: localhost > Date: Wed, 30 Oct 2013 18:11:06 GMT > Content-Type: application/xml > Content-Length: 260 > Prefer: return=minimal, wait=180 > Accept: multipart/mixed > > > > http://cyrusimap.org/ns/sync/1368011844-354 > 1 > > > > HTTP/1.1 207 Multi-Status > Connection: close > Date: Wed, 30 Oct 2013 18:11:06 GMT > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal, wait=180 > Content-Type: multipart/mixed; > boundary="localhost-29378-1383156666-1025603243" > > This is a message with multiple parts in MIME format. > > --localhost-29378-1383156666-1025603243 > Date: Wed, 30 Oct 2013 18:11:06 GMT > Content-Type: application/xml; charset=utf-8 > Content-Length: 421 > > > > > /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics > > > HTTP/1.1 200 OK > > > http://cyrusimap.org/ns/sync/1368011844-355 > > > --localhost-29378-1383156666-1025603243 > Date: Wed, 30 Oct 2013 18:12:47 GMT > Content-Type: application/xml; charset=utf-8 > Content-Length: 375 > > > > > /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics > HTTP/1.1 404 Not Found > > http://cyrusimap.org/ns/sync/1368011844-356 > > > --localhost-29378-1383156666-1025603243 > Date: Wed, 30 Oct 2013 18:14:05 GMT > Content-Type: application/xml; charset=utf-8 > Content-Length: 202 > > > > http://cyrusimap.org/ns/sync/1368011844-356 > > > --localhost-29378-1383156666-1025603243-- > > End of MIME multipart body. > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > > > _______________________________________________ > tc-push-l mailing list > tc-push-l@lists.calconnect.org > http://lists.calconnect.org/mailman/listinfo/tc-push-l > From w3c-dist-auth-request@listhub.w3.org Sat Apr 19 02:52:53 2014 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5CE1A00D8 for ; Sat, 19 Apr 2014 02:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.274 X-Spam-Level: X-Spam-Status: No, score=-5.274 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX5OYqtge8GG for ; Sat, 19 Apr 2014 02:52:47 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A7AB71A00CD for ; Sat, 19 Apr 2014 02:52:47 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1WbRuo-0007y3-2E for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Apr 2014 09:50:30 +0000 Resent-Date: Sat, 19 Apr 2014 09:50:30 +0000 Resent-Message-Id: Received: from jessica.w3.org ([128.30.52.49]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WbRun-0007wi-B8 for w3c-dist-auth@listhub.w3.org; Sat, 19 Apr 2014 09:50:29 +0000 Received: from www-data by jessica.w3.org with local (Exim 4.72) (envelope-from ) id 1WbRun-0003rX-87 for w3c-dist-auth@listhub.w3.org; Sat, 19 Apr 2014 09:50:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1WbGtv-0006Fb-5z for w3c-dist-auth@listhub.w3.org; Fri, 18 Apr 2014 22:04:51 +0000 Received: from mail-ee0-f47.google.com ([74.125.83.47]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1WbGts-0002yM-MY for w3c-dist-auth@w3.org; Fri, 18 Apr 2014 22:04:51 +0000 Received: by mail-ee0-f47.google.com with SMTP id b15so1966104eek.34 for ; Fri, 18 Apr 2014 15:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=KpiDKZvqKmXIABDkMEP+bbmRVTTytFcBwUDdp98hw5g=; b=rowjrE43fBwgPNtOLsVMwqoEvdj7Fl9BiryekmTaRoSFCpoNEVzY3+NN73JYEevhT5 KfaHuv+AoVUnecFVlosnRz+8OQL6m+ufFfmf+g2/qeYhwJeBstJ0ruJCqt87pf0Pj/WJ SGWhmXGUPI/4AFD1SfLJtQDnKOl1otsWQx+yKFJYxYRtvwMuOsrbjO7tICm55vhcSlO8 LielfaxtHx72qpFe/qx5fzuz37bdw6EMZofRXagA/et5x0HT6RcduTPYoDc9GR7p8jYx Pn+GC+NlG+2D4TswGpWuVet7FVr10HBOyeVPJhC4gbu7H5I8ykq99L0E4zNch7buCJ+x 84Tg== X-Received: by 10.15.98.68 with SMTP id bi44mr4309380eeb.97.1397858661816; Fri, 18 Apr 2014 15:04:21 -0700 (PDT) Received: from smtp.dmfs.org (pD9EA6D27.dip0.t-ipconnect.de. [217.234.109.39]) by mx.google.com with ESMTPSA id 48sm80146529eee.2.2014.04.18.15.04.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 18 Apr 2014 15:04:20 -0700 (PDT) Sender: Marten Gajda Received: from [127.0.0.1] (mephisto.fritz.box [192.168.2.18]) by smtp.dmfs.org (Postfix) with ESMTPSA id C8D197E3; Sat, 19 Apr 2014 00:04:17 +0200 (CEST) Message-ID: <5351A15F.5080101@dmfs.org> Date: Sat, 19 Apr 2014 00:04:15 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: tc-push-l@lists.calconnect.org References: <53457537.8040205@andrew.cmu.edu> <534E923A.6020404@wisc.edu> In-Reply-To: <534E923A.6020404@wisc.edu> Content-Type: multipart/alternative; boundary="------------040500050603070109070003" Received-SPF: pass client-ip=74.125.83.47; envelope-from=marten.gajda@googlemail.com; helo=mail-ee0-f47.google.com X-W3C-Hub-Spam-Status: No, score=-0.7 X-W3C-Hub-Spam-Report: DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1WbGts-0002yM-MY 769a8bbf3819ae5fe0d393395bbeae2f X-caa-id: 35cd94a744 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [tc-push-l] WebDAV PUSH based on RFC 6202 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13425 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: This is a multi-part message in MIME format. --------------040500050603070109070003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, today, "AwareDAV" has been brought to my attention, see http://www2005.org/docs/p180.pdf Does anyone have any experience with it? cheers Marten Am 16.04.2014 16:22, schrieb Jesse Thompson: > I chimed in on this conversation on thetc-push-l@lists.calconnect.org > list. Cyrus asked me to post my comments here. (I tried to refactor > content from multiple messages for context, but I apologize if it is > still a bit jumbled - and for top posting) > > I don't have much knowledge in implementing push/realtime HTTP other > than installing various web clients on top of Ejabberd using XEP-0206 > (XMPP over BOSH) and deciding not to use XEP-0025 (Jabber XMPP Polling > at UW-Madison. > http://xmpp.org/extensions/xep-0206.html > http://xmpp.org/extensions/xep-0025.html > > Otherwise, what I am saying is based on what I have read or what others > have told me, so take it with a grain of salt. > > I suggested looking at the work being done on websockets for XMPP. Not > that XMPP should be used as the protocol, but rather that they might > have documented some of the same hurdles you are trying to overcome. > http://tools.ietf.org/html/draft-ietf-xmpp-websocket-02 > > From my standpoint as a calendar server administrator, I shudder to > think of the impact of having tens of thousands of clients keeping > connections open to my main Apache preforking servers. The root of my > recommendation is not to say whether long polling is better or worse > than web sockets, but rather to suggest the option to have the clients > make these long running requests to a secondary URI. This would allow > server administrators to handle those request with a web server > specifically optimized for that type of connection. > > In response to Brad, who brought up the topic of what data is sent over > the websocket, I said that I would consider it an implementation detail > as to what information (and how much) to send over the web socket > connection vs. telling the client to sync via the normal connection. > > The people I know who have implemented realtime web apps generally ditch > the idea of long polling because it doesn't scale. They use web > sockets, but they have clients connect on a different connection than > the main web server that is serving normal requests. > > Not all web servers are non-blocking/asynchronous, so you might not be > able/willing to completely replace existing web servers and downstream > reverse proxy servers. The 2-web server strategy allows you to add in > push capabilities while remaining backwards compatible, as well as > segregate load. If your web sockets server becomes overloaded, clients > should be able to fall back on the non-push capabilities. > > For an example, I know the guys that built > https://www.thegamecrafter.com/ Their main web servers are not handling > any of the web sockets connections. But their application is still > capable of pushing real time updates. They accomplish this by having > the client (javascript) maintain a connection to > https://www.firebase.com/ to receive those updates. > > Firebase is an example of a cloud hosting service for realtime apps. It > allows you to outsource the realtime/push capabilities of your apps. I > don't know if something like that would be appropriate for calendaring, > but it might be an instructive exercise to proof-of-concept leveraging > this type of solution for your work on tc-push. It might at least lead > you to the answers to the questions your were asking. > > Anyway, I hope this is helpful information. > > -- > Jesse Thompson > Technical Consultant - Messaging > Productivity and Collaboration Solutions > Division of Information Technology > University of Wisconsin–Madison > > On 4/9/2014 11:28 AM, Ken Murchison wrote: >> All, >> >> The Calendaring and Scheduling Consortium (CalConnect) is looking at >> ways to have a server "push" changes made to a calendar/addressbook >> collection out to a client. There are already a few proprietary >> mechanisms in place for doing so, but we would like to come up with >> something standard that would be relatively simple to implement for both >> clients and servers and would be applicable to any DAV collection. >> >> One idea that we are toying with is to leverage the existing >> DAV:sync-collection REPORT >> and HTTP long-polling. I >> spent a few hours coding up a prototype version of HTTP long-polling and >> HTTP streaming for DAV:sync-collection REPORTs in my server which I >> describe below. We (CalConnect) are considering using this approach or >> something similar as a starting point and we are interested in any/all >> feedback from the larger DAV community, including: >> >> * Is this approach sane, is there a better way, or is any type of push >> via HTTP a hopeless endeavor? >> * Will this approach (or anything similar) break in the face of >> intermediaries? >> * Will existing HTTP/DAV stacks be able to handle long-polling and/or >> streaming? >> * Should the server advertise its ability to long-poll and/or stream >> for the client to discover or simply leave it up to the client try >> one or both and see what the server does, as is the case in my >> implementation below? >> >> >> Long-polling: >> >> For long-polling, I leveraged the HTTP Prefer header >> and its 'wait' >> preference as a way for the client to tell the server that it wants to >> long poll. If the client doesn't specify a DAV:sync-token (initial >> sync) or if there have been changes since the specified token, then the >> server will respond immediately. Otherwise, it will only respond if a >> change is detected or when the timeout expires, whichever comes first. >> In the case of a delayed response, I issue a 100 (Continue) provisional >> response with a Preference-Applied header to notify the client that the >> server is indeed long-polling as requested. This provisional response >> may or may not be necessary. In my implementation I wait 1 sec less >> than specified to account for processing time so I don't go over what >> the client expects. >> >> Streaming: >> >> The client can request streaming behavior by simply including an Accept >> header with the 'multipart/mixed' media type (I chose this subtype for >> lack of something better - we could use the existing x-mixed-replace or >> create our own). The client can also specify a timeout for the >> streaming using the same 'wait' preference as used for long-polling. In >> the absence of a client-requested timeout, the server will continue to >> add body parts until the client disconnects or the server hits some >> internal timeout. Because a multipart response allows for an epilogue >> following the final delimiter, a client can't just rely on the >> delimiters to detect the end of the response. Therefore, the server >> MUST use either chunked TE or close the connection following the >> multipart response. In my example below, I close-delimit the response >> for better readability. FWIW, I think the same holds true for >> multipart/byteranges responses. In my implementation I include a >> Content-Length header in the body-part headers so the client can detect >> the end of the XML body without looking for the trailing delimiter >> (mainly because the trailing delimiter doesn't appear until the next >> body part). >> >> Examples: >> >> Here is an example of long-polling with 3 requests (I added superfluous >> Date headers to show the timing). The first request returns immediately >> due to a pre-existing change, the second returns upon detecting a >> subsequent change some 95 sec later, and the third times out after 3 min. >> >> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >> Host: localhost >> Date: Wed, 30 Oct 2013 18:11:11 GMT >> Content-Type: application/xml >> Content-Length: 260 >> Prefer: return=minimal, wait=180 >> >> >> >> http://cyrusimap.org/ns/sync/1368011844-354 >> 1 >> >> >> >> HTTP/1.1 207 Multi-Status >> Date: Wed, 30 Oct 2013 18:11:11 GMT >> Vary: Accept-Encoding, Brief, Prefer >> Preference-Applied: return=minimal, wait=180 >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 421 >> >> >> >> >> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >> >> >> HTTP/1.1 200 OK >> >> >> http://cyrusimap.org/ns/sync/1368011844-355 >> >> >> >> >> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >> Host: localhost >> Date: Wed, 30 Oct 2013 18:11:12 GMT >> Content-Type: application/xml >> Content-Length: 260 >> Prefer: return=minimal, wait=180 >> >> >> >> http://cyrusimap.org/ns/sync/1368011844-355 >> 1 >> >> >> >> HTTP/1.1 100 Continue >> Date: Wed, 30 Oct 2013 18:11:12 GMT >> Preference-Applied: wait=180 >> >> HTTP/1.1 207 Multi-Status >> Date: Wed, 30 Oct 2013 18:12:47 GMT >> Vary: Accept-Encoding, Brief, Prefer >> Preference-Applied: return=minimal, wait=180 >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 375 >> >> >> >> >> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >> HTTP/1.1 404 Not Found >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> >> >> >> >> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >> Host: localhost >> Date: Wed, 30 Oct 2013 18:12:48 GMT >> Content-Type: application/xml >> Content-Length: 260 >> Prefer: return=minimal, wait=180 >> >> >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> 1 >> >> >> >> HTTP/1.1 100 Continue >> Date: Wed, 30 Oct 2013 18:12:48 GMT >> Preference-Applied: wait=180 >> >> HTTP/1.1 207 Multi-Status >> Date: Wed, 30 Oct 2013 18:15:47 GMT >> Vary: Accept-Encoding, Brief, Prefer >> Preference-Applied: return=minimal, wait=180 >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 202 >> >> >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> >> >> >> >> Here is the same sequence of events utilizing streaming with a timeout: >> >> REPORT /dav/calendars/user/ken/Default/ HTTP/1.1 >> Host: localhost >> Date: Wed, 30 Oct 2013 18:11:06 GMT >> Content-Type: application/xml >> Content-Length: 260 >> Prefer: return=minimal, wait=180 >> Accept: multipart/mixed >> >> >> >> http://cyrusimap.org/ns/sync/1368011844-354 >> 1 >> >> >> >> HTTP/1.1 207 Multi-Status >> Connection: close >> Date: Wed, 30 Oct 2013 18:11:06 GMT >> Vary: Accept-Encoding, Brief, Prefer >> Preference-Applied: return=minimal, wait=180 >> Content-Type: multipart/mixed; >> boundary="localhost-29378-1383156666-1025603243" >> >> This is a message with multiple parts in MIME format. >> >> --localhost-29378-1383156666-1025603243 >> Date: Wed, 30 Oct 2013 18:11:06 GMT >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 421 >> >> >> >> >> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >> >> >> HTTP/1.1 200 OK >> >> >> http://cyrusimap.org/ns/sync/1368011844-355 >> >> >> --localhost-29378-1383156666-1025603243 >> Date: Wed, 30 Oct 2013 18:12:47 GMT >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 375 >> >> >> >> >> /dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics >> HTTP/1.1 404 Not Found >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> >> >> --localhost-29378-1383156666-1025603243 >> Date: Wed, 30 Oct 2013 18:14:05 GMT >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 202 >> >> >> >> http://cyrusimap.org/ns/sync/1368011844-356 >> >> >> --localhost-29378-1383156666-1025603243-- >> >> End of MIME multipart body. >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> >> >> >> _______________________________________________ >> tc-push-l mailing list >> tc-push-l@lists.calconnect.org >> http://lists.calconnect.org/mailman/listinfo/tc-push-l >> > _______________________________________________ > tc-push-l mailing list > tc-push-l@lists.calconnect.org > http://lists.calconnect.org/mailman/listinfo/tc-push-l -- *Marten Gajda* Schandauer StraĂźe 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 --------------040500050603070109070003 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all,

today, "AwareDAV" has been brought to my attention, see http://www2005.org/docs/p180.pdf
Does anyone have any experience with it?

cheers

Marten


Am 16.04.2014 16:22, schrieb Jesse Thompson:
I chimed in on this conversation on the tc-push-l@lists.calconnect.org 
list.  Cyrus asked me to post my comments here.  (I tried to refactor 
content from multiple messages for context, but I apologize if it is 
still a bit jumbled - and for top posting)

I don't have much knowledge in implementing push/realtime HTTP other 
than installing various web clients on top of Ejabberd using XEP-0206 
(XMPP over BOSH) and deciding not to use XEP-0025 (Jabber XMPP Polling 
at UW-Madison.
http://xmpp.org/extensions/xep-0206.html
http://xmpp.org/extensions/xep-0025.html

Otherwise, what I am saying is based on what I have read or what others 
have told me, so take it with a grain of salt.

I suggested looking at the work being done on websockets for XMPP.  Not 
that XMPP should be used as the protocol, but rather that they might 
have documented some of the same hurdles you are trying to overcome.
http://tools.ietf.org/html/draft-ietf-xmpp-websocket-02

 From my standpoint as a calendar server administrator, I shudder to 
think of the impact of having tens of thousands of clients keeping 
connections open to my main Apache preforking servers.  The root of my 
recommendation is not to say whether long polling is better or worse 
than web sockets, but rather to suggest the option to have the clients 
make these long running requests to a secondary URI.  This would allow 
server administrators to handle those request with a web server 
specifically optimized for that type of connection.

In response to Brad, who brought up the topic of what data is sent over 
the websocket, I said that I would consider it an implementation detail 
as to what information (and how much) to send over the web socket 
connection vs. telling the client to sync via the normal connection.

The people I know who have implemented realtime web apps generally ditch 
the idea of long polling because it doesn't scale.  They use web 
sockets, but they have clients connect on a different connection than 
the main web server that is serving normal requests.

Not all web servers are non-blocking/asynchronous, so you might not be 
able/willing to completely replace existing web servers and downstream 
reverse proxy servers.  The 2-web server strategy allows you to add in 
push capabilities while remaining backwards compatible, as well as 
segregate load.  If your web sockets server becomes overloaded, clients 
should be able to fall back on the non-push capabilities.

For an example, I know the guys that built 
https://www.thegamecrafter.com/  Their main web servers are not handling 
any of the web sockets connections.  But their application is still 
capable of pushing real time updates.  They accomplish this by having 
the client (javascript) maintain a connection to 
https://www.firebase.com/ to receive those updates.

Firebase is an example of a cloud hosting service for realtime apps.  It 
allows you to outsource the realtime/push capabilities of your apps.  I 
don't know if something like that would be appropriate for calendaring, 
but it might be an instructive exercise to proof-of-concept leveraging 
this type of solution for your work on tc-push.  It might at least lead 
you to the answers to the questions your were asking.

Anyway, I hope this is helpful information.

--
Jesse Thompson
Technical Consultant - Messaging
Productivity and Collaboration Solutions
Division of Information Technology
University of Wisconsin–Madison

On 4/9/2014 11:28 AM, Ken Murchison wrote:

All,

The Calendaring and Scheduling Consortium (CalConnect) is looking at
ways to have a server "push" changes made to a calendar/addressbook
collection out to a client.  There are already a few proprietary
mechanisms in place for doing so, but we would like to come up with
something standard that would be relatively simple to implement for both
clients and servers and would be applicable to any DAV collection.

One idea that we are toying with is to leverage the existing
DAV:sync-collection REPORT <http://datatracker.ietf.org/doc/rfc6578/>
and HTTP long-polling <http://datatracker.ietf.org/doc/rfc6202/>.  I
spent a few hours coding up a prototype version of HTTP long-polling and
HTTP streaming for DAV:sync-collection REPORTs in my server which I
describe below.  We (CalConnect) are considering using this approach or
something similar as a starting point and we are interested in any/all
feedback from the larger DAV community, including:

  * Is this approach sane, is there a better way, or is any type of push
    via HTTP a hopeless endeavor?
  * Will this approach (or anything similar) break in the face of
    intermediaries?
  * Will existing HTTP/DAV stacks be able to handle long-polling and/or
    streaming?
  * Should the server advertise its ability to long-poll and/or stream
    for the client to discover or simply leave it up to the client try
    one or both and see what the server does, as is the case in my
    implementation below?


Long-polling:

For long-polling, I leveraged the HTTP Prefer header
<http://tools.ietf.org/html/draft-snell-http-prefer> and its 'wait'
preference as a way for the client to tell the server that it wants to
long poll.  If the client doesn't specify a DAV:sync-token (initial
sync) or if there have been changes since the specified token, then the
server will respond immediately.  Otherwise, it will only respond if a
change is detected or when the timeout expires, whichever comes first.
In the case of a delayed response, I issue a 100 (Continue) provisional
response with a Preference-Applied header to notify the client that the
server is indeed long-polling as requested.  This provisional response
may or may not be necessary.  In my implementation I wait 1 sec less
than specified to account for processing time so I don't go over what
the client expects.

Streaming:

The client can request streaming behavior by simply including an Accept
header with the 'multipart/mixed' media type (I chose this subtype for
lack of something better - we could use the existing x-mixed-replace or
create our own).  The client can also specify a timeout for the
streaming using the same 'wait' preference as used for long-polling.  In
the absence of a client-requested timeout, the server will continue to
add body parts until the client disconnects or the server hits some
internal timeout.  Because a multipart response allows for an epilogue
following the final delimiter, a client can't just rely on the
delimiters to detect the end of the response.  Therefore, the server
MUST use either chunked TE or close the connection following the
multipart response.  In my example below, I close-delimit the response
for better readability.  FWIW, I think the same holds true for
multipart/byteranges responses.  In my implementation I include a
Content-Length header in the body-part headers so the client can detect
the end of the XML body without looking for the trailing delimiter
(mainly because the trailing delimiter doesn't appear until the next
body part).

Examples:

Here is an example of long-polling with 3 requests (I added superfluous
Date headers to show the timing).  The first request returns immediately
due to a pre-existing change, the second returns upon detecting a
subsequent change some 95 sec later, and the third times out after 3 min.

REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:11 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-354</D:sync-token>
   <D:sync-level>1</D:sync-level>
   <D:prop/>
</C:sync-collection>

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:11:11 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 421

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
   <D:response>
<D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
     <D:propstat>
       <D:prop/>
       <D:status>HTTP/1.1 200 OK</D:status>
     </D:propstat>
   </D:response>
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
</D:multistatus>



REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:12 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
   <D:sync-level>1</D:sync-level>
   <D:prop/>
</C:sync-collection>

HTTP/1.1 100 Continue
Date: Wed, 30 Oct 2013 18:11:12 GMT
Preference-Applied: wait=180

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:12:47 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 375

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
   <D:response>
<D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
     <D:status>HTTP/1.1 404 Not Found</D:status>
   </D:response>
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>



REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:12:48 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
   <D:sync-level>1</D:sync-level>
   <D:prop/>
</C:sync-collection>

HTTP/1.1 100 Continue
Date: Wed, 30 Oct 2013 18:12:48 GMT
Preference-Applied: wait=180

HTTP/1.1 207 Multi-Status
Date: Wed, 30 Oct 2013 18:15:47 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: application/xml; charset=utf-8
Content-Length: 202

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>



Here is the same sequence of events utilizing streaming with a timeout:

REPORT /dav/calendars/user/ken/Default/ HTTP/1.1
Host: localhost
Date: Wed, 30 Oct 2013 18:11:06 GMT
Content-Type: application/xml
Content-Length: 260
Prefer: return=minimal, wait=180
Accept: multipart/mixed

<?xml version="1.0" encoding="UTF-8"?>
<C:sync-collection xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-354</D:sync-token>
   <D:sync-level>1</D:sync-level>
   <D:prop/>
</C:sync-collection>

HTTP/1.1 207 Multi-Status
Connection: close
Date: Wed, 30 Oct 2013 18:11:06 GMT
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal, wait=180
Content-Type: multipart/mixed;
boundary="localhost-29378-1383156666-1025603243"

This is a message with multiple parts in MIME format.

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:11:06 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 421

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
   <D:response>
<D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
     <D:propstat>
       <D:prop/>
       <D:status>HTTP/1.1 200 OK</D:status>
     </D:propstat>
   </D:response>
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-355</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:12:47 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 375

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
   <D:response>
<D:href>/dav/calendars/user/ken/Default/4E4B3490-6F01-41B9-AA5B-FE2CD6A30632.ics</D:href>
     <D:status>HTTP/1.1 404 Not Found</D:status>
   </D:response>
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243
Date: Wed, 30 Oct 2013 18:14:05 GMT
Content-Type: application/xml; charset=utf-8
Content-Length: 202

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:sync-token>http://cyrusimap.org/ns/sync/1368011844-356</D:sync-token>
</D:multistatus>

--localhost-29378-1383156666-1025603243--

End of MIME multipart body.

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University



_______________________________________________
tc-push-l mailing list
tc-push-l@lists.calconnect.org
http://lists.calconnect.org/mailman/listinfo/tc-push-l


_______________________________________________
tc-push-l mailing list
tc-push-l@lists.calconnect.org
http://lists.calconnect.org/mailman/listinfo/tc-push-l

--

Marten Gajda
Schandauer StraĂźe 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391

--------------040500050603070109070003--