Subject: [Ietf-calsify] New chair: Eliot Lear

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Tue Apr 25 10:21:50 2006

Eliot Lear is replacing me as co-chair of CALSIFY (Aki is  
continuing).  I'll stay involved as advising Area Director, but of  
course Eliot and Aki will be driving the agenda now, and hopefully  
cracking the whip a bit :)

Thanks,
Lisa

To: IETF-iCalendar <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 25 Apr 2006 10:21:41 -0700
Subject: [Ietf-calsify] New chair: Eliot Lear

Eliot Lear is replacing me as co-chair of CALSIFY (Aki is  
continuing).  I'll stay involved as advising Area Director, but of  
course Eliot and Aki will be driving the agenda now, and hopefully  
cracking the whip a bit :)

Thanks,
Lisa

Date: Mon, 24 Apr 2006 14:56:47 -0700
From: "David C. Thewlis" <[email-masked]>
Organization: DCTA Inc.
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] CalConnect -- Request for Comments - Calendaring on Mobile Devices
Reply-To: [email-masked]

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

Benefits to Participants: Direct input from individual users of mobile 
devices to the vendor community

Background: The Calendaring & Scheduling Consortium's Mobile Technical 
Committee is working on a vision for interoperable calendaring on mobile 
devices.

To better understand what feature sets are currently supported by mobile 
devices and what users desire, CalConnect invites participation of 
consumers in a questionnaire on mobile device capabilities. CalConnect's 
technical experts will use the questionnaire results to develop an 
approach to interoperability of calendaring solutions.

The questionnaire is at http://www.calconnect.org/mobileQs_v2.html

Completing the questionnaire will take 5 to 10 minutes.

Important Note: Any personal contact details provided will be kept 
strictly confidential and will only be used by CalConnect to clarify 
responses to the questionnaire.

The Technical Committee will compile responses over the next month and 
have a draft of results available for the CalConnect Roundtable VI 
meeting on 22-25 May 2006. Following review and feedback, a final 
summary of the results will be published on the CalConnect web site.

We would appreciate your response no later than 5th May 2006.

Thank you in advance for your participation.

Chris Dudding, Symbian Limited
TC Mobile Chair
[email-masked]

Dave Thewlis, CalConnect
Executive Director
[email-masked]

/CalConnect, The Calendaring and Scheduling Consortium, is working 
towards ubiquitous, internoperable Calendaring and Scheduling.  For more 
information about CalConnect, please see our website at 
//_http://www.calconnect.org_//./

<mailto:[email-masked]>

--------------090905020408000502020505
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">
Benefits to Participants: Direct input
from individual users of mobile devices to the vendor community <br>
<br>
Background: The Calendaring &amp;
Scheduling
Consortium&#8217;s Mobile Technical Committee is working on a vision for
interoperable
calendaring on mobile devices. <br>
<br>
To better understand what feature sets
are currently supported by mobile devices and what users desire,
CalConnect
invites participation of consumers in a questionnaire on mobile device
capabilities. CalConnect&#8217;s technical experts will use the questionnaire
results to develop an approach to interoperability of calendaring
solutions.
<br>
<br>
The questionnaire is at
<a class="moz-txt-link-freetext"
 href="http://www.calconnect.org/mobileQs_v2.html">http://www.calconnect.org/mobileQs_v2.html</a>
<br>
<br>
Completing the questionnaire will take
5 to 10 minutes. <br>
<br>
Important Note: Any personal contact
details provided will be kept strictly confidential and will only be
used
by CalConnect to clarify responses to the questionnaire. <br>
<br>
The Technical Committee will compile
responses over the next month and have a draft of results available for
the CalConnect Roundtable VI meeting on 22-25 May 2006. Following
review
and feedback, a final summary of the results will be published on the
CalConnect
web site. <br>
<br>
We would appreciate your response no
later than 5th May 2006. <br>
<br>
Thank you in advance for your
participation.
<br>
<br>
Chris Dudding, Symbian Limited
<br>
TC Mobile Chair
<br>
<a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>
<br>
<br>
Dave Thewlis, CalConnect
<br>
Executive Director
<br>
<a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>
<br>
<br>
<i>CalConnect, The Calendaring and Scheduling
Consortium,
is working towards ubiquitous, internoperable Calendaring and
Scheduling.&nbsp;
For more information about CalConnect, please see our website at </i><a
 href="http://www.calconnect.org"><font color="blue"><i><u>http://www.calconnect.org</u></i></font></a><i>.</i>
<br>
<div class="moz-signature"><a href="mailto:[email-masked]"><br>
</a></div>
</body>
</html>

--------------090905020408000502020505--

Subject: Re: [Ietf-calsify] dtstart and date vs datetime
From: Dan Connolly <[email-masked]>
To: Eliot Lear <[email-masked]>
Organization: World Wide Web Consortium (http://www.w3.org/)
Date: Sun, 23 Apr 2006 21:33:23 -0500
Cc: [email-masked], RDF Calendar <[email-masked]>

On Sun, 2006-04-23 at 11:15 +0200, Eliot Lear wrote:
> Hi Dan,
> 
> I'm a little confused by your message.  On the one hand, you're confused
> by what also appears to me to be a broken example in §4.8.6.3.  It seems
> to me that you found a bug, and that the example should at least
> indicate "VALUE=DATE".

That's one of the three options I can see. I guess I don't really
like it, though. It seems to me that the cat is out of the bag
and this syntax should be supported. Perhaps not, though.

>   On the other hand, I don't understand how you
> ended up with the following:
> 
> Dan Connolly wrote:
> > I just discovered that some code I wrote will produce this:
> > 2006-08-04T::
> >
> > Given this input:
> >
> > DTSTART:20060804
> >   
> Under what circumstances do you end up with either a dash ("-") in the
> date specification or a pair of colons ("::")?

Ah... yes, I should have explained... my code converts iCalendar
datetimes to XML Schema datatype datetimes of the
form YYYY-MM-DDTHH:MM:SS.

> Thanks,
> Eliot
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Date: Sun, 23 Apr 2006 11:15:04 +0200
From: Eliot Lear <[email-masked]>
To: Dan Connolly <[email-masked]>
Subject: Re: [Ietf-calsify] dtstart and date vs datetime
Cc: [email-masked], RDF Calendar <[email-masked]>

Hi Dan,

I'm a little confused by your message.  On the one hand, you're confused
by what also appears to me to be a broken example in §4.8.6.3.  It seems
to me that you found a bug, and that the example should at least
indicate "VALUE=DATE".  On the other hand, I don't understand how you
ended up with the following:

Dan Connolly wrote:
> I just discovered that some code I wrote will produce this:
> 2006-08-04T::
>
> Given this input:
>
> DTSTART:20060804
>   
Under what circumstances do you end up with either a dash ("-") in the
date specification or a pair of colons ("::")?

Thanks,

Eliot

From: Dan Connolly <[email-masked]>
To: [email-masked]
Organization: World Wide Web Consortium (http://www.w3.org/)
Date: Fri, 21 Apr 2006 12:55:18 -0500
Cc: RDF Calendar <[email-masked]>
Subject: [Ietf-calsify] dtstart and date vs datetime

I just discovered that some code I wrote will produce this:
2006-08-04T::

Given this input:

DTSTART:20060804

Seems like my testing would have caught a bug like that
long ago... but maybe it's not so much a bug as bad data.
The default datatype for DTSTART is DATE-TIME, and
all my tests explicitly give a type in the case of DATE:

DTSTART;VALUE=DATE:20060804

The sections on DTSTART and DATETIME are reasonably
clear that DTSTART:20060804 is no good...
http://www.w3.org/2002/12/cal/rfc2445#sec4.8.2.4

But there's a DTSTART:19980205 example discussed in passing
under 4.8.6.3 Trigger
and another DTSTART:19971102

Those examples seem to still be there in the October 11, 2005 draft
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt

So... what's the deal?
  - these examples are bad data and should be fixed

  - the specification of DTSTART should be updated so that
    the default type depends on the value given

  - the specification of the DATE-TIME data type should be
    updated so that values like 19971102 are OK

p.s. there isn't a calisfy test repository yet, is there?
I participate in development of hCalendar test develompent.
  http://microformats.org/wiki/hcalendar-tests

... RDF calendar test development.
  http://www.w3.org/2002/12/cal/test/
  http://www.w3.org/2002/12/cal/#dev

I hope to get those two more sync'd up.

In particular, whatever answer I get from the CALSIFY WG on
this issue, I intend to reflect in those 2 test suites.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Date: Wed, 12 Apr 2006 13:42:53 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] CalConnect Roundtable VI -- May 22-25, Cambridge, Massachusetts - The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

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

*Come to Cambridge for CalConnect's Sixth Roundtable!*

This is a reminder that The Calendaring and Scheduling Consortium's 
Roundtable VI and associated interoperability testing event will be 
hosted by IBM/Lotus in Cambridge, Massachusetts, on May 22-25.  
Registration is now open for both the Roundtable and the IOP testing 
event (see below). 

The *interoperability testing event* will be all day Monday, May 22, and 
Tuesday morning the 23rd.  This event will offer IOP testing against the 
RFCs and extensive CalDAV testing, and will also focus on testing 
Free/Busy support.

The Consortium will offer a *Practicum on Tuesday morning* from 
9:30-12:00 to all Roundtable registrants (member representatives and 
observers), comprising two one-hour overview/levelset sessions on 
iCalendar Specifications and on CalDAV (the new calendaring access 
protocol).  The goal of these sessions is to provide a basic level of 
familiarity and understanding of iCalendar and CalDAV to any attendees 
who are not involved with the specifications and may wish to know more.

Tuesday afternoon is planned to be an in-depth *workshop on Mobile 
Calendaring*, with the goal of better identifying actual vendor and 
customer requirements for mobile interoperable calendaring and 
scheduling and helping to identify use cases, requirements, and a 
consensus vision statement for mobile calendaring in the future.  The 
workshop will be open to all attendees.

Wednesday, and Thursday morning, will be dedicated to *Technical 
Committee sessions* in areas such as CalDAV, Realtime (calendaring 
server-to-server protocols and requirements), Event Publication,  Use 
Case development, and  Authentication, plus a Plenary meeting of the 
Consortium.  All attendees are welcome to participate in any TC sessions 
which interest them. 

Registration is now open for the IOP testing event and for the 
Roundtable (separate registration required).  For more information and 
logistics see http://www.calconnect.org/roundtable6.html and 
http://www.calconnect.org/iopmay2006.html. 

To register for the Roundtable or IOP testing, see 
http://www.calconnect.org/roundtablereg.html (1) and
http://www.calconnect.org/iopreg.html (2).

(1) Please note that if you register by _May 5_ you will get a discount 
on your registration fee for the Roundtable.

(2) If you are a Consortium Member doing interoperability testing, you 
are also eligible for a 10% discount by agreeing to attend three 
consecutive IOP testing events (the discount applies for all three events).

Please contact me if you have any questions. 

See you in May!

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]>

--------------030103070205050809060307
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">
<b>Come to Cambridge for CalConnect's Sixth Roundtable!</b><br>
<br>
This is a reminder that The Calendaring and Scheduling Consortium's
Roundtable VI and associated interoperability testing event will be
hosted by IBM/Lotus in Cambridge, Massachusetts, on May 22-25.&nbsp;
Registration is now open for both the Roundtable and the IOP testing
event (see below).&nbsp; <br>
<br>
The <b>interoperability testing event</b> will be all day Monday, May
22, and Tuesday morning the 23rd.&nbsp; This event will offer IOP testing
against the RFCs and extensive CalDAV testing, and will also focus on
testing Free/Busy support.<br>
<br>
The Consortium will offer a <b>Practicum on Tuesday morning</b> from
9:30-12:00 to all Roundtable registrants (member representatives and
observers), comprising two one-hour overview/levelset sessions on
iCalendar Specifications and on CalDAV (the new calendaring access
protocol).&nbsp;
The goal of these sessions is to provide a basic level of familiarity
and understanding of iCalendar and CalDAV to any attendees who are not
involved with the specifications and may wish to know more.<br>
<br>
Tuesday afternoon is planned to be an in-depth <b>workshop on Mobile
Calendaring</b>, with the goal of better identifying actual vendor and
customer
requirements for mobile interoperable calendaring and scheduling and
helping to identify use cases, requirements, and a consensus vision
statement for mobile calendaring in the future.&nbsp; The workshop will be
open to all attendees.<br>
<br>
Wednesday, and Thursday morning, will be dedicated to <b>Technical
Committee sessions</b> in areas such as CalDAV, Realtime (calendaring
server-to-server protocols and requirements), Event Publication,&nbsp; Use
Case development, and&nbsp; Authentication, plus a Plenary meeting of the
Consortium.&nbsp; All attendees are welcome to participate in any TC
sessions which interest them.&nbsp; <br>
<br>
Registration is now open for the IOP testing event and for the
Roundtable (separate registration required).&nbsp; For more information and
logistics see <a href="http://www.calconnect.org/roundtable6.html">http://www.calconnect.org/roundtable6.html</a>
and <a href="http://www.calconnect.org/iopmay2006.html">http://www.calconnect.org/iopmay2006.html</a>.&nbsp;
<br>
<br>
To register for the Roundtable or IOP testing, see <a
 href="http://www.calconnect.org/roundtablereg.html">http://www.calconnect.org/roundtablereg.html</a>
(1) and <br>
<a href="http://www.calconnect.org/iopreg.html">http://www.calconnect.org/iopreg.html</a>
(2).<br>
<br>
<br>
(1) Please note that if you register by <u>May 5</u> you will get a
discount on your registration fee for the Roundtable. <br>
<br>
(2) If you are a Consortium Member doing interoperability testing, you
are also eligible for a 10% discount by agreeing to attend three
consecutive IOP testing events (the discount applies for all three
events).<br>
<br>
Please contact me if you have any questions.&nbsp; <br>
<br>
See you in May!<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>

--------------030103070205050809060307--

Date: Sun, 09 Apr 2006 11:35:53 +0200
From: Leif Johansson <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] location location location
Cc: [email-masked], [email-masked]

Eliot Lear wrote:
> Tim,
> 
> Great message.  I think you've crystallized something I've been trying
> to sort, which is do the characteristics of a meeting room belong in the
> standard itself or should that be dealt with elsewhere?  Often times
> conferences rooms are listed in LDAP *anyway*.  Is there/should there be
> a standard schema for this sort of thing?
> 
> Eliot

The COSINE schema contained a room objectclass with basic information
such as roomNumber, name and description. I don't know how widely
deployed it is though and you would have to expand on it to be able to
support any sort of capability-discovery for scheduling.

I suppose it is doable.

	Cheers Leif

Date: Fri, 07 Apr 2006 09:05:38 +0200
From: Eliot Lear <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] location location location
Cc: [email-masked], [email-masked]

Tim,

Great message.  I think you've crystallized something I've been trying
to sort, which is do the characteristics of a meeting room belong in the
standard itself or should that be dealt with elsewhere?  Often times
conferences rooms are listed in LDAP *anyway*.  Is there/should there be
a standard schema for this sort of thing?

Eliot

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>, "'Cyrus Daboo'" <[email-masked]>
Subject: RE: [Ietf-calsify] location location location
Date: Thu, 6 Apr 2006 22:06:50 -0400
Cc: [email-masked]

Some thoughts (for discussion):  

1. My understanding of RFC 2445 is that "components" are VEVENT, VTODO,
VJOURNAL - i.e. things with dates.  Trying to define a resource as a
component might break this concept.
2. As pointed out before, a resource is an "attendee" of a VEVENT (meeting)
set up by an organizer. Perhaps a VEVENT property that parallels ATTENDEE
would be useful at times.
3. ATTENDEE isn't really designed to hold all identifying information for a
person, instead it holds an indirect pointer (typically the e-mail address)
to the person.  Why should we design into iCalendar description of a
resource? Instead we should have a resource pointer, right? A URI seems
designed for this purpose (but I am not a web expert so correct me if I am
wrong).
4. For public event type publishing, each venue would/should own its own
VCALENDAR that contained all of the events at that venue, just as I own all
of the events describing my appointments and meetings. I point to my
calendar, and my calendar points to me, but that's the main extent of the
link. Maybe it should be the same for venues - they have a pointer to their
calendar, and if you download or otherwise connect to that calendar with
calendaring tools, the resulting object or file should point back to that
venue.

I don't have an easy answer, and I DO see the need for public event
publishing such as Eventful and Upcoming provide. I just don't see
description of the resource as one of the functions of iCalendar - and it
certainly doesn't help simplify the standard to move interoperability
forward.

Just my two cents worth,

Tim Hare
Interested Bystander, Non-Inc.

Date: Thu, 06 Apr 2006 13:04:45 -0700 (Pacific Daylight Time)
From: Anil SRIVASTAVA <[email-masked]>
Subject: Re: [Ietf-calsify] location location location
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>
Organization: Sun Microsystems [http://www.sun.com]
Accept-Language: English; en
Cc: [email-masked]
Reply-To: [email-masked]

On 2006-04-06/09:28 [-0400], [email-masked] [Cyrus Daboo] wrote:

> Hi Eliot,
> 
> --On April 6, 2006 11:42:05 AM +0200 Eliot Lear <[email-masked]> wrote:
> 
> > Do people see a standard way or "best" way to handling reservations 
> > regarding locations, such as meeting rooms?  Also, at a company like 
> > Cisco it seems to me that we would want to tag something about a 
> > conference bridge.  Is this the sort of thing that is ripe for 
> > standardization?  Right now there are a few proprietary hacks so far 
> > as I can tell.  Or perhaps I'm just showing my ignorance for all to 
> > see?
> 
> I guess right now most system handle meeting rooms etc by given them 
> their own calendar and allowing them to be part of the normal 
> free-busy/invitation process.
> 
> Actually a number of folks in Calconnect have been working on 'venue 
> information' embedded in iCalendar data. Specifically the current 
> Location property is not ideal for describing details about a location 
> that can be parsed into constituents parts (e.g. address, box office 
> phone number, map URL, website etc) but that is really needed for 
> public event descriptions.
> 
> Several possible solutions have been examined, including embedding 
> vCards, creating new properties similar to vCard items, and the 
> favored solution a new component type. It seems like the 
> 'capabilities' of a venue is what you are after - e.g. seating 
> capacity, AV equipment etc The problem with that is that there are so 
> many potential variables involved and its not always clear what 
> criteria could be used for doing bookings etc. We probably want to 
> avoid turning iCalendar into a resource tracking system too, so any 
> effort along these lines needs to be carefully scoped.

Having standard fields for common resource attributes (capacity, phone 
number, AV equipment, etc) is a very common request from calendar users.  

Now if we could model these as a properties of the calendar (including 
resource and user calendar), then that would be information that clients 
could consume when trying to find the 'right' resource for a meeting.

So I think there is a need for new component, one that can be attached 
to the calendar and encapsulates properties of the calendar.

Anil

> 
> -- 
> Cyrus Daboo
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

_______________
Anil SRIVASTAVA
[email-masked]

Date: Thu, 06 Apr 2006 16:47:50 +0200
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] location location location
Cc: [email-masked]

Cyrus & All,

Thanks for your thoughts.  Please see below:
>
> I guess right now most system handle meeting rooms etc by given them
> their own calendar and allowing them to be part of the normal
> free-busy/invitation process.
Right.
>
> Actually a number of folks in Calconnect have been working on 'venue
> information' embedded in iCalendar data. Specifically the current
> Location property is not ideal for describing details about a location
> that can be parsed into constituents parts (e.g. address, box office
> phone number, map URL, website etc) but that is really needed for
> public event descriptions.
Yes, that would be interesting.
>
> Several possible solutions have been examined, including embedding
> vCards, creating new properties similar to vCard items, and the
> favored solution a new component type. It seems like the
> 'capabilities' of a venue is what you are after - e.g. seating
> capacity, AV equipment etc The problem with that is that there are so
> many potential variables involved and its not always clear what
> criteria could be used for doing bookings etc. We probably want to
> avoid turning iCalendar into a resource tracking system too, so any
> effort along these lines needs to be carefully scoped.
>
Indeed.  Do others think this is an interesting area of exploration?

Eliot

Date: Thu, 06 Apr 2006 09:28:00 -0400
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] location location location

Hi Eliot,

--On April 6, 2006 11:42:05 AM +0200 Eliot Lear <[email-masked]> wrote:

> Do people see a standard way or "best" way to handling reservations
> regarding locations, such as meeting rooms?  Also, at a company like
> Cisco it seems to me that we would want to tag something about a
> conference bridge.  Is this the sort of thing that is ripe for
> standardization?  Right now there are a few proprietary hacks so far as
> I can tell.  Or perhaps I'm just showing my ignorance for all to see?

I guess right now most system handle meeting rooms etc by given them their 
own calendar and allowing them to be part of the normal 
free-busy/invitation process.

Actually a number of folks in Calconnect have been working on 'venue 
information' embedded in iCalendar data. Specifically the current Location 
property is not ideal for describing details about a location that can be 
parsed into constituents parts (e.g. address, box office phone number, map 
URL, website etc) but that is really needed for public event descriptions.

Several possible solutions have been examined, including embedding vCards, 
creating new properties similar to vCard items, and the favored solution a 
new component type. It seems like the 'capabilities' of a venue is what you 
are after - e.g. seating capacity, AV equipment etc The problem with that 
is that there are so many potential variables involved and its not always 
clear what criteria could be used for doing bookings etc. We probably want 
to avoid turning iCalendar into a resource tracking system too, so any 
effort along these lines needs to be carefully scoped.

-- 
Cyrus Daboo

Date: Thu, 06 Apr 2006 11:42:05 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] location location location

Hello all,

Do people see a standard way or "best" way to handling reservations
regarding locations, such as meeting rooms?  Also, at a company like
Cisco it seems to me that we would want to tag something about a
conference bridge.  Is this the sort of thing that is ripe for
standardization?  Right now there are a few proprietary hacks so far as
I can tell.  Or perhaps I'm just showing my ignorance for all to see?

Eliot

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Date: Mon, 3 Apr 2006 23:55:49 +0200
Subject: [Ietf-calsify] Re: UNTIL as a "floating" date-time as well as UTC date-time + Unrelated RFC Typo/Bug

Am Montag, 3. April 2006 22:46 schrieb ME:
> Desired:
> Allow for UNTIL to use "floating time" when a valid ";TZID=" is specified
> in the DTSTART.

That creates problems when the UNTIL time happens just at a time zone shift. 
E.g. take a recurrence with the following setting:
  UNTIL;TZID=Europe/Vienna:20060326T023000
In fact, there is no 2:30 here in Vienna, since the hour between 2:00 and 3:00 
is simply cut out. In that case you can solve the problem by arguing that the 
UNTIL is meant that no event occurs after 2:30.

On the other hand, when shall an hourly recurrence with 
  UNTIL;TZID=Europe/Vienna:20061029T023000
end? There are two 2:30 on that day (when summer time ends)...

Only if this ambiguity is resolved (in a way that allows recurrences that end 
on the first 2:30 and that allows recurrences that end on the second 2:30), 
using UNTIL in local time is a good idea.

(Actually, I started writing that mail before reading to the end. I even argue 
below that this is nothing special for the UNTIL, but a general problem, 
which is nowhere solved in the RFC).

> On to UNTIL...
>
> ...
> "The UNTIL rule part defines a date-time value which bounds the
>    recurrence rule in an inclusive manner. If the value specified by UNTIL
> is synchronized with the specified recurrence, this date or date-time
> becomes the last instance of the recurrence. If specified as a
> date-time value, then it MUST be specified in an UTC time
>    format."
> ...
>
> "If observance is known to have an effective end date, the
>         "UNTIL" recurrence rule parameter MUST be used to specify the last
> valid onset of this observance (i.e., the UNTIL date-time will be
> equal to the last instance generated by the recurrence pattern).
> It MUST be specified in UTC time."
> ...
> First partial paragraph suggests that UNTIL does not need to be be in UTC
> unless it is as a date-time value. Does this suggests a "date" value might
> be acceptable?

Yes, but from what I understand from the discussions here and the archives, 
the types of the UNTIL and the type of the DTSTART must match (similar to the 
DTSTART and DTEND: both can be either date or date-time. Although it's 
nowhere written that the types need to match, one of the authors of rfc 2445 
explained that they actually have to match).

So, if the DTSTART is a DATE, the UNTIL must also be a DATE, but if the 
DTSTART is a DATE-TIME, the UNTIL must be, too.

> Forcing UNTIL to be in UTC seems to break modularity of TIMEZONE for
> programmers, and create an unnecessary burden to perform per-timzeone
> calculation of the proper time for the given timezone.

Absolutely. All (or rathe almost all) other TZ calculations can be done in 
local time, but for this comparison a conversion to UTC is needed!

> There is a similar problem with RDATE an its requirement to be in UTC:
> "Alternatively, the "RDATE" property can be used to define the onset
>    of the observance by giving the individual onset date and times.
> "RDATE" in this usage MUST be specified as a local DATE-TIME value in
> UTC time."
> Though RFC says RDATE must also be in UTC, rfc also includes an example
> that seems to show otherwise:
> "RDATE;TZID=US-EASTERN:19970714T083000"

Hmm, strange. The grammar defines tzidparam as a valid parameter for rdate...
I suppose the first sentence is wrong and the "in UTC time" should be 
deleted...

However, again we have the same problem: 
  RDATE;TZID=Europe/Vienna:20061029T023000
Does this mean the first or the second 2:30?

> DTEND in FREEBUSY could also benefit from floating times when DTSTART
> includes ;TZID=

Actually, the requirement that FREEBUSY MUST be in UTC makes working with F/B 
lists so easy because you don't have to care about all the various timezones 
at all. Simply load the times, and convert them from UTC to your local time 
zone (for which there are OS calls available, so no ical library handling the 
TZs is necessary).

> A solution in the RFC?
>
> This next section seems to suggest that "floating" time may be used for
> what I describe above. 

Nope. A time
  DTSTART:20060403T230000
means 23:00 in the viewer's local time zone. If viewed by me, that's 23:00 
CEST, if viewed on the US east cost, it's 23:00 EST (or EDT?), etc.
So that time is not the same (absolute) time for everyone.

> For this, a local client would know about its own timezone, and be able to
> report to the ORGANIZER of an invalid UNTIL. Actually, this invalid UNTIL
> could also be at issue for DTSTART that start with an inavlid time. As a
> result, such an arguement can be applied to DTSTART being forced to UTC
> for the same reason. As a result, this de-values this as a sufficient
> reason to deny "floating times" in UNTIL while TZID is permitted in
> DTSTART.
> A similar reply was provided by:
> From: Jonathan Lennox <[email-masked]>
> "But the same thing's true for every other DATE-TIME in a recurrence
> (DTSTART, DTEND, etc.) -- and indeed in a calendar object.  Why is UNTIL
> special?"

Exactly, that's a general problem that at time zone shifts, one hour in local 
time either doesn't exists, or exists twice. There is no indication in the 
RFC how to solve this ambiguity.

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