Subject: Interop Results

From: [email-masked]
Date: Tue, 2 Nov 2004 17:25:46 -0500

The results of the interop held at UC Berkeley are done and can be located 
at the following URLs.

http://www.calconnect.org/interop/uc%20berkeley%20interop%20testing.pdf 
(document) 
http://www.calconnect.org/interop/8-2004-results.pdf   (spreadsheet link)

---

From: Doug Royer <[email-masked]>
Date: Wed, 03 Nov 2004 11:19:53 -0700

[ALSO sent to CALSIFY]

It looks like all the interop results and summary agree that we need
to have basic objects that can be parsed by non-recurrence aware
applications if for no other reason to allow  implementations that support
some sub-sets of recurrence rules to parse the data.  The new recur-draft
can nail down the exact set that must be implemented in order to be
compliant. . By having the organizer's CUA expand the instances and set
the RECURRENCE-ID value to UTC, it is a format that  at least contains
all of the recurrence data.

In addition it looks like VALARM needs to be an add on as there
is a low level of interoperability between vendors.

In some cases it is hard to tell of the vendor did not support a 
feature, or if
their support is not working per RFC.

It also looks that iTIP needs to be broken down into perhaps individual
METHODs: PUBLISH, REQUEST/REPLY, delegation support,  CANCEL,
ADD,... drafts.

So it looks like we need separate drafts for:

   - Basic - with VEVENT - that describes how to send 2445 recurrence 
rules.

           Implementations that implement 'Basic' can send 2445 
(pre-iCal-Recurence) recurrence
           rules, but if they indicate they support iCal-Recurrence, 
then they would have
           to conform to iCal-Basic and iCal-Recurrence. They can also 
send 2445 VTIMEZONE
           with those objects.

   - VALARM - Do we deprecate PROCEDURE?

   - VTODO

   - Recurrence and VTIMEZONE
           I include VTIMEZONE here as VTIMEZONE is not really needed until
      recurrence rules are included.

   - METHOD:VFREEBUSY

   - METHOD:PUBLISH

   - METHOD(s): REQUEST/REPLY/CANCEL/REFRESH - including how to schedule.

      I think that if you have REQUEST, you have to have REPLY, CANCEL, 
and REQUEST.

   - Delegation

      Viewing the results and my testing is clear that most do not 
support this feature.
       So I think it needs to be optional.

   - METHOD: ADD - Or should this be part of REQUEST.

   - VJOURNAL??

   - New iMIP.

[email-masked] wrote:

>
> The results of the interop held at UC Berkeley are done and can be 
> located at the following URLs.
>

-- 

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

              We Do Standards - You Need Standards