From daboo at isamet.com Fri Mar 4 07:14:37 2005 From: daboo at isamet.com (Cyrus Daboo) Date: Fri Mar 4 07:14:44 2005 Subject: [Ietf-calsify] Jabber chat room for BOF Message-ID: <9433B7FD862E1A78C9D9F58A@ninevah.cyrusoft.com> FYI A Jabber IM chat room has been setup for the BOF next week. So those that will not be present can participate that way if they desire. The jabber address is: calsify@ietf.xmpp.org -- Cyrus Daboo From rlmorgan at washington.edu Thu Mar 10 08:20:02 2005 From: rlmorgan at washington.edu (RL 'Bob' Morgan) Date: Thu Mar 10 08:20:10 2005 Subject: [Ietf-calsify] calsify BoF today Message-ID: A reminder that we'll be having the calsify BoF at IETF 62 today at 1300 CST. The BoF agenda is at: http://ietf.org/ietf/05mar/calsify.txt The Jabber chat room is: calsify@ietf.xmpp.org See http://www.xmpp.org/ietf-chat.html for info on how that works. There's also audio streaming from all the IETF WG sessions this time, see http://videolab.uoregon.edu/events/ietf/ for info on that. We'll do our best to have the discussion happen via the microphone and the chat room. Intro presentation (thank you Cyrus) can be got from: http://staff.washington.edu/rlmorgan/misc/IETF-62-calsify-BOF-intro.sxi http://staff.washington.edu/rlmorgan/misc/IETF-62-calsify-BOF-intro.ppt in OO and Powerpoint respectively. If anyone else has a presentation please send it to me before the meeting if possible. - RL "Bob" From nsb at guppylake.com Thu Mar 10 09:26:09 2005 From: nsb at guppylake.com (Nathaniel Borenstein) Date: Thu Mar 10 09:49:36 2005 Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping the version In-Reply-To: <4210D4F3.9070405@cse.ucsc.edu> References: <0IBW001A4SLXT8@smtp6.wiscmail.wisc.edu> <4210D4F3.9070405@cse.ucsc.edu> Message-ID: <93eada66515822e8a1756faa4bf86083@guppylake.com> +1. Also, we can specify that in the case of a "true" infinite meeting, it is the responsibility of the initiating server to send out a "renewal" at the end of the one/five/hundred year period. On Feb 14, 2005, at 11:42 AM, Elias Sinderson wrote: > Curt Ellmann wrote: > >> I agree that one year is too short-- what is the problem with >> infinitely >> recurring events? There are plenty of examples of events that are >> infinitely recurring-- holidays, anniversaries, and other >> celebrations. >> > I only suggested one year as a matter of conjecture - the limit could > be five years, or ten, for that matter, as long as there is a limit > which allows a /finite/ expansion of recurring events. Note that this > was in response to Doug Royers observation that "the only noticable > issue is infinate recurring entries." I will also note that the > cannonical examples provided for infinitely recurring events have been > all-day events, which do not suffer from the timezone issues that have > been identified. As per Dougs' suggestion, the inclusion of a property > which indicates that a METHOD:REFRESH should be done in the future > seems like a good idea; simply a way to say 'and so on' or 'sync again > later'. I cannot think of a situation where a client would need to get > the infinity of recurrences in a single sync and not be able to sync > again in the future. Further, regarding the question of the duration > placed as an upper bound, allowing any given implementation to set > its' own upper bound on recurrences rather than having it rigidly > declared in the specification would make it possible for devices with > limited profiles to play along as well. > > It may be useful to step back from this issue for a minute and try to > identify use cases that require scheduling of recurring events (or any > event), e.g., five years out. Neither Hotels nor airlines will allow > one to place reservations that far in advance. The most difficult > restaraunt to dine at in California (French Laundry) only takes > reservations several months (4?) out. Business meetings are never > arranged in this matter, and it only seems a matter of convenience to > say that this meeting will recur infinitely rather than specify an end > date several years away. As I mentioned before, even so called > 'infinitely recurring' weekly project meetings are (semi)regularly > rescheduled to accomodate attendees constraints and other recurring > meetings that are scheduled. If anyone can provide a use case which > requires an infinitely recurring event which is not an all day affair > (such as holidays, birthdays, anniversaries, etc.), please provide it. > Extra credit will be given if it isn't some freaky and contrived edge > case, but occurs frequently enough that it would be an honest > inconvenience to a user to schedule seperate events. > > Deprecating infinitely recurring events and placing a sensible upper > bound as suggested would allow recurring events to be represented as > either a RRULE or as a finite sequence of events, and would sidestep > the issues related to timezones that have been raised previously on > the list. It would seem that the benefits of this simplification > greatly outweigh the downside of rescheduling a meeting every couple > years (if it lasts that long) or similar. Further, if RRULEs become an > optional part of the specification, as has been suggested before, this > approach would allow interoperability where one system implements > RRULEs and the other doesn't, as there won't be a problem in an > infinite expansion of events. > > > Cheers, > Elias > > >> -----Original Message----- >> From: ietf-calsify-bounces@osafoundation.org >> [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Michiel >> van >> Leeuwen >> Sent: Saturday, February 12, 2005 2:58 PM >> To: ietf-calsify@osafoundation.org >> Subject: [Ietf-calsify] Re: Comments on radical simplification and >> bumping >> the version >> >> Elias Sinderson wrote: >> >>> Would it be reasonable to deprecate infinitely recurring events and >>> place an upperbound of, say, one year on recurring entries? >> >> I think it isn't such a great idea, becasue one year is a magic >> number. Why one year, and not two years? >> > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > From nsb at guppylake.com Thu Mar 10 09:50:07 2005 From: nsb at guppylake.com (Nathaniel Borenstein) Date: Thu Mar 10 09:50:11 2005 Subject: [Ietf-calsify] radical simplification, too In-Reply-To: <42110701.80509@Royer.com> References: <42110701.80509@Royer.com> Message-ID: <00d482bc42b2cfb8dd1d1c0615c58d77@guppylake.com> +1. And given the inherent tendency of humans to get confused over time zones, a sophisticated implementation might actually use this to double-check, and raise a red flag when it believes that the two specifications are not, in fact, identical. -- Nathaniel On Feb 14, 2005, at 3:16 PM, Doug Royer wrote: > > Another idea is that we make a new parameter (say R-FYI) that *if* > set to true in an RRULE property means that the RDATE's should > be used and that RRULE is just FYI. So you could say in effect, > and the ORGANIZER wants to convey the fact that the meeting is > weekly, but look at the RDATE's for the real instance times. > > Now we can keep the organizers intent when implementations care, > and for those that do not care, here are the real instance > times in RDATEs. > > Preston Stephenson wrote: >> Just a few comments. >> It would be nice to have a list of iCal properties that were defined >> explicitly. >> Be it an iCal lite or an iCal best practices. >> If we could come to a consensus of what they were, >> I would be more willing to make the project I work on fit into that >> consensus. >> If we get into the more difficult ones such as rrule, >> I'm constrained by the architecture of our application. >> I'm limited to fanning out the recurrence rule to a reasonable number >> of occurrences in the future. >> It would nice to support infinite occurring rules, but I don't see it >> happening anytime soon. >> All I'm saying is if rrule was part of the iCal basic, I could only >> support it with certain restrictions. >> It would be nice to have a set of iCal properties that could be >> supported in all cases. >> Thanks. >> Preston >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > > We Do Standards - You Need Standards > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From nsb at guppylake.com Thu Mar 10 09:50:10 2005 From: nsb at guppylake.com (Nathaniel Borenstein) Date: Thu Mar 10 09:50:12 2005 Subject: [Ietf-calsify] Re: What's wrong with more radical simplification? In-Reply-To: <200502121039.31039.reinhold@kainhofer.com> References: <6.2.1.2.0.20050211201730.02d0a120@mail.comcast.net> <200502121039.31039.reinhold@kainhofer.com> Message-ID: <23ccd889c994a02c1297abffb9e3f57f@guppylake.com> Well, here it is two hours before the BOF and I'm finally catching up on the email, but I can't resist commenting on this: Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare: > ... I want calendaring to be just as simple as e-mail is now - On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote; > Hehe, you chose the wrong example here. Do you know how complex the > specification for email is (in particular the mime spec and all the various > encodings possible)? iCalendar is trivial compared to those specs... Actually, the reality is both more interesting than this *and* potentially a model for the current situation. In designing MIME, we were faced with an incredible complexity of potential uses and applications. As such, we largely retreated from specifying formats for *any* of them. Instead, we focused on basic syntactic and encoding requirements for a tremendously extensible format, defined a few core types that we thought were obviously necessary, and left the rest to be done as future extensions. By now, a paper copy of all the MIME extension specifications would probably come in multiple volumes (and would, of course, include all the iCal specs). I am rather glad that we didn't try to do all that work in a single specification! I see the ongoing work of data format specification as being, for all intents and purpose, fractal. Whatever we define today, people tomorrow will be trying to extend it in multiple, unforeseeable directions. The wisdom of the 80/20 rule is that it is a good heuristic for working with fractally complex problems: 1. Solve 80% of the problem facing you. 2. Look deeper at the remaining 20%. 3. Return to step 1. (It doesn't always work, you have to break out of it occasionally, but it's a good default strategy.) In the case of the ical standards, we have a historical failure to follow this model; the format tried to do so many things that it had trouble clarifying even some simple ones. Thus, our current dilemma. I don't doubt the need for some way to express recurrence. I do doubt that there is a simple or obvious solution, or even that there is a single solution; in the long run, we may need multiple languages for specifying RRULES, to support non-Western or non-Terran calendars, for example. But we're not qualified today to plan the details of working with the Ganymede Colony's calendaring system. Thus, when I pipe up about getting rid of recurrence entirely, what I'm really saying is that this is what we should have done in the first place, and only started worrying about specific recurrence types (as opposed to the general architectural notion of recurrence) once we had done a good job of the initial 80% of the problem (including the architectural place of recurrence and other "extension" mechanisms). Our current "cleanup" efforts should at least try to approximate the results of having done things in a more evolutionary manner. That's hard to do, because you almost want to "unlearn" some of the things you think you already know you need while focusing on the core. But I think it's our best hope for clarity and consensus. -- Nathaniel From camerost at exchange.microsoft.com Thu Mar 10 11:20:58 2005 From: camerost at exchange.microsoft.com (Cameron Stillion) Date: Thu Mar 10 11:21:15 2005 Subject: [Ietf-calsify] Re: What's wrong with more radical simplification? Message-ID: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> I wish I could be at the BOF today... If possible, I'd like to communicate to the participants one thing that I think warrants repeating. The calsify effort should be a practical one - and by that, I mean that it should be focused on doing something that will be meaningful to vendors whose iCal implementations will benefit from in the immediate future. While I applaud the philosophical design approaches espoused in many of the "more radical" approaches to iCal, I must assert that anything along the radical edge is going to count against us in the practical department. If we can rally around a *small* number of changes to the currently proposed standard, get it to become an actual standard, and call it done (Shrink wrap it! Ship it!) - then we have accomplished something no other iCal body has been able to do for many years. This standard should be very close to what exists today, especially in shipping code. Ideally, vendors would have a short list of discrepancies to fix in order to become standards compliant, and most interop issues would be eliminated, or at least mitigated. Once we've accomplished that, I believe that we are free to take more daring, radical, or revolutionary approaches toward the standard. But for now, I think we are held somewhat captive by our past on this one, unfortunately - if we took the wrong approach before, let's understand that. But first, let's make this thing a standard. If we don't do it soon, I fear that the ad-hoc standard will trump all of our discussions, and we will have no real say in what "_standard_ iCal support" actually means. Probably more than my .02 worth... Cameron -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Nathaniel Borenstein Sent: Thursday, March 10, 2005 9:50 AM To: Reinhold Kainhofer Cc: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification? Well, here it is two hours before the BOF and I'm finally catching up on the email, but I can't resist commenting on this: Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare: > ... I want calendaring to be just as simple as e-mail is now - On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote; > Hehe, you chose the wrong example here. Do you know how complex the > specification for email is (in particular the mime spec and all the various > encodings possible)? iCalendar is trivial compared to those specs... Actually, the reality is both more interesting than this *and* potentially a model for the current situation. In designing MIME, we were faced with an incredible complexity of potential uses and applications. As such, we largely retreated from specifying formats for *any* of them. Instead, we focused on basic syntactic and encoding requirements for a tremendously extensible format, defined a few core types that we thought were obviously necessary, and left the rest to be done as future extensions. By now, a paper copy of all the MIME extension specifications would probably come in multiple volumes (and would, of course, include all the iCal specs). I am rather glad that we didn't try to do all that work in a single specification! I see the ongoing work of data format specification as being, for all intents and purpose, fractal. Whatever we define today, people tomorrow will be trying to extend it in multiple, unforeseeable directions. The wisdom of the 80/20 rule is that it is a good heuristic for working with fractally complex problems: 1. Solve 80% of the problem facing you. 2. Look deeper at the remaining 20%. 3. Return to step 1. (It doesn't always work, you have to break out of it occasionally, but it's a good default strategy.) In the case of the ical standards, we have a historical failure to follow this model; the format tried to do so many things that it had trouble clarifying even some simple ones. Thus, our current dilemma. I don't doubt the need for some way to express recurrence. I do doubt that there is a simple or obvious solution, or even that there is a single solution; in the long run, we may need multiple languages for specifying RRULES, to support non-Western or non-Terran calendars, for example. But we're not qualified today to plan the details of working with the Ganymede Colony's calendaring system. Thus, when I pipe up about getting rid of recurrence entirely, what I'm really saying is that this is what we should have done in the first place, and only started worrying about specific recurrence types (as opposed to the general architectural notion of recurrence) once we had done a good job of the initial 80% of the problem (including the architectural place of recurrence and other "extension" mechanisms). Our current "cleanup" efforts should at least try to approximate the results of having done things in a more evolutionary manner. That's hard to do, because you almost want to "unlearn" some of the things you think you already know you need while focusing on the core. But I think it's our best hope for clarity and consensus. -- Nathaniel _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From TimHare at comcast.net Sat Mar 12 06:24:32 2005 From: TimHare at comcast.net (Tim Hare) Date: Sat Mar 12 06:24:49 2005 Subject: [Ietf-calsify] Simplification, recurrence, other issues In-Reply-To: <23ccd889c994a02c1297abffb9e3f57f@guppylake.com> References: <6.2.1.2.0.20050211201730.02d0a120@mail.comcast.net> <200502121039.31039.reinhold@kainhofer.com> <23ccd889c994a02c1297abffb9e3f57f@guppylake.com> Message-ID: <6.2.1.2.0.20050312090743.01cc3568@mail.comcast.net> Since I am a "quotee" I feel compelled to clarify my comment: I fully understand the underlying complexity of things (I work with z/OS for example, and I have in the past supported OfficeVision/MVS a very model of medium complexity). What I meant by my comment was: people just "walk up to e-mail and use it" now, they don't think about it so much (because so many developers thought about it and worked on things like MIME); calendar should be that way - people should use it intuitively. Nathaniel used the phrase "recurrence type" - and maybe that's an idea... we've been thinking of various levels of iCalendar, but maybe for recurrences we want the object to identify its own level? For examples: RRULE;RTYPE=Mars-Syntax: {Some syntax defined by those angry Martians who didn't like the basic one} RRULE;RTYPE=Ganymede-Syntax: {Some syntax defined by the Ganymedians (and/or their pals the Ganymeans and Ganymaximums but I digress)} absence of RTYPE implying RDATEs only It does NOT improve simplification, so should be in a higher-level iCalendar, but perhaps it does improve the recurrence rule problem? There would also need, in iTIP or follow-on, need to be a response meaning "I don't get this syntax". Maximum implementations could send the recurrence rules in several (perhaps the most popular in terms of sales) syntaxes at the same time since the receiver would pick only the syntax they'd like. And now for something completely different: Should we be careful to use iCalendar in our posts rather than iCal to avoid confusion with Apple's product? Not for copyright/trademark concerns but I'd like to be clear about what iCalendar the protocol/format does versus what iCal the product does with it. And last but not least: I've lost some e-mail due to a computer failure. There's one issue from Calsify that I would like someone to explain to me OFF the list, if they would: Why, in an iCalendar-Basic using only UTC times, would timezones matter on recurrence rules with participants in different timesones/daylight savings time areas? I seem to recall some discussion, and a valid reason, but I can't remember it and I'd like to. So, if anyone has a concise explanation, please send it to me... thanks. At 12:50 PM 3/10/2005, Nathaniel Borenstein wrote: >Well, here it is two hours before the BOF and I'm finally catching up on >the email, but I can't resist commenting on this: > >Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare: > > ... I want calendaring to be just as simple as e-mail is now - > >On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote; > > Hehe, you chose the wrong example here. Do you know how complex the > > specification for email is (in particular the mime spec and all the various > > encodings possible)? iCalendar is trivial compared to those specs... > >Actually, the reality is both more interesting than this *and* potentially >a model for the current situation. > >In designing MIME, we were faced with an incredible complexity of >potential uses and applications. As such, we largely retreated from >specifying formats for *any* of them. Instead, we focused on basic >syntactic and encoding requirements for a tremendously extensible format, >defined a few core types that we thought were obviously necessary, and >left the rest to be done as future extensions. By now, a paper copy of >all the MIME extension specifications would probably come in multiple >volumes (and would, of course, include all the iCal specs). I am rather >glad that we didn't try to do all that work in a single specification! > >I see the ongoing work of data format specification as being, for all >intents and purpose, fractal. Whatever we define today, people tomorrow >will be trying to extend it in multiple, unforeseeable directions. The >wisdom of the 80/20 rule is that it is a good heuristic for working with >fractally complex problems: 1. Solve 80% of the problem facing >you. 2. Look deeper at the remaining 20%. 3. >Return to step 1. (It doesn't always work, you have to break out of it >occasionally, but it's a good default strategy.) > >In the case of the ical standards, we have a historical failure to follow >this model; the format tried to do so many things that it had trouble >clarifying even some simple ones. Thus, our current dilemma. >I don't doubt the need for some way to express recurrence. I do doubt >that there is a simple or obvious solution, or even that there is a single >solution; in the long run, we may need multiple languages for specifying >RRULES, to support non-Western or non-Terran calendars, for example. But >we're not qualified today to plan the details of working with the Ganymede >Colony's calendaring system. Thus, when I pipe up about getting rid of >recurrence entirely, what I'm really saying is that this is what we should >have done in the first place, and only started worrying about specific >recurrence types (as opposed to the general architectural notion of >recurrence) once we had done a good job of the initial 80% of the problem >(including the architectural place of recurrence and other "extension" >mechanisms). > >Our current "cleanup" efforts should at least try to approximate the >results of having done things in a more evolutionary manner. That's hard >to do, because you almost want to "unlearn" some of the things you think >you already know you need while focusing on the core. But I think it's >our best hope for clarity and consensus. -- Nathaniel > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. From TimHare at comcast.net Sat Mar 12 06:45:11 2005 From: TimHare at comcast.net (Tim Hare) Date: Sat Mar 12 06:45:21 2005 Subject: [Ietf-calsify] Re: What's wrong with more radical simplification? In-Reply-To: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exch ange.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> Message-ID: <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> I've got to agree with Cameron on this one - get some products out the door which interoperate at some level we can use! Speaking as an end user of a couple of different products, and knowing how my work organization works, I've got to say this to the vendors present: Interoperability is NOT going to cost you market share, it may drive sales up. Yes, I know that making things standards-compliant means an organization can pull the plug on your stuff and replace it with a competitor's stuff. But that's going to happen either because of price, which is some organizations trumps technology every time; because of features other than interoperability, like (for a really bad example) animated alarm cartoons; or because of crappy code that breaks all the time. It's not going to happen because your software plays nice with others. Developers - this of course isn't really aimed at you but at those who make decisions about where your resources are applied. And if I could write to all of the marketing folks in your companies: join the Calendaring & Scheduling Consortium and help get this done. Making people's calendar lives nicer would be a great part of the "marketing conversation" we hear about so much these days. In fact, if any of you want to send me e-mail addresses for decision-makers, I will try to send them a reasoned plea about this. I'm not a Consortium member yet myself (I'm saving my box tops up) but I believe in this enough to work on and think about this in my personal time anyway. At 02:20 PM 3/10/2005, Cameron Stillion wrote: >I wish I could be at the BOF today... > >If possible, I'd like to communicate to the participants one thing that >I think warrants repeating. The calsify effort should be a practical >one - and by that, I mean that it should be focused on doing something >that will be meaningful to vendors whose iCal implementations will >benefit from in the immediate future. While I applaud the philosophical >design approaches espoused in many of the "more radical" approaches to >iCal, I must assert that anything along the radical edge is going to >count against us in the practical department. If we can rally around a >*small* number of changes to the currently proposed standard, get it to >become an actual standard, and call it done (Shrink wrap it! Ship it!) - >then we have accomplished something no other iCal body has been able to >do for many years. This standard should be very close to what exists >today, especially in shipping code. Ideally, vendors would have a short >list of discrepancies to fix in order to become standards compliant, and >most interop issues would be eliminated, or at least mitigated. Once >we've accomplished that, I believe that we are free to take more daring, >radical, or revolutionary approaches toward the standard. But for now, I >think we are held somewhat captive by our past on this one, >unfortunately - if we took the wrong approach before, let's understand >that. But first, let's make this thing a standard. If we don't do it >soon, I fear that the ad-hoc standard will trump all of our discussions, >and we will have no real say in what "_standard_ iCal support" actually >means. > >Probably more than my .02 worth... > >Cameron > > >-----Original Message----- >From: ietf-calsify-bounces@osafoundation.org >[mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Nathaniel >Borenstein >Sent: Thursday, March 10, 2005 9:50 AM >To: Reinhold Kainhofer >Cc: ietf-calsify@osafoundation.org >Subject: Re: [Ietf-calsify] Re: What's wrong with more radical >simplification? > >Well, here it is two hours before the BOF and I'm finally catching up on >the email, but I can't resist commenting on this: > >Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare: > > ... I want calendaring to be just as simple as e-mail is now - > >On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote; > Hehe, you >chose the wrong example here. Do you know how complex the > >specification for email is (in particular the mime spec and all the >various > encodings possible)? iCalendar is trivial compared to those >specs... > >Actually, the reality is both more interesting than this *and* >potentially a model for the current situation. > >In designing MIME, we were faced with an incredible complexity of >potential uses and applications. As such, we largely retreated from >specifying formats for *any* of them. Instead, we focused on basic >syntactic and encoding requirements for a tremendously extensible >format, defined a few core types that we thought were obviously >necessary, and left the rest to be done as future extensions. By now, a >paper copy of all the MIME extension specifications would probably come >in multiple volumes (and would, of course, include all the iCal >specs). I am rather glad that we didn't try to do all that work in a >single specification! > >I see the ongoing work of data format specification as being, for all >intents and purpose, fractal. Whatever we define today, people tomorrow >will be trying to extend it in multiple, unforeseeable directions. The >wisdom of the 80/20 rule is that it is a good heuristic for working with >fractally complex problems: 1. Solve 80% >of the problem facing you. 2. Look deeper at the remaining 20%. 3. >Return to step 1. (It doesn't always work, you have to break out of it >occasionally, but it's a good default strategy.) > >In the case of the ical standards, we have a historical failure to >follow this model; the format tried to do so many things that it had >trouble clarifying even some simple ones. Thus, our current dilemma. >I don't doubt the need for some way to express recurrence. I do doubt >that there is a simple or obvious solution, or even that there is a >single solution; in the long run, we may need multiple languages for >specifying RRULES, to support non-Western or non-Terran calendars, for >example. But we're not qualified today to plan the details of working >with the Ganymede Colony's calendaring system. Thus, when I pipe up >about getting rid of recurrence entirely, what I'm really saying is that >this is what we should have done in the first place, and only started >worrying about specific recurrence types (as opposed to the general >architectural notion of recurrence) once we had done a good job of the >initial 80% of the problem (including the architectural place of >recurrence and other "extension" mechanisms). > >Our current "cleanup" efforts should at least try to approximate the >results of having done things in a more evolutionary manner. That's >hard to do, because you almost want to "unlearn" some of the things you >think you already know you need while focusing on the core. But I think >it's our best hope for clarity and consensus. -- Nathaniel > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. From Dave.Thewlis at calconnect.org Sat Mar 12 08:24:29 2005 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Sat Mar 12 08:24:29 2005 Subject: [Ietf-calsify] Re: What's wrong with more radical simplification? In-Reply-To: <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> Message-ID: <423317BD.5030105@calconnect.org> I would like to support Tim's observations about interoperability and its effect. So often the proprietary vs open/interoperable debate, focused on market share, looks like obsessing on the comparative slice percentage of a fixed-diameter pie, as opposed to a perhaps narrower wedge of a much larger pie. We are in a world where nobody has just one product for anything due to mergers and acquisition, or simply multiple fiefdoms and departments. To say nothing of non-enterprise purposes such as event publication, personal calendars, etc. What gets overlooked in the proprietary discussions about getting an enterprise to convert everyone to the same product, thus avoiding interoperability concerns, is the freeze effect on the customer of a conversion - any conversion. Even if the organization sees it through, at the end they spend a bundle, lose months of otherwise productive time, and at best wind up where they started. If the money and other resources could be put towards growth, better service, or anything useful to the bottom line, the pie can grow and so do all the individual pieces. And thanks for the reference to the Consortium, TIm. Naturally I agree with your recommendation. Dave Thewlis, Executive Director The Calendaring and Scheduling Consortium Tim Hare wrote: > I've got to agree with Cameron on this one - get some products out the > door which interoperate at some level we can use! Speaking as an end > user of a couple of different products, and knowing how my work > organization works, I've got to say this to the vendors present: > > > Interoperability is NOT going to cost you market share, it may drive > sales up. > > > Yes, I know that making things standards-compliant means an > organization can pull the plug on your stuff and replace it with a > competitor's stuff. But that's going to happen either because of > price, which is some organizations trumps technology every time; > because of features other than interoperability, like (for a really > bad example) animated alarm cartoons; or because of crappy code that > breaks all the time. It's not going to happen because your software > plays nice with others. Developers - this of course isn't really aimed > at you but at those who make decisions about where your resources are > applied. > > And if I could write to all of the marketing folks in your companies: > join the Calendaring & Scheduling Consortium and help get this done. > Making people's calendar lives nicer would be a great part of the > "marketing conversation" we hear about so much these days. In fact, if > any of you want to send me e-mail addresses for decision-makers, I > will try to send them a reasoned plea about this. I'm not a > Consortium member yet myself (I'm saving my box tops up) but I believe > in this enough to work on and think about this in my personal time > anyway. > From Doug at Royer.com Sat Mar 12 11:16:38 2005 From: Doug at Royer.com (Doug Royer) Date: Sat Mar 12 11:16:57 2005 Subject: [Ietf-calsify] Re: What's wrong with more radical simplification? In-Reply-To: <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> Message-ID: <42334016.8070109@Royer.com> Skipped content of type multipart/mixed-------------- 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/20050312/dc90c664/smime-0001.bin From reinhold at kainhofer.com Sat Mar 12 11:24:05 2005 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Sat Mar 12 11:24:15 2005 Subject: [Ietf-calsify] Re: What's wrong with more radical simplification? In-Reply-To: <42334016.8070109@Royer.com> References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> <42334016.8070109@Royer.com> Message-ID: <200503122024.07033.reinhold@kainhofer.com> Am Samstag, 12. M?rz 2005 20:16 schrieb Doug Royer: > If I made an online survey or form and made it available that contained > all of the MUST, SHOULD, ... would anyone fill it out for their product > knowing the results would be made public to this list? I would for KOrganizer. Reinhold -------------- 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/20050312/1ccb3c46/attachment.bin From leifj at it.su.se Sat Mar 12 13:35:51 2005 From: leifj at it.su.se (Leif Johansson) Date: Sat Mar 12 13:36:13 2005 Subject: [Ietf-calsify] radical simplifications and the "ietf process" Message-ID: <423360B7.1080003@it.su.se> NB - What follows constitutes my take on the BOF last thursday and may or may not match the notes from the meeting. At the BOF there seemed to be clear consensus to pursue work towards draft standard status for the core ical specifications (which entails actually defining what constitutes the 'core'). For those of you not familiar with the terminology, progressing a set of documents to draft standard means among other things that interoperability reports from vendors guide clarification and/or ellimination of features from the specifications. This means lots of work but if done right will result in a set of specifications which is more in line with what people have been able to implement in practice while also increasing the chances of interoperability in the future. A word of warning though: ime there is no such thing as a quick fix to IETF documents. Those who hope for a drive-by edit of a set of RFCs may be disapointed. MVH leifj From daboo at isamet.com Sat Mar 12 14:16:00 2005 From: daboo at isamet.com (Cyrus Daboo) Date: Sat Mar 12 14:16:06 2005 Subject: [Ietf-calsify] Re: What's wrong with more radical simplification? In-Reply-To: <42334016.8070109@Royer.com> References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.c orp.microsoft.com> <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> <42334016.8070109@Royer.com> Message-ID: <2FCD42DFCEE71DABEDB0A509@ninevah.cyrusoft.com> Hi Doug, --On Saturday, March 12, 2005 12:16:38 PM -0700 Doug Royer wrote: > If I made an online survey or form and made it available that contained > all of the MUST, SHOULD, ... would anyone fill it out for their product > knowing the results would be made public to this list? The results from the 2004 Calconnect interop do contain a 2445 compliance table which other vendors could easily adapt: -- Cyrus Daboo From lisa at osafoundation.org Mon Mar 28 11:06:54 2005 From: lisa at osafoundation.org (Lisa Dusseault) Date: Mon Mar 28 11:07:07 2005 Subject: [Ietf-calsify] Transition issues and iCalendar, iMIP, iTIP Message-ID: <128d4d2d95fef3c35c1e643366e6c10d@osafoundation.org> At the BOF and since then in discussing the charter with various people (draft charter to come soon), various people have tried to nail down the issue of what "upgrade" or "versioning" features we need to work on. Using any concrete word seems to be overly specific but maybe the word "transition" will do: we should try to find ways such that iCalendar usage scenarios can include the ability to transition to newer versions, or to or from alternative formats. I find it hard to nail down the transition issue because I don't want to nail any one approach into place until we've had a number of ideas to consider. This seems like one of those design situations where there are a large number of possible solutions (or if not solutions, then at least incremental improvements) and we want to get a sampling of the approach space. I don't think I have anything near the total reasonable number of approaches in my head. That said, here's a start at sampling that space: - We could add capabilities advertisement to iMIP. Clients sending iMIP messages (containing some base format) could advertise via a new mail header or iCalendar attribute their ability to handle other formats besides the base format. - We could add the ability to transport alternate representations within iCalendar. An iCalendar version "2.1" document could contain an iCalendar version 3.0 document, and a client could discard the base document and unpack and use only the more advanced format if it was able to. This could be backward compatible. - We could modify iMIP to allow multipart MIME messages and add some logic about what the multipart means and which part to use. - we could specify LDAP attributes or WebDAV properties that allow iTIP clients to advertise supported formats, together with the destination address to use. All of these approaches solve slightly different problems (and some cause new problems) and I'm sure people have very different ideas about what are the most important problems to solve and how to do that. Before we get into that, can we extend this list with other approaches or variations? Lisa From lisa at osafoundation.org Mon Mar 28 17:55:45 2005 From: lisa at osafoundation.org (Lisa Dusseault) Date: Mon Mar 28 17:55:54 2005 Subject: [Ietf-calsify] Proposed Charter Message-ID: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> Based on the discussion at the Calsify BOF in Minneapolis, a bunch of us (those who volunteered at the time) have worked on the draft WG charter below. Some notes: - The iCalendar revision work, although it may be challenging work, is at least well understood in terms of scope and deliverables. - The transition work which I attempted to characterize in a separate email is not so well scoped out and it's not clear yet what specific proposals might emerge, if any, so this charter would need to be revised when the specific proposals become clear or do not appear after a period. - The XML work which seemed to be supported in the BOF (but nobody actually took consensus) was not supported in the group of people working on this charter, so it appears as "out of scope". -- Lisa ---- Calendaring and Scheduling Standards Simplification (calsify) Chair(s): TBD Applications Area Director(s): Ted Hardie Scott Hollenbeck Mailing Lists: General Discussion: ietf-calsify@osafoundation.org To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability as been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Publish the interoperability issues that have arisen between calendaring and scheduling systems, as well as document the usage of iCalendar by other specifications. (2) Revise the Calendaring and Scheduling standards to advance the state of interoperable calendaring and scheduling by addressing the published interoperability issues. As far as it is possible, the working group will ensure backwards compatibility with widely deployed implementations and other specifications that use it. (3) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (4) Advance the Calendaring and Scheduling standards to Draft Standard. (5) Work on transition (upgrade or versioning) mechanisms for calendar data exchange. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Goals and Milestones: TBD - Submit "Problems in Calendaring and Scheduling Standards". TBD - Submit RFC2445bis. TBD - Submit other revised documents. From Doug at Royer.com Mon Mar 28 18:33:53 2005 From: Doug at Royer.com (Doug Royer) Date: Mon Mar 28 18:34:01 2005 Subject: [Ietf-calsify] Proposed Charter In-Reply-To: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> References: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> Message-ID: <4248BE91.5070800@Royer.com> I think this is great and THANKS for the hard work! Lisa Dusseault wrote: > Based on the discussion at the Calsify BOF in Minneapolis, a bunch of us > (those who volunteered at the time) have worked on the draft WG charter > below. > > Some notes: > - The iCalendar revision work, although it may be challenging work, is > at least well understood in terms of scope and deliverables. > - The transition work which I attempted to characterize in a separate > email is not so well scoped out and it's not clear yet what specific > proposals might emerge, if any, so this charter would need to be revised > when the specific proposals become clear or do not appear after a period. > - The XML work which seemed to be supported in the BOF (but nobody > actually took consensus) was not supported in the group of people > working on this charter, so it appears as "out of scope". > > -- Lisa > ---- ... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards -------------- next part -------------- A non-text attachment was scrubbed... Name: Doug.vcf Type: text/x-vcard Size: 293 bytes Desc: not available Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050328/a5aed5ef/Doug.vcf 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 j2T2Xuaa019782 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Mon, 28 Mar 2005 18:33:58 -0800 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j2T2Xrfr010556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 28 Mar 2005 18:33:54 -0800 Message-ID: <4248BE91.5070800@Royer.com> Date: Mon, 28 Mar 2005 19:33:53 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Proposed Charter References: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> In-Reply-To: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> Content-Type: multipart/mixed; boundary="------------070200010605010704000605" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO 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, 29 Mar 2005 02:33:59 -0000 This is a multi-part message in MIME format. --------------070200010605010704000605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think this is great and THANKS for the hard work! Lisa Dusseault wrote: > Based on the discussion at the Calsify BOF in Minneapolis, a bunch of us > (those who volunteered at the time) have worked on the draft WG charter > below. > > Some notes: > - The iCalendar revision work, although it may be challenging work, is > at least well understood in terms of scope and deliverables. > - The transition work which I attempted to characterize in a separate > email is not so well scoped out and it's not clear yet what specific > proposals might emerge, if any, so this charter would need to be revised > when the specific proposals become clear or do not appear after a period. > - The XML work which seemed to be supported in the BOF (but nobody > actually took consensus) was not supported in the group of people > working on this charter, so it appears as "out of scope". > > -- Lisa > ---- ... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------070200010605010704000605 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------070200010605010704000605-- X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (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 j2T1tpaa017670 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 28 Mar 2005 17:55:51 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf-calsify@osafoundation.org From: Lisa Dusseault Date: Mon, 28 Mar 2005 17:55:45 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Proposed Charter 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, 29 Mar 2005 01:55:52 -0000 Based on the discussion at the Calsify BOF in Minneapolis, a bunch of us (those who volunteered at the time) have worked on the draft WG charter below. Some notes: - The iCalendar revision work, although it may be challenging work, is at least well understood in terms of scope and deliverables. - The transition work which I attempted to characterize in a separate email is not so well scoped out and it's not clear yet what specific proposals might emerge, if any, so this charter would need to be revised when the specific proposals become clear or do not appear after a period. - The XML work which seemed to be supported in the BOF (but nobody actually took consensus) was not supported in the group of people working on this charter, so it appears as "out of scope". -- Lisa ---- Calendaring and Scheduling Standards Simplification (calsify) Chair(s): TBD Applications Area Director(s): Ted Hardie Scott Hollenbeck Mailing Lists: General Discussion: ietf-calsify@osafoundation.org To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability as been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Publish the interoperability issues that have arisen between calendaring and scheduling systems, as well as document the usage of iCalendar by other specifications. (2) Revise the Calendaring and Scheduling standards to advance the state of interoperable calendaring and scheduling by addressing the published interoperability issues. As far as it is possible, the working group will ensure backwards compatibility with widely deployed implementations and other specifications that use it. (3) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (4) Advance the Calendaring and Scheduling standards to Draft Standard. (5) Work on transition (upgrade or versioning) mechanisms for calendar data exchange. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Goals and Milestones: TBD - Submit "Problems in Calendaring and Scheduling Standards". TBD - Submit RFC2445bis. TBD - Submit other revised documents. X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (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 j2SJ71aa017310 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 28 Mar 2005 11:07:04 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <128d4d2d95fef3c35c1e643366e6c10d@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf-calsify@osafoundation.org From: Lisa Dusseault Date: Mon, 28 Mar 2005 11:06:54 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Transition issues and iCalendar, iMIP, iTIP 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, 28 Mar 2005 19:07:05 -0000 At the BOF and since then in discussing the charter with various people (draft charter to come soon), various people have tried to nail down the issue of what "upgrade" or "versioning" features we need to work on. Using any concrete word seems to be overly specific but maybe the word "transition" will do: we should try to find ways such that iCalendar usage scenarios can include the ability to transition to newer versions, or to or from alternative formats. I find it hard to nail down the transition issue because I don't want to nail any one approach into place until we've had a number of ideas to consider. This seems like one of those design situations where there are a large number of possible solutions (or if not solutions, then at least incremental improvements) and we want to get a sampling of the approach space. I don't think I have anything near the total reasonable number of approaches in my head. That said, here's a start at sampling that space: - We could add capabilities advertisement to iMIP. Clients sending iMIP messages (containing some base format) could advertise via a new mail header or iCalendar attribute their ability to handle other formats besides the base format. - We could add the ability to transport alternate representations within iCalendar. An iCalendar version "2.1" document could contain an iCalendar version 3.0 document, and a client could discard the base document and unpack and use only the more advanced format if it was able to. This could be backward compatible. - We could modify iMIP to allow multipart MIME messages and add some logic about what the multipart means and which part to use. - we could specify LDAP attributes or WebDAV properties that allow iTIP clients to advertise supported formats, together with the destination address to use. All of these approaches solve slightly different problems (and some cause new problems) and I'm sure people have very different ideas about what are the most important problems to solve and how to do that. Before we get into that, can we extend this list with other approaches or variations? Lisa X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2CMG0aa005187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 12 Mar 2005 14:16:01 -0800 Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2CM336g007872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 12 Mar 2005 17:03:04 -0500 Date: Sat, 12 Mar 2005 17:16:00 -0500 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification? Message-ID: <2FCD42DFCEE71DABEDB0A509@ninevah.cyrusoft.com> In-Reply-To: <42334016.8070109@Royer.com> References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.c orp.microsoft.com> <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> <42334016.8070109@Royer.com> X-Mailer: Mulberry/3.2.0a1 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () 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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 22:16:04 -0000 Hi Doug, --On Saturday, March 12, 2005 12:16:38 PM -0700 Doug Royer wrote: > If I made an online survey or form and made it available that contained > all of the MUST, SHOULD, ... would anyone fill it out for their product > knowing the results would be made public to this list? The results from the 2004 Calconnect interop do contain a 2445 compliance table which other vendors could easily adapt: -- Cyrus Daboo X-Envelope-From: leifj@it.su.se X-Envelope-To: Received: from smtp1.su.se (smtp1.su.se [130.237.162.112]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2CLa7aZ003216 for ; Sat, 12 Mar 2005 13:36:08 -0800 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 6CBD738037 for ; Sat, 12 Mar 2005 22:36:06 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07129-03 for ; Sat, 12 Mar 2005 22:36:06 +0100 (CET) Received: from [10.145.62.61] (unknown [217.213.129.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 0D52B3800A for ; Sat, 12 Mar 2005 22:36:01 +0100 (CET) Message-ID: <423360B7.1080003@it.su.se> Date: Sat, 12 Mar 2005 22:35:51 +0100 From: Leif Johansson User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at av-in.su.se X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] radical simplifications and the "ietf process" 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: Sat, 12 Mar 2005 21:36:09 -0000 NB - What follows constitutes my take on the BOF last thursday and may or may not match the notes from the meeting. At the BOF there seemed to be clear consensus to pursue work towards draft standard status for the core ical specifications (which entails actually defining what constitutes the 'core'). For those of you not familiar with the terminology, progressing a set of documents to draft standard means among other things that interoperability reports from vendors guide clarification and/or ellimination of features from the specifications. This means lots of work but if done right will result in a set of specifications which is more in line with what people have been able to implement in practice while also increasing the chances of interoperability in the future. A word of warning though: ime there is no such thing as a quick fix to IETF documents. Those who hope for a drive-by edit of a set of RFCs may be disapointed. MVH leifj X-Envelope-From: reinhold@kainhofer.com 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 j2CJOAaa026074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 12 Mar 2005 11:24:12 -0800 Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j2CJO7Rk010607 for ; Sat, 12 Mar 2005 20:24:09 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification? Date: Sat, 12 Mar 2005 20:24:05 +0100 User-Agent: KMail/1.8 References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> <42334016.8070109@Royer.com> In-Reply-To: <42334016.8070109@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1968482.eGbFP1i1BH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503122024.07033.reinhold@kainhofer.com> X-Spam-Score: 0 () 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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 19:24:14 -0000 --nextPart1968482.eGbFP1i1BH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Samstag, 12. M=E4rz 2005 20:16 schrieb Doug Royer: > If I made an online survey or form and made it available that contained > all of the MUST, SHOULD, ... would anyone fill it out for their product > knowing the results would be made public to this list? I would for KOrganizer. Reinhold --nextPart1968482.eGbFP1i1BH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCM0HWTqjEwhXvPN0RAjAaAJ44iwMAS4kkzOZ3PRvVwZy0omhpzACgsXE8 jiOSE+IeB27YwMTpAglx+RY= =88Pk -----END PGP SIGNATURE----- --nextPart1968482.eGbFP1i1BH-- 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 j2CJGlaa025083 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Sat, 12 Mar 2005 11:16:49 -0800 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j2CJGdog016915 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 12 Mar 2005 11:16:45 -0800 Message-ID: <42334016.8070109@Royer.com> Date: Sat, 12 Mar 2005 12:16:38 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification? References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> In-Reply-To: <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070608090701000903000707" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO 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: Sat, 12 Mar 2005 19:16:51 -0000 This is a cryptographically signed message in MIME format. --------------ms070608090701000903000707 Content-Type: multipart/mixed; boundary="------------020500080104010602090309" This is a multi-part message in MIME format. --------------020500080104010602090309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > I've got to agree with Cameron on this one - get some products out the > door which interoperate at some level we can use! Speaking as an end > user of a couple of different products, and knowing how my work > organization works, I've got to say this to the vendors present: This only works when the vendors publish what they do and do not do. So far each person that wants to know must figure it out. The CalConnect results only tell us if those that participate can talk to each other. It does not tell us why things fail (not done, done badly, hard to understand in the spec, ...). When it reaches some level iCal will be moved from proposed standard to standard. So far that seems to be the level of granularity produced. So, if the vendors want to go through all of the MUST, MUST NOT, SHOULD, and SHOULD NOT in iCal, iTIP, and iMIP and publish their compliance, then we can use that model and consider it. Right now it is just a idea that has no published paper or specification to consider. If I made an online survey or form and made it available that contained all of the MUST, SHOULD, ... would anyone fill it out for their product knowing the results would be made public to this list? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020500080104010602090309 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020500080104010602090309-- --------------ms070608090701000903000707 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 9w0BCQUxDxcNMDUwMzEyMTkxNjM5WjAjBgkqhkiG9w0BCQQxFgQU+8Z9gFI0Fjbr/3c4mkP7 DO4ycPIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEArn33HQbjSkOtXvKo2PQbJQFcN0QAA6BZWU9t1+xcN2Hn9aZcI0e3HXgiFo4ue3ZA +aUEV64rCzPln0jeYu72w46BXKCEwFtJcJHtm+4z1iMXqbVVZd2x7X7R/znbLDCvx2terCRF sqvG4WATxpZLjIm2ogbUGfSaE5KLNqp1pSBkR7xIRd8DAZ3pEus0TA+6CKRde5rADoL0Q722 g4Ss9uyjwJYSurnyxafL6VbBcUXN3rN9TAJB0U4/1aNH6VCFpvNm2B8kz2uKzUT2XqyY9XaK i4QxaONv8Ld/PgSfXF7TgT8j2bRQpCwE/5QsUSc1trsprATfKcReKBte2RR22QAAAAAAAA== --------------ms070608090701000903000707-- X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j2CGOQaZ023547 for ; Sat, 12 Mar 2005 08:24:27 -0800 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.119.197 with plain) by smtp807.mail.sc5.yahoo.com with SMTP; 12 Mar 2005 16:24:26 -0000 Message-ID: <423317BD.5030105@calconnect.org> Date: Sat, 12 Mar 2005 08:24:29 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification? References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> In-Reply-To: <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.462 (*) SARE_TOCC_COMBO1,UNDISC_RECIPS 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: 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, 12 Mar 2005 16:24:27 -0000 I would like to support Tim's observations about interoperability and its effect. So often the proprietary vs open/interoperable debate, focused on market share, looks like obsessing on the comparative slice percentage of a fixed-diameter pie, as opposed to a perhaps narrower wedge of a much larger pie. We are in a world where nobody has just one product for anything due to mergers and acquisition, or simply multiple fiefdoms and departments. To say nothing of non-enterprise purposes such as event publication, personal calendars, etc. What gets overlooked in the proprietary discussions about getting an enterprise to convert everyone to the same product, thus avoiding interoperability concerns, is the freeze effect on the customer of a conversion - any conversion. Even if the organization sees it through, at the end they spend a bundle, lose months of otherwise productive time, and at best wind up where they started. If the money and other resources could be put towards growth, better service, or anything useful to the bottom line, the pie can grow and so do all the individual pieces. And thanks for the reference to the Consortium, TIm. Naturally I agree with your recommendation. Dave Thewlis, Executive Director The Calendaring and Scheduling Consortium Tim Hare wrote: > I've got to agree with Cameron on this one - get some products out the > door which interoperate at some level we can use! Speaking as an end > user of a couple of different products, and knowing how my work > organization works, I've got to say this to the vendors present: > > > Interoperability is NOT going to cost you market share, it may drive > sales up. > > > Yes, I know that making things standards-compliant means an > organization can pull the plug on your stuff and replace it with a > competitor's stuff. But that's going to happen either because of > price, which is some organizations trumps technology every time; > because of features other than interoperability, like (for a really > bad example) animated alarm cartoons; or because of crappy code that > breaks all the time. It's not going to happen because your software > plays nice with others. Developers - this of course isn't really aimed > at you but at those who make decisions about where your resources are > applied. > > And if I could write to all of the marketing folks in your companies: > join the Calendaring & Scheduling Consortium and help get this done. > Making people's calendar lives nicer would be a great part of the > "marketing conversation" we hear about so much these days. In fact, if > any of you want to send me e-mail addresses for decision-makers, I > will try to send them a reasoned plea about this. I'm not a > Consortium member yet myself (I'm saving my box tops up) but I believe > in this enough to work on and think about this in my personal time > anyway. > 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 j2CEjJaZ012522 for ; Sat, 12 Mar 2005 06:45:19 -0800 Received: from thare.comcast.net (pcp03356962pcs.micske01.fl.comcast.net[68.84.26.220]) by comcast.net (rwcrmhc11) with SMTP id <2005031214451301300oeb9ge>; Sat, 12 Mar 2005 14:45:14 +0000 Message-Id: <6.2.1.2.0.20050312092548.01c29c90@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 12 Mar 2005 09:45:11 -0500 To: ietf-calsify@osafoundation.org From: Tim Hare Subject: RE: [Ietf-calsify] Re: What's wrong with more radical simplification? In-Reply-To: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exch ange.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST 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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 14:45:20 -0000 I've got to agree with Cameron on this one - get some products out the door which interoperate at some level we can use! Speaking as an end user of a couple of different products, and knowing how my work organization works, I've got to say this to the vendors present: Interoperability is NOT going to cost you market share, it may drive sales up. Yes, I know that making things standards-compliant means an organization can pull the plug on your stuff and replace it with a competitor's stuff. But that's going to happen either because of price, which is some organizations trumps technology every time; because of features other than interoperability, like (for a really bad example) animated alarm cartoons; or because of crappy code that breaks all the time. It's not going to happen because your software plays nice with others. Developers - this of course isn't really aimed at you but at those who make decisions about where your resources are applied. And if I could write to all of the marketing folks in your companies: join the Calendaring & Scheduling Consortium and help get this done. Making people's calendar lives nicer would be a great part of the "marketing conversation" we hear about so much these days. In fact, if any of you want to send me e-mail addresses for decision-makers, I will try to send them a reasoned plea about this. I'm not a Consortium member yet myself (I'm saving my box tops up) but I believe in this enough to work on and think about this in my personal time anyway. At 02:20 PM 3/10/2005, Cameron Stillion wrote: >I wish I could be at the BOF today... > >If possible, I'd like to communicate to the participants one thing that >I think warrants repeating. The calsify effort should be a practical >one - and by that, I mean that it should be focused on doing something >that will be meaningful to vendors whose iCal implementations will >benefit from in the immediate future. While I applaud the philosophical >design approaches espoused in many of the "more radical" approaches to >iCal, I must assert that anything along the radical edge is going to >count against us in the practical department. If we can rally around a >*small* number of changes to the currently proposed standard, get it to >become an actual standard, and call it done (Shrink wrap it! Ship it!) - >then we have accomplished something no other iCal body has been able to >do for many years. This standard should be very close to what exists >today, especially in shipping code. Ideally, vendors would have a short >list of discrepancies to fix in order to become standards compliant, and >most interop issues would be eliminated, or at least mitigated. Once >we've accomplished that, I believe that we are free to take more daring, >radical, or revolutionary approaches toward the standard. But for now, I >think we are held somewhat captive by our past on this one, >unfortunately - if we took the wrong approach before, let's understand >that. But first, let's make this thing a standard. If we don't do it >soon, I fear that the ad-hoc standard will trump all of our discussions, >and we will have no real say in what "_standard_ iCal support" actually >means. > >Probably more than my .02 worth... > >Cameron > > >-----Original Message----- >From: ietf-calsify-bounces@osafoundation.org >[mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Nathaniel >Borenstein >Sent: Thursday, March 10, 2005 9:50 AM >To: Reinhold Kainhofer >Cc: ietf-calsify@osafoundation.org >Subject: Re: [Ietf-calsify] Re: What's wrong with more radical >simplification? > >Well, here it is two hours before the BOF and I'm finally catching up on >the email, but I can't resist commenting on this: > >Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare: > > ... I want calendaring to be just as simple as e-mail is now - > >On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote; > Hehe, you >chose the wrong example here. Do you know how complex the > >specification for email is (in particular the mime spec and all the >various > encodings possible)? iCalendar is trivial compared to those >specs... > >Actually, the reality is both more interesting than this *and* >potentially a model for the current situation. > >In designing MIME, we were faced with an incredible complexity of >potential uses and applications. As such, we largely retreated from >specifying formats for *any* of them. Instead, we focused on basic >syntactic and encoding requirements for a tremendously extensible >format, defined a few core types that we thought were obviously >necessary, and left the rest to be done as future extensions. By now, a >paper copy of all the MIME extension specifications would probably come >in multiple volumes (and would, of course, include all the iCal >specs). I am rather glad that we didn't try to do all that work in a >single specification! > >I see the ongoing work of data format specification as being, for all >intents and purpose, fractal. Whatever we define today, people tomorrow >will be trying to extend it in multiple, unforeseeable directions. The >wisdom of the 80/20 rule is that it is a good heuristic for working with >fractally complex problems: 1. Solve 80% >of the problem facing you. 2. Look deeper at the remaining 20%. 3. >Return to step 1. (It doesn't always work, you have to break out of it >occasionally, but it's a good default strategy.) > >In the case of the ical standards, we have a historical failure to >follow this model; the format tried to do so many things that it had >trouble clarifying even some simple ones. Thus, our current dilemma. >I don't doubt the need for some way to express recurrence. I do doubt >that there is a simple or obvious solution, or even that there is a >single solution; in the long run, we may need multiple languages for >specifying RRULES, to support non-Western or non-Terran calendars, for >example. But we're not qualified today to plan the details of working >with the Ganymede Colony's calendaring system. Thus, when I pipe up >about getting rid of recurrence entirely, what I'm really saying is that >this is what we should have done in the first place, and only started >worrying about specific recurrence types (as opposed to the general >architectural notion of recurrence) once we had done a good job of the >initial 80% of the problem (including the architectural place of >recurrence and other "extension" mechanisms). > >Our current "cleanup" efforts should at least try to approximate the >results of having done things in a more evolutionary manner. That's >hard to do, because you almost want to "unlearn" some of the things you >think you already know you need while focusing on the core. But I think >it's our best hope for clarity and consensus. -- Nathaniel > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > >_______________________________________________ >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: 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 j2CEOhaZ010431 for ; Sat, 12 Mar 2005 06:24:43 -0800 Received: from thare.comcast.net (pcp03356962pcs.micske01.fl.comcast.net[68.84.26.220]) by comcast.net (sccrmhc11) with SMTP id <20050312142437011005o2uoe>; Sat, 12 Mar 2005 14:24:37 +0000 Message-Id: <6.2.1.2.0.20050312090743.01cc3568@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 12 Mar 2005 09:24:32 -0500 To: ietf-calsify@osafoundation.org From: Tim Hare Subject: Re: [Ietf-calsify] Simplification, recurrence, other issues In-Reply-To: <23ccd889c994a02c1297abffb9e3f57f@guppylake.com> References: <6.2.1.2.0.20050211201730.02d0a120@mail.comcast.net> <200502121039.31039.reinhold@kainhofer.com> <23ccd889c994a02c1297abffb9e3f57f@guppylake.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST 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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 14:24:45 -0000 Since I am a "quotee" I feel compelled to clarify my comment: I fully understand the underlying complexity of things (I work with z/OS for example, and I have in the past supported OfficeVision/MVS a very model of medium complexity). What I meant by my comment was: people just "walk up to e-mail and use it" now, they don't think about it so much (because so many developers thought about it and worked on things like MIME); calendar should be that way - people should use it intuitively. Nathaniel used the phrase "recurrence type" - and maybe that's an idea... we've been thinking of various levels of iCalendar, but maybe for recurrences we want the object to identify its own level? For examples: RRULE;RTYPE=Mars-Syntax: {Some syntax defined by those angry Martians who didn't like the basic one} RRULE;RTYPE=Ganymede-Syntax: {Some syntax defined by the Ganymedians (and/or their pals the Ganymeans and Ganymaximums but I digress)} absence of RTYPE implying RDATEs only It does NOT improve simplification, so should be in a higher-level iCalendar, but perhaps it does improve the recurrence rule problem? There would also need, in iTIP or follow-on, need to be a response meaning "I don't get this syntax". Maximum implementations could send the recurrence rules in several (perhaps the most popular in terms of sales) syntaxes at the same time since the receiver would pick only the syntax they'd like. And now for something completely different: Should we be careful to use iCalendar in our posts rather than iCal to avoid confusion with Apple's product? Not for copyright/trademark concerns but I'd like to be clear about what iCalendar the protocol/format does versus what iCal the product does with it. And last but not least: I've lost some e-mail due to a computer failure. There's one issue from Calsify that I would like someone to explain to me OFF the list, if they would: Why, in an iCalendar-Basic using only UTC times, would timezones matter on recurrence rules with participants in different timesones/daylight savings time areas? I seem to recall some discussion, and a valid reason, but I can't remember it and I'd like to. So, if anyone has a concise explanation, please send it to me... thanks. At 12:50 PM 3/10/2005, Nathaniel Borenstein wrote: >Well, here it is two hours before the BOF and I'm finally catching up on >the email, but I can't resist commenting on this: > >Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare: > > ... I want calendaring to be just as simple as e-mail is now - > >On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote; > > Hehe, you chose the wrong example here. Do you know how complex the > > specification for email is (in particular the mime spec and all the various > > encodings possible)? iCalendar is trivial compared to those specs... > >Actually, the reality is both more interesting than this *and* potentially >a model for the current situation. > >In designing MIME, we were faced with an incredible complexity of >potential uses and applications. As such, we largely retreated from >specifying formats for *any* of them. Instead, we focused on basic >syntactic and encoding requirements for a tremendously extensible format, >defined a few core types that we thought were obviously necessary, and >left the rest to be done as future extensions. By now, a paper copy of >all the MIME extension specifications would probably come in multiple >volumes (and would, of course, include all the iCal specs). I am rather >glad that we didn't try to do all that work in a single specification! > >I see the ongoing work of data format specification as being, for all >intents and purpose, fractal. Whatever we define today, people tomorrow >will be trying to extend it in multiple, unforeseeable directions. The >wisdom of the 80/20 rule is that it is a good heuristic for working with >fractally complex problems: 1. Solve 80% of the problem facing >you. 2. Look deeper at the remaining 20%. 3. >Return to step 1. (It doesn't always work, you have to break out of it >occasionally, but it's a good default strategy.) > >In the case of the ical standards, we have a historical failure to follow >this model; the format tried to do so many things that it had trouble >clarifying even some simple ones. Thus, our current dilemma. >I don't doubt the need for some way to express recurrence. I do doubt >that there is a simple or obvious solution, or even that there is a single >solution; in the long run, we may need multiple languages for specifying >RRULES, to support non-Western or non-Terran calendars, for example. But >we're not qualified today to plan the details of working with the Ganymede >Colony's calendaring system. Thus, when I pipe up about getting rid of >recurrence entirely, what I'm really saying is that this is what we should >have done in the first place, and only started worrying about specific >recurrence types (as opposed to the general architectural notion of >recurrence) once we had done a good job of the initial 80% of the problem >(including the architectural place of recurrence and other "extension" >mechanisms). > >Our current "cleanup" efforts should at least try to approximate the >results of having done things in a more evolutionary manner. That's hard >to do, because you almost want to "unlearn" some of the things you think >you already know you need while focusing on the core. But I think it's >our best hope for clarity and consensus. -- Nathaniel > >_______________________________________________ >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: 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 j2AJLAaZ014132 for ; Thu, 10 Mar 2005 11:21:10 -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); Thu, 10 Mar 2005 11:21:01 -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; Thu, 10 Mar 2005 11:21:01 -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); Thu, 10 Mar 2005 11:20:37 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7503.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-calsify] Re: What's wrong with more radical simplification? Date: Thu, 10 Mar 2005 11:20:58 -0800 Message-ID: <1198328AFDBF5841B27E40C40C331537029D08EF@df-chewy-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-calsify] Re: What's wrong with more radical simplification? Thread-Index: AcUlmeRKrhOPn5ROQTaZx5DKINAGsAACnMKA From: "Cameron Stillion" To: "Nathaniel Borenstein" , "Reinhold Kainhofer" X-OriginalArrivalTime: 10 Mar 2005 19:20:37.0966 (UTC) FILETIME=[3DAFD6E0:01C525A6] X-Spam-Score: 0 () 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 j2AJLAaZ014132 Cc: 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: Thu, 10 Mar 2005 19:21:13 -0000 I wish I could be at the BOF today... If possible, I'd like to communicate to the participants one thing that I think warrants repeating. The calsify effort should be a practical one - and by that, I mean that it should be focused on doing something that will be meaningful to vendors whose iCal implementations will benefit from in the immediate future. While I applaud the philosophical design approaches espoused in many of the "more radical" approaches to iCal, I must assert that anything along the radical edge is going to count against us in the practical department. If we can rally around a *small* number of changes to the currently proposed standard, get it to become an actual standard, and call it done (Shrink wrap it! Ship it!) - then we have accomplished something no other iCal body has been able to do for many years. This standard should be very close to what exists today, especially in shipping code. Ideally, vendors would have a short list of discrepancies to fix in order to become standards compliant, and most interop issues would be eliminated, or at least mitigated. Once we've accomplished that, I believe that we are free to take more daring, radical, or revolutionary approaches toward the standard. But for now, I think we are held somewhat captive by our past on this one, unfortunately - if we took the wrong approach before, let's understand that. But first, let's make this thing a standard. If we don't do it soon, I fear that the ad-hoc standard will trump all of our discussions, and we will have no real say in what "_standard_ iCal support" actually means. Probably more than my .02 worth... Cameron -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Nathaniel Borenstein Sent: Thursday, March 10, 2005 9:50 AM To: Reinhold Kainhofer Cc: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification? Well, here it is two hours before the BOF and I'm finally catching up on the email, but I can't resist commenting on this: Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare: > ... I want calendaring to be just as simple as e-mail is now - On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote; > Hehe, you chose the wrong example here. Do you know how complex the > specification for email is (in particular the mime spec and all the various > encodings possible)? iCalendar is trivial compared to those specs... Actually, the reality is both more interesting than this *and* potentially a model for the current situation. In designing MIME, we were faced with an incredible complexity of potential uses and applications. As such, we largely retreated from specifying formats for *any* of them. Instead, we focused on basic syntactic and encoding requirements for a tremendously extensible format, defined a few core types that we thought were obviously necessary, and left the rest to be done as future extensions. By now, a paper copy of all the MIME extension specifications would probably come in multiple volumes (and would, of course, include all the iCal specs). I am rather glad that we didn't try to do all that work in a single specification! I see the ongoing work of data format specification as being, for all intents and purpose, fractal. Whatever we define today, people tomorrow will be trying to extend it in multiple, unforeseeable directions. The wisdom of the 80/20 rule is that it is a good heuristic for working with fractally complex problems: 1. Solve 80% of the problem facing you. 2. Look deeper at the remaining 20%. 3. Return to step 1. (It doesn't always work, you have to break out of it occasionally, but it's a good default strategy.) In the case of the ical standards, we have a historical failure to follow this model; the format tried to do so many things that it had trouble clarifying even some simple ones. Thus, our current dilemma. I don't doubt the need for some way to express recurrence. I do doubt that there is a simple or obvious solution, or even that there is a single solution; in the long run, we may need multiple languages for specifying RRULES, to support non-Western or non-Terran calendars, for example. But we're not qualified today to plan the details of working with the Ganymede Colony's calendaring system. Thus, when I pipe up about getting rid of recurrence entirely, what I'm really saying is that this is what we should have done in the first place, and only started worrying about specific recurrence types (as opposed to the general architectural notion of recurrence) once we had done a good job of the initial 80% of the problem (including the architectural place of recurrence and other "extension" mechanisms). Our current "cleanup" efforts should at least try to approximate the results of having done things in a more evolutionary manner. That's hard to do, because you almost want to "unlearn" some of the things you think you already know you need while focusing on the core. But I think it's our best hope for clarity and consensus. -- Nathaniel _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: nsb@guppylake.com X-Envelope-To: Received: from socrates.netpos.com ([152.160.5.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2AHo8aZ004568 for ; Thu, 10 Mar 2005 09:50:08 -0800 Received: from [IPv6:::1] (unknown [152.160.5.34]) by socrates.netpos.com (Postfix) with ESMTP id ED15C274135; Thu, 10 Mar 2005 12:50:07 -0500 (EST) In-Reply-To: <200502121039.31039.reinhold@kainhofer.com> References: <6.2.1.2.0.20050211201730.02d0a120@mail.comcast.net> <200502121039.31039.reinhold@kainhofer.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23ccd889c994a02c1297abffb9e3f57f@guppylake.com> Content-Transfer-Encoding: 7bit From: Nathaniel Borenstein Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification? Date: Thu, 10 Mar 2005 12:50:10 -0500 To: Reinhold Kainhofer X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: 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: Thu, 10 Mar 2005 17:50:11 -0000 Well, here it is two hours before the BOF and I'm finally catching up on the email, but I can't resist commenting on this: Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare: > ... I want calendaring to be just as simple as e-mail is now - On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote; > Hehe, you chose the wrong example here. Do you know how complex the > specification for email is (in particular the mime spec and all the various > encodings possible)? iCalendar is trivial compared to those specs... Actually, the reality is both more interesting than this *and* potentially a model for the current situation. In designing MIME, we were faced with an incredible complexity of potential uses and applications. As such, we largely retreated from specifying formats for *any* of them. Instead, we focused on basic syntactic and encoding requirements for a tremendously extensible format, defined a few core types that we thought were obviously necessary, and left the rest to be done as future extensions. By now, a paper copy of all the MIME extension specifications would probably come in multiple volumes (and would, of course, include all the iCal specs). I am rather glad that we didn't try to do all that work in a single specification! I see the ongoing work of data format specification as being, for all intents and purpose, fractal. Whatever we define today, people tomorrow will be trying to extend it in multiple, unforeseeable directions. The wisdom of the 80/20 rule is that it is a good heuristic for working with fractally complex problems: 1. Solve 80% of the problem facing you. 2. Look deeper at the remaining 20%. 3. Return to step 1. (It doesn't always work, you have to break out of it occasionally, but it's a good default strategy.) In the case of the ical standards, we have a historical failure to follow this model; the format tried to do so many things that it had trouble clarifying even some simple ones. Thus, our current dilemma. I don't doubt the need for some way to express recurrence. I do doubt that there is a simple or obvious solution, or even that there is a single solution; in the long run, we may need multiple languages for specifying RRULES, to support non-Western or non-Terran calendars, for example. But we're not qualified today to plan the details of working with the Ganymede Colony's calendaring system. Thus, when I pipe up about getting rid of recurrence entirely, what I'm really saying is that this is what we should have done in the first place, and only started worrying about specific recurrence types (as opposed to the general architectural notion of recurrence) once we had done a good job of the initial 80% of the problem (including the architectural place of recurrence and other "extension" mechanisms). Our current "cleanup" efforts should at least try to approximate the results of having done things in a more evolutionary manner. That's hard to do, because you almost want to "unlearn" some of the things you think you already know you need while focusing on the core. But I think it's our best hope for clarity and consensus. -- Nathaniel X-Envelope-From: nsb@guppylake.com X-Envelope-To: Received: from socrates.netpos.com ([152.160.5.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2AHo5aZ004565 for ; Thu, 10 Mar 2005 09:50:05 -0800 Received: from [IPv6:::1] (unknown [152.160.5.34]) by socrates.netpos.com (Postfix) with ESMTP id A12BA274084 for ; Thu, 10 Mar 2005 12:50:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <42110701.80509@Royer.com> References: <42110701.80509@Royer.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00d482bc42b2cfb8dd1d1c0615c58d77@guppylake.com> Content-Transfer-Encoding: 7bit From: Nathaniel Borenstein Subject: Re: [Ietf-calsify] radical simplification, too Date: Thu, 10 Mar 2005 12:50:07 -0500 To: ietf-calsify@osafoundation.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () 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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 17:50:10 -0000 +1. And given the inherent tendency of humans to get confused over time zones, a sophisticated implementation might actually use this to double-check, and raise a red flag when it believes that the two specifications are not, in fact, identical. -- Nathaniel On Feb 14, 2005, at 3:16 PM, Doug Royer wrote: > > Another idea is that we make a new parameter (say R-FYI) that *if* > set to true in an RRULE property means that the RDATE's should > be used and that RRULE is just FYI. So you could say in effect, > and the ORGANIZER wants to convey the fact that the meeting is > weekly, but look at the RDATE's for the real instance times. > > Now we can keep the organizers intent when implementations care, > and for those that do not care, here are the real instance > times in RDATEs. > > Preston Stephenson wrote: >> Just a few comments. >> It would be nice to have a list of iCal properties that were defined >> explicitly. >> Be it an iCal lite or an iCal best practices. >> If we could come to a consensus of what they were, >> I would be more willing to make the project I work on fit into that >> consensus. >> If we get into the more difficult ones such as rrule, >> I'm constrained by the architecture of our application. >> I'm limited to fanning out the recurrence rule to a reasonable number >> of occurrences in the future. >> It would nice to support infinite occurring rules, but I don't see it >> happening anytime soon. >> All I'm saying is if rrule was part of the iCal basic, I could only >> support it with certain restrictions. >> It would be nice to have a set of iCal properties that could be >> supported in all cases. >> Thanks. >> Preston >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > > We Do Standards - You Need Standards > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: nsb@guppylake.com X-Envelope-To: Received: from socrates.netpos.com ([152.160.5.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2AHnVaZ004532 for ; Thu, 10 Mar 2005 09:49:32 -0800 Received: from [IPv6:::1] (unknown [152.160.5.34]) by socrates.netpos.com (Postfix) with ESMTP id 19FD0274084 for ; Thu, 10 Mar 2005 12:49:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <4210D4F3.9070405@cse.ucsc.edu> References: <0IBW001A4SLXT8@smtp6.wiscmail.wisc.edu> <4210D4F3.9070405@cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93eada66515822e8a1756faa4bf86083@guppylake.com> Content-Transfer-Encoding: 7bit From: Nathaniel Borenstein Subject: Re: [Ietf-calsify] Re: Comments on radical simplification and bumping the version Date: Thu, 10 Mar 2005 12:26:09 -0500 To: ietf-calsify@osafoundation.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () 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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 17:49:33 -0000 +1. Also, we can specify that in the case of a "true" infinite meeting, it is the responsibility of the initiating server to send out a "renewal" at the end of the one/five/hundred year period. On Feb 14, 2005, at 11:42 AM, Elias Sinderson wrote: > Curt Ellmann wrote: > >> I agree that one year is too short-- what is the problem with >> infinitely >> recurring events? There are plenty of examples of events that are >> infinitely recurring-- holidays, anniversaries, and other >> celebrations. >> > I only suggested one year as a matter of conjecture - the limit could > be five years, or ten, for that matter, as long as there is a limit > which allows a /finite/ expansion of recurring events. Note that this > was in response to Doug Royers observation that "the only noticable > issue is infinate recurring entries." I will also note that the > cannonical examples provided for infinitely recurring events have been > all-day events, which do not suffer from the timezone issues that have > been identified. As per Dougs' suggestion, the inclusion of a property > which indicates that a METHOD:REFRESH should be done in the future > seems like a good idea; simply a way to say 'and so on' or 'sync again > later'. I cannot think of a situation where a client would need to get > the infinity of recurrences in a single sync and not be able to sync > again in the future. Further, regarding the question of the duration > placed as an upper bound, allowing any given implementation to set > its' own upper bound on recurrences rather than having it rigidly > declared in the specification would make it possible for devices with > limited profiles to play along as well. > > It may be useful to step back from this issue for a minute and try to > identify use cases that require scheduling of recurring events (or any > event), e.g., five years out. Neither Hotels nor airlines will allow > one to place reservations that far in advance. The most difficult > restaraunt to dine at in California (French Laundry) only takes > reservations several months (4?) out. Business meetings are never > arranged in this matter, and it only seems a matter of convenience to > say that this meeting will recur infinitely rather than specify an end > date several years away. As I mentioned before, even so called > 'infinitely recurring' weekly project meetings are (semi)regularly > rescheduled to accomodate attendees constraints and other recurring > meetings that are scheduled. If anyone can provide a use case which > requires an infinitely recurring event which is not an all day affair > (such as holidays, birthdays, anniversaries, etc.), please provide it. > Extra credit will be given if it isn't some freaky and contrived edge > case, but occurs frequently enough that it would be an honest > inconvenience to a user to schedule seperate events. > > Deprecating infinitely recurring events and placing a sensible upper > bound as suggested would allow recurring events to be represented as > either a RRULE or as a finite sequence of events, and would sidestep > the issues related to timezones that have been raised previously on > the list. It would seem that the benefits of this simplification > greatly outweigh the downside of rescheduling a meeting every couple > years (if it lasts that long) or similar. Further, if RRULEs become an > optional part of the specification, as has been suggested before, this > approach would allow interoperability where one system implements > RRULEs and the other doesn't, as there won't be a problem in an > infinite expansion of events. > > > Cheers, > Elias > > >> -----Original Message----- >> From: ietf-calsify-bounces@osafoundation.org >> [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Michiel >> van >> Leeuwen >> Sent: Saturday, February 12, 2005 2:58 PM >> To: ietf-calsify@osafoundation.org >> Subject: [Ietf-calsify] Re: Comments on radical simplification and >> bumping >> the version >> >> Elias Sinderson wrote: >> >>> Would it be reasonable to deprecate infinitely recurring events and >>> place an upperbound of, say, one year on recurring entries? >> >> I think it isn't such a great idea, becasue one year is a magic >> number. Why one year, and not two years? >> > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > X-Envelope-From: rlmorgan@washington.edu X-Envelope-To: Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2AGK6aa030540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Mar 2005 08:20:06 -0800 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j2AGK3bR029444 for ; Thu, 10 Mar 2005 08:20:03 -0800 Received: from wireless-130-129-134-145.ietf62.ietf.org (wireless-130-129-134-145.ietf62.ietf.org [130.129.134.145]) (authenticated bits=0) by smtp.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j2AGK2Tv015661 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 10 Mar 2005 08:20:03 -0800 Date: Thu, 10 Mar 2005 10:20:02 -0600 (CST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsify Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-calsify] calsify BoF today 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, 10 Mar 2005 16:20:06 -0000 A reminder that we'll be having the calsify BoF at IETF 62 today at 1300 CST. The BoF agenda is at: http://ietf.org/ietf/05mar/calsify.txt The Jabber chat room is: calsify@ietf.xmpp.org See http://www.xmpp.org/ietf-chat.html for info on how that works. There's also audio streaming from all the IETF WG sessions this time, see http://videolab.uoregon.edu/events/ietf/ for info on that. We'll do our best to have the discussion happen via the microphone and the chat room. Intro presentation (thank you Cyrus) can be got from: http://staff.washington.edu/rlmorgan/misc/IETF-62-calsify-BOF-intro.sxi http://staff.washington.edu/rlmorgan/misc/IETF-62-calsify-BOF-intro.ppt in OO and Powerpoint respectively. If anyone else has a presentation please send it to me before the meeting if possible. - RL "Bob" X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j24FEbaa018454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Mar 2005 07:14:38 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j24F2v6g020312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Mar 2005 10:02:57 -0500 Date: Fri, 04 Mar 2005 10:14:37 -0500 From: Cyrus Daboo To: Ietf-calsify@osafoundation.org Message-ID: <9433B7FD862E1A78C9D9F58A@ninevah.cyrusoft.com> X-Mailer: Mulberry/3.2.0a1 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-calsify] Jabber chat room for BOF 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, 04 Mar 2005 15:14:41 -0000 FYI A Jabber IM chat room has been setup for the BOF next week. So those that will not be present can participate that way if they desire. The jabber address is: calsify@ietf.xmpp.org -- Cyrus Daboo