[Ietf-calsify] summary of issues discussed in the jabber session

[Chris Bryant]

It seems to me that there is a common set of recurrence types that most 
interpersonal scheduling tools try to accomodate.  Lisa's proposal addresses 
these types.  It seems that we could work out some wording that says that 
interpersonal scheduling tools should limit their recurrence rules to a 
specific set.  This would allow creators and consumers of this data to 
simplify their implementations, only supporting that specific set of rules. 
We could keep the hourly/minutely/secondly specs in the rfc, but people 
would need to be aware that even well behaving consumers of this data would 
be free to just ignore those rules or fail to process the event containing 
those rules.  If there are scheduling tools that desire to exchange 
hourly/minutely/secondly events, there would still be a standard format by 
which this would be done.

Chris

----- Original Message ----- 
From: "Lisa Dusseault" <lisa at osafoundation.org>
To: "Mike Douglass" <douglm at rpi.edu>
Cc: <ietf-calsify at osafoundation.org>
Sent: Wednesday, December 13, 2006 11:14 PM
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber 
session


>
> Since I'm one of the advocates for removing some of the recurrence 
> "feaures", I'll clarify that this might only hold for interpersonal 
> scheduling.  I'm hoping Reinhold never schedules me for meetings  every 
> fifteen minutes, and one of the reasons is that my client  doesn't have 
> the functionality to let me alter that recurrence  pattern to something 
> more reasonable.
>
> RFC2445 won't go away, any application that wants to use more complex 
> recurrence rules can.  A personal alarm application (I've used "fob"  in 
> the past and it sounds like what Reinhold's talked about) might  use a 
> different set of recurrence features than interpersonal  scheduling.  Is 
> there a need for interoperability for that kind of  use case?  Do personal 
> alarm applications ever even export and import  alarm data?
>
> Lisa
>
> On Dec 13, 2006, at 10:58 AM, Mike Douglass wrote:
>
>> I hope I wasn't trying to accuse anyone of laziness. I'd have to  accuse 
>> myself first... The allowable storage and transport formats  will usually 
>> be a superset of what's implemented in any given ui  and that's probably 
>> reasonable enough. I doubt we'll put seconds  and minutes in our user ui 
>> but I am considering their use for  internal events. Alarms will probably 
>> work in most cases as will  very simple recurrences but the point of 
>> recurrences is they allow  for greater complexity where needed.
>>
>> My recollection of a brief walk around vendor booths was that most 
>> weren't even aware there was a calendar data 'standard' available  for 
>> use and where the use of seconds and minutes might be  appropriate they 
>> aren't being used because vendors don't even use  icalendar.
>>
>> Triggering system events such as backup or synch seems to be an  ideal 
>> use for icalendar and rather more undarstandable than cron.  Unlikely if 
>> we drop seconds and minutes.
>>
>> As it so happens we're just implementing recurrences in our ui and  it is 
>> hard, but the main obstacle to me is the RFC - not what we're  trying to 
>> implement. Clearly inconsistencies need to be resolved  and the various 
>> traps for the unwary documented so that we all take  a consistent 
>> approach but I'd hope that wouldn't result in a loss  of functionality.
>>
>> Cyrus Daboo wrote:
>>> Hi Mike,
>>>
>>> --On December 13, 2006 10:54:49 AM -0500 Mike Douglass  <douglm at rpi.edu> 
>>> wrote:
>>>
>>>> The arguments for removal of these options seem to be based on  nobody
>>>> using them - however there don't seem to be many places where  they are
>>>> made available. This holds true for some of the other simplification
>>>> suggestions.
>>>>
>>>> That is, until applications make these options available we  cannot 
>>>> tell
>>>> how much they would be used.
>>>>
>>>> Removal of these options just guarantees icalendar data will  never be
>>>> used in certain areas
>>>
>>> But perhaps the application developers choose not to make them 
>>> available precisely because their own surveys/requirements from  users 
>>> did not show any demand. Its not necessarily because the  developers 
>>> were "too lazy" to implement.
>>>
>>> Just from a personal standpoint I can tell you that I have never  had 
>>> cause to create an hourly, minutely or secondly event even  though the 
>>> client I use allows that via UI. Though I have used the  VALARM repeat 
>>> capability to have alarms trigger at five minute  intervals leading up 
>>> to the start of an event. That's why I would  like to know why Reinhold 
>>> choose to use VEVENTs. My feeling is  that you can use VALARM for those 
>>> cases and if you want to see  something on the calendar, then the client 
>>> can quite easily  display the VALARM "instances" using an appropriate 
>>> widget in the UI.
>>>
>>
>> -- 
>>
>> Mike Douglass                           douglm at rpi.edu
>> Senior Systems Programmer
>> Communication & Collaboration Technologies      518 276 6780(voice)  2809
>> (fax)
>> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> Ietf-calsify at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
>
>