Subject: [Ietf-calsify] Interop results

From: pregen at egenconsulting.com ([email-masked])
Date: Thu Sep 2 13:04:00 2004

I wanted to give the list a status update on the interop results.  I am 
waiting on a reply back from one of the participants of the interop.  They 
expect to have the results back to me within two weeks. They got caught up 
in "work" (surprise - don't we all) and they are traveling to boot.

I have enough details that I can post what is working/not working, (based 
on all 4 interops) but if I include their last minute details we have a 
bunch more data.  I'd like to include that information because it relates 
to TODO's. 

I'll post another status update early next week.

---

From: TimHare at comcast.net ([email-masked])
Date: Sun Sep 5 19:29:26 2004

iTIP was the "transport-independent" format, and iCalendar was the format 
for the calendar objects - I think these two concepts are useful. I do 
think, however, that we are having serious problems trying to add outer 
layers to this (and I do think layered approaches work well, usually). In 
traditonal layered "things", each outer layer provides an envelope, and 
doesn't really care what the contents of the envelope are. In calendaring, 
however, it's hard to add an outer layer to exchange calendar objects, 
without reference to the objects - for example, you can't easily have a 
protocol layer for scheduling a meeting without the dates and times being 
exposed to that layer of the protocol.

I think that the interactive protocol (CAP) is _intended_  to be an outer 
layer for iTIP, but it does add a lot of new components, properties, and or 
values - and therefore a lot of complexity. I think that it's useful to 
consider how these all should relate - and perhaps IF we can layer these, 
rework things into layers. To that end, I would propose that we take the 
major elements list (and many thanks for the HTML table, by the way) and 
try to add two things to each element:

         A. What "protocol layer" the element has to be part of, if 
any,  using three(?) layers of iCalendar, iTIP, and the application layer
         B. What "level" the element has to be part of - level 0 being the 
most basic interoperability layer
             (and I guess we ought to define how many levels and what they are)

At 11:26 AM 8/30/04, Nathaniel Borenstein wrote:
>It's starting to sound to me like the transport format should be a 
>*subset* of the interactive access format.  Is that a useful thing to 
>consider in simplifying the documents?  -- Nathaniel
>
>On Aug 29, 2004, at 10:47 PM, Bernard Desruisseaux wrote:
>
>>Cameron Stillion wrote:
>>
>>>I would like to suggest the removal of VALARM from the iCal spec.
>>>  I have yet to hear or come up with a good scenario that includes sending
>>>alarm information from one client to another.
>>
>>Cameron,
>>
>>Here's a good scenario:
>>
>>1- I'm invited to a meeting.
>>
>>2- I synchronize my SyncML device.
>>
>>3- Since the calendar server knows that I want reminders
>>    with a 10 minutes lead time, the VEVENT uploaded to
>>    my SyncML device will contain a VALARM specifying an
>>    alarm 10 minutes prior the VEVENT start time.
>>
>>Don't ask me for a good scenario in the context of iTIP.
>>In my opinion, VALARM should not be used in the context
>>of iTIP. If you receive an iTIP message with a VALARM
>>just ignore it.
>>
>>Cheers,
>>Bernard
>>
>>_______________________________________________
>>Ietf-calsify mailing list
>>[email-masked]
>>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc.