Subject: Re: CalDAV draft Informal Last-Call

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 07 Mar 2006 08:39:08 -0500

Quick update.  We will submit the CalDAV draft for Last Call when
Internet-Draft posting will resume after the next IETF meeting.
That will give more time to people to review the draft.

Cheers,
Bernard

Bernard Desruisseaux wrote:
> 
> We submitted CalDAV draft -10 to the IETF yesterday. The draft has
> not been officially announced yet, but it is already available for
> you to review at the following URL:
> 
> http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt
> 
> We would like to submit the CalDAV draft for Last Call in time for
> the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do
> so, we would like to get as much feedback as possible from the
> participants of the "ietf-caldav" mailing list as well as from the
> members of the WebDAV and Calsify Working Groups.
> 
> Once officially announced the draft should be available at:
> 
>   http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt
> 
> Previous versions of the draft are available at:
> 
>   http://ietfreport.isoc.org/idref/draft-dusseault-caldav/
> 
> Discussion on CalDAV is taking place on the "ietf-caldav" mailing list:
> 
>   mailto:[email-masked]
> 
> which is archived at:
> 
>   http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 
> Reports on the 4 CalDAV Interoperability Events organized by the
> Calendaring and Scheduling Consortium (CalConnect) can be found at:
> 
>   http://www.calconnect.org/ioppast.html
> 
> Finally, additional information on CalDAV can also be found at:
> 
>   http://ietf.webdav.org/caldav/
> 
> Please review draft -10 and send us feedback/questions/comments.
> 
> Thanks for you help!
> 
> Cheers,
> Bernard
> 
> -- 
> 
> C.1.  Changes in -10
> 
>    a.  Added new section about support for X- items when storing data.
> 
>    b.  Added new precondition to allow servers to reject queries on
>        unsupported X- items, and a new example.
> 
>    c.  Added new text about always supporting X- in calendar-data.
> 
>    d.  Created new section for PUT, COPY and MOVE preconditions.
> 
>    e.  Report examples re-done with full listing of calendar data in
>        Appendix.
> 
>    f.  Removed description of using UID, SUMMARY etc as resource name.
> 
>    g.  Indicate that calendar object resource may contain only
>        overridden components.
> 
>    h.  Add security consideration about not expose details in resource
>        names.
> 
>    i.  Add constraint that free-busy-query can only be run on a
>        collection.
> 
>    j.  Add preconditions for calendar-timezone property/elements in
>        MKCALENDAR, PROPPATCH and calendar-query REPORT.
> 
>    k.  Fix principal-match example.
> 
> 
>

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 15 Mar 2006 21:35:52 -0500

I thought it would be worthwhile to update everybody on the
changes we are planning to make in draft -11 based on the
issues that have been brought up so far:

- Added new preconditions:
    * CALDAV:number-of-recurrences-within-limits for PUT;
    * CALDAV:calendar-collection-location-ok for MOVE and COPY.
- Redefined the CALDAV:no-uid-conflict precondition.
- Minor editorial changes.
- Update to references.
- Added element CALDAV:is-not-defined.
- Added new attribute "negate-condition" to the
   CALDAV:text-match element.

The last two changes were required to be able to query the to-dos
that are *not* completed and *not* cancelled. The issue is that
the CALDAV:calendar-query REPORT does not provide support for a
"not" operator. To be able to address the above use case without
increasing the complexity of the CALDAV:calendar-query REPORT
significantly we have decided to add a new condition "is-not-defined" 
and to add a "negate-condition" attribute to be able to negate the
"text-match" condition.

Here's the DTD declarations that will be added to the draft:

   <!ELEMENT is-not-defined EMPTY>

   <!ATTLIST text-match negate-condition (yes | no) #IMPLIED "no">

Here's an example for the to-dos use case:

    REPORT /bernard/work/ HTTP/1.1
    Host: cal.example.com
    Depth: 1
    Content-Type: application/xml; charset="utf-8"
    Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
      <D:prop xmlns:D="DAV:">
        <D:getetag/>
        <C:calendar-data/>
      </D:prop>
      <C:filter>
        <C:comp-filter name="VCALENDAR">
          <C:comp-filter name="VTODO">
            <C:prop-filter name="COMPLETED">
              <C:is-not-defined/>
            </C:prop-filter>
            <C:prop-filter name="STATUS">
              <C:text-match
                 negate-condition="yes">CANCELLED</c:text-match>
            </C:prop-filter>
          </C:comp-filter>
        </C:comp-filter>
      </C:filter>
    </C:calendar-query>

Please continue to send us feedback/questions/comments.

Thanks,
Bernard

Bernard Desruisseaux wrote:
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Mar 2006 18:42:14 +0100

Bernard Desruisseaux wrote:
> ...

Bernard,

so did you consider whether CalDAV is going to be based on RFC2518 or on 
RFC2518bis? That is, would a CalDAV client be able to rely on 
RFC2518bis, or would they need to interact with both kinds of servers?

Are CalDAV server implementors implementing RFC2518bis (or are they 
planning to)?

Best regards, Julian