[Ietf-caldav] various comments on scheduling outbox

[Bernard Desruisseaux]

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 -- Ietf-caldav at osafoundation.org
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>