Subject: CalDAV draft Informal Last-Call

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 22 Feb 2006 22:08:46 -0500

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: Julian Reschke <[email-masked]>
Date: Thu, 23 Feb 2006 09:08:15 +0100

Hm.

It strikes me as a particularly bad idea to last-call a draft that 
builds on top of RFC2518, while, at the same time, RFC2518bis is last 
called.

Reasons:

- you will likely have to update the spec to refer to rfc2518bis instead 
anyway, and this frequently is more work than just updating a single 
reference (in particular, the stuff about ETags in section 5.3.4 is 
partly in conflict with RFC2616, and likely to be in conflict with the 
separate document about ETag handling in HTTP the IETF has decided to 
produce).

- the group of people who can give constructive feedback to CalDAV 
definitively overlaps with those who can review RFC2518bis.

Therefore I strongly suggest not to last-call anything WebDAV related 
before RFC2518bis' last call has ended.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 23 Feb 2006 09:59:15 -0500

Julian,

Thanks for your feedback!  The idea to do an informal last call is
exactly to get this kind of feedback. :-)

Lisa, Cyrus and I already discussed about the possibility of making
reference to RFC2518bis. We will consider your feedback on this issue.

Meanwhile, it would be appreciated if you could elaborate some more on
the implication of referencing RFC2518bis instead of RFC2518 in CalDAV.

Thanks,
Bernard

P.S. I have printed rfc2518bis and will take the time to review it!

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Feb 2006 16:21:02 +0100

> reference to RFC2518bis. We will consider your feedback on this issue.

Well, and that's the problem. To provide that kind of feedback, I'll 
have to review the spec, and that's the one thing I really don't have 
time for during RFC2518bis' last call :-)

> P.S. I have printed rfc2518bis and will take the time to review it!

Great!

Best regards, Julian