W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

Re: CalDAV draft Informal Last-Call

From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
Date: Thu, 23 Feb 2006 09:59:15 -0500
Message-ID: <43FDCDC3.3000004@oracle.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: CalDAV DevList <ietf-caldav@osafoundation.org>, Calsify WG <ietf-calsify@osafoundation.org>, WebDAV WG <w3c-dist-auth@w3.org>, Ted Hardie <hardie@qualcomm.com>, Lisa Dusseault <lisa@osafoundation.org>, Cyrus Daboo <cyrus@daboo.name>

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!

Julian Reschke wrote:
> 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
> 
> 
> 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:ietf-caldav@osafoundation.org
>>
>> 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.
>>
>>
>>
>>
> 
> 
Received on Thursday, 23 February 2006 15:01:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:13 GMT