Subject: [Ietf-calsify] List issues so far.

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Mon Sep 13 17:40:51 2004

Good Catch Oren... Perhaps it hasn't been mentioned yet.  I heartily
agree that we should remove this "additionally confusing way" to group
calendar events.  Especially since there is no clear statement of what
it means to do so, or why a CUA would want to...

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Oren
Sreebny
Sent: Monday, September 13, 2004 5:31 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.

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?

- Oren

On Mon, 13 Sep 2004, Doug Royer wrote:

>
>        List if ideas (in random order) on this list.
>
>        (1). 2445 - (iCAL) Changes and fixes.
>
>        (1.1) 2445 - Split into separate drafts
>
>        This allows for separation of topics and allows each to make
>        it or not to standard.
>
>        (1.1.1) 2445 - Basic which includes VEVENT
>
>        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
>
>        (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
>        want to do this, we need a more specific proposal.
>
>        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>        are saying  want  to  do  this,  we  need  a  more  specific
>        proposal.
>
>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?
>
>        (1.1.2.3) 2445 - No more than one RRULE per component?  I think
>        we  are  saying  we want to do this, we need a more specific
>        proposal.
>
>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>        want  to  do this, we need a more specific proposal and will
>        involve time zone data being evaluated at CUA only.
>
>        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>        want to do this.
>
>        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>        values. (FBTYPE).  Do we need more discussion?
>
>        (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  CUAs  that
>        can  not  display  the  data  ignore it anyway.  Having this
>        property does not break CUAs that do not use it.   How  many
>        use this?
>
>        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  Thin CUA's
>        can not use it anyway and ignore it.  Having  this  property
>        does  not break CUAs that do not use it.  How many use this?
>
>        This eliminates the need to send VTIMEZONE.
>
>        (1.1.2.9) 2445 - Deprecate properties
>
>        (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
>        GREGORIAN in scope at this time.
>
>        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
>
>        (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
>        undefined  meaning  must  be  deprecated  as  there  is   no
>        interoperability.
>
>        (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
>        to keep this.  See "Access Control" below.
>
>        (1.1.3) 2445 - New VTODO draft
>
>        (1.1.4) 2445 - New VJOURNAL draft
>
>        (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
>        them.  Need an exhaustive discussion.
>
>        (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
>        proposal on new time zone format for CUAs  to  share  common
>        time zone data.  Need more feedback.
>
>
>
>        (2) 2446 - (iTIP) Changes and fixes.
>
>        (2.1) 2446 - Simplify updates - settle on one way
>
>
>
>        (3) 2447 - (iMIP) Changes and fixes.
>
>        (3.1) 2447 - Specify minimum  MIME support needed
>
>
>        (4)  New - Access Control
>
>        The  access  control  over  iMIP  is not the same as access
>        control needed for client/server transport of objects.  Need
>        to define and document.
>
> --
>
> 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
>
>
>
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify