Subject: [Ietf-calsify] UTC

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Sat Oct 2 09:31:05 2004

Tim -- I'm actually not at all inclined to give up on recurrence 
altogether.  I just think we've been doing it almost altogether wrong.

I apologize for not expressing myself as clearly as I might have liked, 
but my thoughts have been crystalizing quite slowly -- probably my age. 
  Let me try to summarize my current (and tentative) thinking:

1.  "Recurrence" is an infinitely complex concept.  Any language that 
could express all desirable recurrences would be too complex to 
implement, let alone standardize.

2.  Although there are some kinds of recurrence we can all agree are 
highly valuable (e.g. weekly meetings), there is no simple strategy by 
which to encapsulate a single set of things that some or most of us 
would find useful.  In other words, there is a potential for unbounded 
frustration and argument in defining the "edge cases" of a set of 
"universally important" recurrence rules.

3.  We should therefore give up on the concept of a single, special, 
"privileged" language for repeat events, such as the current RRULE.

4.  Instead, we need a framework for an extensible set of recurrence 
rule languages (RRL's).  I predict most RRL's will actually be quite 
simple, targeting very specific purposes.  (The UNIX "cron" format 
comes to mind as a very useful "level-zero" RRL.)  I'm not sure if it 
will be possible, but it would be really nice if some RRL's could be 
timezone-smart without requiring the basic protocol to be 
timezone-smart.  (<Rathole-provocation> Would it really hurt if an 
event that was scheduled for "every Tuesday at 9" was 
timezone-agnostic?  Isn't it the case that for a virtual meeting across 
time zones, people are going to either doublecheck or assume the 
timezone in which the meeting is based, which is often "out of band" 
knowledge from a protocol perspective?</rathole-provocation>)

5.  The hardest part, if we do this, will be handling communication 
between heterogeneous calendaring agents with disjoint RRL sets that 
they support.  I can see two main ways to approach this problem:

-- Always send dual representation with a lowest-common-denominator 
lingua franca.  This is the essence of the  "always send a set, 
optionally send a rule"  proposal that I have floated in the past.  It 
is also the fundamental motivation for "multipart/alternative" in MIME 
-- avoid format negotiations by always sending a dumbed-down form of 
the data.  The primary downsides are less efficient data 
representations (which certainly doesn't seem to have hurt email), and 
no universal representation of (the philosophically dubious but 
emotionally comforting concept of) infinitely recurring events.

-- Allow servers to translate RRL's that clients don't understand.  
This would be relatively easy for CAP/CALDAV -- it could be done like 
ESMTP negotiation, and it would be the server's responsibility to 
provide something that the client says it can understand.  It's more 
challenging for mail/IMIP, but I could imagine extending the 
functionality of the SMTP/iMIP receiver to notice unrecognized rule 
languages and locate a rule translation server.  The latter could be 
any CAP/CALDAV server that understood the right rule languages.

I don't know how much of this we have the appetite to bite off, 
particularly at first, but I sure do like the idea of separating 
recurrence from the rest of the spec.  I think that our primary goal 
should be to facilitate evolution: make the simple things work, with an 
extension mechanism for gradually tackling more and more of the hard 
cases.  An extensible set of RRL's would be one way to accomplish that. 
  There may be others.  -- Nathaniel

On Sep 30, 2004, at 11:50 PM, [email-masked] wrote:

> I'd hate to give up the idea of some form of recurrence too easily. 
> For the most common use cases - like weekly and monthly events - 
> recurrence is a convenient and efficient shorthand. Perhaps we can 
> adopt the following simplifications:
>
> 1. All components exchanged or published use UTC for date/time 
> properties.
> 2. A new component is defined, VRECUR (or a better name) is defined 
> for use only locally, which has simple properties for recurring 
> events.
> 3. VRECUR does not allow infinite repetition
> 4. Components have a recurrence ID (RID - something I think was 
> proposed before?) which can be null.
> 4. VRECUR dates and times use floating time to eliminate daylight 
> savings time problems.
> 5. When exchanging VRECUR components, send the VRECUR with RID and 
> beginning time converted to UTC, then convert to VEVENT/VTODO/etc. and 
> UTC and send those, with the same RID.
> 6. Recipients can accept and store the VRECUR if capable, and ignore 
> the events with that RID, or ignore the VRECUR and accept the events.
> 7. "Exchanging" also applies to publishing to a file.
>
> This is a minor amount of overhead compared to just exchanging the 
> individual events, yet allows both ends to use the more compact way of 
> storing the recurring events if desired.  It leaves conversion from 
> UTC to local time as a presentation problem. We would still have to 
> define the "simple properties" for VRECUR. I think we would need to 
> concentrate on the few use cases which are used by the majority of 
> people. There's probably an 80/20 rule there somewhere. Does anyone 
> have a way to gather statistics on recurrence definitions? For 
> example, where I work we use Notes and I'd bet 80% of recurrence is 
> "weekly".
>
> If this seems like it's not solving the problem or introducing new 
> ones, then I'd agree to "just UTC with no RRULEs in the base spec", 
> and putting RRULEs elsewhere.
>
>
> At 02:45 PM 9/30/04, Doug Royer wrote:
>
>
>> Helge Hess wrote:
>>
>>>
>>> As mentioned before this issue might be resolved by putting rrules 
>>> into an extension to a core spec, so that we have a base spec which 
>>> only requires UTC which of course would be a huge simplification.
>>
>> I agree. For protocols like CAP and CalDAV, that works. For iMIP 
>> there may be
>> no way in advance to know if the recipient will ignore or understand 
>> any extensions.
>>
>> So I think that the base set needs to be 100% compatible at the iMIP 
>> level.
>>
>> Perhaps we need to add an optional property that can be added to iCAL 
>> objects
>> that indicate the extensions supported by the sender. Then the 
>> recipient
>> will know how it can reply. And then the recipient also includes this
>> extension property so then the originator may then track which 
>> recipient
>> supports which features.  Such as:
>>
>>    EXTENSIONS: XXXX,YYYY,ZZZZ
>>
>> where XXXX, YYYY, and ZZZZ are RFC numbers that describe extensions.
>> This would be placed in the VCALENDAR objects. Then the recipient
>> of the object would know that the sender supports RFC-XXXX, RFC-YYYY,
>> and RFC-ZZZZ extensions.
>>
>> Vendor specific extensions could be handled with a vendor specific
>> property such as X-EXTENSIONS that could follow the vendor 
>> specifications.
>>
>> If the EXTENSIONS property is absent, then the sender only supports
>> RFC-'calsify-basic' which I think needs to be compatible with iCAL
>> and would not include the rrule properties.
>>
>> --
>>
>> Doug Royer                     |   http://INET-Consulting.com
>> -------------------------------|-----------------------------
>> [email-masked]                 | Office: (208)520-4044
>> http://Royer.com/People/Doug   | Fax:    (866)594-8574
>>                               | Cell:   (208)520-4044
>>
>>              We Do Standards - You Need Standards
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>