Subject: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Mon Sep 13 18:37:47 2004

I agree with the question...

> The question we need to ask is:
> 
>    Do we want to be able to transfer 'sync' an entire calendar in one
pass?
>
> If yes, then we have to allow multiple BEGIN/END per transfer.

But I disagree with your reasoning.

Transferring an entire calendar in one pass - does not seem to require
more than one METHOD. If I am publishing an entire calendar, then I have
one VCALENDAR with METHOD=PUBLISH.  If I am sending a request for you to
attend a whole calendar's worth of meetings, then I presume I have one
VCALENDAR with METHOD=REQUEST.  

The scenario you describe above seems to never need more than one
method.  Only when batching multiple REQUEST/UPDATE/PUBLISH do we get
into needing multiple VCALENDARS. But this is not processing a calendar
so much as processing multiple transactions to a calendar.

Perhaps I'm looking at it more from a client transport interop
perspective again... But if so, then help me understand the real
scenario that leads us to this need.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Monday, September 13, 2004 6:15 PM
To: [email-masked]
Subject: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?

I think its a new issue.

When transferring only booked entries one begin/end works.

However METHOD is global to BEGIN/END VCALENDAR and you can not have a
single BEGIN/END VCALENDAR that contains more than one METHOD value
type.

So, if you are transporting more than one METHOD, you MUST use multiple
BEGIN/END VCALENDAR objects.

iMIP  enforces only one METHOD per MIME object.
So you can not transfer an entire calendar in one iMIP MIME object
anyway.

CAP has a VCALSTORE component that can encapsulate many VCALENDAR
objects as a way to solve that problem.

Do we want to create a wrapper object (VCALSTORE?) so that we can
transfer multiple METHOD VCALENDAR objects?

If not, then implementations that do not accept multiple BEGIN/END
vcalendar objects can not transfer any iTIP object that might be in a
calendar in a single transfer.

Not an answer - just some info...

The question we need to ask is:

    Do we want to be able to transfer 'sync' an entire calendar in one
pass?

If yes, then we have to allow multiple BEGIN/END per transfer.

I think the answer is yes.

Oren Sreebny wrote:

>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core Object is a 
>collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped
together."
>
>But implementations don't all support multiple VCALENDAR blocks - for 
>instance, in Oracle Cal when you export iCalendar data it surrounds  
>each VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither 
>Apple's iCal nor Outlook will accept that as an import format - they 
>want all the VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
>  
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 14 06:59:40 2004

>VCALENDAR with METHOD=REQUEST. 
That is one mode of using calendars.

The other is that the data transfer -into- the calendar is automatic.
And the CUA reads from the calendar. For example it is possible
for iTIP REQUESTS to be stored in the CS until processed by the CUA.

Those are client/server CUA/CS's. They must transfer all iTIP methods
objects to/from the CS.  So if you send me a REQUEST, it will be stored
in my calendar, even when my CUA is not running. Later when I start
my CUA it will load my calendar (PUBLISH/REQUEST/ADD/whatever).

Those are the requirements for client/server implementations.

This is not an issue for  iMIP-CUA's as iMIP only allows one METHOD
per object anyway..  For non-iMIP CUAs this will be an issue. Both
models exists. CalDav looks to be a client/server model also.

Ether way it still does not solve the problem that some (1?) 
implementation(s)
split each VEVENT into a separate VCALENDAR objects, even when
all of the METHOD values are the same.

Or is it that only one implementation can not handle multiple BEGIN/END
VCALENDAR even when all have the same METHOD value ?

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040914/236322b4/smime.bin