Subject: [Ietf-calsify] RRULEs, TimeZones

From: Veikko.Punkka at nokia.com ([email-masked])
Date: Thu Oct 14 00:42:45 2004

We could try another alternative approach. We could try to find the RRULE features that
do not have interoperability issues, and have those in the base spec.

My hunch is that all we are going to get is daily repeats, possibly repeats every n days.
Coincidentially, I think these are the only ones that can be expressed without a reference 
to a local time zone, using the current spec.

Untimed repeating events (ones that do only specify a date, not time) would also be possible to
represent without a reference to a local time zone. For example I hold my anniversaries on
a specific date, even though it means a different period of time in every time zone.
Unfortunately, the current spec does not provide a very good way to represent these.
At least partly because of this they also have interoperability problems.

Timed repeating events that have the same fixed time in every time zone (say 6:30 in the
morning, regardless of the time zone) would also be possible to represent without 
a reference to a local time zone. Unfortunately, the current spec does not provide a very 
good way to represent these. At least partly because of this they also have interoperability 
problems.

Veikko Punkka

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: 14 October, 2004 07:34
> To: [email-masked]
> Subject: Re: [Ietf-calsify] RRULEs, TimeZones
> 
> 
> There's a good point here, we can't afford to work on this forever...
> 
> Has anyone from previous Interops or other sources got a 
> listing of RRULE 
> issues that exist between implementations? If we can list all 
> of the places 
> where RRULE interoperabiltiy is broken, will vendors / 
> implementors commit 
> on this list to work out the differences and solve the 
> problems? If they 
> will, and not get into finger-pointing sessions, then RRULEs 
> should be in a 
> base spec. If not, then RRULEs need to be in an extension spec and 
> implementations that don't support RRULEs or don't support them in an 
> interoperable way will have to calculate the individual 
> VEVENTs (obviously 
> within a finite timeframe) and exchange those.
> 
> As for timezones:  it's the political timezone system that is 
> broken on 
> this issue, not necessarily our RFCs.  If we have to have 
> them (for the use 
> cases others have cited?), then can we simplify how we 
> exchange them? How 
> about the spec referencing some repository for political timezone 
> definitions, and the spec only referencing TZs by a standard 
> name? There 
> are standards for names of political entities (like states in 
> the US which 
> have two-letter postal codes, and also federal state ID 
> numbers), standards 
> for names of languages (EN, FR, etc.), so why couldn't one of these 
> standards bodies "hold" the timezones also?
> 
> 
> At 09:49 PM 10/13/04, Mark Swanson wrote:
> 
> >I'm a little surprised to hear this. Based on the seemingly infinite 
> >amount of
> >time wasted waffling over 2445 (all good smart folks 
> involved) I couldn't
> >fathom trying to make _two_ specifications work.
> 
> Tim Hare
> Interested Bystander, Non-Inc. 
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Oct 28 10:52:16 2004

The difficult part is to ensure that we can distinguish old and new objects
and interoperate as much as possible. I think this will work with the vast
majority of products. The goal is interoperability between vendors.

After re-reading many of these posts and the larger number in calsch I 
would like
to make this proposal. One new property and one new parameter. These
will uniquely identify the supported formats of the senders. Includes
are some scenarios.

1) We standardize on never sending any recurrence rule to a 
user/UPN/calendar
     until the sending side has confirmation that the recipient can 
handle recurrence rules.

2) We add a property to all iTIP replies that indicate the supported 
features of the
     side that is replying. We name this new property EXTENSIONS. And it 
will be
     a muilti valued   property that lists the RFC numbers of extensions 
supported by the
     sender of the object.  This property will go at the same level as 
VERSION.

3) We add a new parameter to the DTSTART property that indicates that
     this is part of a recurring set, even when no recurrence rule is 
provided.
     The name of this parameter is 'IS-SUB-SET' and is a boolean. And that
     it is a mandatory parameter for all iCal-Basic objects.

Scenarios:

When the sender sends an object without the EXTENSION property and
one of the following:

    a)  No 'IS-SUB-SET' parameter in the DTSTART, then the recipient knows
    this is an RFC-2445 object. And the recipient knows that the sender 
is unaware
    of the newer iCal specifications.

    b) Has a DTSTART with the IS-SUB-SET (true or false) then the recipient
    knows that the sender does not support recurrence rules, and
    that the sender supports iCal-Basic.

    c) Has a DTSTART with the IS-SUB-SET parameter set to TRUE, then
    the recipient knows that the sender does not support recurrence rules,
    and that the recipient only has a sub-set of the object times. And that
    the recipient may at a later time wish to do  a REFRESH to get  the
    latest version (new SEQUENCE) of the UID. Which may contain
    new objects with new DTSTART values.

    d) Has a DTSTART with the IS-SUB-SET property set to FALSE.
    Then the recipient knows that the sender does not support recurrence
    rules and that the objects instances are complete as of the time they
    were sent.

If the sender sends out an object with an EXTENSIONS property
that contains the RFC number of the new-recurrence-rfc, then
the recipient knows that the sender supports recurrence rules.
Then:

    e) If the sender is unaware if the recipient understands recurrence 
rules.
    then the sender must expand the recurring instances, add the IS-SUBSET
    parameter to all objects that have been expanded.  And add its unique
    RECURRENCE-ID to those objects.

    f) If the sender is aware that the recipient does NOT understand
    recurrence rules, then send the object exactly as in (e).

    g) If the sender is aware that the recipient CAN handle recurrence
    rules, then the sender can still send the object as in (e), or send
    the the object with IS-SUB-SET false and include any recurrence
    rules as specified in the RFC described in the EXTENSIONS property 
values.

When replying back the replying application would never send
back the original EXTENSION property value. It only sends
its known extensions  - if any. As the replying application would have
already received the initial  object from the sender. The replying 
application would
be aware if the sender was  RFC-2445, iCal-Basic, and EXTENSIONS aware.
The replying application would not add IS-SUB-SET as it would not know.

For a COUNTER object.

    The sending application would add any EXTENSIONS property
    and values, and the IS-SUB-SET parameters to any new
    DTSTART properties that were part of the COUNTER.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041028/b94070a9/smime.bin