Subject: [Ietf-calsify] Recommendationsfor strippingdown iCaltoa manageable 'standard'

From: Carol.Tsai at Reardencommerce.com (Carol Tsai)
Date: Fri Oct 28 09:31:35 2005

Hi Cameron,

I was researching on how to create an iCal that has the show as time be Tentative when I came accross your posting (http://lists.osafoundation.org/pipermail/ietf-calsify/2004-August/000050.html). I was wondering if you received a reply to that? I agree that the TRANSP property doesn't seem to have a Tentative option.

Carol Tsai

REARDEN commerce
1400 Fashion Island Blvd Suite 150
San Mateo Ca 94404

T 650 212 8474
F 650 212 8499

www.reardencommerce.com <http://www.reardencommerce.com>

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Fri Oct 28 20:11:29 2005

Hi Carol,

In the thread you are making reference to, Doug is saying:

 > In CAP for example you can ask for the dynamic
 > VFREEBUSY object that represents the free time from a calendar.

it would be interesting to know how that works in CAP.

Cheers,
Bernard

Carol Tsai wrote:

> Hi Cameron,
> 
> I was researching on how to create an iCal that has the show as time
> be Tentative when I came accross your posting
> (http://lists.osafoundation.org/pipermail/ietf-calsify/2004-August/000050.html).
> I was wondering if you received a reply to that? I agree that the
> TRANSP property doesn't seem to have a Tentative option.
> 
> Carol Tsai
> 
> REARDEN commerce 1400 Fashion Island Blvd Suite 150 San Mateo Ca
> 94404
> 
> T 650 212 8474 F 650 212 8499
> 
> _______________________________________________ Ietf-calsify mailing
> list [email-masked] 
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Fri Oct 28 20:43:06 2005

Carol,

The table I posted in a separate thread was built with the
assumption that the "TENTATIVE" part in "BUSY-TENTATIVE" was
derived from STATUS:TENTATIVE based on the following information:

RFC 2445, section 4.2.9 Free/Busy Time Type:

  The value BUSY-TENTATIVE indicates that the time interval is busy
  because one or more events have been *tentatively scheduled* for
  that interval.

RFC 2445, section 4.8.1.11 Status:

  Description: In a group scheduled calendar component, the property is
  used by the "Organizer" to provide a confirmation of the event to the
  "Attendees". For example in a "VEVENT" calendar component, the
  "Organizer" can indicate that a meeting is tentative, confirmed or
  cancelled.

You may ask "But what if I tentatively accepted the event?" (i.e.,
you set PARTSTAT=TENTATIVE on *your* ATTENDEE property). Shouldn't
the derived FBTYPE be BUSY-TENTATIVE even though the event might
have been confirmed by the Organizer (i.e., STATUS:CONFIRMED)?
It seems not.

Section 4.8.1.11 makes me believe that an attendee would not change
the value of the STATUS property set by the Organizer (i.e., "the
property is used by the Organizer..."). But I don't believe it is
the case for the TRANSP property given that its purpose is to "define
whether an event is transparent or not to busy time searches" on a
calendar. The same way you would ignore/modify the VALARM that you
would receive from the Organizer, you would also ignore/modify the
value of the TRANSP property as you wish.

Cheers,
Bernard

---

From: Anil.Srivastava at Sun.COM (Anil SRIVASTAVA)
Date: Sat Oct 29 08:44:39 2005

> have been confirmed by the Organizer (i.e., STATUS:CONFIRMED)?

That being the case, I think it is clearly broken.  The attendees 
individual acceptance status has to play a role in the dynamically 
generated FB time.  If an attendee has not accepted the event or 
declined it, then clearly they are not attending the meeting the 
organizer put together and are therefor available. 

PARTSTAT of an attendee should take precedence over the STATUS property.  

Anil

> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]

-- 
_______________
Anil SRIVASTAVA
[email-masked]

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Sat Oct 29 09:02:17 2005

Part of the iCalendar model confusion here is whether the VEVENT  
component is part of a personal calendar, or part of a shared  
repository of events.

In the case where VEVENTs are in a personal calendar, stored only on my  
machine (or on a server where other agents don't view the event as part  
of their calendar), then in that context it would be reasonable to  
model free-busy as being independent from attendance.    In this  
model/context:
  - Any event in a personal calendar that is confirmed and opaque would  
affect free-busy.
  - Even if there is no attendance list, it's on the personal calendar  
and opacity means it affects free-busy.
  - If there is an attendance list, and the user is not on that list,  
it's still on their personal calendar and thus opacity means it affects  
free-busy.
I believe this is the way most personal calendars work today, importing  
ICS files or storing data in ICS files locally or via WebCAL.

In the case where VEVENTs are in a shared repository, where multiple  
individuals view the same component, now attendance would affect  
free-busy.
  - If the user shows up as an attendee, and the event is confirmed, and  
the event is opaque, this would affect free-busy
  - Possibly opacity and status should be per-user properties.  Several  
attendees of a meeting might be in different stages of invitations --  
some confirmed, some only tentative.
I believe some shared calendar servers do work this way today and they  
should describe what they've actually implemented and what that means  
for iCalendar.

But what context dependencies mean for the overall discussion is that  
we can't discuss what free-busy means independent of context.  It may  
be very difficult to standardize this in just one way in RFC2445 bis  
and we should keep in mind other possibilities.  For example, we could  
split RFC2445 bis into several sections/documents
   1. the base format, used in many contexts
   2.  what different elements of the base format mean in import/export  
of ICS files for personal calendars
   3.  what different elements of the base format mean in iTIP usage

Lisa

On Oct 29, 2005, at 8:43 AM, Anil SRIVASTAVA wrote:

> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Oct 29 11:57:26 2005

> it would be interesting to know how that works in CAP.

CAP has the concept of BOOKED items. So only BOOKED items
are used in the results:

     Such a CS MUST dynamically create the results of a search for
    "VFREEBUSY" components at search time when searching for STATE() =
    'BOOKED' items.

And it gets more complex depending on if the CAP server can
or can not expand recurrences.

There was never any agreement on how the VFREEBUSY contents
were calculated, so it is unspecified. And I do not think
that there is a predefined solution that will work for
all calendars or implementations.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

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

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Oct 29 12:32:04 2005

> ...
 > It may be very difficult to standardize this in just one way in 
RFC2445 bis
>   3.  what different elements of the base format mean in iTIP usage

OR - make TRANSP a calendar owner property that is only used as a hint
on import and allow the calendar owner to alter the value when a remote
event is stored locally. Then once stored in the local calendar the
TRANSP has a meaning only for that local calendar. Then the ATTENDEEs
PARTSTAT parameter can be ignored for free-busy calculations as the
owner of the local calendar where the copy of the event is stored has
full control of he TRANSP property.

I can publish a VFREEBUSY that is a composite of multiple calendars.
So all of the above proposals can only be a guideline for computing
the BUSY time and not a rule that must match the contents of
a VFREEBUSY object to a specific calendar.

--

---

From: cbryant-ical at corp.usa.net (Chris Bryant)
Date: Sun Oct 30 18:21:14 2005

> full control of he TRANSP property.
Handling the TRANSP this way makes sense to me, and this is the way we 
handle it today.  There are other attributes that we also handle this way, 
including VALARMs, CATEGORY, PRIORITY, and CLASSIFICATION.  All of these 
make sense as a suggestion in iTIP, but may mean something different to an 
individual participant, and therefore a participant should be able to change 
their own settings for the event once it is in their own calendar.

This does not completely avoid the PARTSTAT issue, because TRANSP identifies 
busy or free, but not tentative.  To determine if a meeting is tentative, we 
need to also either look at the individuals PARTSTAT entry for a group 
event, or the STATUS for an individual event.

This approach works well when each user has their own copy of all events, 
but does not work well when a server tries to use a shared model to store 
information for multiple users in one iCal VEVENT.  But I think the shared 
model is a case where 2445 is being stretched as a storage model when it was 
really made as a transport model.

Chris Bryant 

From: "Chris Bryant" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Ietf-calsify] Transparency, status, attendance and free-busyinteractions
Date: Sun, 30 Oct 2005 21:21:06 -0500
Organization: USA.NET
Z-USANET-MsgId: XID913JJEcVJ0489X29

> full control of he TRANSP property.
Handling the TRANSP this way makes sense to me, and this is the way we 
handle it today.  There are other attributes that we also handle this way, 
including VALARMs, CATEGORY, PRIORITY, and CLASSIFICATION.  All of these 
make sense as a suggestion in iTIP, but may mean something different to an 
individual participant, and therefore a participant should be able to change 
their own settings for the event once it is in their own calendar.

This does not completely avoid the PARTSTAT issue, because TRANSP identifies 
busy or free, but not tentative.  To determine if a meeting is tentative, we 
need to also either look at the individuals PARTSTAT entry for a group 
event, or the STATUS for an individual event.

This approach works well when each user has their own copy of all events, 
but does not work well when a server tries to use a shared model to store 
information for multiple users in one iCal VEVENT.  But I think the shared 
model is a case where 2445 is being stretched as a storage model when it was 
really made as a transport model.

Chris Bryant 

Date: Sat, 29 Oct 2005 13:32:00 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Transparency, status, attendance and free-busy interactions
Reply-To: [email-masked]

RFC2445 bis

-- 

Date: Sat, 29 Oct 2005 12:57:21 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030008060301050201010404
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

-- 

--------------ms030008060301050201010404
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030008060301050201010404--

From: Lisa Dusseault <[email-masked]>
Date: Sat, 29 Oct 2005 09:02:04 -0700
To: [email-masked]
Cc: [email-masked], Carol Tsai <[email-masked]>, [email-masked]
Subject: [Ietf-calsify] Transparency, status, attendance and free-busy interactions

Lisa

>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Sat, 29 Oct 2005 08:43:55 -0700 (Pacific Daylight Time)
From: Anil SRIVASTAVA <[email-masked]>
Subject: Re: [Ietf-calsify] Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Organization: Sun Microsystems [http://www.sun.com]
Accept-Language: English; en
Cc: [email-masked], [email-masked], Carol Tsai <[email-masked]>
Reply-To: [email-masked]

Anil

-- 
_______________
Anil SRIVASTAVA
[email-masked]

Date: Sat, 29 Oct 2005 10:19:19 +0300
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Draft agenda published

All,

The working group agenda has been posted here:
http://www3.ietf.org/proceedings/05nov/agenda/calsify.html

Changes are possible still, and of course, comments are welcome!

Cheers,
Aki

Date: Fri, 28 Oct 2005 23:43:04 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Carol Tsai <[email-masked]>
Subject: Re: [Ietf-calsify] Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'
Cc: [email-masked], [email-masked]

Carol,

Cheers,
Bernard

> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 28 Oct 2005 23:10:58 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Carol Tsai <[email-masked]>
Subject: Re: [Ietf-calsify] Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'
Cc: [email-masked]

Hi Carol,

Cheers,
Bernard

> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 28 Oct 2005 15:57:41 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Re: [Ietf-caldav] How to derive FREEBUSY;	FBTYPE from a VEVENT?
Reply-To: Calsify WG <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms060306090403060003040201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

>>I can have the Dallas Cowboys football team on my calendar. Each game
>>could have a TRANSP:OPAQUE property because that is what I imported
>>from their web page ICS file.. 
> 
> 
> Just because you got a calendar with "wrong" settings, doesn't mean the 
> standard needs to support this...
> The TRANSP needs to be used for automatic F/B creation,

I disagree that it is a 'NEED'.

> since that's the only 
> hint a GW server (or a fat client) has about which time is free and which is 
> busy.

I do agree that it is a 'HINT'.

It is not the wrong settings. The ORGANIZER of the Dallas Cowboys
football team could in fact set and want it to be TRANSP:OPAQUE
because the game consumes time.

I do want my time to be FREE for the game because I will
not be attending, and because I want work to be able to book
that time in my calendar.

TRANSP:OPAQUE is what the ORGANIZER sent, it does not force
me to be busy simply because I have it on my calendar. It means
that -IF- I accept it as more important than work this
time, then I am BUSY.

FREEBUSY is for the calendar, not always the ORGANIZER and
not always a specific ATTENDEE.

It is also possible that I got a METHOD:REQUEST + TRANSP:OPAQUE
+ STATUS:CONFIRMED component and I want in my calendar even
when I sent a PARTSTAT=DECLINED METHOD:REPLY. My time is NOT
busy for that meeting that I decline to attend. While at the
same time having that entry in my calendar as I need to know
that a meeting is taking place.

Only the owner of the calendar knows if the time is booked
or FYI for a specific calendar.

A specific implementation might want to automate it as
you state above. However I will not be BUSY just because a I
have an iMIP vevent for a TV show entry from a calendar where
the entry is OPAQUE.

I can also come up with cases where OPAQUE always
means BUSY - a resource calendar for example. So I agree that
some implementation may want to automate the BUSY time. I disagree
that that the ORGANIZER always gets to mandate if I am BUSY.

-- 

--------------ms060306090403060003040201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060306090403060003040201--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Re: [Ietf-caldav] How to derive FREEBUSY; FBTYPE from a VEVENT?
Date: Fri, 28 Oct 2005 23:05:45 +0200

Am Freitag, 28. Oktober 2005 22:31 schrieb Doug Royer:
> Cyrus Daboo wrote:
> > I don't think either of these should ever be 'derived' from a VEVENT.
> > Rather, if a user wants to specify those, they directly create a
> > VFREEBUSY object in their calendar and use that.
>
> I agree. An event could exist that if happens, I NEED to be there,
> so I would mark MY time as BUSY. And have it in my calendar.
>
> Other events could be likely to occur, yet I am not sure I will attend
> and I would NOT mark MY time as BUSY. And have it in my calendar.
>
> While both of the above VEVENTs from the ORGANIZER could have the TRANSP
> property set to OPAQUE - meaning that it consumes time when booked
> by the ATTENDEE.  So the ORGANIZER in both cases is saying this is
> an OPAQUE VEVENT, if you decide to that you will be using that time
> for that reason.
>
> I can have the Dallas Cowboys football team on my calendar. Each game
> could have a TRANSP:OPAQUE property because that is what I imported
> from their web page ICS file.. 

Just because you got a calendar with "wrong" settings, doesn't mean the 
standard needs to support this...
The TRANSP needs to be used for automatic F/B creation, since that's the only 
hint a GW server (or a fat client) has about which time is free and which is 
busy.

> Yet I will not be attending. I may 
> wish to just watch it on TV if I am not otherwise busy. 

"Attending" doesn't necessarily mean that you are there. You can also attend 
via TV etc. All that's important is if you want to mark that time as free or 
not.

> So I would 
> mark that time as FREE and still have it on my calendar. 

Yes, TRANSP:FREE. Nobody stops you from modifying that football game from 
OPAQUE to FREE.

> I also may 
> have the super bowl game marked as BUSY even when I will not be
> attending.

Sure, TRANSP:OPAQUE
Most calendaring apps (at least korganizer and evolution) let you select if 
the time of the event should be marked as busy or as free.

> I do not think that you can have a table that says if TRANSP is OPAQUE
> then the time MUST BE BUSY, even if on my calendar.

RFC 2445 says: 
   Events that consume actual time for the individual or resource associated
   with the calendar SHOULD be recorded as OPAQUE, allowing them to be
   detected by free-busy time searches. Other events, which do not take
   up the individual's (or resource's) time SHOULD be recorded as
   TRANSPARENT, making them invisible to free-busy time searches.

So, you are right, it's not a MUST, "only" a SHOULD... Basically that 
paragraph says that there is a 1:1 correspondence.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer maintainer

Date: Fri, 28 Oct 2005 14:31:32 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Re: [Ietf-caldav] How to derive FREEBUSY; FBTYPE from a VEVENT?
Reply-To: Calsify WG <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms020307020009080100030907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Cyrus Daboo wrote:

> 
> I don't think either of these should ever be 'derived' from a VEVENT. 
> Rather, if a user wants to specify those, they directly create a 
> VFREEBUSY object in their calendar and use that.

I agree. An event could exist that if happens, I NEED to be there,
so I would mark MY time as BUSY. And have it in my calendar.

Other events could be likely to occur, yet I am not sure I will attend
and I would NOT mark MY time as BUSY. And have it in my calendar.

While both of the above VEVENTs from the ORGANIZER could have the TRANSP
property set to OPAQUE - meaning that it consumes time when booked
by the ATTENDEE.  So the ORGANIZER in both cases is saying this is
an OPAQUE VEVENT, if you decide to that you will be using that time
for that reason.

I can have the Dallas Cowboys football team on my calendar. Each game
could have a TRANSP:OPAQUE property because that is what I imported
from their web page ICS file.. Yet I will not be attending. I may
wish to just watch it on TV if I am not otherwise busy. So I would
mark that time as FREE and still have it on my calendar. I also may
have the super bowl game marked as BUSY even when I will not be
attending.

I do not think that you can have a table that says if TRANSP is OPAQUE
then the time MUST BE BUSY, even if on my calendar.

-- 

--------------ms020307020009080100030907
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020307020009080100030907--

Date: Fri, 28 Oct 2005 14:12:33 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Re: [Ietf-caldav] How to derive FREEBUSY; FBTYPE from a VEVENT?
Reply-To: Calsify WG <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms020002030300050506000500
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Cyrus Daboo wrote:

> 
> One other thing that came up as I reviewed this: its not totally clear 
> to me how free-busy is supposed to work with all day events. If I have 
> an all day event marked with TRANSP=OPAQUE, should the FREEBUSY property 
> specify a date-time or a date only? 2445 only seems to show timed cases 
> and kind of implies that times are always required. Can this be clarified?

The ABNF in 2445 says:

fbvalue    = period *["," period]
      ;Time value MUST be in the UTC time format.

And:

      period     = period-explicit / period-start

      period-explicit = date-time "/" date-time
      ; [ISO 8601] complete representation basic format for a period of
      ; time consisting of a start and end. The start MUST be before the
      ; end.

      period-start = date-time "/" dur-value
      ; [ISO 8601] complete representation basic format for a period of
      ; time consisting of a start and positive duration of time.

The FREEBUSY property is a date-time only value in UTC. And 'period'
can not be a 'date' only value.

The reason that it is in UTC, is that the VREEBUSY property
only exists in a VFREEBUSY component, and a VFREEBUSY component
does not contain a VTIMEZONE component.

So without it being a UTC date/time value, it would be impossible
to determine what slice is busy across time zones for an 'all-day'
event in the ORGANIZERS unspecified time zone .

-- 

--------------ms020002030300050506000500
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020002030300050506000500--

Date: Fri, 28 Oct 2005 10:52:01 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-calsify] Re: [Ietf-caldav] How to derive FREEBUSY; FBTYPE from a VEVENT?

Hi Bernard,

--On October 28, 2005 10:30:34 AM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> When would a calendar application derive FBTYPE=BUSY-UNAVAILABLE ?
>
> When would a calendar application derive FBTYPE=x-name ?

I don't think either of these should ever be 'derived' from a VEVENT. 
Rather, if a user wants to specify those, they directly create a VFREEBUSY 
object in their calendar and use that.

That said, I certainly would like to see a table like the one you created 
appearing in either 2445bis or 2446bis.

One other thing that came up as I reviewed this: its not totally clear to 
me how free-busy is supposed to work with all day events. If I have an all 
day event marked with TRANSP=OPAQUE, should the FREEBUSY property specify a 
date-time or a date only? 2445 only seems to show timed cases and kind of 
implies that times are always required. Can this be clarified?

-- 
Cyrus Daboo

Date: Fri, 28 Oct 2005 10:30:34 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-calsify] How to derive FREEBUSY;FBTYPE from a VEVENT?

The FBTYPE parameter of FREEBUSY properties of VFREEBUSY components
can take one of the following values:

  - FREE
  - BUSY
  - BUSY-UNAVAILABLE
  - BUSY-TENTATIVE
  - x-name

How can a calendar application (e.g., CalDAV Server) derive the
proper FBTYPE value from a given VEVENT?

Assuming that the FBTYPE parameter of the FREEBUSY property of
a VFREEBUSY component should be derived from the TRANSP and
STATUS properties of the VEVENT component, does the following
table make sense?

     +---------------------------++------------------+
     |          VEVENT           || VFREEBUSY        |
     +-------------+-------------++------------------+
     | TRANSP      | STATUS      || FBTYPE           |
     +=============+=============++==================+
     | TRANSPARENT | <Any value> || FREE             |
     +-------------+-------------++------------------+
     |             | CANCELLED   || FREE             |
     |             +-------------++------------------+
     |             | <Undefined> || BUSY             |
     | OPAQUE      | CONFIRMED   ||                  |
     | <Undefined> +-------------++------------------+
     |             |    ???      || BUSY-UNAVAILABLE |
     |             +-------------++------------------+
     |             | TENTATIVE   || BUSY-TENTATIVE   |
     +-------------+-------------++------------------+

When would a calendar application derive FBTYPE=BUSY-UNAVAILABLE ?

When would a calendar application derive FBTYPE=x-name ?

Cheers,
Bernard

Content-class: urn:content-classes:message
Subject: [Ietf-calsify] Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'
Date: Thu, 27 Oct 2005 01:02:31 -0700
From: "Carol Tsai" <[email-masked]>
To: <[email-masked]>

Hi Cameron,

I was researching on how to create an iCal that has the show as time be =
Tentative when I came accross your posting =
(http://lists.osafoundation.org/pipermail/ietf-calsify/2004-August/000050=
.html). I was wondering if you received a reply to that? I agree that =
the TRANSP property doesn't seem to have a Tentative option.

Carol Tsai

REARDEN commerce

T 650 212 8474
F 650 212 8499

To: [email-masked]
From: [email-masked]
Sender: Michael Lee <[email-masked]>
Date: Wed, 26 Oct 2005 18:50:02 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-00.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux, C. Stoner
	Filename	: draft-ietf-calsify-rfc2445bis-00.txt
	Pages		: 166
	Date		: 2005-10-26
	
   Calendar systems export, transport and sometimes even store calendar
   information in a standard, interoperable format.  This memo defines
   the common format for openly exchanging calendaring and scheduling
   information across the Internet, known as the iCalendar object
   format.  An iCalendar object may represent an event, to-do or task,
   or journal entry (note).

   Comments are solicited and should be addressed to the working group's
   mailing list at [email-masked] and/or the editor.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-calsify-rfc2445bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2445bis-00.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Sun, 23 Oct 2005 08:36:41 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Aki Niemi <[email-masked]>
Subject: Re: [Ietf-calsify] xCal - time to submit?
Cc: [email-masked], Calsify <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030700080105030901050508
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Aki Niemi wrote:
> [Speaking as individual again]
> 
> Inline.
> 
> ext Doug Royer wrote:
> 
>>
>>
>> Aki Niemi wrote:
>>
>>> [Speaking as an individual, not chair.]
>>>
>>> Hi,
>>>
>>> A couple of issues occured to me while reading the draft:
>>>
>>> First, the problem this draft is trying to solve seems approximately 
>>> the same that MMUSIC aimed at in its SDPng work, in which the idea 
>>> was to move from the current SDP into an XML based format. Even the 
>>> core difficulty seems to be the same, namely the huge installed base 
>>> only supporting the legacy format makes transition a bit hairy. 
>>
>>
>> What move?
> 
> 
> As in stop using the current format and start using the new one.

What new one? xCal is YEARS old.

Its clear that you have not really read xCal. And it is clear
that you are not interested in discussing any real points in the draft.

-- 

--------------ms030700080105030901050508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030700080105030901050508--

Date: Sun, 23 Oct 2005 14:57:39 +0100
Subject: Re: [Ietf-calsify] xCal - time to submit?
From: Dave Cridland <[email-masked]>
To: Aki Niemi <[email-masked]>
Cc: [email-masked], [email-masked], "[email-masked]" <[email-masked]>

On Sun Oct 23 13:28:11 2005, Aki Niemi wrote:
> ext Doug Royer wrote:
>> What move?
> 
> As in stop using the current format and start using the new one.
> 
>> What transition?
> 
> As in how to cope with the co-existance of applications that 
> support the  new format and the old format, and applications that 
> only support the old format.

I think the problem with xCal is not that it's an irrelevant and 
pointless format, because it isn't - I think it's potentially very 
useful. But it's nothing to do with this WG, which is why reaction is 
pretty hostile. Here, the WG is trying to get decent interoperability 
between calendaring applications. XML doesn't help that in the 
slightest, and as you point out, if anything, it hurts that.

However, many existing systems work "better" with XML, and so I can 
fully understand that a neat method of producing iCal objects in XML 
is valuable. No, I don't want to see iMIP capable CUAs start to send 
out xCal, as that'd be pointless, but yes, a web-based calendaring 
system might well be capable of spitting out xCal if requested, and 
some simple front-ends may even require that - and that's fine.

So essentially, I think xCal as a concept is fine, just that care 
should be taken to define its scope a little better.

I *haven't* read the draft, incidentally, but I still can tell the 
scope is obviously not clearly defined, because otherwise the threads 
going on in this WG about xCal would presumably be very different.

If xCal is actually presented as "a better format", then it's 
over-egging itself (I think a child of four could make a better 
format than iCal, but the deployed base renders this a waste of 
time). If xCal presents itself as a format more suited to XML-centric 
environments, than I'm all for it.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Sun, 23 Oct 2005 15:28:11 +0300
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] xCal - time to submit?
Cc: Calsify <[email-masked]>, "[email-masked]" <[email-masked]>

[Speaking as individual again]

Inline.

ext Doug Royer wrote:
> 
> 
> Aki Niemi wrote:
> 
>> [Speaking as an individual, not chair.]
>>
>> Hi,
>>
>> A couple of issues occured to me while reading the draft:
>>
>> First, the problem this draft is trying to solve seems approximately 
>> the same that MMUSIC aimed at in its SDPng work, in which the idea was 
>> to move from the current SDP into an XML based format. Even the core 
>> difficulty seems to be the same, namely the huge installed base only 
>> supporting the legacy format makes transition a bit hairy. 
> 
> What move?

As in stop using the current format and start using the new one.

> What transition?

As in how to cope with the co-existance of applications that support the 
  new format and the old format, and applications that only support the 
old format.

I thought you were familiar with these issues since the draft talks 
about them as well.

In the draft you suggest using multipart/alternative as a transitional 
mechanism. I find that solution lacking, in that will there ever be a 
time when apps can stop using MIME multipart, and simply use the xCal 
MIME type alone? Is that even the intention? If not, what is the benefit 
in defining this alternative format, if the only practical result is 
bloated message payload?

Your draft also says:

    XML
    applications conforming to this specification MUST be able to
    properly parse and process a MIME multipart entity containing the
    MIME type associated with this iCalendar XML document type.

Which is nice, but does not help at all. It is the legacy iCalendar 
application that would need to support MIME multiparts, in order for 
this "transition" to work. A big number does, but probably not all; how 
is this handled?

>> Secondly, if we think of xCal as being a next generation iCal format, 
> 
> Clearly you have not read the draft. It says:

I consider this type of statement quite a weak form of argument in 
general. If something does not come across well in a draft, often the 
reader is not at fault, but the draft needs improvement.

Believe me, I read the draft. I would not be shooting my mouth off if I 
hadn't. :)

>      This memo only provides an alternative, XML
>        representation for the standard syntax defined in [iCAL].
> 
> No 'Next generation' at all.

Why is this then needed at all? As I said in my previous post, because 
XML is cool is not a good enough reason. If it was, then I'm sure the 
ASN.1 constituent would deserve a format as well, followed by a league 
of other groups that like their data representation scheme the best.

Your draft doesn't explain this point, and I think it really should.

> If you go to the CALSCH mailing list archives you can see that other
> non-1:1 mappings of iCal were NOT desired and discouraged by the IESG.

I see, was a reason given? Should this discussion appear in the draft? 
It would really help those of us who have not followed calsch in the 
past in detail

Cheers,
Aki

Date: Sat, 22 Oct 2005 14:15:39 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] xCal - time to submit?
Cc: Calsify <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030705060604070607040006
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Aki Niemi wrote:
> [Speaking as an individual, not chair.]
> 
> Hi,
> 
> A couple of issues occured to me while reading the draft:
> 
> First, the problem this draft is trying to solve seems approximately the 
> same that MMUSIC aimed at in its SDPng work, in which the idea was to 
> move from the current SDP into an XML based format. Even the core 
> difficulty seems to be the same, namely the huge installed base only 
> supporting the legacy format makes transition a bit hairy.

What move?

What transition?

> Secondly, if we think of xCal as being a next generation iCal format, 

Clearly you have not read the draft. It says:

  	This memo only provides an alternative, XML
    	representation for the standard syntax defined in [iCAL].

No 'Next generation' at all.

If you go to the CALSCH mailing list archives you can see that other
non-1:1 mappings of iCal were NOT desired and discouraged by the IESG.

> wouldn't it be more beneficial to design it from scratch instead of 
> simply doing a 1:1 syntactic transform?

Fell free to submit such a draft. The xCal draft allow iCal
data "as defined in iCal to be mixed with XML data.

The rest of your email seems to repeat your above point.

-- 

--------------ms030705060604070607040006
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030705060604070607040006--

Date: Sat, 22 Oct 2005 22:44:38 +0300
From: Aki Niemi <[email-masked]>
To: ext Doug Royer <[email-masked]>
Subject: Re: [Ietf-calsify] xCal - time to submit?
Cc: Calsify <[email-masked]>, "[email-masked]" <[email-masked]>

[Speaking as an individual, not chair.]

Hi,

A couple of issues occured to me while reading the draft:

First, the problem this draft is trying to solve seems approximately the 
same that MMUSIC aimed at in its SDPng work, in which the idea was to 
move from the current SDP into an XML based format. Even the core 
difficulty seems to be the same, namely the huge installed base only 
supporting the legacy format makes transition a bit hairy.

Secondly, if we think of xCal as being a next generation iCal format, 
wouldn't it be more beneficial to design it from scratch instead of 
simply doing a 1:1 syntactic transform? After all, XML offers a lot of 
additional features that could be leveraged when doing a "better" 
calendar format.

A very simple example: rather than using "x-" prefix for private 
extensions, standard XML techniques could be used, i.e., putting the 
private extension element under a private (different) XML namespace.

This really boils down to "why?". What benefit is there to define this 
iCal to XML transformation? Because XML is cool is not enough, IMO, 
there needs to be some real benefits as well, especially when there is 
this huge existing installed base for iCal.

Having said all this, this might still be interesting work for even the 
IETF to take on, but I strongly feel this work would benefit from a much 
wider audience. Perhaps in the form of some comments and experiences 
from the MMUSIC WG, and probably a few thoughts from the XML "mafia" of 
the IETF as well.

Personally, I think this ought to be aiming at a BoF rather than an 
individual submission to the IESG.

Cheers,
Aki

ext Doug Royer wrote:
> 
> 
> xCal has been around for quite a while. I have included
> the last comments (and they were great feedback).
> 
> Is it time to move xCal from draft to RFC status?
> This is the 2nd round of xCal. The first was was delayed so
> this version re-started at -00 as the other draft-many
> had expired.
> 
> Please let me know if you have any more issues:
> 
> http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-02.txt
> 
> If not, lets move this to RFC proposed standard.
> 
> Thanks!
> 
> 
> ------------------------------------------------------------------------
> 

Date: Sat, 22 Oct 2005 22:15:11 +0300
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Agenda requests for IETF64

All,

We are scheduled to meet in Vancouver on Monday, Nov 7 for one hour. We 
will be composing the agenda for the meeting, and would now like to 
solicit agenda proposals from the group.

Naturally, the charter items will be considered priority items, but in 
all probability, we will have some time to discuss non-WG items, and/or 
dedicate some time to discuss specific topics of interest to this group.

Email your proposals privately to both chairs, please.

Cheers,
Aki

Date: Sat, 22 Oct 2005 19:13:45 +0300
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] xCal - time to submit?
Cc: Calsify <[email-masked]>, "[email-masked]" <[email-masked]>

Nevertheless, your original message had calsify WG in the To header field.

My reply was simply a reminder, that that particular IETF WG (being the 
only active IETF WG addressed) is not responsible for this work, and 
that any submission of xCal to the IESG is by an *individual* and not 
endorsed by the working group. That's all.

Cheers,
Aki

ext Doug Royer wrote:
> 
> I may have forgot to set the REPLY-TO the xCal mailing list.
> Often others overrode or ignored that.
> 
> And we have to post announcements to all related lists, else we are
> told to when we ask for final last call.
> 
> 
> Aki Niemi wrote:
> 
>> Speaking as calsify chair, I'd simply like to point out that this 
>> would in any case be strictly an individual effort; XML representation 
>> of iCalendar is firmly out of the scope of the calsify WG.
>>
>> Cheers,
>> Aki
>>
> 

Date: Fri, 21 Oct 2005 13:04:38 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Aki Niemi <[email-masked]>, "[email-masked]" <[email-masked]>, Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] xCal - time to submit?
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020806000207080205010202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I may have forgot to set the REPLY-TO the xCal mailing list.
Often others overrode or ignored that.

And we have to post announcements to all related lists, else we are
told to when we ask for final last call.

Aki Niemi wrote:
> Speaking as calsify chair, I'd simply like to point out that this would 
> in any case be strictly an individual effort; XML representation of 
> iCalendar is firmly out of the scope of the calsify WG.
> 
> Cheers,
> Aki
> 

-- 

--------------ms020806000207080205010202
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020806000207080205010202--

Date: Fri, 21 Oct 2005 19:20:48 +0300
From: Aki Niemi <[email-masked]>
To: ext Doug Royer <[email-masked]>
Subject: Re: [Ietf-calsify] xCal - time to submit?
Cc: Calsify <[email-masked]>, "[email-masked]" <[email-masked]>

Speaking as calsify chair, I'd simply like to point out that this would 
in any case be strictly an individual effort; XML representation of 
iCalendar is firmly out of the scope of the calsify WG.

Cheers,
Aki

ext Doug Royer wrote:
> 
> 
> xCal has been around for quite a while. I have included
> the last comments (and they were great feedback).
> 
> Is it time to move xCal from draft to RFC status?
> This is the 2nd round of xCal. The first was was delayed so
> this version re-started at -00 as the other draft-many
> had expired.
> 
> Please let me know if you have any more issues:
> 
> http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-02.txt
> 
> If not, lets move this to RFC proposed standard.
> 
> Thanks!
> 
> 
> ------------------------------------------------------------------------
> 

To: [email-masked]
From: [email-masked]
Sender: Michael Lee <[email-masked]>
Date: Fri, 21 Oct 2005 10:50:01 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-2446bis-00.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Transport-Independent Interoperability Protocol (iTIP)
	Author(s)	: C. Daboo
	Filename	: draft-ietf-calsify-2446bis-00.txt
	Pages		: 122
	Date		: 2005-10-21
	
   This document specifies a protocol using the iCalendar object
   specification to provide scheduling interoperability between
   different calendar systems.  This is done in a general way so as to
   allow multiple methods of communication between systems.  Subsequent
   documents will define profiles of this protocol using specific
   interoperable methods of communications between systems.

   iTIP complements the iCalendar object specification by adding
   semantics for group scheduling methods commonly available in current
   calendar systems.  These scheduling methods permit two or more
   calendar systems to perform transactions such as publish, schedule,
   reschedule, respond to scheduling requests, negotiation of changes or
   cancel.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-calsify-2446bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-2446bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-2446bis-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-calsify-2446bis-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] DTEND for day events
Date: Wed, 19 Oct 2005 17:36:04 +0200

On Wednesday 19 October 2005 16:29, [email-masked] wrote:
> I'm trying to close down this issue that was raised by Neal and answered by
> Jeffrey.  It does seem that 2445 has DTEND as always being exclusive, but
> it's not explained very well.  In an effort to clear up the confusion, we'd
> like to change 2445's text to include the following examples to clarify:
>
>    To specify a meeting that starts at 15:00 and ends at 16:00:
>
>    DTSTART:20051011T150000Z
>    DTEND:20051011T160000Z
>
>
>    To specify an event that will last all day on October 11th and October
>    12th:
>
>    DTSTART;VALUE=DATE:20051011
>    DTEND;VALUE=DATE:20051013
>
>    Note that DTEND is exclusive, as expressed in both examples.  The time
>    1600 is not included in the event duration of the first example and the
>    date of the 13th is not included in the duration of the second example.

Maybe we should also add an example where no DTEND is given. In particular, 
the DTEND is then effectively DTSTART+1 day (which section 4.6.1 explains as 
"end of the calendar date given by DTSTART").

So only 
    DTSTART;VALUE=DATE:20051011
without a DTEND is effectively equivalent to
    DTSTART;VALUE=DATE:20051011
    DTEND;VALUE=DATE:20051012

And how should the following be interpreted where DTSTART and DTEND are the 
same day? 
    DTSTART;VALUE=DATE:20051011
    DTEND;VALUE=DATE:20051011
I suppose this should then be a timeless event as opposed to an event that 
takes up the whole day.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] DTEND for day events
Date: Wed, 19 Oct 2005 17:36:08 +0200

On Wednesday 19 October 2005 16:42, Doug Fults wrote:
> Your description is very helpful.  When I first implemented iCalendar
> support awhile back, I was quite confused by why the actual calendars
> out there seemed to be doing something different than the spec in this
> regard.  

Well, apparently, all implementations got it wrong according to one author of 
rfc 2445 (see my mail a while back)... But since *all* do it consistently, 
let's now change the standard (or rather clear it up) to reflect reality ;-)

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

Date: Wed, 19 Oct 2005 07:42:42 -0700
From: Doug Fults <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] DTEND for day events
Cc: Calsify <[email-masked]>

Chris,

Your description is very helpful.  When I first implemented iCalendar 
support awhile back, I was quite confused by why the actual calendars 
out there seemed to be doing something different than the spec in this 
regard.  This would have cleared things right up.

Doug Fults "long time calendar programmer, newbie on this board"

>I'm trying to close down this issue that was raised by Neal and answered by
>Jeffrey.  It does seem that 2445 has DTEND as always being exclusive, but
>it's not explained very well.  In an effort to clear up the confusion, we'd
>like to change 2445's text to include the following examples to clarify:
>
>   To specify a meeting that starts at 15:00 and ends at 16:00:
>
>   DTSTART:20051011T150000Z
>   DTEND:20051011T160000Z
>
>
>   To specify an event that will last all day on October 11th and October
>   12th:
>
>   DTSTART;VALUE=DATE:20051011
>   DTEND;VALUE=DATE:20051013
>
>   Note that DTEND is exclusive, as expressed in both examples, .  The time
>   1600 is not included in the event duration of the first example and the
>   date of the 13th is not included in the duration of the second example.
>
>Thanks all-
>Chris Stoner
>
>
>  
>
>>Hi Neal,
>>
>>    
>>
>>>rfc2445 is unclear if the DTEND is inclusive or exclusive when both the
>>>      
>>>
>
>  
>
>>>DTSTART and DTEND are DATEs.
>>>      
>>>
>>To find the language about this, you have to look in the (not
>>intuitively located) VEVENT definition.  It says:
>>
>>The "DTSTART" property for a "VEVENT" specifies the inclusive start
>>   of the event. For recurring events, it also specifies the very first
>>   instance in the recurrence set. The "DTEND" property for a "VEVENT"
>>   calendar component specifies the non-inclusive end of the event.
>>
>>It doesn't say anything specific about DATE valued events, so DTEND is
>>always exclusive.
>>
>>In practice, Apple's iCal always exports one-day all-day events with an
>>explicit DTEND of the day after the start.  I scratched my head about
>>that for a while, too, till I looked in VEVENT.
>>
>>Sincerely,
>>Jeffrey Harris
>>    
>>
>

Subject: Re: [Ietf-calsify] DTEND for day events
To: Calsify <[email-masked]>
Date: Wed, 19 Oct 2005 10:29:19 -0400
From: [email-masked]

I'm trying to close down this issue that was raised by Neal and answered by
Jeffrey.  It does seem that 2445 has DTEND as always being exclusive, but
it's not explained very well.  In an effort to clear up the confusion, we'd
like to change 2445's text to include the following examples to clarify:

   To specify a meeting that starts at 15:00 and ends at 16:00:

   DTSTART:20051011T150000Z
   DTEND:20051011T160000Z

   To specify an event that will last all day on October 11th and October
   12th:

   DTSTART;VALUE=DATE:20051011
   DTEND;VALUE=DATE:20051013

   Note that DTEND is exclusive, as expressed in both examples, .  The time
   1600 is not included in the event duration of the first example and the
   date of the 13th is not included in the duration of the second example.

Thanks all-
Chris Stoner

> Hi Neal,
>
> > rfc2445 is unclear if the DTEND is inclusive or exclusive when both the

> > DTSTART and DTEND are DATEs.
>
> To find the language about this, you have to look in the (not
> intuitively located) VEVENT definition.  It says:
>
> The "DTSTART" property for a "VEVENT" specifies the inclusive start
>    of the event. For recurring events, it also specifies the very first
>    instance in the recurrence set. The "DTEND" property for a "VEVENT"
>    calendar component specifies the non-inclusive end of the event.
>
> It doesn't say anything specific about DATE valued events, so DTEND is
> always exclusive.
>
> In practice, Apple's iCal always exports one-day all-day events with an
> explicit DTEND of the day after the start.  I scratched my head about
> that for a while, too, till I looked in VEVENT.
>
> Sincerely,
> Jeffrey Harris

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Mon, 17 Oct 2005 18:44:49 +0200
Lines: 18
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: xCal - time to submit?

Helge Hess wrote:
> On 17. Okt 2005, at 18:08 Uhr, Michiel van Leeuwen wrote:
>> For example all the ical share websites, or other ways you can share a 
>> calendar. You can't use multipart/alternative on a webserver.
> 
> You accomplish the same thing using content negotiation in HTTP, that is 
> "accept: text/xml" vs "accept: text/iCalendar" (or both, or both 
> including content preference, say: "accept: text/xml, q=1.0; 
> text/calendar, q=0.5;").

Ok, I didn't think of it. And the spec doesn't mention it (While it does 
mention multipart/alternative.) It might be worth adding it.

But even then, for the best interop, any app need to be able to consume 
both, and only produce the most common format, iCalendar. I still don't 
see the advantage of xCal in the light of calsify.

Michiel

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Re: xCal - time to submit?
Date: Mon, 17 Oct 2005 18:37:04 +0200
To: Calsify <[email-masked]>

On 17. Okt 2005, at 18:08 Uhr, Michiel van Leeuwen wrote:
> For example all the ical share websites, or other ways you can  
> share a calendar. You can't use multipart/alternative on a webserver.

You accomplish the same thing using content negotiation in HTTP, that  
is "accept: text/xml" vs "accept: text/iCalendar" (or both, or both  
including content preference, say: "accept: text/xml, q=1.0; text/ 
calendar, q=0.5;").

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Mon, 17 Oct 2005 18:08:06 +0200
Lines: 16
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: xCal - time to submit?

Doug Royer wrote:
> Why do you say that non-xml applications need need to support xml?
> The draft clearly explains that they must be shipped with iCal objects.

IT says so, but that isn't always possible. For example all the ical 
share websites, or other ways you can share a calendar. You can't use 
multipart/alternative on a webserver.

> And it shows how to mix the standard iCal data with other XML objects,
> this is the reason of also having an XML representation of iCal data.

That's nice, but it doesn't simplify things. And I thought that was the 
goal of calsify. So we have to find the balance between simplifying and 
adding more features. I vote for simplify.

Michiel

Date: Sun, 16 Oct 2005 14:36:52 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: xCal - time to submit?
Cc: [email-masked]
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000904070404010901040605
Content-Type: multipart/mixed; boundary="------------030306020401040204090609"

This is a multi-part message in MIME format.
--------------030306020401040204090609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Michiel van Leeuwen wrote:
> Doug Royer wrote:
> 
>> It explicitly states it is a representation if iCal.
> 
> 
> It's a new representation. That is the new part. For an app, it is not 
> enough to just be able to read 'old' iCalendar files, but now they also 
> need an xml parser and parse xCal. And with new things come new bugs and 
> new problems.

Why do you say that non-xml applications need need to support xml?
The draft clearly explains that they must be shipped with iCal objects.

Again, have you read the draft?

And it shows how to mix the standard iCal data with other XML objects,
this is the reason of also having an XML representation of iCal data.

-- 

--------------030306020401040204090609
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-594-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------030306020401040204090609--

--------------ms000904070404010901040605
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000904070404010901040605--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Sun, 16 Oct 2005 22:23:30 +0200
Lines: 20
Sender: news <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-calsify] Re: xCal - time to submit?

Doug Royer wrote:
> It explicitly states it is a representation if iCal.

It's a new representation. That is the new part. For an app, it is not 
enough to just be able to read 'old' iCalendar files, but now they also 
need an xml parser and parse xCal. And with new things come new bugs and 
new problems.

And in the light of calsify: Having two ways to represent that same data 
doesn't make things simpler. You need to choose one format, and be able 
to read both. More sources of interop problems.

> There are TWO OTHER XML calendaring drafts. Perhaps you read one
> of the other XML calendar drafts out there? Both of those
> other drafts are not a 1:1 mapping to iCal.

Yeah, those formats might be even a bigger problem, but imo that isn't a 
reason to have xCal.

Michiel

Date: Sun, 16 Oct 2005 13:13:13 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Michiel van Leeuwen <[email-masked]>
Subject: Re: [Ietf-calsify] Re: xCal - time to submit?
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050208030506030704060509
Content-Type: multipart/mixed; boundary="------------090905010801030105080807"

This is a multi-part message in MIME format.
--------------090905010801030105080807
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Michiel van Leeuwen wrote:
> Doug Royer wrote:
> 
>> Is it time to move xCal from draft to RFC status?
> 
> 
> Why would you want to do that? What is the advantage of adding a new 
> standard?

What new standard? My draft proposes no new components, properties,
parameters, or values. My draft does not propose any change
to any component, property, parameter, or value..

It explicitly states it is a representation if iCal. That's why I
released the XSLT transform to iCal on surceforge prior to this request.
So that it was clear and verifiable that it was a 1:1 mapping of iCal.

> To me, that doesn't seem to simplify things, it just adds more 
> problems. I would just drop the thing, and live with one standard (it 
> might not be a perfect standard, but we need to live with it anyway, 
 > convert all apps and all files out there)

There are TWO OTHER XML calendaring drafts. Perhaps you read one
of the other XML calendar drafts out there? Both of those
other drafts are not a 1:1 mapping to iCal.

-- 

--------------090905010801030105080807
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-594-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------090905010801030105080807--

--------------ms050208030506030704060509
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050208030506030704060509--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Sun, 16 Oct 2005 10:58:37 +0200
Lines: 10
Sender: news <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-calsify] Re: xCal - time to submit?

Doug Royer wrote:
> Is it time to move xCal from draft to RFC status?

Why would you want to do that? What is the advantage of adding a new 
standard? To me, that doesn't seem to simplify things, it just adds more 
problems. I would just drop the thing, and live with one standard (it 
might not be a perfect standard, but we need to live with it anyway, 
adding a new one won't suddenly convert all apps and all files out there)

Michiel

Date: Fri, 14 Oct 2005 12:59:00 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>, Calsify <[email-masked]>
Subject: [Ietf-calsify] xCal - time to submit?

This is a cryptographically signed message in MIME format.

--------------ms090807040400020206000300
Content-Type: multipart/mixed; boundary="------------090803040305080000080400"

This is a multi-part message in MIME format.
--------------090803040305080000080400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

xCal has been around for quite a while. I have included
the last comments (and they were great feedback).

Is it time to move xCal from draft to RFC status?
This is the 2nd round of xCal. The first was was delayed so
this version re-started at -00 as the other draft-many
had expired.

Please let me know if you have any more issues:

http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-02.txt

If not, lets move this to RFC proposed standard.

Thanks!

-- 

--------------090803040305080000080400
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-594-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------090803040305080000080400--

--------------ms090807040400020206000300
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090807040400020206000300--

Date: Tue, 11 Oct 2005 21:06:30 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] <1 week to draft deadline
Cc: Calsify <[email-masked]>

Lisa,

I have just submitted draft-ietf-calsify-rfc2445bis-00.txt.

It is already available online at the following URL:

http://ietf.webdav.org/calsify/rfc2445bis/draft-ietf-calsify-rfc2445bis-00.txt

Please note that I have also setup an "Issues List" for
this draft at the following URL:

http://ietf.webdav.org/calsify/rfc2445bis/rfc2445bis-issues.html

Cheers,
Bernard

Lisa Dusseault wrote:

> 
> We have less than one week until the new-draft deadline for Vancouver IETF.
> http://www.ietf.org/meetings/cutoff_dates_64.html
> 
> With this in mind, CALSIFY authors may have to just make proposals 
> (straw man solutions) right in the Internet-Drafts, submit that for the 
> archives, and then discuss on the list and in the meeting.  Any 
> proposals in the internet-drafts can then be changed in future versions 
> of those drafts if necessary.
> 
> Lisa
> 

Date: Tue, 11 Oct 2005 20:05:57 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Mike Douglass <[email-masked]>
Subject: Re: [Ietf-calsify] DTEND for day events
Cc: [email-masked]

Mike,

This is not allowed.

See RFC 2445, Section 4.6.1 Event Component, Page 53:

    The "VEVENT" is also the calendar component used to specify an
    anniversary or daily reminder within a calendar. These events have a
    DATE value type for the "DTSTART" property instead of the default
    data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
    MUST be specified as a DATE value also.

Cheers,
Bernard

Mike Douglass wrote:

> Slightly related, is a vevent DATE DTEND allowed with a DATE-TIME 
> DTSTART and if so what does it mean?
> 
> I could only find that a DATE DTSTART requires a DATE DTEND if present.
> 

Date: Tue, 11 Oct 2005 14:03:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] <1 week to draft deadline

Hi Lisa,

--On October 11, 2005 10:59:38 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> We have less than one week until the new-draft deadline for Vancouver
> IETF.
> http://www.ietf.org/meetings/cutoff_dates_64.html
>
> With this in mind, CALSIFY authors may have to just make proposals (straw
> man solutions) right in the Internet-Drafts, submit that for the
> archives, and then discuss on the list and in the meeting.  Any proposals
> in the internet-drafts can then be changed in future versions of those
> drafts if necessary.

I have just finished the conversion of iTIP into XMl format and started 
doing some minor edits. I will push this out prior to the deadline even if 
there have been no substantial changes to the content.

-- 
Cyrus Daboo

To: Calsify <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 11 Oct 2005 10:59:38 -0700
Subject: [Ietf-calsify] <1 week to draft deadline

We have less than one week until the new-draft deadline for Vancouver 
IETF.
http://www.ietf.org/meetings/cutoff_dates_64.html

With this in mind, CALSIFY authors may have to just make proposals 
(straw man solutions) right in the Internet-Drafts, submit that for the 
archives, and then discuss on the list and in the meeting.  Any 
proposals in the internet-drafts can then be changed in future versions 
of those drafts if necessary.

Lisa

Date: Thu, 06 Oct 2005 09:33:58 -0400
From: Mike Douglass <[email-masked]>
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] Specifying language

I was looking into maintaining different language values in the calendar 
so we could have something like that given as an example in the rfc

     LOCATION;LANGUAGE=en:Germany
     LOCATION;LANGUAGE=no:Tyskland

Is it possible/legal to deliver two locations given that location should 
only appear once in an event? Likewise for any other text field.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Tue, 04 Oct 2005 10:14:27 -0400
From: Simon Vaillancourt <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] What is the appropriate serialization for a recurring event with one event changed?

Hello Jeffrey,
   This is a bug in our product where we don't add an RDATE to the main 
event (It's already on our todo list). You should have seen something like :

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5
EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)
RDATE:20051005T180000Z

the other VEVENT has

RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
DTSTART;TZID=US/Pacific:20051005T110000

As far as "Is an EXDATE appropriate for the original time if an event's 
time has been moved?".  Ideally, the meeting you store on a CalDAV 
server would remain unchanged when you retrieve it later on, but when 
plugging a CalDAV interface on top of an existing calendar store(Like we 
do at Oracle) it's a different story. For the Oracle product, we 1) 
Convert the iCalendar meeting to our internal format, 2)Do a diff of 
both meeting representations and send the detected changes to our 
calendar backend.  This conversion and diff process might explain the 
differences you see between the meeting you put in and the meeting you 
retrieve later on. I'm sure many would argue that "moving" a recurrence 
vs "deleting and creating" a recurrence is very different even if the 
expanded end result in a standard calendar UI is the same,  that's why 
we're still working on perfecting our diff and conversion algorithms.

Regards,
Simon

Jeffrey Harris wrote:

>Hi Folks,
>
>I've been working a bit with Oracle's CalDAV server and Apple's iCal,
>and they have pretty different behaviors when serializing a recurring
>event with a change to one event.
>
>Lets take, for example, a daily event, starting Monday at 9AM, last
>occurrence Friday at 9AM.  If I change Wednesday's event to 11AM, what
>should the resulting stream look like?
>
>iCal exports this as two VEVENTs, one has (omitting lots of other lines):
>
>DTSTART;TZID=US/Pacific:20051003T090000
>RRULE:FREQ=DAILY;COUNT=5
>
>the other VEVENT has
>
>RECURRENCE-ID:20051005T160000Z          #Wednesday at 9AM PDT (in UTC)
>DTSTART;TZID=US/Pacific:20051005T110000 #Wednesday at 11AM PDT
>
>Oracle's stream also has two VEVENTs:
>
>DTSTART;TZID=US/Pacific:20051003T090000
>RRULE:FREQ=DAILY;COUNT=5
>EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)
>
>the other VEVENT has
>
>RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
>DTSTART;TZID=US/Pacific:20051005T110000
>
>Is one of these more correct than the other?  Is an EXDATE appropriate
>for the original time if an event's time has been moved?  What does it
>mean for a RECURRENCE-ID to reference a time that isn't already in the
>recurrence set?
>
>Sincerely,
>Jeffrey

Date: Tue, 04 Oct 2005 02:09:39 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] What is the appropriate serialization for a	recurring event with one event changed?
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000205090709060804020902
Content-Type: multipart/mixed; boundary="------------010101010709020704040301"

This is a multi-part message in MIME format.
--------------010101010709020704040301
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

These are some of the reasons for iTIP-bis. We can observe
what some vendors do, we must document 'the' way it needs
to be done.

I think that both are wrong as shown, for the following reasons:

The Apple way (as you described it) is also wrong as it depends
on the iCal parser being a one pass parser (read and process in
order). A two pass parser that sorts by UID/SEQUENCE/DTSTAMP and
follows the iTIP rules may get a different answer than Apple
when SEQUENCE and DTSTAMP are the same or missing.

Apple in your example DOES NOT depend on the SEQUENCE/DTSTAMP
of objects and the METHOD.

If you have a:
	
	METHOD:REQUEST
	DTSTART;TZID=US/Pacific:20051003T090000
	RRULE:FREQ=DAILY;COUNT=5

And have a:

	METHOD:REQUEST
	SEQUENCE: <larger than above with same UID>
	RECURRENCE-ID:20051005T160000Z
	DTSTART;TZID=US/Pacific:20051005T110000

It means replace the 9am  appointment with the new value.

If they have the same SEQUENCE, then the one with the
newer DTSTAMP obsoletes the other (iTIP 2.1.5).

If no SEQUENCE is provided, the default is ZERO
and the one with the newer DTSTAMP wins as 'the' object
for that UID.

If they have different SEQUENCE values:
A CUA can process the above two METHOD:REQUESTs and
produce a valid METHOD:PUBLISH calendar that could have:

	METHOD:PUBLISH
	DTSTART;TZID=US/Pacific:20051003T090000
	RRULE:FREQ=DAILY;COUNT=5
	EXDATE:20051005T160000Z
	RDATE:;TZID=US/Pacific:20051005T110000

  -OR-

If you have a:

  	DTSTART;TZID=US/Pacific:20051003T090000
	RRULE:FREQ=DAILY;COUNT=5
	EXDATE:20051005T160000Z

And have a:

	RECURRENCE-ID:20051005T180000Z(in UTC)
	SEQUENCE: <larger than above with same UID>
	DTSTART;TZID=US/Pacific:20051005T110000

Then the sending CUA is busted, as there is no such
instance to replace

RECURRENCE-ID has little meaning in a PUBLISH calendar as there
is no ordering to objects. One parser might read them in order and
then write them sorted by UID or something. Making
the RECURRENCE-ID usless without SEQUENCE/DTSTAMP. (Perhaps your
examples had them and you did not provide them?)

 > Is one of these more correct than the other?  Is an EXDATE appropriate
 > for the original time if an event's time has been moved?  What does it
 > mean for a RECURRENCE-ID to reference a time that isn't already in the
 > recurrence set?

> I think that's wrong. This RECURRENCE-ID specifies the occurrence of the RRULE 
> that is changed by that VEVENT. Since Wed  11 AM PDT is not part of the 
> RRULE, I'm not sure how this should be interpreted by a client... Shall it 
> still occur? Or shall it simply be ignored because that RECURRENCE-ID does 
> not exist in the RRULE.

> The correct way is iCal's way, where no EXDATE is necessary (since the 
> RECURRENCE-ID already says that that specific event on October 5 was changed 
> from 9AM to 11AM).

I agree, if the SEQUENCE number in the 1st one is lower than
the SEQUENCE number in the 2nd one.

If the SEQUENCE/DTSTAMP numbers are the same (no SEQUENCE is zero and
DTSTAMP is the same), then the 2nd is simply bogus as it has no
meaning to have a RECURRENCE-ID with no previous object.

-- 

--------------010101010709020704040301
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------010101010709020704040301--

--------------ms000205090709060804020902
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000205090709060804020902--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] What is the appropriate serialization for a recurring event with one event changed?
Date: Tue, 4 Oct 2005 09:24:17 +0200

Am Dienstag, 4. Oktober 2005 01:41 schrieb Jeffrey Harris:
> Hi Folks,
>
> I've been working a bit with Oracle's CalDAV server and Apple's iCal,
> and they have pretty different behaviors when serializing a recurring
> event with a change to one event.
>
> Lets take, for example, a daily event, starting Monday at 9AM, last
> occurrence Friday at 9AM.  If I change Wednesday's event to 11AM, what
> should the resulting stream look like?
>
> iCal exports this as two VEVENTs, one has (omitting lots of other lines):
>
> DTSTART;TZID=US/Pacific:20051003T090000
> RRULE:FREQ=DAILY;COUNT=5
>
> the other VEVENT has
>
> RECURRENCE-ID:20051005T160000Z          #Wednesday at 9AM PDT (in UTC)
> DTSTART;TZID=US/Pacific:20051005T110000 #Wednesday at 11AM PDT

> Oracle's stream also has two VEVENTs:
>
> DTSTART;TZID=US/Pacific:20051003T090000
> RRULE:FREQ=DAILY;COUNT=5
> EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)
>
> the other VEVENT has
>
> RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
> DTSTART;TZID=US/Pacific:20051005T110000

I think that's wrong. This RECURRENCE-ID specifies the occurrence of the RRULE 
that is changed by that VEVENT. Since Wed  11 AM PDT is not part of the 
RRULE, I'm not sure how this should be interpreted by a client... Shall it 
still occur? Or shall it simply be ignored because that RECURRENCE-ID does 
not exist in the RRULE.

The correct way is iCal's way, where no EXDATE is necessary (since the 
RECURRENCE-ID already says that that specific event on October 5 was changed 
from 9AM to 11AM).

> Is one of these more correct than the other?

Yes, iCal's is correct, I think.

> Is an EXDATE appropriate 
> for the original time if an event's time has been moved?  

No, that's not needed, since RECURRENCE-ID should give the original time of 
the occurrence.

> What does it 
> mean for a RECURRENCE-ID to reference a time that isn't already in the
> recurrence set?

That's the question... How shall clients interpret such VEVENTS?

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer maintainer

Date: Mon, 03 Oct 2005 21:35:13 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Calsify WG <[email-masked]>, WebDAV WG <[email-masked]>
Subject: [Ietf-calsify] [Fwd: I-D ACTION:draft-dusseault-caldav-08.txt]

This is a multi-part message in MIME format.
--------------030201060504080201040300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

We submitted CalDAV draft -08 to the IETF last Friday.
It is now available at the following URL:

http://www.ietf.org/internet-drafts/draft-dusseault-caldav-08.txt

We are planning to submit a new revision in a few weeks for
an informal Last-Call on the ietf-caldav, ietf-calsify and
w3c-dist-auth (WebDAV) mailing lists before we actually submit
it to the IESG.

Please review the draft and send us feedback/questions/comments.

Thanks,
Bernard

B.1.  Changes in -08

    a.  Removed statement that said that client SHOULD always request
        DAV:getetag in calendar REPORTs.

    b.  Removed redefiniton of DAV:response.

    c.  Removed XML elements CALDAV:calendar-data-only.

    d.  Removed resource type CALDAV:calendar-home.

    e.  Moved the CALDAV:calendar-data element in the DAV:prop element in
        requests, and in the DAV:propstat element in responses.

    f.  Further defined the request body of MKCALENDAR to allow clients
        to set properties at calendar collection creation time.

    g.  Renamed CALDAV:calendar-home-URL to CALDAV:calendar-home-set

    h.  Clarified the fact that calendar collections may only contain
        calendar object resources and ordinary collections.

    i.  Clarified that calendar REPORTs should only be applied to
        calendar object resources contained in calendar collections.

    j.  Changed the CALDAV:calendar-component-restriction-set and CALDAV:
        calendar-restriction properties to always be protected.

    k.  Changed to use existing postcondition DAV:needs-privileges
        instead of a new CALDAV:insufficient-privilege postcondition.

    l.  Added example for limit-recurrence-set.

    m.  Added example for expand-recurrence-set.

    n.  Moved CALDAV:calendar-address-set in the calendar-schedule draft
        and renamed it to CALDAV:calendar-user-address-set.

    o.  Added guidelines on attachments and alarms.

-------- Original Message --------
Subject: I-D ACTION:draft-dusseault-caldav-08.txt
Date: Mon, 03 Oct 2005 15:50:02 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Calendaring Extensions to WebDAV (CalDAV)
	Author(s)	: L. Dusseault, et al.
	Filename	: draft-dusseault-caldav-08.txt
	Pages		: 75
	Date		: 2005-10-3
	
This document specifies a set of methods, headers, message bodies,
    properties, and reports that define calendar access extensions to the
    WebDAV protocol.  The new protocol elements are intended to make
    WebDAV-based calendaring and scheduling an interoperable standard
    that supports calendar access, calendar management, calendar sharing,
    and calendar publishing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-08.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-dusseault-caldav-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-dusseault-caldav-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------030201060504080201040300
Content-Type: Message/External-body;
 name="draft-dusseault-caldav-08.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-dusseault-caldav-08.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

nt-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------030201060504080201040300--

Date: Mon, 03 Oct 2005 16:41:30 -0700
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] What is the appropriate serialization for a recurring event with one event changed?

Hi Folks,

I've been working a bit with Oracle's CalDAV server and Apple's iCal,
and they have pretty different behaviors when serializing a recurring
event with a change to one event.

Lets take, for example, a daily event, starting Monday at 9AM, last
occurrence Friday at 9AM.  If I change Wednesday's event to 11AM, what
should the resulting stream look like?

iCal exports this as two VEVENTs, one has (omitting lots of other lines):

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5

the other VEVENT has

RECURRENCE-ID:20051005T160000Z          #Wednesday at 9AM PDT (in UTC)
DTSTART;TZID=US/Pacific:20051005T110000 #Wednesday at 11AM PDT

Oracle's stream also has two VEVENTs:

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5
EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)

the other VEVENT has

RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
DTSTART;TZID=US/Pacific:20051005T110000

Is one of these more correct than the other?  Is an EXDATE appropriate
for the original time if an event's time has been moved?  What does it
mean for a RECURRENCE-ID to reference a time that isn't already in the
recurrence set?

Sincerely,
Jeffrey

Date: Mon, 03 Oct 2005 16:12:36 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>, Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-calsify] New xCal draft sent to the IETF

This is a cryptographically signed message in MIME format.

--------------ms070405090106090606080503
Content-Type: multipart/mixed; boundary="------------080503040904020800040207"

This is a multi-part message in MIME format.
--------------080503040904020800040207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I have sent -02 of xCal to the IETF, copies at:

	http://inet-consulting.com/draft-royer-calsch-xcal-02.txt
	http://inet-consulting.com/draft-royer-calsch-xcal-02.html
	http://inet-consulting.com/draft-royer-calsch-xcal-02.xml

Namespace to urn:ietf:params:xml:ns:xcal

I removed unneeded namespace prefixes in examples.

The iCalendar LANGUAGE parameter is now xml:lang

I specified, standard XML encoding, rather than
specifically sayiing 'entity' encoding.

I updated the XSLT (xml -> iCal translator) on SourceForge
(http://sourceforge.net/projects/icalendar/) to translate
xml:lang -> LANGUAGE.

-- 

--------------080503040904020800040207
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------080503040904020800040207--

--------------ms070405090106090606080503
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070405090106090606080503--

Date: Mon, 03 Oct 2005 13:26:00 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Error in link to Timezone Questionnaire Results Document
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------080507080208000305030503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I made an error in transcribing the URL to the Timezone Questionnaire 
Results document in my previous posting.  The correct link is:

http://www.calconnect.org/publications/resultsfromtimezonequestionnairev1.0.pdf.

You may also retrief the document by going to http://www.calconnect.org 
and selecting "Work Products" from the sidebar.

Apologies,

Dave Thewlis
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------080507080208000305030503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I made an error in transcribing the URL to the Timezone Questionnaire
Results document in my previous posting.&nbsp; The correct link is: <br>
<br>
<a
 href="http://www.calconnect.org/publications/resultsfromtimezonequestionnairev1.0.pdf">http://www.calconnect.org/publications/resultsfromtimezonequestionnairev1.0.pdf</a>.<br>
<br>
You may also retrief the document by going to <a
 href="http://www.calconnect.org">http://www.calconnect.org</a> and
selecting "Work Products" from the sidebar.<br>
<br>
Apologies,<br>
<br>
Dave Thewlis<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

--------------080507080208000305030503--

Date: Mon, 03 Oct 2005 12:40:52 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Results from CalConnect Timezone Questionnaire
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------000801050005090105020101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

TC-TIMEZONE, the TIMEZONE Technical Committee of the Calendaring and 
Scheduling Consortium, has published the results of the Timezone 
Questionnaire it conducted earlier
this year. The document is available on the CalConnect web site at 
http://www.calconnect.org/publications/resultsfrom 
timezonequestionnairev1.0.pdf 
<http://www.calconnect.org/publications/caldavusecasesv1.0.pdf> or by 
going to http://www.calconnect.org and selecting "Work Products" from 
the sidebar index.
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------000801050005090105020101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
TC-TIMEZONE, the TIMEZONE Technical Committee of the Calendaring and
Scheduling Consortium, has published the results of the Timezone
Questionnaire it conducted earlier<br>
this year. The document is available
on the CalConnect web site at <a
 href="http://www.calconnect.org/publications/caldavusecasesv1.0.pdf">http://www.calconnect.org/publications/resultsfrom
timezonequestionnairev1.0.pdf</a>
or by going to <a href="http://www.calconnect.org">http://www.calconnect.org</a>
and selecting "Work Products" from the sidebar index.<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------000801050005090105020101--