Subject: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Mon Aug 21 20:06:06 2006

In section 3.2 Parameters of RFC 2445 it says:

 > If the iCalendar object contains more than one calendar component
 > type, then multiple component parameters MUST be specified.

But the specification is silent as what should be done with the
"method" parameter when the iCalendar object (or iCalendar stream)
is a sequence of iCalendar objects.

Old text:

 > The "method" parameter MUST be the same value as that
 > specified in the "METHOD" component property in the iCalendar object.
 > If one is present, the other MUST also be present.

New text:

 > The "method" parameter MUST be specified only for iCalendar
 > stream that contains a single iCalendar object. The "method"
 > parameter MUST be the same value as that specified in the "METHOD"
 > component property in the iCalendar object. If one is present,
 > the other MUST also be present.

Cheers,
Bernard

---

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Tue Aug 22 02:58:23 2006

Bernard Desruisseaux wrote:

> > stream that contains a single iCalendar object.

No, I think this is not correct. It is Ok to have multiple iCalendar 
objects in an iCalendar stream, as long as they all have the same METHOD 
property.
Otherwise miltipart/mixed containing several text/calendar has to be used.

> The "method"

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Tue Aug 22 12:59:59 2006

> objects in an iCalendar stream, as long as they all have the same METHOD 

Where is that defined?

My reasoning is that if the iCalendar stream contains more than one
iCalendar object then it most likely doesn't describe a scheduling
transaction, and thus you probably shouldn't specify a "method"
parameter in the Content-Type header field.

Cheers,
Bernard

---

From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell)
Date: Tue Aug 22 13:03:57 2006

If I invite a new attendee to a repeating meeting that has  been modified 
after the rule was created than the iCalendar stream should have original 
invite with rule plus additional VEvents for the modified dates.

Bernard Desruisseaux <[email-masked]> 
Sent by: [email-masked]
08/22/2006 04:00 PM

To
Alexey Melnikov <[email-masked]>
cc
Calsify WG <[email-masked]>
Subject
Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of 
iCalendar objects

Where is that defined?

Cheers,
Bernard
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060822/f61e8810/attachment.html

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Tue Aug 22 13:20:44 2006

Hi Robert,

> invite with rule plus additional VEvents for the modified dates.

Right, but in terms of iTIP that would all be sent as a single iCalendar 
object (one BEGIN/END:VCALENDAR) so there would be a single METHOD. As far 
as iTIP is concerned, you can only ever send one iCalendar object per 
transaction (i.e. per MIME type). However, iCalendar itself does not have 
that restriction - multiple iCalendar objects per iCalendar stream (mime 
part) is allowed.

The question is how to handle the method= mime parameter for multiple 
iCalendar objects per stream (mime part). I think Bernard's argument that 
method= is not specified is fine since such an object is not being used in 
iTIP, and thus method is not of interest.

-- 
Cyrus Daboo

---

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Thu Aug 24 08:52:30 2006

Bernard Desruisseaux wrote:

>> objects in an iCalendar stream, as long as they all have the same 
>> METHOD property.
>
> Where is that defined?

It is nowhere prohibited :-).

> parameter in the Content-Type header field.

I don't feel good about disallowing "method" with iCalendar stream 
containing multiple objects.
An implementation already has to check if the "method" parameter matches 
what is specified in the calendar stream with a single object. It is not 
difficult to check all objects.

Does anybody have some statistics on how frequently a calendar stream 
can contain multiple calendar objects?