Subject: [Ietf-caldav] Processing the ScheduleInbox
From: Josh Millar-Usiskin <[email-masked]>
To: [email-masked]
Date: Thu, 17 Jan 2008 14:17:31 -0600
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Hello everyone. I am currently developing a CalDAV(-schedule) API 
library. I've been using the CalDAV and CalDAV-schedule RFCs as 
reference. One thing that I believe CalDAV-schedule has missed is how to 
determine which calendar collection a message is dealing with. I have 
two use cases of concern:

1) Upon receiving the first REQUEST message, which calendar collection 
should the event be created in, if accepted?

2) Upon receiving an update REQUEST message, the only way that I can 
think of to match the message to the calendar object resource is by UID. 
But according to CalDAV [RFC 4791], a UID is only unique for a 
particular calendar collection. Conceivably, there could be two events 
with the same UID in separate calendar collections for the acting CU.

Any insight that I may have overlooked would be greatly appreciated.

Thanks,

Josh Usiskin

Date: Tue, 15 Jan 2008 15:20:02 +0000
From: Gren Elliot <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] draft-desruisseaux-caldav-sched-04 a few potential corrections

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
draft-desruisseaux-caldav-sched-04 section 5.4.1 on Conformance says :<br>
<pre>Conformance:  This property MUST be protected and SHOULD NOT be
      returned by [<a href="http://tools.ietf.org/html/rfc4918"
 title="&quot;HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)&quot;">RFC4918</a>]).

</pre>
I assume this should be like text elsewhere :<br>
<pre>   Conformance:  This property MUST be protected and SHOULD NOT be
      returned by a PROPFIND allprop request (as defined in <a
 href="http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-04#section-14.2">Section 14.2</a>
      of [<a href="http://tools.ietf.org/html/rfc4918"
 title="&quot;HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)&quot;">RFC4918</a>]).</pre>
<br>
----------------------------------------<br>
<pre><span class="h4"><h4>9.1.5.  CALDAV:schedule-post-vfreebusy Privilege</h4></span>   The CALDAV:schedule-post-vfreebusy privilege controls the use of the
   POST method to submit scheduling messages for VFREEBUSY calendar
   components on the resource.  It is ignored for resources that are not
   scheduling Outbox collections.

   &lt;!ELEMENT schedule-post-vfreebusy EMPTY &gt;

</pre>
I assume this is talking about requesting FREEBUSY information
by posting to the outbox URL? If so, I would prefer wording something
like<br>
<br>
<pre>   The CALDAV:schedule-post-vfreebusy privilege controls the use of the
   POST method to request FREEBUSY information. It is ignored for resources that are not
   scheduling Outbox collections.</pre>
as to me, asking for freebusy information is not the same as submitting
a scheduling message.<br>
<br>
Regards,<br>
Gren.<br>
<br>
</body>
</html>

Date: Mon, 07 Jan 2008 11:18:56 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Gren Elliot <[email-masked]>
Subject: Re: [Ietf-caldav] draft-desruisseaux-caldav-sched-04 PROPPATCH	precondition CALDAV:valid-free-busy-set
Cc: CalDAV DevList <[email-masked]>

Hi Gren,

The text currently specify when the precondition identifier is returned in 
the response of a failed PROPPATCH request.  We should rephrase this to 
specify what is the actual requirement instead.

Thanks for pointing this out.

Cheers,
Bernard

Gren Elliot wrote:
> Hi,
> 
> draft-desruisseaux-caldav-sched-04 Section 5.3.2  Additional 
> Precondition for PROPPATCH
> says the precondition is :
> 
> (CALDAV:valid-free-busy-set): One or more resources referenced in
>      a CALDAV:calendar-free-busy-set property being stored on a
>      scheduling Inbox collection is invalid.
> 
> Should the "invalid" read "valid"?  I can understand that some of the 
> resources might be invalid due to calendar deletions or future additions 
> but requiring one to be invalid seems wrong.
> 
> Regards,
> Gren.
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 

Date: Mon, 7 Jan 2008 15:07:02 +0000
From: Gren Elliot <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] draft-desruisseaux-caldav-sched-04 PROPPATCH precondition CALDAV:valid-free-busy-set

Hi,

draft-desruisseaux-caldav-sched-04 Section 5.3.2  Additional 
Precondition for PROPPATCH
says the precondition is :

(CALDAV:valid-free-busy-set): One or more resources referenced in
      a CALDAV:calendar-free-busy-set property being stored on a
      scheduling Inbox collection is invalid.

Should the "invalid" read "valid"?  I can understand that some of the 
resources might be invalid due to calendar deletions or future additions 
but requiring one to be invalid seems wrong.

Regards,
Gren.