Subject: [Ietf-caldav] resource v collection flagging of scheduling objects
From: Mike Douglass <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Tue, 30 Sep 2008 23:05:22 -0400
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Another reason for flagging of scheduling objects at the resource level
only...

We should not extend WebDAV in a way that unexpected side effects will
occur when WebDAV operations take place.

So...

if we assume we use flagging of events to mark scheduling objects:

COPY drops the flag - copied scheduling objects become non-scheduling
MOVE retains the flag

then webdav clients introduce the minimum of unexpected side effects -
only deletion will trigger off scheduling operations which might be OK
(unless they do MOVE by COPY+DELETE)

This allows the use of davexplorer for example to move stuff around, or
a simple file browser.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Tue, 30 Sep 2008 09:42:47 -0400
From: Mike Douglass <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-caldav] Scheduling section 3.1.1 (again)
Cc: [email-masked]

Would it not have been better to flag events as being an
active-scheduling-event?

An event becomes active when it is sent to the attendees by the
organizer or received by an attendee.

uid must be unique among all active events

When an event is copied it becomes inactive.

Simple search of the db finds all active scheduling events.

Can be highlighted in the ui, listed when not all attendees have
confirmed etc.

Bernard Desruisseaux wrote:
> Hi Mike,
>
> While the PROPPATCH request you have in mind looks pretty simple at
> first you have to realize that it could actually trigger a lot of
> operations on the server.
>
> When converting a basic calendar collection into a scheduling
> collection, the server would need to make sure there are no UID
> conflict amongst all your scheduling calendar collections, and the
> server would also end up sending a lot of meeting invitations on your
> behalf.
>
> When converting a scheduling calendar collection into a basic calendar
> collection, the server would end up sending METHOD:REPLY with
> PARTSTAT=DECLINED for all the invitations you had in your calendar.
>
> And... the server wouldn't have any way of telling you exactly what
> went wrong in the response to your PROPPATCH request in case of errors.
>
> I'm guessing you would like your users to be able to convert their
> basic calendar collections into scheduling calendar collections
> themselves after their server will have been upgraded to a version of
> your server that provides support for scheduling calendar
> collections... and thus would like to see this operation possible
> through the protocol.
>
> Given that our intent is not to allow users to change this themselves,
> would it be acceptable if we were to require (MUST) the
> DAV:resourcetype to simply be protected (i.e., can't be changed from
> client over CalDAV) instead of immutable. This way a compliant server
> would still be allowed to change the DAV:resourcetype itself and
> perhaps provide a mean to the end users to change it (not over CalDAV,
> or else don't tell me).
>
> Thanks,
> Bernard
>
> Mike Douglass wrote:
>> You have the text:
>>
>>    The DAV:resourcetype property on a calendar collection MUST be
>>    immutable.  Once a calendar collection has been created, servers MUST
>>    NOT change it from a scheduling calendar collection to a basic
>>    calendar collection, or vice versa.
>>
>>
>> Why and from a client perspective how is this enforced?
>>
>> User has non-scheduling calendar X
>> Moves the contents to Y
>> Deletes X
>> Recreates X as scheduling calendar
>> Moves Y/* back into X
>>
>> or alternatively just does a PROPPATCH
>>
>>
>>
>
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Tue, 30 Sep 2008 15:40:58 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-caldav] typo in scheduling examples

Hello,

Typo in scheduling draft (old and new):

It looks like all the scheduling examples returning a 
C:schedule-response have invalid <C:recipient> elements since those 
directly contain a mailto url, instead of having this url wrapped in an 
<href> element, as per 
http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-05#section-11.3 .

Arnaud Q

Date: Mon, 29 Sep 2008 16:28:44 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Re: [Ietf-caldav] MKCALENDAR or extended MKCOL
Cc: [email-masked]

Hi Arnaud,

We don't want draft-desruisseaux-caldav-sched to depend on 
draft-daboo-webdav-mkcol.

When draft-daboo-webdav-mkcol will be published it will update both 
RFC4791 (CalDAV calendar-access) as well as CalDAV Scheduling 
(calendar-auto-schedule).

Cheers,
Bernard

Arnaud Quillaud wrote:
> Hello,
> 
> The new scheduling draft still makes use of MKCALENDAR to create 
> scheduling enabled calendar collections 
> (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-05#section-3.1.1). 
> 
> Moreover, it changes its semantic since the default behavior is now to 
> create a scheduling enabled collection.
> 
> Shouldn't we instead leverage the extended mkcol 
> (http://tools.ietf.org/html/draft-daboo-webdav-mkcol) ?
> 
> Arnaud Q
> _______________________________________________
> 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, 29 Sep 2008 15:55:38 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Mike Douglass <[email-masked]>
Subject: Re: [Ietf-caldav] Scheduling section 3.1.1 (again)
Cc: [email-masked]

Hi Mike,

While the PROPPATCH request you have in mind looks pretty simple at 
first you have to realize that it could actually trigger a lot of 
operations on the server.

When converting a basic calendar collection into a scheduling 
collection, the server would need to make sure there are no UID conflict 
amongst all your scheduling calendar collections, and the server would 
also end up sending a lot of meeting invitations on your behalf.

When converting a scheduling calendar collection into a basic calendar 
collection, the server would end up sending METHOD:REPLY with 
PARTSTAT=DECLINED for all the invitations you had in your calendar.

And... the server wouldn't have any way of telling you exactly what went 
wrong in the response to your PROPPATCH request in case of errors.

I'm guessing you would like your users to be able to convert their basic 
calendar collections into scheduling calendar collections themselves 
after their server will have been upgraded to a version of your server 
that provides support for scheduling calendar collections... and thus 
would like to see this operation possible through the protocol.

Given that our intent is not to allow users to change this themselves, 
would it be acceptable if we were to require (MUST) the DAV:resourcetype 
to simply be protected (i.e., can't be changed from client over CalDAV) 
instead of immutable. This way a compliant server would still be allowed 
to change the DAV:resourcetype itself and perhaps provide a mean to the 
end users to change it (not over CalDAV, or else don't tell me).

Thanks,
Bernard

Mike Douglass wrote:
> You have the text:
> 
>    The DAV:resourcetype property on a calendar collection MUST be
>    immutable.  Once a calendar collection has been created, servers MUST
>    NOT change it from a scheduling calendar collection to a basic
>    calendar collection, or vice versa.
> 
> 
> Why and from a client perspective how is this enforced?
> 
> User has non-scheduling calendar X
> Moves the contents to Y
> Deletes X
> Recreates X as scheduling calendar
> Moves Y/* back into X
> 
> or alternatively just does a PROPPATCH
> 
> 
> 

Date: Mon, 29 Sep 2008 13:40:21 -0400
From: Mike Douglass <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] Scheduling section 3.1.1 (again)

You have the text:

   The DAV:resourcetype property on a calendar collection MUST be
   immutable.  Once a calendar collection has been created, servers MUST
   NOT change it from a scheduling calendar collection to a basic
   calendar collection, or vice versa.

Why and from a client perspective how is this enforced?

User has non-scheduling calendar X
Moves the contents to Y
Deletes X
Recreates X as scheduling calendar
Moves Y/* back into X

or alternatively just does a PROPPATCH

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Mon, 29 Sep 2008 11:55:16 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on: 3.2.3.3. HTTP Methods
Cc: [email-masked]

Arnaud Quillaud wrote:
> ** DELETE of unprocessed iTIP REQUEST on calendar-inbox **
> 
> Could we define the behavior of a DELETE on an unprocessed iTIP REQUEST 
> in the calendar-inbox as corresponding to a remove action.
> By doing that, we would allow a client to directly decline a meeting 
> without having to first insert it into one of the owner's calendar to 
> just delete it from there to trigger a decline.

Interesting idea. I don't believe that should be the default behavior
of DELETE though. Perhaps the server could send a reply only when
the resquest header "Schedule-Reply" is explicitly set to "T".

> ** MOVE of unprocessed iTIP REQUEST on calendar-inbox to scheduling 
> collection **
> 
> Could we define the behavior of a MOVE of an unprocessed iTIP REQUEST on 
> calendar-inbox into a scheduling collection as corresponding to the 
> automatic processing of an invitation into that scheduling collection.
> By doing that, we would allow a client to process an invitation, accept 
> and store in one single operation, without even having to to know how to 
> translate an iTIP message (potentially containing only info about a 
> particular instance, etc...) into a calendar resource.
> 
> We might want to add an http header to specify the PARSTAT to set.

I'm not sure it would be wise to play with the semantic of MOVE that 
way. While I may be wrong, I'm expecting most server to provide support 
for a default calendar and thus make this potential performance 
improvement unneeded.

Also, clients may actually want to change more than just the ATTENDEE's 
PARTSTAT from the incoming invitation. For instance, when the invitation 
is accepted the client may actually need to add some reminders (VALARM), 
and when the invitation is declined, the client may actually need to 
also set TRANSP to TRANSPARENT.

> ** DELETE on default calendar collection **
> 
> Should we add a new precondition when trying to delete the default 
> calendar collection ?

Yes. This is missing.

Thanks,
Bernard

> 
> Arnaud Q
> _______________________________________________
> 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: Fri, 26 Sep 2008 16:36:30 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Re: [Ietf-caldav] various comments on scheduling outbox
Cc: [email-masked]

Bonjour Arnaud,

Arnaud Quillaud wrote:
> ** Content of outbox **
> 
> At 
> http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-05#section-3.1.2 
> , there is no mention of what the content of the scheduling outbox might 
> be (only itip but no freebusy message, auto delete,...). The definition 
> of the POST method does not specify either whether a POST may result in 
> a resource being created.
> The only hint I could find is that in section 8.1.3, the 201 status code 
> is listed.

It has never been clear to me whether there was any valid use case to 
keep copies of outgoing scheduling messages in the scheduling Outbox 
collection.

With the new approach introduced in draft -05, most scheduling 
operations aren't targeted at the scheduling Outbox collection anymore, 
as such we've removed the following text that was in draft -04:

  > When a client targets the POST method at a scheduling Outbox
  > collection, the server MAY create a copy of the scheduling message in
  > that scheduling Outbox collection, unless the request contains a
  > free-busy message, in which case the server MUST NOT store a copy of
  > the free-busy message.  Copies that are created serve as a record of
  > outgoing scheduling messages.

- Do you think the scheduling Outbox should simply be a regular resource
   (i.e., not a collection?)

- Do you have any valid use case were it would be useful to keep
   outgoing scheduling message in the scheduling Outbox collection?
   Would it make sense for a server to create a scheduling message in
   the scheduling Outbox collection when a scheduling object resource
   has been created, modified, or removed in a scheduling calendar
   collection?

or you don't really clear as long as the draft is clear?

> ** CALDAV:max-resource-size property on outbox **
> 
> The CALDAV:max-resource-size property is not listed in the scheduling 
> outbox definition. Nevertheless, it is mentioned in 8.1 in the 
> CALDAV:max-resource-size precondition.

Here's the issue we ran into. When you create or modify a scheduling
object resource in a scheduling calendar collection, which 
CALDAV:max-resource-size should be considered? The value specified on 
the scheduling calendar collection or the one on the scheduling Outbox 
collection... or perhaps the smallest of the two?

> 
> ** Preconditions **
> 
> I guess this one is a remaining from the 04 version and is no longer 
> applicable:
> <<
> 
> (CALDAV:attachments-allowed): The resource submitted in the POST
>      request MUST NOT contain any inline ATTACH properties;
> 
>  >>

Indeed.

Thanks,
Bernard

> 
> Arnaud Q
> _______________________________________________
> 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: Fri, 26 Sep 2008 16:44:10 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked], tc-caldav <[email-masked]>
Subject: [Ietf-caldav] sending attendee PARSTAT update and iMIP - default value for schedule-calendar-transp - creation of attendee scheduling object

** 3.3.1.1. Processing an "Attendee" reply **

When processing an attendee reply we have this MUST:
 <<

The server MUST send scheduling messages to all the other "Attendees"
   indicating the change in participation status of the "Attendee"
   replying, subject to the recurrence requirements of Section 3.5.1 <http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-05#section-3.5.1>.

 >>

Does this also apply to ATTENDEEs to whom the server has to send an iMIP 
message ? For a meeting with a large number of attendees, this might 
become really annoying.

** 6.1. CALDAV:schedule-calendar-transp Property **
What is the default value when not present ? opaque ?

** creation of attendee scheduling object resources **
<<

The creation of attendee scheduling object resources will typically
   be done by the server in cases where a default scheduling calendar
   collection is defined.  In cases where no default scheduling calendar
   collection is defined, the server MAY prevent calendar user agents
   from forging attendee scheduling object resources by forbidding their
   creation or imposing restrictions on their creation.  For instance, a
   server MAY require the presence of a scheduling message, received
   from the "ORGANIZER" with the same "UID" property value, in the
   scheduling Inbox collection of the owner of the scheduling calendar
   collection.

 >>

About "forbidding their creation": This would make it impossible for 
clients to process any "schedule-unprocessed" invitation so I think this 
case should be removed.

About "imposing restrictions" and the particular example that you take: 
The server would prevent clients from inserting any messages received 
through other means (e.g. iMIP message). So even a MAY does not sound right.

Date: Fri, 26 Sep 2008 16:42:08 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked], tc-caldav <[email-masked]>
Subject: [Ietf-caldav] Comments on 3.2.3. Handling Scheduling Object Resources

** Default value for SCHEDULE-AGENT **

Having the default value being SERVER still sounds wrong to me. If I'm 
using a calendar-access only client and my server is suddenly migrated 
to a schedule enabled server, I will suddenly start sending invitations 
without even knowing it.

** Reloading **

<<

As a result clients SHOULD reload the calendar data from
   the server as soon as it is stored in order to update to the new
   server generated state information.

 >>

Why SHOULD and not just MAY ? This is just a hint, no ?

** Restrictions for create and modify**

<<

The server MUST reject any attempt to set the "PARTSTAT"
       iCalendar property parameter value of the "ATTENDEE" iCalendar
       property of other users in the calendar object resource to a
       value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property
       parameter value is not present or set to the value "SERVER".

 >>

We already discussed this but just for the records:
The server may end up generating an iMIP message for a particular 
attendee, hence the response from that attendee (and hence his PARTSTAT) 
may come via iMIP. In that case, the client must be able to update the 
attendee PARTSTAT to a value other than NEEDS-ACTION.
If I understood correctly, a solution would be to have a new 
"server-request" value for the SCHEDULE-AGENT. This value could be set 
only by the server (as the result of sending the invitation via iMIP). 
Any attendee with such a value could have its PARSTAT changed by the client.

** Restriction for modify **

<<

The client MUST NOT change the "UID" iCalendar property parameter
       value in the scheduling object resource.

 >>

but this is true already from calendar-access so is there any particular 
reason why this was re stated ?

** Attendee removing an event **

<<

 If
       the server is unable to deliver the scheduling message, the
       remove action MUST fail, and an appropriate "SCHEDULE-STATUS"
       iCalendar property parameter set on the "ORGANIZER" property in
       the scheduling object resource stored by the server.

 >>

For the remove action failing, you imply that the whole operation is 
synchronous which is not the case in reality.

Arnaud Q

Date: Fri, 26 Sep 2008 16:41:07 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked], tc-caldav <[email-masked]>
Subject: [Ietf-caldav] Comments on scheduling inbox

** CALDAV:min-date-time andCALDAV:max-date-time **

Might want to have those on scheduling inbox  when calendar queries are 
allowed.

** CALDAV:schedule-state property**
We might have discussed this already but in the case where the state is 
"processed", it would be very handy for clients to have a backpointer to 
the updated resource, especially for stateless (cacheless) clients. It 
is OK if the backpointer becomes broken.

Arnaud Q

Date: Fri, 26 Sep 2008 16:33:49 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked], tc-caldav <[email-masked]>
Subject: [Ietf-caldav] Comments on: 3.2.3.3. HTTP Methods

** DELETE of unprocessed iTIP REQUEST on calendar-inbox **

Could we define the behavior of a DELETE on an unprocessed iTIP REQUEST 
in the calendar-inbox as corresponding to a remove action.
By doing that, we would allow a client to directly decline a meeting 
without having to first insert it into one of the owner's calendar to 
just delete it from there to trigger a decline.

** MOVE of unprocessed iTIP REQUEST on calendar-inbox to scheduling 
collection **

Could we define the behavior of a MOVE of an unprocessed iTIP REQUEST on 
calendar-inbox into a scheduling collection as corresponding to the 
automatic processing of an invitation into that scheduling collection.
By doing that, we would allow a client to process an invitation, accept 
and store in one single operation, without even having to to know how to 
translate an iTIP message (potentially containing only info about a 
particular instance, etc...) into a calendar resource.

 We might want to add an http header to specify the PARSTAT to set.

** DELETE on default calendar collection **

Should we add a new precondition when trying to delete the default 
calendar collection ?

Arnaud Q

Date: Fri, 26 Sep 2008 16:32:01 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked], tc-caldav <[email-masked]>
Subject: [Ietf-caldav] various comments on scheduling outbox

** Content of outbox **

At 
http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-05#section-3.1.2 
, there is no mention of what the content of the scheduling outbox might 
be (only itip but no freebusy message, auto delete,...). The definition 
of the POST method does not specify either whether a POST may result in 
a resource being created.
The only hint I could find is that in section 8.1.3, the 201 status code 
is listed.

** CALDAV:max-resource-size property on outbox **

The CALDAV:max-resource-size property is not listed in the scheduling 
outbox definition. Nevertheless, it is mentioned in 8.1 in the 
CALDAV:max-resource-size precondition.

** Preconditions **

I guess this one is a remaining from the 04 version and is no longer 
applicable:
<<

(CALDAV:attachments-allowed): The resource submitted in the POST
      request MUST NOT contain any inline ATTACH properties;

 >>

Arnaud Q

Date: Fri, 26 Sep 2008 09:19:01 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, [email-masked], tc-caldav <[email-masked]>
Subject: [Ietf-caldav] Re: [Tc-caldav-l] CALDAV:min-date-time and CALDAV:max-date-time on	scheduling outbox

Hi Arnaud,

--On September 26, 2008 11:25:10 AM +0200 Arnaud Quillaud 
<[email-masked]> wrote:

> The scheduling outbox
> (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-05#section-3.
> 1.2)  may have a "CALDAV:supported-calendar-data" property. What about
> CALDAV:min-date-time and CALDAV:max-date-time ?
>
> Some servers may restrict the time range accessible for freebusy queries
> (e.g 1 week before, 6 month ahead), so that would give the client a way
> to discover that range.

Right - it probably makes sense to include all the "restriction" WebDAV 
properties on calendar collection on the Outbox too.

-- 
Cyrus Daboo

Date: Fri, 26 Sep 2008 11:25:10 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked], tc-caldav <[email-masked]>
Subject: [Ietf-caldav] CALDAV:min-date-time and CALDAV:max-date-time on scheduling outbox

The scheduling outbox 
(http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-05#section-3.1.2) 
may have a "CALDAV:supported-calendar-data" property. What about 
CALDAV:min-date-time and CALDAV:max-date-time ?

Some servers may restrict the time range accessible for freebusy queries 
(e.g 1 week before, 6 month ahead), so that would give the client a way 
to discover that range.

Arnaud Q

Date: Fri, 26 Sep 2008 11:07:18 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked], tc-caldav <[email-masked]>
Subject: [Ietf-caldav] MKCALENDAR or extended MKCOL

Hello,

The new scheduling draft still makes use of MKCALENDAR to create 
scheduling enabled calendar collections 
(http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-05#section-3.1.1).
Moreover, it changes its semantic since the default behavior is now to 
create a scheduling enabled collection.

Shouldn't we instead leverage the extended mkcol 
(http://tools.ietf.org/html/draft-daboo-webdav-mkcol) ?

Arnaud Q

Date: Wed, 24 Sep 2008 10:04:01 -0400
From: Cyrus Daboo <[email-masked]>
To: Shug Boabby <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] CalDAV comments, a bit too late...

Hi Shug,

--On September 24, 2008 4:00:54 PM +0300 Shug Boabby 
<[email-masked]> wrote:

> I realise that CalDAV is now supported by many big vendors, including
> Google and Apple, so I doubt that the protocol could be changed in any
> way. Nonetheless, being called RFC-4791 implies that comments are
> still welcome (and I have some steam to let off after using this
> ghastly protocol which it seems we are all stuck with!)

The reality is CalDAV came along because previous attempts to create a 
"clean and simple" calendaring and scheduling protocol in the IETF came to 
naught because they invariably ended up getting too complex - and the 
reason for that is that calendaring and scheduling itself is complex. 
CalDAV worked because it was based on existing, well understood protocols 
that had a much lower barrier to entry because there were already lots of 
tools and libraries for HTTP, WebDAV and iCalendar. Within about four 
months of the inaugural Calendaring & Scheduling meeting in September 2004 
there were several servers and clients showing basic interoperability for 
calendar access.

That said CalDAV is a basis for a calendaring solution and not the final 
solution. There is plenty of scope for extensions to do things like 
aggregation of queries, or synchronization reports for more efficient 
bandwidth usage. Indeed many of these have been discussed by those people 
actually implementing and deploying CalDAV since those are the folks who 
really get to see the limitations in practice. Other extensions such as 
Atom/RSS feeds on calendar collections and the like have also been 
discussed.

It is also pretty easy to write a caching proxy gateway that would allow 
you to use a "clean and simple" protocol on the J2ME side to talk to one or 
more CalDAV servers.

> I recently embarked on creating a J2ME application which would use a
> CalDAV server to store everything. The reason is obvious, as it means
> that resources are easily synchronised with all good desktop calendar
> applications.

Well I wrote a prototype CalDAV J2ME client almost four years ago. Yes it 
used raw sockets and I adapted my own WebDAV and iCalendar libraries from a 
desktop product (i.e. did not have to start from scratch), and it had 
virtually no UI - just a simple list of events for today or over the next 
week. But that was sufficient for what I needed and it performed adequately.

It is worth noting that calendaring vendors are concerned about mobile 
devices. In fact the Calendaring and Scheduling Consortium is hosting its 
second mobile calendaring interoperability test event in the Czech Republic 
in November (<http://www.calconnect.org/miop0811.shtml>). I believe one of 
the areas that the mobile technical committee in the Consortium wants to 
turn its attention to is how CalDAV can better work with mobile devices, so 
I am sure they will be proposing extensions etc to help with that. I would 
certainly urge anyone who is interested in this area to find a way to get 
involved in that effort, or to continue discussion of this topic on this 
list.

-- 
Cyrus Daboo

Date: Wed, 24 Sep 2008 15:59:59 +0200
From: Julian Reschke <[email-masked]>
To: Shug Boabby <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV comments, a bit too late...
Cc: [email-masked]

Shug Boabby wrote:
> ...
> - basing it on WebDAV instead of HTTP means that most standard
> libraries may not be used
> ...

"most"?

> ...
> - sharing resources with other users (even other users on the same
> server) is not even considered
> ...

I though it was by explicitly requiring WebDAV ACL support.

> ...
> CalDAV is based on WebDAV, which is covered with HTTP compatibility
> problems. For example, all flavours of Java exclude WebDAV support in
> their standard network library and use of methods such as REPORT and
> PROPFIND are forbidden. Other languages face similar troubles. Support
> is available from third parties on J2SE and J2EE (but no
> maintenance!). No support is available for J2ME and raw socket access
 > ...

What exactly do you mean by "no maintenance"?

> ...
> My preferred solution would have been to stick with plain old HTTP!
> There is nothing in this protocol that could not have been achieved
> with simple GET, POST and (optionally) PUT. I wouldn't even have
> considered HTTP headers to contain anything special... something
> CalDAV relies on heavily (e.g. Depth and If-None-Match).
 > ...

How is if-none-match "special"?

> One of the things I really like about the Freebase API is the fact
> that non-standard queries can be formulated in fairly simple JSON
> format (but could easily have been XML), but that for most things a
> simple GET-based query will also work. It would have been highly
> desirable if the most common CalDAV queries could have been achieved
> as simply as sending a GET query to
> server.com/caldav/todo/username/calendar?state=incomplete&from=20060712T182145Z
 > ...

I agree with this one. See for instance 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#rfc.section.C>.

> ...
> Also, where is the definition of the "urn:ietf:params:xml:ns:caldav"
> and "DAV" namespaces? A schema is needed if correct XML is to be
> expected!
> ...

No, a schema is not needed :-) A spec is needed, though. See the WebDAV 
and the CalDAV specs.

> ...
> I've already hinted that creating XML is often burdensome on mobile
> devices, and also that creating new resources is not guaranteed to
> succeed. As an example, consider creating a new VTODO item, given that
> we know the collection URL. A PUT request is made to a URL that we
> must create ourselves, and we must add the HTTP header "If-None-Match:
> *". It is then non-obvious how one is expected to check the reason for
> failure! Currently I am scanning the text of the Cosmo response for a
> non-201 response and the String "If-None-Match disallows conditional
> request", but this is clearly implementation specific. Creating new
> resources could not have been designed to be more difficult.
> ...

You should check for the right HTTP status (it should be 412).

That being said: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>.

 > ...

BR, Julian

Date: Wed, 24 Sep 2008 15:37:47 +0200
To: "Shug Boabby" <[email-masked]>, "[email-masked]" <[email-masked]>
From: "Filip Navara" <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV comments, a bit too late...

Hi!

> -----Original Message-----
> From: "Shug Boabby" <[email-masked]>
> To: [email-masked]
> Date: 09/24/08 15:01
> Subject: [Ietf-caldav] CalDAV comments, a bit too late...
--snip--
> - basing it on WebDAV instead of HTTP means that most standard
> libraries may not be used

Probably the only case of standard libraries not working with WebDAV
is the one of Java that you mentioned. All the other frameworks that
I worked with supported it without a glitch.

--snip--
> It should also be noted that the current protocol excludes AJAX access to
> data via the usual JSON cross-server route.

Do you realize that the X in AJAX stands for XML? In fact AJAX was used
for the very first time in Outlook Web Access to access WebDAV on the
Exchange server.

--snip--
> My preferred solution would have been to stick with plain old HTTP!
> There is nothing in this protocol that could not have been achieved
> with simple GET, POST and (optionally) PUT. I wouldn't even have
> considered HTTP headers to contain anything special... something
> CalDAV relies on heavily (e.g. Depth and If-None-Match).

This has been tried and done - see WCAP and Google Data protocols.

--snip--
> - obtain all TODO items that have been modified since a given
> timestamp or ETag was created

At first, this could be done with a single query, but there are experimental
drafts to address this on WebDAV level (http://tools.ietf.org/id/draft-daboo-webdav-sync-00.txt).

--snip--
> I would also assume that queries on the collection-home
> be applied to all collections/calendars! This is not the case, and
> there does not appear to be a way to do it.

There is a way to do it, use the Depth: infinity header. It may not be
supported on the server due to excessive workload, but quite a few
existing servers support it.

--snip--
> It would have been highly
> desirable if the most common CalDAV queries could have been achieved
> as simply as sending a GET query to
> server.com/caldav/todo/username/calendar?state=incomplete&from=20060712T182145Z

This is what WCAP does, but it's not easily extensible, while XML w/ namespaces is.

--snip--
> It might sound like this is purely aesthetic, but it is not. It takes
> a lot of code to be capable of handling and creating the XML queries
> that CalDAV requires, leading to the exclusion of some mobile devices.

What the heck? You can hard code the XML for your common queries as standard text string. Not any harder than passing the parameters in URL.

--snip--
> Also, where is the definition of the "urn:ietf:params:xml:ns:caldav"
> and "DAV" namespaces? A schema is needed if correct XML is to be
> expected!

The "DAV:" namespace is covered in RFC 4918 (and RFC 3744 and others).
"urn:ietf:params:xml:ns:caldav" is covered in RFC 4791. As far as I know
there are no authoritative complete schemas, but indiviual DTD definitions
of elements are present in the RFCs.

--snip--
> A PUT request is made to a URL that we
> must create ourselves, and we must add the HTTP header "If-None-Match:
> *". It is then non-obvious how one is expected to check the reason for
> failure! Currently I am scanning the text of the Cosmo response for a
> non-201 response and the String "If-None-Match disallows conditional
> request", but this is clearly implementation specific.

This is not implementation specific and the error codes are well defined.
Successful PUT can basically result only in 201 or 204 responses where
204 can't happen if "If-None-Match: *" is specified. Anyway, any 2xx
error code should be treated as successful creation of the resource.

--snip--
> Another classic example is timezone support. Prior to using CalDAV, I
> had expected it to do all the grunt work of timezones... such that I
> could make all my queries in GMT and never be confused. However, it
> seems that CalDAV is expecting all clients (even mobile clients) to
> have rich timezone support and to therefore have full international
> iCal support.

Wrong, wrong, wrong. Look again at the "expand" element in RFC
4791.

--snip--
> # No support for sharing

Actually you are confusing two things - sharing and delegating. Both of
which are supported. Sharing is supported through the mandatory
requirement to support WebDAV ACLs. For delegating see
http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-05.txt

Best regards,
Filip Navara

Date: Wed, 24 Sep 2008 16:00:54 +0300
From: "Shug Boabby" <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] CalDAV comments, a bit too late...

Dear all,

I realise that CalDAV is now supported by many big vendors, including
Google and Apple, so I doubt that the protocol could be changed in any
way. Nonetheless, being called RFC-4791 implies that comments are
still welcome (and I have some steam to let off after using this
ghastly protocol which it seems we are all stuck with!)

I recently embarked on creating a J2ME application which would use a
CalDAV server to store everything. The reason is obvious, as it means
that resources are easily synchronised with all good desktop calendar
applications.

However, the first task was to learn how to make simple calls using
CalDAV and I have been astonished at how difficult and inefficient
this protocol is. It makes me wonder if any use cases were considered
during its design, and if mock scenarios were even considered. My
primary complaints are listed here, with more detail below:-

- basing it on WebDAV instead of HTTP means that most standard
libraries may not be used
- not enough can be achieved with a single query, increasing latency
for mobile devices
- using an XML query/response format is serious overkill for many use cases
- many queries and actions are too burdensome to the client, e.g.
creating new resources, timezone handling
- sharing resources with other users (even other users on the same
server) is not even considered

But in short, why is this not a simple protocol? One of the most
beautiful web APIs I have ever used is the one provided by
Freebase.com, which is trying to accomplish something infinitely more
powerful than CalDAV but does it in a protocol that is easy to
understand. It is based on MQL, but it could have easily have been
XML. Even the rich media API is incredibly simple and powerful. CalDAV
is, at the end of the day, just an online store for files that hold
all the real info, with some filters to reduce bandwidth usage and
mechanisms to allow caching... why on Earth is it so bloody verbose
and complicated!?

# WebDAV

CalDAV is based on WebDAV, which is covered with HTTP compatibility
problems. For example, all flavours of Java exclude WebDAV support in
their standard network library and use of methods such as REPORT and
PROPFIND are forbidden. Other languages face similar troubles. Support
is available from third parties on J2SE and J2EE (but no
maintenance!). No support is available for J2ME and raw socket access
is required, which is not even guaranteed on all devices, due to the
security manager.

This strikes a serious blow to mobile development, which is quite
considerable given the nature of the service that is being provided by
CalDAV! Mobile (especially J2ME) access, should have been a primary
consideration when choosing the base transport of the protocol! It
should also be noted that the current protocol excludes AJAX access to
data via the usual JSON cross-server route.

My preferred solution would have been to stick with plain old HTTP!
There is nothing in this protocol that could not have been achieved
with simple GET, POST and (optionally) PUT. I wouldn't even have
considered HTTP headers to contain anything special... something
CalDAV relies on heavily (e.g. Depth and If-None-Match).

# Too much reliance on multiple queries

It is not possible to do any of the following actions in a single
query, even if you know a user's principal URL:-

- obtain the list of all their calendars
- obtain all TODO items that have been modified since a given
timestamp or ETag was created
- create a new resource (this can be attempted in a single query if
the calendar URL is known, but it is not guaranteed to succeed)

These are all very common queries and actions. It is therefore
critical that both bandwidth and number of queries be optimised, with
preference on minimising the number of queries. On a mobile device
with a strong connection, the latency per query can be as much as 5
seconds. Without making several assumptions on the client side (e.g.
collection-home doesn't move, collections don't move), the end user
will be left waiting for 30 seconds every time they want to list their
TODO items! For example, when given a user's principal, the following
must be done in order to obtain their TODO items:-

- obtain the location of collection-home
- obtain the list of calendars
- obtain all the VTODO items, one query per calendar

which is 4 queries for the typical person with a "home" and "work"
calendar, neglecting to check for all the various methods and resource
types which are seemingly optional.

My preferred solution would have been to impose standardised URL
resource locations at the base of a server and require that all
methods and resource types are supported. For example, a user's
principal would always be at `/user/username`, with collections
`/collection/username` and possibly even some common shortcuts such as
`/todo/username`, `/event/username` which would imply that all queries
on collections should be restricted to VTODO/VEVENT items
respectively. I would also assume that queries on the collection-home
be applied to all collections/calendars! This is not the case, and
there does not appear to be a way to do it.

# XML overkill

One of the things I really like about the Freebase API is the fact
that non-standard queries can be formulated in fairly simple JSON
format (but could easily have been XML), but that for most things a
simple GET-based query will also work. It would have been highly
desirable if the most common CalDAV queries could have been achieved
as simply as sending a GET query to
server.com/caldav/todo/username/calendar?state=incomplete&from=20060712T182145Z

It might sound like this is purely aesthetic, but it is not. It takes
a lot of code to be capable of handling and creating the XML queries
that CalDAV requires, leading to the exclusion of some mobile devices.
Obviously this is just a pain to the desktop developer, but it is much
more serious in mobile development.

Also, where is the definition of the "urn:ietf:params:xml:ns:caldav"
and "DAV" namespaces? A schema is needed if correct XML is to be
expected!

My preferred solution would have been to provide some simple GET
access for the most obvious use cases, e.g. obtaining all events or
todo items, with the most common filters. To be honest, I struggle to
think of a case where a complex XML query would be required over
simple access! The XML query language is highly over-engineered as far
as I am concerned. I don't even believe an XML query language is
needed for CalDAV... it would have been enough to define an XML
response format.

# Burdensome queries and actions

I've already hinted that creating XML is often burdensome on mobile
devices, and also that creating new resources is not guaranteed to
succeed. As an example, consider creating a new VTODO item, given that
we know the collection URL. A PUT request is made to a URL that we
must create ourselves, and we must add the HTTP header "If-None-Match:
*". It is then non-obvious how one is expected to check the reason for
failure! Currently I am scanning the text of the Cosmo response for a
non-201 response and the String "If-None-Match disallows conditional
request", but this is clearly implementation specific. Creating new
resources could not have been designed to be more difficult.

Another classic example is timezone support. Prior to using CalDAV, I
had expected it to do all the grunt work of timezones... such that I
could make all my queries in GMT and never be confused. However, it
seems that CalDAV is expecting all clients (even mobile clients) to
have rich timezone support and to therefore have full international
iCal support.

My preferred solution would be to never expect clients to generate
unique URLs! Sending a POST to the base of the collections could add
the resource, and a response could indicate the server-assigned URL
and ETag, possibly even mirroring back the resource so that
server-added attributes would be known (e.g. the UID for VTODOs). I'd
also consider adding a mechanism whereby all resources are treated in
GMT and that the server does the conversions where necessary.

# No support for sharing

I am absolutely shocked at the lack of support for sharing or
delegating resources between users on a server. I can imagine that it
would be a difficult thing to do, but it would be of immense benefit
and increase the value of the CalDAV protocol by orders of magnitude.
It appears that even security issues have been considered
implementation details. Without having thought of this, I wonder why
CalDAV is so laborious. Without support for contacts, sharing and
delegation... I'm sorry to say, but I think CalDAV should really have
been quite a trivial API to design.

I've had a look at GroupDAV and I am not impressed with that effort.
Their reliance on WebDAV is again going to cause them problems, and it
has not received any traction, where CalDAV has... mostly because it
was the only protocol out there.

-- 
Shug

Date: Fri, 19 Sep 2008 20:25:13 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] [Fwd: I-D	Action:draft-desruisseaux-caldav-sched-05.txt]

Hi folks,

> -------- Original Message --------
> Subject: I-D Action:draft-desruisseaux-caldav-sched-05.txt
> Date: Fri, 19 Sep 2008 15:15:01 -0700 (PDT)
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : CalDAV Scheduling Extensions to WebDAV
> 	Author(s)       : C. Daboo, B. Desruisseaux
> 	Filename        : draft-desruisseaux-caldav-sched-05.txt
> 	Pages           : 55
> 	Date            : 2008-09-19

This new draft represents a major change to the caldav scheduling spec. The 
new protocol puts much more emphasis on the server to do all the work of 
scheduling rather than the client - so the server takes care of spotting 
changes to events that require scheduling messages to be sent and it does 
that. It also processes incoming scheduling messages automatically updating 
existing copies of the event to the new state.

These changes were prompted by implementation experience of the old drafts 
by several vendors of clients and servers. It was clear from these 
experiences that leaving too much up to the client was asking for trouble. 
Also, relying on the client to do a lot of the work introduces latencies 
into the update process that often prove unacceptable to users.

So here is the new spec. Please review and send comments. There are still a 
few areas that need a more work, but for the most part it should be 
complete, barring any oversights on the authors' part.

-- 
Cyrus Daboo

Date: Fri, 19 Sep 2008 20:00:28 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] [Fwd: I-D Action:draft-desruisseaux-caldav-sched-05.txt]

This is a multi-part message in MIME format.
--------------000206050509070903000905
Content-Type: multipart/alternative;
	boundary="------------050508050301070105090000"

--------------050508050301070105090000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

FYI

-------- Original Message --------
Subject: 	I-D Action:draft-desruisseaux-caldav-sched-05.txt
Date: 	Fri, 19 Sep 2008 15:15:01 -0700 (PDT)
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : CalDAV Scheduling Extensions to WebDAV
	Author(s)       : C. Daboo, B. Desruisseaux
	Filename        : draft-desruisseaux-caldav-sched-05.txt
	Pages           : 55
	Date            : 2008-09-19

This document defines extensions to the CalDAV "calendar-access"
feature to specify a standard way of performing scheduling
transactions with iCalendar-based calendar components.  This document
defines the "calendar-auto-schedule" feature of CalDAV.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------050508050301070105090000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
FYI<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
 cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>I-D Action:draft-desruisseaux-caldav-sched-05.txt</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Fri, 19 Sep 2008 15:15:01 -0700 (PDT)</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Reply-To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : CalDAV Scheduling Extensions to WebDAV
	Author(s)       : C. Daboo, B. Desruisseaux
	Filename        : draft-desruisseaux-caldav-sched-05.txt
	Pages           : 55
	Date            : 2008-09-19

This document defines extensions to the CalDAV "calendar-access"
feature to specify a standard way of performing scheduling
transactions with iCalendar-based calendar components.  This document
defines the "calendar-auto-schedule" feature of CalDAV.

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-05.txt">http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-05.txt</a>

Internet-Drafts are also available by anonymous FTP at:
<a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/</a>

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

</pre>
</body>
</html>

--------------050508050301070105090000--

--------------000206050509070903000905
Content-Type: Message/External-body;
	name="draft-desruisseaux-caldav-sched-05.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="draft-desruisseaux-caldav-sched-05.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

--------------000206050509070903000905
Content-Type: text/plain;
 name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message Part"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--------------000206050509070903000905--

Date: Fri, 19 Sep 2008 12:32:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] iTIP codes for CalDAV Schedule

Hi Arnaud,

--On September 19, 2008 4:49:43 PM +0200 Arnaud Quillaud 
<[email-masked]> wrote:

> When using CalDAV Schedule or iSchedule, for each recipient an iTIP
> status is returned in the response.
>
> Which iTIP status to use is not totally obvious from just reading the
> table at
> http://tools.ietf.org/html/draft-ietf-calsify-2446bis-07#section-3.6
>
> For example, what would be the code for:
> * a recipient in a domain not handled by this server ? 3.8 no authority ?
> * a recipient in a domain handled by this server but the recipient is
> unknown ? 3.7 invalid calendar user, 3.8 no authority ?....
> * a recipient in a domain handled by this server but the originator lacks
> privileges to send iTIP messages to this recipient ?
> * a recipient in a domain handled by this server but the recipient has
> reached his quota ?
>
> Then, assuming that the CalDAV Server is iSchedule enabled what would be
> the code for a recipient in a remote iSchedule domain but the remote
> iSchedule server is currently (temporarily) down ( CalDAV client ---->
> CalDAV Server --x--> remote iSchedule Server ) ?
>
> About that last case, and assuming a scheduling REQUEST, the CalDAV
> Server may elect to return SUCCESS to the client even if the remote
> server is down and try to redeliver asynchronously.
> Now how does the server notify the client that it eventually gave up
> trying ? iTIP seems to sugest that it should put a REPLY in the
> originator's inbox with a REQUEST-STATUS property set to 5.1 service
> unavailable. Should this type of behavior be mentioned in the spec ?
> What if the message to be sent is already a REPLY ?

Yes it would be better to be explicit about what iTIP codes appear in 
various cases. We have already done that to some extent in the new caldav 
scheduling draft which we should be posting later today or over the 
weekend. That includes defining some new 1.xx codes to cover delivery 
status information (including "server is still trying") as well as attendee 
reply status. Those cover some of the bullet points you had, so please 
review and comment when you see the new draft.

-- 
Cyrus Daboo

Date: Fri, 19 Sep 2008 16:49:43 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-caldav] iTIP codes for CalDAV Schedule

Hello,

When using CalDAV Schedule or iSchedule, for each recipient an iTIP 
status is returned in the response.

Which iTIP status to use is not totally obvious from just reading the 
table at 
http://tools.ietf.org/html/draft-ietf-calsify-2446bis-07#section-3.6

For example, what would be the code for:
* a recipient in a domain not handled by this server ? 3.8 no authority ?
* a recipient in a domain handled by this server but the recipient is 
unknown ? 3.7 invalid calendar user, 3.8 no authority ?....
* a recipient in a domain handled by this server but the originator 
lacks privileges to send iTIP messages to this recipient ?
* a recipient in a domain handled by this server but the recipient has 
reached his quota ?

Then, assuming that the CalDAV Server is iSchedule enabled what would be 
the code for a recipient in a remote iSchedule domain but the remote 
iSchedule server is currently (temporarily) down ( CalDAV client ----> 
CalDAV Server --x--> remote iSchedule Server ) ?

About that last case, and assuming a scheduling REQUEST, the CalDAV 
Server may elect to return SUCCESS to the client even if the remote 
server is down and try to redeliver asynchronously.
Now how does the server notify the client that it eventually gave up 
trying ? iTIP seems to sugest that it should put a REPLY in the 
originator's inbox with a REQUEST-STATUS property set to 5.1 service 
unavailable. Should this type of behavior be mentioned in the spec ?
What if the message to be sent is already a REPLY ?

Thanks,

Arnaud Q

Date: Thu, 18 Sep 2008 16:14:22 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Re: [Ietf-caldav] calendar-inbox and calendar-access support.
Cc: [email-masked]

Arnaud Quillaud wrote:
> Hello,
>
> The calendar scheduling draft at 
> http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-04 mentions 
> that:
>
> <<
>
>   A CalDAV scheduling server MAY also support the CalDAV calendar-
>   access feature [RFC4791 <http://tools.ietf.org/html/rfc4791>], and 
> that adds the following requirements:
>
>      MUST support the CALDAV:calendar-query and CALDAV:multiget REPORTs
>      on CALDAV:schedule-inbox and CALDAV:schedule-outbox collection
>      resource types.
>
>
> >>
>
> While this seems relatively straightforward for the multiget report, 
> timerange based filtering brings up a few questions:
> 1) Some itip objects may not contain any time related property (e.g. 
> VEVENT REPLY 
> http://tools.ietf.org/html/draft-ietf-calsify-2446bis-07#section-3.2.3). 
> Should those be considered as always matching, never matching,... ?

Always matching.  That's the approach we've used for VTODO in RFC4791.

> 2) May a calendar inbox/outbox be associated with a particular 
> timezone, just like a regular calendar collection ?
>
Yes. We will clarify that CALDAV:calendar-timezone MAY be set on the 
scheduling inbox collection.
> Extending question 2),  can a client expect a calendar-access enabled 
> inbox/outbox to expose the properties listed at 
> http://tools.ietf.org/html/rfc4791#section-5.2 ? It seems like it is 
> the case (e.g. CALDAV:max-resource-size is mentioned) but this is not 
> totally clear (e.g. CALDAV:supported-calendar-component-set is still 
> missing).

CALDAV:supported-calendar-data should definitely be supported on both 
the scheduling inbox and outbox collections. CALDAV:max-resource-size 
would also make sense, but then with the new scheduling approach it 
really is the value set on the scheduling calendar collection that will 
matter. Other than that, it's not clear that support for the other 
calendar collection properties is actually needed on the scheduling 
inbox and outbox collections.

Cheers,
Bernard
>
> Thanks,
>
> Arnaud Q
> _______________________________________________
> 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: Wed, 17 Sep 2008 13:54:18 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-caldav] calendar-inbox and calendar-access support.

Hello,

The calendar scheduling draft at 
http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-04 mentions that:

<<

   A CalDAV scheduling server MAY also support the CalDAV calendar-
   access feature [RFC4791 <http://tools.ietf.org/html/rfc4791>], and that adds the following requirements:

      MUST support the CALDAV:calendar-query and CALDAV:multiget REPORTs
      on CALDAV:schedule-inbox and CALDAV:schedule-outbox collection
      resource types.

 >>

While this seems relatively straightforward for the multiget report, 
timerange based filtering brings up a few questions:
1) Some itip objects may not contain any time related property (e.g. 
VEVENT REPLY 
http://tools.ietf.org/html/draft-ietf-calsify-2446bis-07#section-3.2.3). 
Should those be considered as always matching, never matching,... ?
2) May a calendar inbox/outbox be associated with a particular timezone, 
just like a regular calendar collection ?

Extending question 2),  can a client expect a calendar-access enabled 
inbox/outbox to expose the properties listed at 
http://tools.ietf.org/html/rfc4791#section-5.2 ? It seems like it is the 
case (e.g. CALDAV:max-resource-size is mentioned) but this is not 
totally clear (e.g. CALDAV:supported-calendar-component-set is still 
missing).

Thanks,

Arnaud Q