From Dave.Thewlis at calconnect.org Thu Dec 2 07:50:40 2004 From: Dave.Thewlis at calconnect.org (David C. Thewlis) Date: Thu Dec 2 07:51:21 2004 Subject: [Ietf-calsify] Call for Participantion -- Second Calconnect Interop - 11-12 January 2005 - Seattle, Washington References: <200411181732510014.00FA5091@smtp.west.cox.net> <200412020748000071.082E3FF1@smtp.west.cox.net> Message-ID: <200412020750400882.0830B41C@smtp.west.cox.net> Please note that this announcement is being posted on multiple calendaring-related reflectors and to the Calconnect mailing lists to ensure as wide a distribution as possible. Our apologies if you receive multiple copies. CALL FOR PARTICIPATION -- SECOND INTEROP TESTING EVENT - 11-12 January 2005 The second Interop of The Calendaring and Scheduling Consortium (CALCONNECT.ORG) will take place Tuesday and Wednesday, January 11-12, 2005. It will be hosted by the University of Washington and the venue will be on the UW Campus in Seattle, Washington. This event will feature three separate Interop testing scenarios. Participating organizations are welcome to test against one, two, or all three scenarios. Please note however that these scenarios will be going on simultaneously so you will probably need a team for each scenario you participate in. Space will be limited so early notification and registration is advised. INTEROP SCENARIOS (a) Full scale interop: against iCal, iMIP, iTIP, essentially the same scenario as the one done in July 2004. The goal is to get results from testing by more implementations to augment the data from July -- at the July event Oracle and IBM tested; it would be very useful to have results from other vendors to augment the understanding of the RFCs gained from the July (and earlier) Interops. (b) Min-IOP Interop: The Min-IOP Technical Committee of the Consortium was formed to identify and define the "Minimum Interoperable Subset" for iCalendar as part of the work towards the Calsify effort in the IETF. This Interop scenario is for implementations to test against that subset. The goal is to help define baseline requirements for the CALSIFY effort and to determine what the real world common subset actually is, so the more implementations tested against this common subset the more realistic and useful the results will be. (c) CalDAV Interop: Oracle Corporation will provide a prototype CalDAV server for client testing, and work is progressing on the definition of the test cases for the scenario. Some vendors have expressed interest in being able to do a CalDAV Interop as soon as possible. This will provide early feedback to the server implementors, the CalDAV specification authors, and the client implementors. WHO MAY PARTICIPATE IN THE INTEROPS Any vendor or organization wishing to test a calendaring and scheduling implementation is welcome to attend whether or not they are a Consortium member. Note that Consortium members do receive a substantial discount on their Interop participation fee (see below). CONSORTIUM ROUNDTABLE II Technical committee meetings of the Calendaring and Scheduling Consortium are also planned for 11-12 January at the same location, followed by an all-hands Consortium Roundtable on Thursday 13 January. Interop participants who are not Consortium members will not be able to participate in the other Consortium activities as they are reserved to members. However, a non-member Interop Participant can join the Consortium at the event and become a member immediately and be able to participate in the technical committee and roundtable meetings. REGISTRATION FEE The registration fee for the Interop is $1500 for Consortium members and $2500 for non-members. The registration fee covers two individuals; additional individuals are $150 each for members or non-members. (If you are planning to participate in more than one Interop scenario you may need more than two people.) Members: Please note that the Interop Registration Fee for Members also covers the registration fee for participation in the Consortium events for the interop participants. HOW TO REGISTER AND FURTHER INFORMATION Detailed information including logistics will be posted on the Consortium website as as it becomes available; go to http://www.calconnect.org and select "Interops Future". You may also register online on the website by selecting "Interops Registration". For questions or more information, or to inform us of your plan to participate in the Interop, please contact me at the Consortium. Best Regards, Dave Thewlis Executive Director The Calendaring and Scheduling Consortium 1550 Dena Drive McKinleyville CA 95519-4146 +1 707 840 9391 (voice) +1 415 946 3454 (fax) +1 707 498 2238 (mobile) Dave.Thewlis@calconnect.org www.calconnect.org From Dave.Thewlis at calconnect.org Sat Dec 4 06:16:26 2004 From: Dave.Thewlis at calconnect.org (David C. Thewlis) Date: Sat Dec 4 06:17:08 2004 Subject: [Ietf-calsify] Meeting Notice: CalConnect Roundtable II -- The Calendaring and Scheduling Consortium References: <200411181732510014.00FA5091@smtp.west.cox.net> <200412031704340937.022969F3@smtp.west.cox.net> <200412040611340300.0209B674@smtp.west.cox.net> Message-ID: <200412040616260730.020E2CC2@smtp.west.cox.net> Our apologies if you receive multiple copies of this announcement. We've had requests from non-members for notification of Consortium events so we are circulating this notice widely. MEETING NOTICE: CALCONNECT ROUNDTABLE II The second Calendaring and Scheduling Consortium Roundtable will be held Tuesday-Thursday, 11-13 January, 2005, hosted by the University of Washington on the UW Campus in Seattle, Washington. We expect to have space for 25-30 people so early notification of intent to participate will be important. This three-day event will include Consortium Technical Committee Meetings for all TCs which wish to meet in person, and a full Roundtable of all participants to consider TC reports, evaluate progress, and establish next steps and directions in working towards interoperable Calendaring and Scheduling. There will also be a co-located Interop Testing Event on Tuesday and Wednesday, which will run three different testing scenarios (please see the information for this Interop on the Consortium website). This event is open to Consortium members only. Participation in the co-located Interop is open to both members and non-members. Non-members interested in the Consortium may join the Consortium prior to the Roundtable or onsite (including non-members participating in the Interop event) and attend the Consortium activities. SCHEDULE The general schedule is: Interops (in parallel) - all day Tuesday, Wednesday morning TC meetings - all day Tuesday, Wednesday morning, and afternoon as needed Group Dinner - Wednesday evening Roundtable - may begin Wednesday mid-afternoon; Thursday until 3:00 REGISTRATION FEE There is a nominal registration fee for the Roundtable to cover meeting facilities, food and breaks, and the group dinner. If your organization is a Consortium member participating in the co-located Interop, and you are covered by the Interop Registration Fee, you need not pay a separate registration fee for the Roundtable. MORE INFORMATION AND REGISTRATION More information about this event, including logistics information, venues, fees, etc. is posted on the Consortium website. Please go to www.calconnect.org and select Membership Activities-->Next Roundtable. If you are interested in participating in the Interop, please see Interops-->Jan 2005. The event hotel is the Seattle Watertown: www.watertownseattle.com, The cutoff date for the group rate (group name "calconnect" is 20 December 2004. If you wish to attend the Roundtable, please contact me directly (contact information below) to register and to arrange payment of registration fees. Remember that space is limited by the size of the venue meeting room; early registration is advised. If you plan to attend the Interop, please use the registration form on the Consortium website; see Interops-->Register. If you will attend both the Interop and the Roundtable, please contact me directly to be sure you are included in planning for both events. Please contact me if you have any questions. Best Regards, Dave Thewlis, Executive Director The Calendaring and Scheduling Consortium 1550 Dena Drive McKinleyville CA 95519-4146 +1 707 840 9391 (voice) +1 415 946 3454 (fax) +1 707 498 2238 (mobile) Dave.Thewlis@calconnect.org www.calconnect.org From TimHare at comcast.net Mon Dec 20 18:08:39 2004 From: TimHare at comcast.net (TimHare@comcast.net) Date: Mon Dec 20 18:12:47 2004 Subject: [Ietf-calsify] another thought for simplification / levels Message-ID: <122120040208.22434.41C785A7000650BD000057A222007621940A9D0EB80307AB@comcast.net> This idea was inspired by someone who asked about my XML-with-calendar guideline draft; I'm posting it here because I think this may be the most appropriate place to begin this discussion. We've had some discussion about having various levels of iCalendar to allow simplification. This would of course require a mechanism that allowed one to know what levels were supported by sender and receiver. There are also quite a few people that are thinking about and working on events/scheduling information in XML - which makes sense because of the large number of XML tools available to developers and its growing use as an interchange mechanism. This has prompted me to think that perhaps the "simplified" version of iCalendar ought to be an XML version instead? There are several advantages to this idea in my opinion: 1. We could use XML to group things from different levels together (this is just an example) (whatever we decide level 0 stuff is goes here) (more advanced items go here) 2. XML allows developers to use namespaces for extensions and additions 3. XML tools are prevalent in many development packages and databases systems, easing development 4. XML is understood at some level by many more developers 5. We can always "down-convert" an XML representation to iCalendar through XSLT 6. For events calendars and the like: the structure of XML would make it easier to create search tools for events There of course will be negatives - one of which is the addition of code to existing products that support iCalendar, to also support the new XML-based format. My instincts tell me that many of these products already support XML in some ways, so that much of the software infrastructure to support XML is already there (for example, MS Office supports XML for quite a few things now); but I am not a software vendor, so take that with a grain of salt unless vendor representatives on this list would care to comment. I posting this a discussion-generator. This being the holidays, I don't expect a lot of discussion right at the moment, but please, let's kick this one around for a bit. Tim Hare Interested Bystander, Non-Inc. From camerost at exchange.microsoft.com Mon Dec 20 18:44:25 2004 From: camerost at exchange.microsoft.com (Cameron Stillion) Date: Mon Dec 20 18:47:55 2004 Subject: [Ietf-calsify] another thought for simplification / levels Message-ID: <1198328AFDBF5841B27E40C40C33153701D6C0BA@df-chewy-msg.exchange.corp.microsoft.com> XML does bring some advantages to the table that frankly, ought to be considered for any new standard - the first and most significant, I think, is that no new parsers need to be written. Or at least, the number of encoding and parsing errors that are likely to occur are significantly decreased. Internationalization is comparitively easy, and no low-level description of the format would need be discussed. One can focus on the schema instead. Your suggestion that there exists support for XML in existing applications is fair, but be wary about overcommitting libraries that you are not intimately familiar with. I suspect that there are several XML parsers within many large codebases, but I cannot say whether any of them are of sufficient or desirable to use in these circumstances. Obviously it behooves vendors to develop good low-level support for parsing XML, and it may very well be arguably good to push them in that direction anyway. Assuming they are there already might be bolder than you think. In general, I like your idea, but I think it is most meaningful for new standards, and I see your suggestion as a new standard: xCalendar perhaps. This might be very compelling especially for calendar publishing software that could also provide transforms for these types of data and thereby provide glowing chrome to navigate a .xcal on a web site, for example. icalshare.com or icalx.com might both decide to do some cool fancy things with that, especially if a vendor or two adopted it. My suspicion is that only some compelling new features would bring vendors to the state of wanting to. (e.g. support for mime-type-specified bodies ...., non-gregorian recurrences ... and the like) Back to the current state of affairs, I believe the calsify endeavor is to add nothing to the existing standard, but only to simplify it to the point of standard-application-usability and interoperability. I suggest that a new and separate endeavor should pursue the xml-ified variation. That's my take... ++cam; -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of TimHare@comcast.net Sent: Monday, December 20, 2004 6:09 PM To: ietf-calsify@osafoundation.org Cc: Jonathan Boarman Subject: [Ietf-calsify] another thought for simplification / levels This idea was inspired by someone who asked about my XML-with-calendar guideline draft; I'm posting it here because I think this may be the most appropriate place to begin this discussion. We've had some discussion about having various levels of iCalendar to allow simplification. This would of course require a mechanism that allowed one to know what levels were supported by sender and receiver. There are also quite a few people that are thinking about and working on events/scheduling information in XML - which makes sense because of the large number of XML tools available to developers and its growing use as an interchange mechanism. This has prompted me to think that perhaps the "simplified" version of iCalendar ought to be an XML version instead? There are several advantages to this idea in my opinion: 1. We could use XML to group things from different levels together (this is just an example) (whatever we decide level 0 stuff is goes here) (more advanced items go here) 2. XML allows developers to use namespaces for extensions and additions 3. XML tools are prevalent in many development packages and databases systems, easing development 4. XML is understood at some level by many more developers 5. We can always "down-convert" an XML representation to iCalendar through XSLT 6. For events calendars and the like: the structure of XML would make it easier to create search tools for events There of course will be negatives - one of which is the addition of code to existing products that support iCalendar, to also support the new XML-based format. My instincts tell me that many of these products already support XML in some ways, so that much of the software infrastructure to support XML is already there (for example, MS Office supports XML for quite a few things now); but I am not a software vendor, so take that with a grain of salt unless vendor representatives on this list would care to comment. I posting this a discussion-generator. This being the holidays, I don't expect a lot of discussion right at the moment, but please, let's kick this one around for a bit. Tim Hare Interested Bystander, Non-Inc. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From Doug at Royer.com Mon Dec 20 19:12:00 2004 From: Doug at Royer.com (Doug Royer) Date: Mon Dec 20 19:13:02 2004 Subject: [Ietf-calsify] another thought for simplification / levels In-Reply-To: <122120040208.22434.41C785A7000650BD000057A222007621940A9D0EB80307AB@comcast.net> References: <122120040208.22434.41C785A7000650BD000057A222007621940A9D0EB80307AB@comcast.net> Message-ID: <41C79480.5000804@Royer.com> TimHare@comcast.net wrote: >There are several advantages to this idea in my opinion: > > 1. We could use XML to group things from different levels together (this is just an example) > > > > (whatever we decide level 0 stuff is goes here) > > > (more advanced items go here) > > > > > If (an example) if RRULE were in an extended set, what would be the advantage of wrapping it with another tag? Other than making it visually separate, what would be the advantage? In 2445 when you do not know a component, property, or parameter name, you are suppose to ignore it anyway. And it is more complicated than that. Some properties may be in one RFC an not another or some extended properties may exist in newer RFC's causing yet more extensions. The extensions method must be a non-linier solution that can include or exclude future RFCs. Just adding the wrapper will cause only a delay and not a solution to the problem. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041220/3d8aab70/smime.bin From Doug at Royer.com Mon Dec 20 19:18:32 2004 From: Doug at Royer.com (Doug Royer) Date: Mon Dec 20 19:18:44 2004 Subject: [Ietf-calsify] another thought for simplification / levels In-Reply-To: <1198328AFDBF5841B27E40C40C33153701D6C0BA@df-chewy-msg.exchange.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C33153701D6C0BA@df-chewy-msg.exchange.corp.microsoft.com> Message-ID: <41C79608.6010209@Royer.com> Cameron Stillion wrote: >Back to the current state of affairs, I believe the calsify endeavor is >to add nothing to the existing standard, but only to simplify it to the >point of standard-application-usability and interoperability. I suggest >that a new and separate endeavor should pursue the xml-ified variation. > >That's my take... > > Yes, I completely agree, we have to solve the problem of what is in the basic and extended objects regardless of XML or iCal format. And as I have been told many times by the IESG, they will not allow an XML-iCal that is not compatible with 2445 formats. We can not throw away existing implementations, we have to first clarify existing standards. Then we can extend iCal. And iCal or XML format will not matter until that is solved. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041220/1656dc40/smime-0001.bin From TimHare at comcast.net Tue Dec 21 14:41:42 2004 From: TimHare at comcast.net (TimHare@comcast.net) Date: Tue Dec 21 15:36:06 2004 Subject: [Ietf-calsify] another thought for simplification / levels In-Reply-To: <41C79480.5000804@Royer.com> References: <122120040208.22434.41C785A7000650BD000057A222007621940A9D0EB80307AB@comcast.net> <41C79480.5000804@Royer.com> Message-ID: <6.1.1.1.0.20041221173633.027f0cb0@mail.comcast.net> Just to clear something up - my XML was just an example, not the definitive way to do it; obviously it would take a lot of thought to get the XML right. And in answer to other posts - I think I agree that XML-calendar is another project, different from calendar simplification; however if simplification doesn't happen in a relatively short time frame, those who are working on calendaring in other venues (RDF Calendar being just one example) may produce something that works, in XML, before simplification and interoperability are complete for our set of RFCs. And in my not-so-humble opinion of the industry as a whole, working stuff trumps IETF standards - even if the working protocols later get written up as standards. I haven't seen a lot of work on the simplification/interoperability front lately on this list (it may be happening elsewhere, though). At 10:12 PM 12/20/04, Doug Royer wrote: >TimHare@comcast.net wrote: > >>There are several advantages to this idea in my opinion: >> >> 1. We could use XML to group things from different levels >> together (this is just an example) >> >> >> >> (whatever we decide level 0 stuff is goes here) >> >> >> (more advanced items go here) >> >> >> >> > >If (an example) if RRULE were in an extended set, what would be the advantage >of wrapping it with another tag? Other than making it visually separate, >what would >be the advantage? > >In 2445 when you do not know a component, property, or parameter name, you >are suppose to ignore it anyway. > >And it is more complicated than that. Some properties may be in one RFC >an not another or some extended properties may exist in newer RFC's causing >yet more extensions. > >The extensions method must be a non-linier solution that can include >or exclude future RFCs. Just adding the wrapper >will cause only a delay and not a solution to the problem. > >-- > >Doug Royer | http://INET-Consulting.com >-------------------------------|----------------------------- >Doug@Royer.com | Office: (208)612-4638 >http://Royer.com | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > > > > > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. From Doug at Royer.com Sun Dec 26 20:06:38 2004 From: Doug at Royer.com (Doug Royer) Date: Sun Dec 26 20:06:53 2004 Subject: [Ietf-calsify] 2445 next - and is contents Message-ID: <41CF8A4E.5030601@Royer.com> I think we need to move the scheduling information in 2445 into 2446-next. And I do not think that anyone uses the REPEAT property in a VALARM. (1) In addition to moving recurrence rule into a separate draft, I think that scheduling objects in 2445 need to be moved from 2445 into 2446-next. For example, SENT-BY DELEGATED-TO DELEGATED-FROM RSVP I do not think these have much of a meaning without scheduling. So I propose they get moved to 2446-next and are not included in 2445-next. (2) Do we need the ability for an individual VALARM to repeat itself? I do not think so. I think we can deprecate the REPEAT property. Just casually looking, I do not see any implementation that allows the user to specify that an individual VALARM is repeated. Same with the DURATION property in a VALARM. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041226/09fd10a3/smime.bin From kainhofer at finanz.math.tu-graz.ac.at Mon Dec 27 13:27:45 2004 From: kainhofer at finanz.math.tu-graz.ac.at (Reinhold Kainhofer) Date: Mon Dec 27 15:05:57 2004 Subject: [Ietf-calsify] 2445 next - and is contents In-Reply-To: <41CF8A4E.5030601@Royer.com> References: <41CF8A4E.5030601@Royer.com> Message-ID: <200412272227.51417.reinhold@kainhofer.com> Am Montag, 27. Dezember 2004 05:06 schrieb Doug Royer: > (2) Do we need the ability for an individual VALARM to repeat itself? > I do not think so. I think we can deprecate the REPEAT property. > > Just casually looking, I do not see any implementation > that allows the user to specify that an individual > VALARM is repeated. Evolution has repeating alarms. And for KOrganizer I seriously consider adding it (but it won't go into KDE 3.4, but maybe into KDE 4.0). 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 / KPilot maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041227/73edef23/attachment.bin From pregen at egenconsulting.com Wed Dec 29 07:50:59 2004 From: pregen at egenconsulting.com (pregen@egenconsulting.com) Date: Wed Dec 29 07:51:09 2004 Subject: [Ietf-calsify] another thought for simplification / levels In-Reply-To: <6.1.1.1.0.20041221173633.027f0cb0@mail.comcast.net> Message-ID: Hi Tim. Sorry for the delay in posting to the list. I'm weeding through my emails - message here is don't go away for the holidays - it kills you later - 8-( I agree with you that other projects are in the works and probably already have come up with implementations that don't follow the standards. Indeed, working code will always override standards, unfortunately (or fortunately - depending on your point of view.) I am still, as I have always been, an end user (not a calendar developer) who has been waiting, since 1989, for good calendar interoperability and a way to search peoples schedules - anywhere. And when I talk to other users/companies, that's all they want as well (for now). I am working with a client right now who is a large organization and who runs three - count them three - different calendaring systems. This is because of recent mergers. It's not what they want but moving large amounts of people to one calendar is not feasible, economically, in the near future. So, they are back to using the phone to set up meetings among the three groups. To them, they have gone backwards in time. Yes, with the extended reach of the internet, we can start looking at exciting ways to do calendar searches, etc. However, right now, several organizations would simply be happy with "my calendar product talks to your calendar product." Easily. Without magic mirrors and addon products. Whatever we do to get there - standards or not - will work in our books. TimHare@comcast.net Sent by: ietf-calsify-bounces@osafoundation.org 12/21/2004 05:41 PM To ietf-calsify@osafoundation.org cc Doug@royer.com Subject Re: [Ietf-calsify] another thought for simplification / levels Just to clear something up - my XML was just an example, not the definitive way to do it; obviously it would take a lot of thought to get the XML right. And in answer to other posts - I think I agree that XML-calendar is another project, different from calendar simplification; however if simplification doesn't happen in a relatively short time frame, those who are working on calendaring in other venues (RDF Calendar being just one example) may produce something that works, in XML, before simplification and interoperability are complete for our set of RFCs. And in my not-so-humble opinion of the industry as a whole, working stuff trumps IETF standards - even if the working protocols later get written up as standards. I haven't seen a lot of work on the simplification/interoperability front lately on this list (it may be happening elsewhere, though). At 10:12 PM 12/20/04, Doug Royer wrote: >TimHare@comcast.net wrote: > >>There are several advantages to this idea in my opinion: >> >> 1. We could use XML to group things from different levels >> together (this is just an example) >> >> >> >> (whatever we decide level 0 stuff is goes here) >> >> >> (more advanced items go here) >> >> >> >> > >If (an example) if RRULE were in an extended set, what would be the advantage >of wrapping it with another tag? Other than making it visually separate, >what would >be the advantage? > >In 2445 when you do not know a component, property, or parameter name, you >are suppose to ignore it anyway. > >And it is more complicated than that. Some properties may be in one RFC >an not another or some extended properties may exist in newer RFC's causing >yet more extensions. > >The extensions method must be a non-linier solution that can include >or exclude future RFCs. Just adding the wrapper >will cause only a delay and not a solution to the problem. > >-- > >Doug Royer | http://INET-Consulting.com >-------------------------------|----------------------------- >Doug@Royer.com | Office: (208)612-4638 >http://Royer.com | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > > > > > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From Doug at Royer.com Wed Dec 29 18:25:38 2004 From: Doug at Royer.com (Doug Royer) Date: Wed Dec 29 18:26:14 2004 Subject: [Ietf-calsify] iCal-Basic - draft 00 Message-ID: <41D36722.6040505@Royer.com> I have taken the discussion on the CALSIFY mailing list and edited RFC-2445 into a proposal for iCal-Basic. Recurrence rules are not in iCal-Basic. iCal-Basic allows for extension that include specific sub-sets of future extensions (like recurrence rules that are likely to be added). An off mailing list discussion requested that RDATE be added to iCal-Basic as it would be very simple to implement. I have submitted draft-royer-ical-basic-00.txt and would appreciate any feedback. Thanks! -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041229/fb1fe744/smime.bin From Doug at Royer.com Thu Dec 30 11:14:35 2004 From: Doug at Royer.com (Doug Royer) Date: Thu Dec 30 11:15:01 2004 Subject: [Ietf-calsify] The guts of recurrence rules as implemented Message-ID: <41D4539B.10802@Royer.com> (A) Looking at the data used by vendors, there seems to be 4 ways vendors deal with recurring rules: (A.1) Only keep the original object and expand the instances dynamically. (A.2) Only keep the expanded instances and toss the original. Makes infinitely expanding object break. (A.3) Keep both the original and expanded instances. And they dynamically expand and cache the expanded instances as needed. (A.4) Ignore any recurrence rules. Makes much break. (B) And there are 2 ways vendors do DTSTART and RECURRENCE-ID on expanded instances. (B.1) In the expanded instance, they keep DTSTART the same as in the original object (iTIP 4.5.7.2 & 4.5.7.2). Set the RECURRENCE-ID value equal to the effective start time of the instance. (B.2) Set the DTSTART value and the RECURRENCE-ID value equal to each other all of the time. For those that do (A.2) they later notice they are unable to reschedule some types of requests under specific circumstances. (C) A solution to (A.*) is to suggest that both the expanded and unexpended objects be sent by default. And we pick some limit for infinite or large expanding rules. (I had suggested a way to represent that on this list earlier - IS-SUB-SET parameter) Now for what will be the debate. (B.*). (B.2) I see no advantage to always setting the DTSTART and RECURRENCE-ID value to be equal to the value of the other. The vendor data that I have seen that does this does not store the raw ICS files anyway (as their primary cal-store). So translating to/from the iTIP way does not seem like a burden. Doing the math to compute the start time is easy on any system including PDAs. That has been converted. If you do not remember, new to the list or can not find it, post a message for the details. (B.1) By doing (B.1) any single instance has all of the information needed to reschedule under any circumstances. Except: when the vendor stores in (A.2) format. In the past there has been a large debate on this. I went back and re-read the debate and in every case that I could find (after looking to see how the vendor really did it) was a mixture of (B.1) and (A.2) where things broke. So, I think that (C) solves the problem. Everyone gets what they want PLUS they have to do the simple math if they store their data in (A.2) format. If we do (C) and (B.2) then people that do not do (A.2) can not correctly store their data and other specific combinations of things break later in scheduling. In a simple example. A 3 day recurring VEVENT would send a total of 3 VEVENTs when exchanging calendar information (by default). In all three objects the DTSTART value would be the DTSTART value of the first instance (B.1 method). The RECURRENCE-ID value would be the effective start date of the specific instance. And all recurrence rules would be included in all objects. More bandwidth - but as far as I can tell 100% interoperate with anyone that even comes close to complying with 2445 and 2446. Right now (B.2) implementations already have to do the math, they just do it when sending objects. And (B.1) implementations already do the math when getting objects. By adding some unique property (Like the EXTENSIONS one I propose) then everyone can tell that the sender is conforming to the 'new' standard. The other solution is for the 3 day VEVENT to send 4 objects. The original, then include 3 more VEVENTs in (B.2) format. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041230/48f9af0e/smime.bin From chao at osafoundation.org Thu Dec 30 16:28:26 2004 From: chao at osafoundation.org (Chih-Chao Lam) Date: Thu Dec 30 16:28:36 2004 Subject: [Ietf-calsify] iMip design questions Message-ID: At OSAF (www.osafoundation.org), we're developing Chandler, a PIM client including email, calendaring and task management applications. We are at an early stage of evaluating how we should support iMip and had a few design/workflow questions. Lisa Dusseault suggested that this forum would be highly useful. I only have a cursory understanding of the iCalendar, iTip and iMip RFCs, so apologies if I am not getting something obvious. Here're our main queries: We would like event invitations that can be modified by any attendee and rebroadcasted (via email) to all attendees and the organizer of the event. * Is this possible under iMip? * Or is the Organizer the only person that can modify and update the event? * Are there workarounds to make this possible and yet allow interoperability with existing clients? * What does iMIP have to say about forwarded invitations? * How is forwarded an iMIP invitation different from adding attendees to the same invitation? * Can an attendee have two different email addresses? and thus reply from a different email address from the one specified by the organizer? * MUST support for iMip mean we have to support S/MIME? (as my reading of the spec indicates?) * Does iMIP support VJOURNAL in addition to VEVENT and VTASK? Answers to the above questions are highly appreciated, especially from the following 2 context: 1. What does the theoretical RFCs have to say? 2. What are the pragmatic interoperability issues with today's existing clients? Thanks, chao From Doug at Royer.com Thu Dec 30 17:59:28 2004 From: Doug at Royer.com (Doug Royer) Date: Thu Dec 30 17:59:42 2004 Subject: [Ietf-calsify] iMip design questions In-Reply-To: References: Message-ID: <41D4B280.2030604@Royer.com> Chih-Chao Lam wrote: > At OSAF (www.osafoundation.org), we're developing Chandler, a PIM client > including email, calendaring and task management applications. We are at > an early stage of evaluating how we should support iMip and had a few > design/workflow questions. Lisa Dusseault suggested that this forum > would be highly useful. I only have a cursory understanding of the > iCalendar, iTip and iMip RFCs, so apologies if I am not getting > something obvious. Here're our main queries: > > We would like event invitations that can be modified by any attendee and > rebroadcasted (via email) to all attendees and the organizer of the event. > * Is this possible under iMip? Using iTIP (RFC-2446), the attendee reply back to the organizer, then the organizer can rebroadcast > * Or is the Organizer the only person that can modify and update the > event? The Organizer is a role that is often one person. The RFC-2446 Organizer role is the only person that has the authority to update the authoritative event. If not then calendars and scheduling would be hackers heaven for CAL-SPAM as they added spam like attendees. > * Are there workarounds to make this possible and yet allow > interoperability with existing clients? Many are working on interoperability. That is what the CALSIFY mailing list is about. > > * What does iMIP have to say about forwarded invitations? That is covered in iTIP (RFC-2445), they are allowed. The organizer may elect to reject them. > * How is forwarded an iMIP invitation different from adding > attendees to the same invitation? Only the organizer can add attendees. Others may send a REPLY message to the organizer as if they had been invited. The organizer may accept or reject those replies. > > * Can an attendee have two different email addresses? and thus reply > from a different email address from the one specified by the organizer? The data in the ATTENDEE property specifies the email address the the organizer will use to send email to the attendee. So if they want updates, the organizer will have to be using the same email address. A person could have two or more entries, that might be a pain for the attendee that had to accept and reject all of them. > * MUST support for iMip mean we have to support S/MIME? (as my > reading of the spec indicates?) It says yes. Almost no one does S/MIME. > > * Does iMIP support VJOURNAL in addition to VEVENT and VTASK? Yes to VJOURNAL and VEVENT and yes to VTODO (not VTASK). > > Answers to the above questions are highly appreciated, especially from > the following 2 context: > 1. What does the theoretical RFCs have to say? > 2. What are the pragmatic interoperability issues with today's > existing clients? The problems are mostly with scheduling (iTIP / RFC-2446). Some implementations did not comply with the specifications. Some did not comply with iCalendar (RFC-2445). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041230/0425560b/smime.bin X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBV1xXaa014135 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 30 Dec 2004 17:59:35 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id iBV1xSeW028409 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 30 Dec 2004 17:59:30 -0800 Message-ID: <41D4B280.2030604@Royer.com> Date: Thu, 30 Dec 2004 18:59:28 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chih-Chao Lam Subject: Re: [Ietf-calsify] iMip design questions References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030807060004050506090204" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: OSAF Development , ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 01:59:40 -0000 This is a cryptographically signed message in MIME format. --------------ms030807060004050506090204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chih-Chao Lam wrote: > At OSAF (www.osafoundation.org), we're developing Chandler, a PIM client > including email, calendaring and task management applications. We are at > an early stage of evaluating how we should support iMip and had a few > design/workflow questions. Lisa Dusseault suggested that this forum > would be highly useful. I only have a cursory understanding of the > iCalendar, iTip and iMip RFCs, so apologies if I am not getting > something obvious. Here're our main queries: > > We would like event invitations that can be modified by any attendee and > rebroadcasted (via email) to all attendees and the organizer of the event. > * Is this possible under iMip? Using iTIP (RFC-2446), the attendee reply back to the organizer, then the organizer can rebroadcast > * Or is the Organizer the only person that can modify and update the > event? The Organizer is a role that is often one person. The RFC-2446 Organizer role is the only person that has the authority to update the authoritative event. If not then calendars and scheduling would be hackers heaven for CAL-SPAM as they added spam like attendees. > * Are there workarounds to make this possible and yet allow > interoperability with existing clients? Many are working on interoperability. That is what the CALSIFY mailing list is about. > > * What does iMIP have to say about forwarded invitations? That is covered in iTIP (RFC-2445), they are allowed. The organizer may elect to reject them. > * How is forwarded an iMIP invitation different from adding > attendees to the same invitation? Only the organizer can add attendees. Others may send a REPLY message to the organizer as if they had been invited. The organizer may accept or reject those replies. > > * Can an attendee have two different email addresses? and thus reply > from a different email address from the one specified by the organizer? The data in the ATTENDEE property specifies the email address the the organizer will use to send email to the attendee. So if they want updates, the organizer will have to be using the same email address. A person could have two or more entries, that might be a pain for the attendee that had to accept and reject all of them. > * MUST support for iMip mean we have to support S/MIME? (as my > reading of the spec indicates?) It says yes. Almost no one does S/MIME. > > * Does iMIP support VJOURNAL in addition to VEVENT and VTASK? Yes to VJOURNAL and VEVENT and yes to VTODO (not VTASK). > > Answers to the above questions are highly appreciated, especially from > the following 2 context: > 1. What does the theoretical RFCs have to say? > 2. What are the pragmatic interoperability issues with today's > existing clients? The problems are mostly with scheduling (iTIP / RFC-2446). Some implementations did not comply with the specifications. Some did not comply with iCalendar (RFC-2445). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030807060004050506090204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMjMxMDE1OTI4WjAjBgkqhkiG9w0BCQQxFgQUzp4b1Xtu0WKj+ybSt/r1 QFJmB1cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAXCbt3l7H7QSQhlcuxBsrsSbhoJMzf52sZNBQQHxHgtlbw0iyusyTg1IHVlyN1DxF UKisDU6JYBchBFVxheVAExcrwvGBtizPiCN7/Cx6tBwdeX+M0iISZc9lEUCfCMqh8eWSsXPT UBzDiXAf1qaIIqixncZ8BlnffzjGDuBzJCM47xkOrJDZ2bGDcVCfTMmBcaXj+0RiyQyRO3he y36Hu3GSnpysZzeYExl5LdoZ6wIYQYdKdT3SngY0pO0VKrgQJMG6G+h3nWRAW4Tmzt7UuVKD BjlE70ujnT8GmfWo9pW64kDR5GPedVV1uvQV4WPSTHgJxEEpoixPzbSXDMeLpQAAAAAAAA== --------------ms030807060004050506090204-- X-Envelope-From: chao@osafoundation.org Received: from [192.168.101.210] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBV0SVaa008684 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Dec 2004 16:28:32 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: OSAF Development , ietf-calsify@osafoundation.org From: Chih-Chao Lam Date: Thu, 30 Dec 2004 16:28:26 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-calsify] iMip design questions X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 00:28:34 -0000 At OSAF (www.osafoundation.org), we're developing Chandler, a PIM client including email, calendaring and task management applications. We are at an early stage of evaluating how we should support iMip and had a few design/workflow questions. Lisa Dusseault suggested that this forum would be highly useful. I only have a cursory understanding of the iCalendar, iTip and iMip RFCs, so apologies if I am not getting something obvious. Here're our main queries: We would like event invitations that can be modified by any attendee and rebroadcasted (via email) to all attendees and the organizer of the event. * Is this possible under iMip? * Or is the Organizer the only person that can modify and update the event? * Are there workarounds to make this possible and yet allow interoperability with existing clients? * What does iMIP have to say about forwarded invitations? * How is forwarded an iMIP invitation different from adding attendees to the same invitation? * Can an attendee have two different email addresses? and thus reply from a different email address from the one specified by the organizer? * MUST support for iMip mean we have to support S/MIME? (as my reading of the spec indicates?) * Does iMIP support VJOURNAL in addition to VEVENT and VTASK? Answers to the above questions are highly appreciated, especially from the following 2 context: 1. What does the theoretical RFCs have to say? 2. What are the pragmatic interoperability issues with today's existing clients? Thanks, chao X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBUJEeaa022247 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 30 Dec 2004 11:14:43 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id iBUJEZeW023253 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 30 Dec 2004 11:14:36 -0800 Message-ID: <41D4539B.10802@Royer.com> Date: Thu, 30 Dec 2004 12:14:35 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080100010609060505040100" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] The guts of recurrence rules as implemented X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 19:14:56 -0000 This is a cryptographically signed message in MIME format. --------------ms080100010609060505040100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (A) Looking at the data used by vendors, there seems to be 4 ways vendors deal with recurring rules: (A.1) Only keep the original object and expand the instances dynamically. (A.2) Only keep the expanded instances and toss the original. Makes infinitely expanding object break. (A.3) Keep both the original and expanded instances. And they dynamically expand and cache the expanded instances as needed. (A.4) Ignore any recurrence rules. Makes much break. (B) And there are 2 ways vendors do DTSTART and RECURRENCE-ID on expanded instances. (B.1) In the expanded instance, they keep DTSTART the same as in the original object (iTIP 4.5.7.2 & 4.5.7.2). Set the RECURRENCE-ID value equal to the effective start time of the instance. (B.2) Set the DTSTART value and the RECURRENCE-ID value equal to each other all of the time. For those that do (A.2) they later notice they are unable to reschedule some types of requests under specific circumstances. (C) A solution to (A.*) is to suggest that both the expanded and unexpended objects be sent by default. And we pick some limit for infinite or large expanding rules. (I had suggested a way to represent that on this list earlier - IS-SUB-SET parameter) Now for what will be the debate. (B.*). (B.2) I see no advantage to always setting the DTSTART and RECURRENCE-ID value to be equal to the value of the other. The vendor data that I have seen that does this does not store the raw ICS files anyway (as their primary cal-store). So translating to/from the iTIP way does not seem like a burden. Doing the math to compute the start time is easy on any system including PDAs. That has been converted. If you do not remember, new to the list or can not find it, post a message for the details. (B.1) By doing (B.1) any single instance has all of the information needed to reschedule under any circumstances. Except: when the vendor stores in (A.2) format. In the past there has been a large debate on this. I went back and re-read the debate and in every case that I could find (after looking to see how the vendor really did it) was a mixture of (B.1) and (A.2) where things broke. So, I think that (C) solves the problem. Everyone gets what they want PLUS they have to do the simple math if they store their data in (A.2) format. If we do (C) and (B.2) then people that do not do (A.2) can not correctly store their data and other specific combinations of things break later in scheduling. In a simple example. A 3 day recurring VEVENT would send a total of 3 VEVENTs when exchanging calendar information (by default). In all three objects the DTSTART value would be the DTSTART value of the first instance (B.1 method). The RECURRENCE-ID value would be the effective start date of the specific instance. And all recurrence rules would be included in all objects. More bandwidth - but as far as I can tell 100% interoperate with anyone that even comes close to complying with 2445 and 2446. Right now (B.2) implementations already have to do the math, they just do it when sending objects. And (B.1) implementations already do the math when getting objects. By adding some unique property (Like the EXTENSIONS one I propose) then everyone can tell that the sender is conforming to the 'new' standard. The other solution is for the 3 day VEVENT to send 4 objects. The original, then include 3 more VEVENTs in (B.2) format. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080100010609060505040100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMjMwMTkxNDM1WjAjBgkqhkiG9w0BCQQxFgQUGJHoVZ2LYe7LJTCliRIx +1oZ41QwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEApYz/V/O2MpQreLjP3iXXDDFq5oaE3VmBITUgV7UsfexLC7k78ksiL4auAKX1EXtA r5e1GJqvp6hm/s/rtwWosmrAyXvSrIJw91oVTvxwYtjLSx8aYJOPaW62VAePYWSniqdPCwsz Y6DKmepx5mv15kqz0HcHQWSIKJYU4zOvOYNwmxqcfZ4OTSzcFTmeHSpPieFcMwgYUPtMZMcu 5RId6PdIeDTcQE9BzlWj6H0byYv5NM3qV+UhUUR+sXGbu7gn35JFDkvjqMcY3E77NB1/uCdQ QB1RU79BTEng7lUgky+BNgbbC6cElofhlgxjeaLMFyzrjVj9SM1pmszzd5o61QAAAAAAAA== --------------ms080100010609060505040100-- X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBU2Pvaa030450 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 29 Dec 2004 18:25:59 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id iBU2PdeW010423 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 29 Dec 2004 18:25:40 -0800 Message-ID: <41D36722.6040505@Royer.com> Date: Wed, 29 Dec 2004 19:25:38 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , ietf-calsify@osafoundation.org, CalDAV DevList Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070605020908040607000407" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-calsify] iCal-Basic - draft 00 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 02:26:12 -0000 This is a cryptographically signed message in MIME format. --------------ms070605020908040607000407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have taken the discussion on the CALSIFY mailing list and edited RFC-2445 into a proposal for iCal-Basic. Recurrence rules are not in iCal-Basic. iCal-Basic allows for extension that include specific sub-sets of future extensions (like recurrence rules that are likely to be added). An off mailing list discussion requested that RDATE be added to iCal-Basic as it would be very simple to implement. I have submitted draft-royer-ical-basic-00.txt and would appreciate any feedback. Thanks! -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070605020908040607000407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMjMwMDIyNTM4WjAjBgkqhkiG9w0BCQQxFgQU1bXWM0YYK78GwejC0hlR UJN7U44wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAdt61bNu+Ke6f6UeV0ICZl2VB4WpiHVZHSWu/gRbDdhvLV8mypRJkx8fN/YyTOwx7 QD3PSE8ft3wQ+ZYGM++JwZUq6Llx68wvj9RO7ctABN8ddj2ZyWagcqkfK7R2mI2fRnRJxOoa hE0SQEhd76149r0UaWJHdPv9ZNHv8HBJOBjAZc0VXPpTrP13W3/4LyD6Cg8KbBK8y01M1t8V 70yUEt+WhOknKn2O98FOmNkqOQ5xCQKdtpU0B+Ta8cG3BEYK1nsCOF3NPEZ5kUAqzPoqwX6w ZVU5xIhx8jeNABQivj7iOpfVILk9mlMSK74FyZxzPWfAA42LG/rGjTsXl/0dRAAAAAAAAA== --------------ms070605020908040607000407-- X-Envelope-From: pregen@egenconsulting.com Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBTFp3aZ028262; Wed, 29 Dec 2004 07:51:03 -0800 In-Reply-To: <6.1.1.1.0.20041221173633.027f0cb0@mail.comcast.net> To: TimHare@comcast.net Subject: Re: [Ietf-calsify] another thought for simplification / levels MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: pregen@egenconsulting.com Date: Wed, 29 Dec 2004 10:50:59 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 12/29/2004 10:51:03 AM, Serialize complete at 12/29/2004 10:51:03 AM Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org, ietf-calsify-bounces@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 15:51:07 -0000 Hi Tim. Sorry for the delay in posting to the list. I'm weeding through my emails - message here is don't go away for the holidays - it kills you later - 8-( I agree with you that other projects are in the works and probably already have come up with implementations that don't follow the standards. Indeed, working code will always override standards, unfortunately (or fortunately - depending on your point of view.) I am still, as I have always been, an end user (not a calendar developer) who has been waiting, since 1989, for good calendar interoperability and a way to search peoples schedules - anywhere. And when I talk to other users/companies, that's all they want as well (for now). I am working with a client right now who is a large organization and who runs three - count them three - different calendaring systems. This is because of recent mergers. It's not what they want but moving large amounts of people to one calendar is not feasible, economically, in the near future. So, they are back to using the phone to set up meetings among the three groups. To them, they have gone backwards in time. Yes, with the extended reach of the internet, we can start looking at exciting ways to do calendar searches, etc. However, right now, several organizations would simply be happy with "my calendar product talks to your calendar product." Easily. Without magic mirrors and addon products. Whatever we do to get there - standards or not - will work in our books. TimHare@comcast.net Sent by: ietf-calsify-bounces@osafoundation.org 12/21/2004 05:41 PM To ietf-calsify@osafoundation.org cc Doug@royer.com Subject Re: [Ietf-calsify] another thought for simplification / levels Just to clear something up - my XML was just an example, not the definitive way to do it; obviously it would take a lot of thought to get the XML right. And in answer to other posts - I think I agree that XML-calendar is another project, different from calendar simplification; however if simplification doesn't happen in a relatively short time frame, those who are working on calendaring in other venues (RDF Calendar being just one example) may produce something that works, in XML, before simplification and interoperability are complete for our set of RFCs. And in my not-so-humble opinion of the industry as a whole, working stuff trumps IETF standards - even if the working protocols later get written up as standards. I haven't seen a lot of work on the simplification/interoperability front lately on this list (it may be happening elsewhere, though). At 10:12 PM 12/20/04, Doug Royer wrote: >TimHare@comcast.net wrote: > >>There are several advantages to this idea in my opinion: >> >> 1. We could use XML to group things from different levels >> together (this is just an example) >> >> >> >> (whatever we decide level 0 stuff is goes here) >> >> >> (more advanced items go here) >> >> >> >> > >If (an example) if RRULE were in an extended set, what would be the advantage >of wrapping it with another tag? Other than making it visually separate, >what would >be the advantage? > >In 2445 when you do not know a component, property, or parameter name, you >are suppose to ignore it anyway. > >And it is more complicated than that. Some properties may be in one RFC >an not another or some extended properties may exist in newer RFC's causing >yet more extensions. > >The extensions method must be a non-linier solution that can include >or exclude future RFCs. Just adding the wrapper >will cause only a delay and not a solution to the problem. > >-- > >Doug Royer | http://INET-Consulting.com >-------------------------------|----------------------------- >Doug@Royer.com | Office: (208)612-4638 >http://Royer.com | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > > > > > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: kainhofer@finanz.math.tu-graz.ac.at X-Envelope-To: Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBRMTwaa020916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Dec 2004 14:30:01 -0800 Received: from localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id iBRMTucE016464 for ; Mon, 27 Dec 2004 23:29:57 +0100 Received: from reinhold by localhost with local (Exim 3.36 #1 (Debian)) id 1Cj2P9-0003ym-00 for ; Mon, 27 Dec 2004 22:27:51 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2445 next - and is contents Date: Mon, 27 Dec 2004 22:27:45 +0100 User-Agent: KMail/1.7.91 References: <41CF8A4E.5030601@Royer.com> In-Reply-To: <41CF8A4E.5030601@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2731628.29uNvRVZUi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412272227.51417.reinhold@kainhofer.com> X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Mon, 27 Dec 2004 15:05:55 -0800 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 22:30:05 -0000 --nextPart2731628.29uNvRVZUi Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 27. Dezember 2004 05:06 schrieb Doug Royer: > (2) Do we need the ability for an individual VALARM to repeat itself? > I do not think so. I think we can deprecate the REPEAT property. > > Just casually looking, I do not see any implementation > that allows the user to specify that an individual > VALARM is repeated. Evolution has repeating alarms. And for KOrganizer I seriously consider add= ing=20 it (but it won't go into KDE 3.4, but maybe into KDE 4.0). Reinhold =2D-=20 =2D----------------------------------------------------------------- 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 / KPilot maintain= er --nextPart2731628.29uNvRVZUi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB0H5WTqjEwhXvPN0RAt/iAKCwAwMvTVmz9D12xoQnW33aixa+vgCgsXPd rlCfOwkbe35/gzwLTBOpTuY= =DalF -----END PGP SIGNATURE----- --nextPart2731628.29uNvRVZUi-- X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBR46jaa025138 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Sun, 26 Dec 2004 20:06:46 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id iBR46deW021269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 26 Dec 2004 20:06:40 -0800 Message-ID: <41CF8A4E.5030601@Royer.com> Date: Sun, 26 Dec 2004 21:06:38 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010500010600020300010504" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] 2445 next - and is contents X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 04:06:49 -0000 This is a cryptographically signed message in MIME format. --------------ms010500010600020300010504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think we need to move the scheduling information in 2445 into 2446-next. And I do not think that anyone uses the REPEAT property in a VALARM. (1) In addition to moving recurrence rule into a separate draft, I think that scheduling objects in 2445 need to be moved from 2445 into 2446-next. For example, SENT-BY DELEGATED-TO DELEGATED-FROM RSVP I do not think these have much of a meaning without scheduling. So I propose they get moved to 2446-next and are not included in 2445-next. (2) Do we need the ability for an individual VALARM to repeat itself? I do not think so. I think we can deprecate the REPEAT property. Just casually looking, I do not see any implementation that allows the user to specify that an individual VALARM is repeated. Same with the DURATION property in a VALARM. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010500010600020300010504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMjI3MDQwNjM4WjAjBgkqhkiG9w0BCQQxFgQUZR57YanYfsCFh5lmbQiH YUx9o70wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAcjNhaps42qE3ADipuOC3DNZEQ1WZFnCPwNg44pA1UXfORAlscGQZYeEN1nLC3koI wmtsqDnTBAnmaOzaPnKrZZbGGVsncPn8+YfbtxPRCUX9ZAAHY1h/ypVAmWi3e8TkivpueVim n7ctC/9GgDW5f0XgH8YNNTt4LNy7a8/mmykmt6OgZ/FhSHmH2mGtn2MDOzS+hhhXszJaCiB0 GeffIpxIFtZ0YifqZJOYS2cfEWoajspj6sGsEttYh7ShINYP7CAd+POalR79aU2a+9FSHMDg H4NDz8Mne+nrvaRAhDri305sahpEUtp3dEGV3PJe1Ok0SaxUm9zUsNOU1OQlUQAAAAAAAA== --------------ms010500010600020300010504-- X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBLNa2aZ017433 for ; Tue, 21 Dec 2004 15:36:02 -0800 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <20041221233556013001ab74e>; Tue, 21 Dec 2004 23:35:56 +0000 Message-Id: <6.1.1.1.0.20041221173633.027f0cb0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 21 Dec 2004 17:41:42 -0500 To: ietf-calsify@osafoundation.org From: TimHare@comcast.net Subject: Re: [Ietf-calsify] another thought for simplification / levels In-Reply-To: <41C79480.5000804@Royer.com> References: <122120040208.22434.41C785A7000650BD000057A222007621940A9D0EB80307AB@comcast.net> <41C79480.5000804@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.42 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Doug@Royer.com X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 23:36:05 -0000 Just to clear something up - my XML was just an example, not the definitive way to do it; obviously it would take a lot of thought to get the XML right. And in answer to other posts - I think I agree that XML-calendar is another project, different from calendar simplification; however if simplification doesn't happen in a relatively short time frame, those who are working on calendaring in other venues (RDF Calendar being just one example) may produce something that works, in XML, before simplification and interoperability are complete for our set of RFCs. And in my not-so-humble opinion of the industry as a whole, working stuff trumps IETF standards - even if the working protocols later get written up as standards. I haven't seen a lot of work on the simplification/interoperability front lately on this list (it may be happening elsewhere, though). At 10:12 PM 12/20/04, Doug Royer wrote: >TimHare@comcast.net wrote: > >>There are several advantages to this idea in my opinion: >> >> 1. We could use XML to group things from different levels >> together (this is just an example) >> >> >> >> (whatever we decide level 0 stuff is goes here) >> >> >> (more advanced items go here) >> >> >> >> > >If (an example) if RRULE were in an extended set, what would be the advantage >of wrapping it with another tag? Other than making it visually separate, >what would >be the advantage? > >In 2445 when you do not know a component, property, or parameter name, you >are suppose to ignore it anyway. > >And it is more complicated than that. Some properties may be in one RFC >an not another or some extended properties may exist in newer RFC's causing >yet more extensions. > >The extensions method must be a non-linier solution that can include >or exclude future RFCs. Just adding the wrapper >will cause only a delay and not a solution to the problem. > >-- > >Doug Royer | http://INET-Consulting.com >-------------------------------|----------------------------- >Doug@Royer.com | Office: (208)612-4638 >http://Royer.com | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > > > > > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBL3Idaa021163 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Mon, 20 Dec 2004 19:18:40 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id iBL3IXaa014866 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 20 Dec 2004 19:18:34 -0800 Message-ID: <41C79608.6010209@Royer.com> Date: Mon, 20 Dec 2004 20:18:32 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] another thought for simplification / levels References: <1198328AFDBF5841B27E40C40C33153701D6C0BA@df-chewy-msg.exchange.corp.microsoft.com> In-Reply-To: <1198328AFDBF5841B27E40C40C33153701D6C0BA@df-chewy-msg.exchange.corp.microsoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050005070204030408090408" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 03:18:43 -0000 This is a cryptographically signed message in MIME format. --------------ms050005070204030408090408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cameron Stillion wrote: >Back to the current state of affairs, I believe the calsify endeavor is >to add nothing to the existing standard, but only to simplify it to the >point of standard-application-usability and interoperability. I suggest >that a new and separate endeavor should pursue the xml-ified variation. > >That's my take... > > Yes, I completely agree, we have to solve the problem of what is in the basic and extended objects regardless of XML or iCal format. And as I have been told many times by the IESG, they will not allow an XML-iCal that is not compatible with 2445 formats. We can not throw away existing implementations, we have to first clarify existing standards. Then we can extend iCal. And iCal or XML format will not matter until that is solved. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050005070204030408090408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMjIxMDMxODMyWjAjBgkqhkiG9w0BCQQxFgQU/vj6rqflQnnnGmshm17t HlabP5wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEATQJCD7QE22Tv/CtitUvUwOqwD46MLe7uyKNNEIUNe7Yx67HYlTeJbOMqNrqVxoDn bMUaXUkg8FAhen6BnN+C4i+E4XmpYjs2Uwz1L05G5p1qWBw3aeZoCSGf1XbDsofGaIFez76f ANt1YWvZ9ruBxZoBXNVSXxsHFZ4hBDTvDVTKydcT3WHnfgcpNqY39/jwh8O+DKGRlmLcAWI9 J7IdLEoRTE4Y5RTzl7SQ0XTxQwm/WgYfM01mY05tVSx0nxxOBHFwJ4Vt6NWlPPl453ij7yK9 zLn+QIlnGoqzj/Dc5qNJzEa6kKKn1mq+fP4aoRe69Hi+VsUp/+rCrQ3RY5y4igAAAAAAAA== --------------ms050005070204030408090408-- X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBL3Csaa020283 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Mon, 20 Dec 2004 19:12:58 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id iBL3Ckaa014825 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 20 Dec 2004 19:12:50 -0800 Message-ID: <41C79480.5000804@Royer.com> Date: Mon, 20 Dec 2004 20:12:00 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] another thought for simplification / levels References: <122120040208.22434.41C785A7000650BD000057A222007621940A9D0EB80307AB@comcast.net> In-Reply-To: <122120040208.22434.41C785A7000650BD000057A222007621940A9D0EB80307AB@comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030704070802090701050706" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 03:13:01 -0000 This is a cryptographically signed message in MIME format. --------------ms030704070802090701050706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit TimHare@comcast.net wrote: >There are several advantages to this idea in my opinion: > > 1. We could use XML to group things from different levels together (this is just an example) > > > > (whatever we decide level 0 stuff is goes here) > > > (more advanced items go here) > > > > > If (an example) if RRULE were in an extended set, what would be the advantage of wrapping it with another tag? Other than making it visually separate, what would be the advantage? In 2445 when you do not know a component, property, or parameter name, you are suppose to ignore it anyway. And it is more complicated than that. Some properties may be in one RFC an not another or some extended properties may exist in newer RFC's causing yet more extensions. The extensions method must be a non-linier solution that can include or exclude future RFCs. Just adding the wrapper will cause only a delay and not a solution to the problem. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030704070802090701050706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMjIxMDMxMjAwWjAjBgkqhkiG9w0BCQQxFgQUzvh9mA3S/qZ9i2KWZ1Yx jEW0cOwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAwmpHEJbPuuadxdSAImAhL+dS7utfJ1wDHxthwhHCLYzrPdY+fIIPR+1d3rjJg3YR suN1/VQL4jCUsu3857fqMvAWNnjJT0V4a4zy7p9ccqlu2KXk79fFzsVBcKRrVeQ5JvzoOQSn TnxiUPf0VbthZQDY2a/uLRDNqrdkktlvMPuexxREh3yc6zbj91xKYVdhQCidfOO1eh6FF6Pt JWg2CgHTWz/TJaMI7We0XhDX0wkAL1b80qDSPAqMRY7eKXBYZzPwcjmUtSEYoflXgoyTOtJN 7e9F8nS+1s/q93nRTPnRzZQG44g68S3Jd1/rV+pG/Ac/FWH9Z3hy5U52ewLo9AAAAAAAAA== --------------ms030704070802090701050706-- X-Envelope-From: camerost@exchange.microsoft.com X-Envelope-To: Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBL2iPaZ018511 for ; Mon, 20 Dec 2004 18:44:25 -0800 Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 18:43:05 -0800 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Mon, 20 Dec 2004 18:43:05 -0800 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 18:43:05 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-calsify] another thought for simplification / levels Date: Mon, 20 Dec 2004 18:44:25 -0800 Message-ID: <1198328AFDBF5841B27E40C40C33153701D6C0BA@df-chewy-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-calsify] another thought for simplification / levels Thread-Index: AcTnAsK2De7drqy/QDKEvOMe6dLGdgAAbeYg From: "Cameron Stillion" To: , X-OriginalArrivalTime: 21 Dec 2004 02:43:05.0020 (UTC) FILETIME=[CBEACFC0:01C4E706] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id iBL2iPaZ018511 X-Mailman-Approved-At: Mon, 20 Dec 2004 18:47:53 -0800 Cc: Jonathan Boarman X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 02:44:30 -0000 XML does bring some advantages to the table that frankly, ought to be considered for any new standard - the first and most significant, I think, is that no new parsers need to be written. Or at least, the number of encoding and parsing errors that are likely to occur are significantly decreased. Internationalization is comparitively easy, and no low-level description of the format would need be discussed. One can focus on the schema instead. Your suggestion that there exists support for XML in existing applications is fair, but be wary about overcommitting libraries that you are not intimately familiar with. I suspect that there are several XML parsers within many large codebases, but I cannot say whether any of them are of sufficient or desirable to use in these circumstances. Obviously it behooves vendors to develop good low-level support for parsing XML, and it may very well be arguably good to push them in that direction anyway. Assuming they are there already might be bolder than you think. In general, I like your idea, but I think it is most meaningful for new standards, and I see your suggestion as a new standard: xCalendar perhaps. This might be very compelling especially for calendar publishing software that could also provide transforms for these types of data and thereby provide glowing chrome to navigate a .xcal on a web site, for example. icalshare.com or icalx.com might both decide to do some cool fancy things with that, especially if a vendor or two adopted it. My suspicion is that only some compelling new features would bring vendors to the state of wanting to. (e.g. support for mime-type-specified bodies ...., non-gregorian recurrences ... and the like) Back to the current state of affairs, I believe the calsify endeavor is to add nothing to the existing standard, but only to simplify it to the point of standard-application-usability and interoperability. I suggest that a new and separate endeavor should pursue the xml-ified variation. That's my take... ++cam; -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of TimHare@comcast.net Sent: Monday, December 20, 2004 6:09 PM To: ietf-calsify@osafoundation.org Cc: Jonathan Boarman Subject: [Ietf-calsify] another thought for simplification / levels This idea was inspired by someone who asked about my XML-with-calendar guideline draft; I'm posting it here because I think this may be the most appropriate place to begin this discussion. We've had some discussion about having various levels of iCalendar to allow simplification. This would of course require a mechanism that allowed one to know what levels were supported by sender and receiver. There are also quite a few people that are thinking about and working on events/scheduling information in XML - which makes sense because of the large number of XML tools available to developers and its growing use as an interchange mechanism. This has prompted me to think that perhaps the "simplified" version of iCalendar ought to be an XML version instead? There are several advantages to this idea in my opinion: 1. We could use XML to group things from different levels together (this is just an example) (whatever we decide level 0 stuff is goes here) (more advanced items go here) 2. XML allows developers to use namespaces for extensions and additions 3. XML tools are prevalent in many development packages and databases systems, easing development 4. XML is understood at some level by many more developers 5. We can always "down-convert" an XML representation to iCalendar through XSLT 6. For events calendars and the like: the structure of XML would make it easier to create search tools for events There of course will be negatives - one of which is the addition of code to existing products that support iCalendar, to also support the new XML-based format. My instincts tell me that many of these products already support XML in some ways, so that much of the software infrastructure to support XML is already there (for example, MS Office supports XML for quite a few things now); but I am not a software vendor, so take that with a grain of salt unless vendor representatives on this list would care to comment. I posting this a discussion-generator. This being the holidays, I don't expect a lot of discussion right at the moment, but please, let's kick this one around for a bit. Tim Hare Interested Bystander, Non-Inc. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBL2CXaZ015469 for ; Mon, 20 Dec 2004 18:12:36 -0800 Received: from 204.127.205.147 ([204.127.205.147]) by comcast.net (sccrmhc11) with SMTP id <2004122102084001100aufm7e>; Tue, 21 Dec 2004 02:12:28 +0000 Received: from [68.46.236.23] by 204.127.205.147; Tue, 21 Dec 2004 02:08:39 +0000 From: TimHare@comcast.net To: ietf-calsify@osafoundation.org Date: Tue, 21 Dec 2004 02:08:39 +0000 Message-Id: <122120040208.22434.41C785A7000650BD000057A222007621940A9D0EB80307AB@comcast.net> X-Mailer: AT&T Message Center Version 1 (Nov 22 2004) X-Authenticated-Sender: VGltSGFyZUBjb21jYXN0Lm5ldA== X-Spam-Score: 3.975 (***) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, NO_REAL_NAME, RCVD_BY_IP, RCVD_DOUBLE_IP_LOOSE, RCVD_NUMERIC_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Jonathan Boarman Subject: [Ietf-calsify] another thought for simplification / levels X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 02:12:42 -0000 This idea was inspired by someone who asked about my XML-with-calendar guideline draft; I'm posting it here because I think this may be the most appropriate place to begin this discussion. We've had some discussion about having various levels of iCalendar to allow simplification. This would of course require a mechanism that allowed one to know what levels were supported by sender and receiver. There are also quite a few people that are thinking about and working on events/scheduling information in XML - which makes sense because of the large number of XML tools available to developers and its growing use as an interchange mechanism. This has prompted me to think that perhaps the "simplified" version of iCalendar ought to be an XML version instead? There are several advantages to this idea in my opinion: 1. We could use XML to group things from different levels together (this is just an example) (whatever we decide level 0 stuff is goes here) (more advanced items go here) 2. XML allows developers to use namespaces for extensions and additions 3. XML tools are prevalent in many development packages and databases systems, easing development 4. XML is understood at some level by many more developers 5. We can always "down-convert" an XML representation to iCalendar through XSLT 6. For events calendars and the like: the structure of XML would make it easier to create search tools for events There of course will be negatives - one of which is the addition of code to existing products that support iCalendar, to also support the new XML-based format. My instincts tell me that many of these products already support XML in some ways, so that much of the software infrastructure to support XML is already there (for example, MS Office supports XML for quite a few things now); but I am not a software vendor, so take that with a grain of salt unless vendor representatives on this list would care to comment. I posting this a discussion-generator. This being the holidays, I don't expect a lot of discussion right at the moment, but please, let's kick this one around for a bit. Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB4EH6aZ015430 for ; Sat, 4 Dec 2004 06:17:06 -0800 Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041204141701.URGO5357.fed1rmmtao04.cox.net@davet23> for ; Sat, 4 Dec 2004 09:17:01 -0500 Message-ID: <200412040616260730.020E2CC2@smtp.west.cox.net> References: <200411181732510014.00FA5091@smtp.west.cox.net> <200412031704340937.022969F3@smtp.west.cox.net> <200412040611340300.0209B674@smtp.west.cox.net> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Sat, 04 Dec 2004 06:16:26 -0800 From: "David C. Thewlis" To: "ietf-calsify reflector" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Meeting Notice: CalConnect Roundtable II -- The Calendaring and Scheduling Consortium X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 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: Sat, 04 Dec 2004 14:17:07 -0000 Our apologies if you receive multiple copies of this announcement. We've had requests from non-members for notification of Consortium events so we are circulating this notice widely. MEETING NOTICE: CALCONNECT ROUNDTABLE II The second Calendaring and Scheduling Consortium Roundtable will be held Tuesday-Thursday, 11-13 January, 2005, hosted by the University of Washington on the UW Campus in Seattle, Washington. We expect to have space for 25-30 people so early notification of intent to participate will be important. This three-day event will include Consortium Technical Committee Meetings for all TCs which wish to meet in person, and a full Roundtable of all participants to consider TC reports, evaluate progress, and establish next steps and directions in working towards interoperable Calendaring and Scheduling. There will also be a co-located Interop Testing Event on Tuesday and Wednesday, which will run three different testing scenarios (please see the information for this Interop on the Consortium website). This event is open to Consortium members only. Participation in the co-located Interop is open to both members and non-members. Non-members interested in the Consortium may join the Consortium prior to the Roundtable or onsite (including non-members participating in the Interop event) and attend the Consortium activities. SCHEDULE The general schedule is: Interops (in parallel) - all day Tuesday, Wednesday morning TC meetings - all day Tuesday, Wednesday morning, and afternoon as needed Group Dinner - Wednesday evening Roundtable - may begin Wednesday mid-afternoon; Thursday until 3:00 REGISTRATION FEE There is a nominal registration fee for the Roundtable to cover meeting facilities, food and breaks, and the group dinner. If your organization is a Consortium member participating in the co-located Interop, and you are covered by the Interop Registration Fee, you need not pay a separate registration fee for the Roundtable. MORE INFORMATION AND REGISTRATION More information about this event, including logistics information, venues, fees, etc. is posted on the Consortium website. Please go to www.calconnect.org and select Membership Activities-->Next Roundtable. If you are interested in participating in the Interop, please see Interops-->Jan 2005. The event hotel is the Seattle Watertown: www.watertownseattle.com, The cutoff date for the group rate (group name "calconnect" is 20 December 2004. If you wish to attend the Roundtable, please contact me directly (contact information below) to register and to arrange payment of registration fees. Remember that space is limited by the size of the venue meeting room; early registration is advised. If you plan to attend the Interop, please use the registration form on the Consortium website; see Interops-->Register. If you will attend both the Interop and the Roundtable, please contact me directly to be sure you are included in planning for both events. Please contact me if you have any questions. Best Regards, Dave Thewlis, Executive Director The Calendaring and Scheduling Consortium 1550 Dena Drive McKinleyville CA 95519-4146 +1 707 840 9391 (voice) +1 415 946 3454 (fax) +1 707 498 2238 (mobile) Dave.Thewlis@calconnect.org www.calconnect.org X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from fed1rmmtao12.cox.net (fed1rmmtao12.cox.net [68.230.241.27]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB2FpJaZ006973 for ; Thu, 2 Dec 2004 07:51:19 -0800 Received: from davet23 ([24.254.88.112]) by fed1rmmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041202155114.WIMB3870.fed1rmmtao12.cox.net@davet23> for ; Thu, 2 Dec 2004 10:51:14 -0500 Message-ID: <200412020750400882.0830B41C@smtp.west.cox.net> References: <200411181732510014.00FA5091@smtp.west.cox.net> <200412020748000071.082E3FF1@smtp.west.cox.net> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Thu, 02 Dec 2004 07:50:40 -0800 From: "David C. Thewlis" To: "ietf-calsify reflector" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Call for Participantion -- Second Calconnect Interop - 11-12 January 2005 - Seattle, Washington X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 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: Thu, 02 Dec 2004 15:51:20 -0000 Please note that this announcement is being posted on multiple calendaring-related reflectors and to the Calconnect mailing lists to ensure as wide a distribution as possible. Our apologies if you receive multiple copies. CALL FOR PARTICIPATION -- SECOND INTEROP TESTING EVENT - 11-12 January 2005 The second Interop of The Calendaring and Scheduling Consortium (CALCONNECT.ORG) will take place Tuesday and Wednesday, January 11-12, 2005. It will be hosted by the University of Washington and the venue will be on the UW Campus in Seattle, Washington. This event will feature three separate Interop testing scenarios. Participating organizations are welcome to test against one, two, or all three scenarios. Please note however that these scenarios will be going on simultaneously so you will probably need a team for each scenario you participate in. Space will be limited so early notification and registration is advised. INTEROP SCENARIOS (a) Full scale interop: against iCal, iMIP, iTIP, essentially the same scenario as the one done in July 2004. The goal is to get results from testing by more implementations to augment the data from July -- at the July event Oracle and IBM tested; it would be very useful to have results from other vendors to augment the understanding of the RFCs gained from the July (and earlier) Interops. (b) Min-IOP Interop: The Min-IOP Technical Committee of the Consortium was formed to identify and define the "Minimum Interoperable Subset" for iCalendar as part of the work towards the Calsify effort in the IETF. This Interop scenario is for implementations to test against that subset. The goal is to help define baseline requirements for the CALSIFY effort and to determine what the real world common subset actually is, so the more implementations tested against this common subset the more realistic and useful the results will be. (c) CalDAV Interop: Oracle Corporation will provide a prototype CalDAV server for client testing, and work is progressing on the definition of the test cases for the scenario. Some vendors have expressed interest in being able to do a CalDAV Interop as soon as possible. This will provide early feedback to the server implementors, the CalDAV specification authors, and the client implementors. WHO MAY PARTICIPATE IN THE INTEROPS Any vendor or organization wishing to test a calendaring and scheduling implementation is welcome to attend whether or not they are a Consortium member. Note that Consortium members do receive a substantial discount on their Interop participation fee (see below). CONSORTIUM ROUNDTABLE II Technical committee meetings of the Calendaring and Scheduling Consortium are also planned for 11-12 January at the same location, followed by an all-hands Consortium Roundtable on Thursday 13 January. Interop participants who are not Consortium members will not be able to participate in the other Consortium activities as they are reserved to members. However, a non-member Interop Participant can join the Consortium at the event and become a member immediately and be able to participate in the technical committee and roundtable meetings. REGISTRATION FEE The registration fee for the Interop is $1500 for Consortium members and $2500 for non-members. The registration fee covers two individuals; additional individuals are $150 each for members or non-members. (If you are planning to participate in more than one Interop scenario you may need more than two people.) Members: Please note that the Interop Registration Fee for Members also covers the registration fee for participation in the Consortium events for the interop participants. HOW TO REGISTER AND FURTHER INFORMATION Detailed information including logistics will be posted on the Consortium website as as it becomes available; go to http://www.calconnect.org and select "Interops Future". You may also register online on the website by selecting "Interops Registration". For questions or more information, or to inform us of your plan to participate in the Interop, please contact me at the Consortium. Best Regards, Dave Thewlis Executive Director The Calendaring and Scheduling Consortium 1550 Dena Drive McKinleyville CA 95519-4146 +1 707 840 9391 (voice) +1 415 946 3454 (fax) +1 707 498 2238 (mobile) Dave.Thewlis@calconnect.org www.calconnect.org