From reinhold at kainhofer.com Mon Apr 3 14:55:49 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Mon Apr 3 14:56:05 2006 Subject: [Ietf-calsify] Re: UNTIL as a "floating" date-time as well as UTC date-time + Unrelated RFC Typo/Bug In-Reply-To: <45504.69.55.237.254.1144097191.squirrel@ssl.passwall.com> References: <45504.69.55.237.254.1144097191.squirrel@ssl.passwall.com> Message-ID: <200604032355.49857.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > "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: reinhold@kainhofer.com, 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEMZnlTqjEwhXvPN0RAm2PAJ4lRRbvHoLegsj2XpxG0AXzbnIClgCeP3Ui 70KwjqxPHJK0tgpLEqlRBio= =15Si -----END PGP SIGNATURE----- From lear at cisco.com Thu Apr 6 02:42:05 2006 From: lear at cisco.com (Eliot Lear) Date: Thu Apr 6 02:42:09 2006 Subject: [Ietf-calsify] location location location Message-ID: <4434E26D.5030401@cisco.com> 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 cyrus at daboo.name Thu Apr 6 06:28:00 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Apr 6 06:27:42 2006 Subject: [Ietf-calsify] location location location In-Reply-To: <4434E26D.5030401@cisco.com> References: <4434E26D.5030401@cisco.com> Message-ID: <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> Hi Eliot, --On April 6, 2006 11:42:05 AM +0200 Eliot Lear 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 From lear at cisco.com Thu Apr 6 07:47:50 2006 From: lear at cisco.com (Eliot Lear) Date: Thu Apr 6 07:47:55 2006 Subject: [Ietf-calsify] location location location In-Reply-To: <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> References: <4434E26D.5030401@cisco.com> <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> Message-ID: <44352A16.5050507@cisco.com> 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 From Anil.Srivastava at Sun.COM Thu Apr 6 13:04:45 2006 From: Anil.Srivastava at Sun.COM (Anil SRIVASTAVA) Date: Thu Apr 6 13:04:52 2006 Subject: [Ietf-calsify] location location location In-Reply-To: <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> References: <4434E26D.5030401@cisco.com> <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> Message-ID: On 2006-04-06/09:28 [-0400], cyrus@daboo.name [Cyrus Daboo] wrote: > Hi Eliot, > > --On April 6, 2006 11:42:05 AM +0200 Eliot Lear 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 > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM From TimHare at comcast.net Thu Apr 6 19:06:50 2006 From: TimHare at comcast.net (Tim Hare) Date: Thu Apr 6 19:06:51 2006 Subject: [Ietf-calsify] location location location In-Reply-To: Message-ID: <20060407020648.5EA96142267@laweleka.osafoundation.org> 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. From lear at cisco.com Fri Apr 7 00:05:38 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Apr 7 00:05:45 2006 Subject: [Ietf-calsify] location location location In-Reply-To: <20060407020648.5EA96142267@laweleka.osafoundation.org> References: <20060407020648.5EA96142267@laweleka.osafoundation.org> Message-ID: <44360F42.8040808@cisco.com> 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 leifj at it.su.se Sun Apr 9 02:35:53 2006 From: leifj at it.su.se (Leif Johansson) Date: Sun Apr 9 02:36:00 2006 Subject: [Ietf-calsify] location location location In-Reply-To: <44360F42.8040808@cisco.com> References: <20060407020648.5EA96142267@laweleka.osafoundation.org> <44360F42.8040808@cisco.com> Message-ID: <4438D579.1050207@it.su.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEONV58Jx8FtbMZncRAvQeAJ9xmAVhXzm9uvpY8xLAgpw0XJYpcwCgp8tf QI5IKie3G+FGM7A3LWH/q/c= =y9BW -----END PGP SIGNATURE----- From Dave.Thewlis at calconnect.org Wed Apr 12 13:42:53 2006 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Wed Apr 12 13:42:56 2006 Subject: [Ietf-calsify] CalConnect Roundtable VI -- May 22-25, Cambridge, Massachusetts - The Calendaring and Scheduling Consortium Message-ID: <443D664D.1060601@calconnect.org> *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 ? Dave.Thewlis@calconnect.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060412/c9241c1a/attachment.html From connolly at w3.org Fri Apr 21 10:55:18 2006 From: connolly at w3.org (Dan Connolly) Date: Fri Apr 21 10:55:25 2006 Subject: [Ietf-calsify] dtstart and date vs datetime Message-ID: <1145642119.27608.664.camel@dirk.w3.org> 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 From lear at cisco.com Sun Apr 23 02:15:04 2006 From: lear at cisco.com (Eliot Lear) Date: Sun Apr 23 02:15:11 2006 Subject: [Ietf-calsify] dtstart and date vs datetime In-Reply-To: <1145642119.27608.664.camel@dirk.w3.org> References: <1145642119.27608.664.camel@dirk.w3.org> Message-ID: <444B4598.9040601@cisco.com> 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 connolly at w3.org Sun Apr 23 19:33:23 2006 From: connolly at w3.org (Dan Connolly) Date: Sun Apr 23 19:33:28 2006 Subject: [Ietf-calsify] dtstart and date vs datetime In-Reply-To: <444B4598.9040601@cisco.com> References: <1145642119.27608.664.camel@dirk.w3.org> <444B4598.9040601@cisco.com> Message-ID: <1145846004.27608.832.camel@dirk.w3.org> 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 From dthewlis at dcta.com Mon Apr 24 14:56:47 2006 From: dthewlis at dcta.com (David C. Thewlis) Date: Mon Apr 24 14:57:06 2006 Subject: [Ietf-calsify] CalConnect -- Request for Comments - Calendaring on Mobile Devices Message-ID: <444D499F.3010507@dcta.com> 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 chris.dudding@symbian.com Dave Thewlis, CalConnect Executive Director dave.thewlis@calconnect.org /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_//./ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060424/6510dd91/attachment.htm From lisa at osafoundation.org Tue Apr 25 10:21:41 2006 From: lisa at osafoundation.org (Lisa Dusseault) Date: Tue Apr 25 10:21:50 2006 Subject: [Ietf-calsify] New chair: Eliot Lear Message-ID: <2617649B-A556-4083-9BB8-A40669C4110A@osafoundation.org> 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CCE197F763 for ; Tue, 25 Apr 2006 10:21:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE6F314226C for ; Tue, 25 Apr 2006 10:21:48 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02878-03 for ; Tue, 25 Apr 2006 10:21:48 -0700 (PDT) Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B6C014226B for ; Tue, 25 Apr 2006 10:21:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <2617649B-A556-4083-9BB8-A40669C4110A@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF-iCalendar From: Lisa Dusseault Date: Tue, 25 Apr 2006 10:21:41 -0700 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-5.9 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-calsify] New chair: Eliot Lear X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 17:21:48 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5AFEA7F72C for ; Mon, 24 Apr 2006 14:57:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4C9CC142281 for ; Mon, 24 Apr 2006 14:57:04 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02020-06 for ; Mon, 24 Apr 2006 14:57:02 -0700 (PDT) Received: from s-utl01-dcpop.stsn.net (s-utl01-dcpop.stsn.net [72.255.0.201]) by laweleka.osafoundation.org (Postfix) with SMTP id 63DBB142246 for ; Mon, 24 Apr 2006 14:57:02 -0700 (PDT) Received: from s-utl01-dcpop.stsn.net ([127.0.0.1]) by s-utl01-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2006042417565908732 ; Mon, 24 Apr 2006 17:56:59 -0400 Received: from [127.0.0.1] ([10.77.47.251]) by s-utl01-dcpop.stsn.net; Mon, 24 Apr 2006 17:56:57 -0400 Message-ID: <444D499F.3010507@dcta.com> Date: Mon, 24 Apr 2006 14:56:47 -0700 From: "David C. Thewlis" Organization: DCTA Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-calsify list Content-Type: multipart/alternative; boundary="------------090905020408000502020505" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-5.9 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, BAYES_00, HTML_30_40, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-calsify] CalConnect -- Request for Comments - Calendaring on Mobile Devices X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 21:57:04 -0000 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 chris.dudding@symbian.com Dave Thewlis, CalConnect Executive Director dave.thewlis@calconnect.org /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_//./ --------------090905020408000502020505 Content-Type: text/html; charset=ISO-8859-1 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
chris.dudding@symbian.com

Dave Thewlis, CalConnect
Executive Director
dave.thewlis@calconnect.org

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.

--------------090905020408000502020505-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 308BE7F71F for ; Sun, 23 Apr 2006 19:33:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 22FAD142279 for ; Sun, 23 Apr 2006 19:33:27 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17710-01 for ; Sun, 23 Apr 2006 19:33:26 -0700 (PDT) Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by laweleka.osafoundation.org (Postfix) with ESMTP id 57EB114227B for ; Sun, 23 Apr 2006 19:33:26 -0700 (PDT) Received: from dirk.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id CF3524EFAA; Sun, 23 Apr 2006 22:33:24 -0400 (EDT) Subject: Re: [Ietf-calsify] dtstart and date vs datetime From: Dan Connolly To: Eliot Lear In-Reply-To: <444B4598.9040601@cisco.com> References: <1145642119.27608.664.camel@dirk.w3.org> <444B4598.9040601@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: World Wide Web Consortium (http://www.w3.org/) Date: Sun, 23 Apr 2006 21:33:23 -0500 Message-Id: <1145846004.27608.832.camel@dirk.w3.org> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-calsify@osafoundation.org, RDF Calendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 02:33:27 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B73B77F77F for ; Sun, 23 Apr 2006 02:15:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A8479142274 for ; Sun, 23 Apr 2006 02:15:09 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04812-10 for ; Sun, 23 Apr 2006 02:15:08 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F554142273 for ; Sun, 23 Apr 2006 02:15:08 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 23 Apr 2006 02:15:08 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3N9F7h0019516; Sun, 23 Apr 2006 02:15:07 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp4377.cisco.com [10.61.81.24]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k3N9E65Z032673; Sun, 23 Apr 2006 02:14:07 -0700 Message-ID: <444B4598.9040601@cisco.com> Date: Sun, 23 Apr 2006 11:15:04 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Dan Connolly Subject: Re: [Ietf-calsify] dtstart and date vs datetime References: <1145642119.27608.664.camel@dirk.w3.org> In-Reply-To: <1145642119.27608.664.camel@dirk.w3.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit DKIM-Signature: a=rsa-sha1; q=dns; l=622; t=1145783648; x=1146647648; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-calsify]=20dtstart=20and=20date=20vs=20datetime |To:Dan=20Connolly=20; X=v=3Dcisco.com=3B=20h=3DfM7E6V0l0PHZVfZx1aAbIu664rk=3D; b=EKlLzvIdnwdwDZVTResdqqJBEnLJlO3iCG8rDzeV3uGIE9a0pomQp27nWoB8+A283Yk1BlQv WnUVFOR1YHnhuCHnVogrXcn5RKC/jDZTHaipUqxW98wZXvrhVwD/ScG9; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-calsify@osafoundation.org, RDF Calendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 09:15:09 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6999D7F820 for ; Fri, 21 Apr 2006 10:55:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BDEC14225E for ; Fri, 21 Apr 2006 10:55:24 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31612-02 for ; Fri, 21 Apr 2006 10:55:22 -0700 (PDT) Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by laweleka.osafoundation.org (Postfix) with ESMTP id C6153142250 for ; Fri, 21 Apr 2006 10:55:22 -0700 (PDT) Received: from dirk.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id F26EE4EF7E; Fri, 21 Apr 2006 13:55:19 -0400 (EDT) From: Dan Connolly To: ietf-calsify@osafoundation.org Content-Type: text/plain Organization: World Wide Web Consortium (http://www.w3.org/) Date: Fri, 21 Apr 2006 12:55:18 -0500 Message-Id: <1145642119.27608.664.camel@dirk.w3.org> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: RDF Calendar Subject: [Ietf-calsify] dtstart and date vs datetime X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2006 17:55:24 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2D2947F7F5 for ; Wed, 12 Apr 2006 13:42:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1E7DA142276 for ; Wed, 12 Apr 2006 13:42:56 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05462-01 for ; Wed, 12 Apr 2006 13:42:55 -0700 (PDT) Received: from fed1rmmtao02.cox.net (fed1rmmtao02.cox.net [68.230.241.37]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5AEE0142274 for ; Wed, 12 Apr 2006 13:42:55 -0700 (PDT) Received: from [192.168.0.102] (really [70.191.49.25]) by fed1rmmtao02.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060412204254.NOAJ14494.fed1rmmtao02.cox.net@[192.168.0.102]>; Wed, 12 Apr 2006 16:42:54 -0400 Message-ID: <443D664D.1060601@calconnect.org> Date: Wed, 12 Apr 2006 13:42:53 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-calsify list Content-Type: multipart/alternative; boundary="------------030103070205050809060307" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_20_30, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-calsify] CalConnect Roundtable VI -- May 22-25, Cambridge, Massachusetts - The Calendaring and Scheduling Consortium X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 20:42:56 -0000 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 · Dave.Thewlis@calconnect.org --------------030103070205050809060307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 · Dave.Thewlis@calconnect.org
--------------030103070205050809060307-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D94967F6BF for ; Sun, 9 Apr 2006 02:35:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C222C142277 for ; Sun, 9 Apr 2006 02:35:59 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05112-02 for ; Sun, 9 Apr 2006 02:35:58 -0700 (PDT) Received: from smtp3.su.se (smtp3.su.se [130.237.93.228]) by laweleka.osafoundation.org (Postfix) with ESMTP id 20C9914224D for ; Sun, 9 Apr 2006 02:35:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id C524C3BE43; Sun, 9 Apr 2006 11:35:55 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12220-02-2; Sun, 9 Apr 2006 11:35:55 +0200 (CEST) Received: from [10.0.0.242] (1-1-2-20a.rny.sth.bostream.se [82.182.132.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id D3BE73BE24; Sun, 9 Apr 2006 11:35:54 +0200 (CEST) Message-ID: <4438D579.1050207@it.su.se> Date: Sun, 09 Apr 2006 11:35:53 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] location location location References: <20060407020648.5EA96142267@laweleka.osafoundation.org> <44360F42.8040808@cisco.com> In-Reply-To: <44360F42.8040808@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-calsify@osafoundation.org, Anil.Srivastava@Sun.COM X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2006 09:36:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEONV58Jx8FtbMZncRAvQeAJ9xmAVhXzm9uvpY8xLAgpw0XJYpcwCgp8tf QI5IKie3G+FGM7A3LWH/q/c= =y9BW -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EC5317F6C0 for ; Fri, 7 Apr 2006 00:05:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DD8CA142270 for ; Fri, 7 Apr 2006 00:05:43 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26046-07 for ; Fri, 7 Apr 2006 00:05:41 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C4F3142267 for ; Fri, 7 Apr 2006 00:05:41 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 07 Apr 2006 00:05:41 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3775f7T022407; Fri, 7 Apr 2006 00:05:41 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp447.cisco.com [10.61.65.191]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k3775dbs019849; Fri, 7 Apr 2006 00:05:39 -0700 Message-ID: <44360F42.8040808@cisco.com> Date: Fri, 07 Apr 2006 09:05:38 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Tim Hare Subject: Re: [Ietf-calsify] location location location References: <20060407020648.5EA96142267@laweleka.osafoundation.org> In-Reply-To: <20060407020648.5EA96142267@laweleka.osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=350; t=1144393541; x=1145257541; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-calsify]=20location=20location=20location |To:Tim=20Hare=20; X=v=3Dcisco.com=3B=20h=3Dy3xurM/TeLC7QebJmU75JhYbVdI=3D; b=dAayWvyYdw0pj3/E4JqyBkH8c4HSZtHWnXnAEZCULQnZDX1TUOrE+ROb87CpxP5vYEpKGMro wqvBlv2BArLNqDGGuAbd85OEdj3QNaoEI8ISKauoWYFwJl58T6yBo1yB; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-calsify@osafoundation.org, Anil.Srivastava@Sun.COM X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 07:05:44 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E2D8E7F745 for ; Thu, 6 Apr 2006 19:06:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D310914226E for ; Thu, 6 Apr 2006 19:06:49 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23185-05 for ; Thu, 6 Apr 2006 19:06:48 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5EA96142267 for ; Thu, 6 Apr 2006 19:06:48 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc14) with SMTP id <20060407020646m1400r83ale>; Fri, 7 Apr 2006 02:06:46 +0000 From: "Tim Hare" To: , "'Cyrus Daboo'" Subject: RE: [Ietf-calsify] location location location Date: Thu, 6 Apr 2006 22:06:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcZZtV4jIUgGBKXeSuWyrMRVsRi1GQAL+WvA Message-Id: <20060407020648.5EA96142267@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 02:06:50 -0000 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 308087F777 for ; Thu, 6 Apr 2006 13:04:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 22A1F14226C for ; Thu, 6 Apr 2006 13:04:51 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00588-07 for ; Thu, 6 Apr 2006 13:04:50 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4D373142267 for ; Thu, 6 Apr 2006 13:04:50 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k36K4nJO016903 for ; Thu, 6 Apr 2006 14:04:49 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IXB00801GSBZ300@mail-amer.sun.com> (original mail from Anil.Srivastava@Sun.COM) for ietf-calsify@osafoundation.org; Thu, 06 Apr 2006 14:04:49 -0600 (MDT) Received: from [192.18.127.162] (host-162-127-18-192.iplanet.com [192.18.127.162]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXB002D0H40CR50@mail-amer.sun.com>; Thu, 06 Apr 2006 14:04:49 -0600 (MDT) Date: Thu, 06 Apr 2006 13:04:45 -0700 (Pacific Daylight Time) From: Anil SRIVASTAVA Subject: Re: [Ietf-calsify] location location location In-reply-to: <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> Sender: Anil.Srivastava@Sun.COM To: Cyrus Daboo Message-id: Organization: Sun Microsystems [http://www.sun.com] MIME-version: 1.0 X-Mailer: Pine 4.64 (Windows XP) - Got Pine? [http://www.washington.edu/pine] Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Enterprise System Communication Suite 4 References: <4434E26D.5030401@cisco.com> <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> X-Message-flag: Outlook: the best virus distribution system around X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anil.Srivastava@Sun.COM List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 20:04:51 -0000 On 2006-04-06/09:28 [-0400], cyrus@daboo.name [Cyrus Daboo] wrote: > Hi Eliot, > > --On April 6, 2006 11:42:05 AM +0200 Eliot Lear 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 > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2CE797F72D for ; Thu, 6 Apr 2006 07:47:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 13DE314226E for ; Thu, 6 Apr 2006 07:47:54 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26720-02 for ; Thu, 6 Apr 2006 07:47:53 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by laweleka.osafoundation.org (Postfix) with ESMTP id 609D114226D for ; Thu, 6 Apr 2006 07:47:53 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 06 Apr 2006 07:47:53 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k36Elqw1007342; Thu, 6 Apr 2006 07:47:53 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp4240.cisco.com [10.61.80.143]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k36ElrJr021476; Thu, 6 Apr 2006 07:47:54 -0700 Message-ID: <44352A16.5050507@cisco.com> Date: Thu, 06 Apr 2006 16:47:50 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] location location location References: <4434E26D.5030401@cisco.com> <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> In-Reply-To: <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1352; t=1144334875; x=1145198875; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-calsify]=20location=20location=20location |To:Cyrus=20Daboo=20; X=v=3Dcisco.com=3B=20h=3DXUG3By3r65kBXfzUpH6JSYgE+v4=3D; b=p+wes0qJQzNPTX+D/JOIDa97P2dBDKyOi8rjD1XnQ3rXQn8+n8OeqcqxqhmzlO+7u8S7JArT 1/aDwi3IyOKvC3HzJ9hbj0L1+9gmU0TZUQKTm7CiPZDU/eN/Eszalus2; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 14:47:54 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 662007F731 for ; Thu, 6 Apr 2006 06:27:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 582ED142267 for ; Thu, 6 Apr 2006 06:27:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18278-04 for ; Thu, 6 Apr 2006 06:27:39 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id C7E3B142247 for ; Thu, 6 Apr 2006 06:27:39 -0700 (PDT) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id C68FCD4764F; Thu, 6 Apr 2006 09:27:38 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Thu, 06 Apr 2006 09:27:27 -0400 X-Sasl-enc: 3MEj5kDrXjPZ1VrrcDBV1i3UDb2zw7YEiT/paiKIx8Eb 1144330047 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 9452A2B20; Thu, 6 Apr 2006 09:27:26 -0400 (EDT) Date: Thu, 06 Apr 2006 09:28:00 -0400 From: Cyrus Daboo To: Eliot Lear , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] location location location Message-ID: <9C16954C319CB04DD66DC8E6@Cyrus-Daboo.local> In-Reply-To: <4434E26D.5030401@cisco.com> References: <4434E26D.5030401@cisco.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 13:27:40 -0000 Hi Eliot, --On April 6, 2006 11:42:05 AM +0200 Eliot Lear 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2E37A7F6EB for ; Thu, 6 Apr 2006 02:42:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 08B73142266 for ; Thu, 6 Apr 2006 02:42:08 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13107-04 for ; Thu, 6 Apr 2006 02:42:06 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by laweleka.osafoundation.org (Postfix) with ESMTP id B5560142262 for ; Thu, 6 Apr 2006 02:42:06 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 06 Apr 2006 02:42:06 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k369g6w1029059 for ; Thu, 6 Apr 2006 02:42:06 -0700 (PDT) Received: from [144.254.22.247] (dhcp-wdata-vlan18-22-247.cisco.com [144.254.22.247]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k369g8wQ013026 for ; Thu, 6 Apr 2006 02:42:09 -0700 Message-ID: <4434E26D.5030401@cisco.com> Date: Thu, 06 Apr 2006 11:42:05 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=438; t=1144316529; x=1145180529; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:location=20location=20location |To:=22ietf-calsify@osafoundation.org=22=20; X=v=3Dcisco.com=3B=20h=3DNIbq5tFlZgPPOWnBNJZlOCRINqs=3D; b=SJEyV8x2akFTLbOcHVBDkt4wrg2MwKP82e+OIDbNsehVt0ieO2pRiNIBpy1GWaUIGQTox1hy nRXOaw/bBQ3pULASzRQxSVGbq9eFwRl5Yt4daHHKU4ltkDcT/DSBnwHW; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] location location location X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 09:42:08 -0000 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 Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4DF1E7F62E for ; Mon, 3 Apr 2006 14:56:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4005B142281 for ; Mon, 3 Apr 2006 14:56:03 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05044-01 for ; Mon, 3 Apr 2006 14:55:59 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9DCBD14227E for ; Mon, 3 Apr 2006 14:55:58 -0700 (PDT) Received: from wiener.fam.tuwien.ac.at (wienernfs [12.0.0.100]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k33LttOx006452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 3 Apr 2006 23:55:55 +0200 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by wiener.fam.tuwien.ac.at with esmtp (Exim 4.50) id 1FQX1f-0005r0-Kr for Ietf-calsify@osafoundation.org; Mon, 03 Apr 2006 23:55:55 +0200 From: Reinhold Kainhofer Organization: Vienna University of Technology To: CALSIFY Mailinglist User-Agent: KMail/1.9.1 References: <45504.69.55.237.254.1144097191.squirrel@ssl.passwall.com> In-Reply-To: <45504.69.55.237.254.1144097191.squirrel@ssl.passwall.com> Content-Disposition: inline Date: Mon, 3 Apr 2006 23:55:49 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200604032355.49857.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-calsify] Re: UNTIL as a "floating" date-time as well as UTC date-time + Unrelated RFC Typo/Bug X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 21:56:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > "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: reinhold@kainhofer.com, 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEMZnlTqjEwhXvPN0RAm2PAJ4lRRbvHoLegsj2XpxG0AXzbnIClgCeP3Ui 70KwjqxPHJK0tgpLEqlRBio= =15Si -----END PGP SIGNATURE-----