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

[Lisa Dusseault]

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