Subject: [Ietf-calsify] timezone/rrule standard/basic proposal

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Thu Oct 28 15:50:21 2004

Here's a thought:

The simple/basic version of ICalendar would not use timezones and everything 
is in UTC.  Applications that implement the simple version would have a big 
warning sticker that described the limitation of two people/recur/cross 
midnight problem.

The full version would use timezones and handle rrules properly. A small 
office that had everyone in the same building could use the 'lite' version 
and larger/distributed organizations (and/or people) could use software that 
implements the full (perhaps more expensive) version.

I know there is some resistance to providing a spec that isn't perfect, but I 
think the case above is a real-world compromise.

Thoughts?

-- 
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb

---

From: TimHare at comcast.net ([email-masked])
Date: Thu Oct 28 20:56:17 2004

>Both Doug and Mark's recent proposals have some merit. I see, however, a 
>need to identify iCal Basic,  iCal SomethingElse, iCal Complex, in a 
>slightly different way than EXTENSIONS. Since iCal Basic, or Level 0, or 
>whatever we're calling it, will have LESS capabilities than the current 
>RFC 2445/2446,  I think it might be better to identify that level by 
>something other than the lack of extension properties. I think we either 
>need a LEVEL property, or a LEVEL parameter on the VERSION property, that 
>identifies what level we are dealing with, with the default being the 
>lowest possible level for that version. There's still room for EXTENSIONS 
>with its RFC identification scheme, under this proposal, I just want to 
>see clear identification, early in the data stream, of what we're dealing with.

Examples:

VERSION; LEVEL=BASIC: 3.0               Identifies compliance with only the 
most basic iCal RFCs (Mark's "lite" version) after
VERSION; LEVEL=STANDARD: 2.0    Complies with RFC 2445/6/7 as written today
VERSION: 2.0                            Same as above, under 2.0 default 
would be LEVEL=STANDARD to grandfather existing stuff
VERSION: 3.0                            Same as the first one, under 3.0 
default would be LEVEL=BASIC
VERSION; LEVEL=EXTENDED: 3.0    Standard plus extensions, look for the 
EXTENSIONS property
EXTENSIONS: RFC9901, RFC9902, RFC9903

I would also suggest that the spec require that EXTENSIONS if coded 
immediately follow VERSION and that VERSION immediately follow VCALENDAR, 
to aid clients that are perhaps handling the data stream in a sequential 
fashion, but that's not a requirement that I'd have to have.

If you defined what the levels meant, you might eliminate the need for the 
IS-SUB-SET parameter. Define LEVEL=BASIC to be UTC-only and no RRULES, then 
follow Doug's suggestion and send only LEVEL=BASIC when you don't know the 
capabilities at the other end.

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Oct 28 21:08:01 2004

>implements the full (perhaps more expensive) version.
The problem is not the size of your office. The problem can be the location
of your customers and vendors.

If we disallow recurrence rules in 'basic'  then the time zone boundry 
problem
goes away as each instance of the same entry has a RECURRENCE-ID
that can be specified in UTC, even when the DTSTART propertyt is not.

So, along with the proposal I send earlier today, we could add that
in 'Basic' the time zone for single instance objects be in UTC.
And that the RECURRENCE-ID value for expanded instances be in UTC
even when the DTSTART property is not.

This would allow implementations that know TZ processing to continue
to work with 'Basic' and 2445 objects.

-- 

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/2ecc57d2/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Oct 28 21:18:57 2004

[email-masked] wrote:

>
>> Both Doug and Mark's recent proposals have some merit. I see, 
>> however, a need to identify iCal Basic,  iCal SomethingElse, iCal 
>> Complex, in a slightly different way than EXTENSIONS. Since iCal 
>> Basic, or Level 0, or whatever we're calling it, will have LESS 
>> capabilities than the current RFC 2445/2446,  I think it might be 
>> better to identify that level by something other than the lack of 
>> extension properties. I think we either need a LEVEL property, or a 
>> LEVEL parameter on the VERSION property, that identifies what level 
>> we are dealing with, with the default being the lowest possible level 
>> for that version. There's still room for EXTENSIONS with its RFC 
>> identification scheme, under this proposal, I just want to see clear 
>> identification, early in the data stream, of what we're dealing with.
>
The problem with a LEVEL property or parameter is that it is liner set of
inclusive revisions.  For example LEVEL '3' implies '0', '1', and '2' 
support. And
there would be no way to say that '2' is optional. Everyone would have
to support every included option lower than the number value provided.

Where the EXTENSION property is a random set of possibly non-inclusive 
extensions.
Example EXTENSION '3' can mean you only support options '0' and '3'. And 
that
you do not support '1' and '2' options.

> immediately follow VERSION and that VERSION immediately follow 
> VCALENDAR, to aid clients that are perhaps handling the data stream in 
> a sequential fashion, but that's not a requirement that I'd have to have. 

I think we could make this a SHOULD and then that makes 2445 objects 
complient.

>
>
> If you defined what the levels meant, you might eliminate the need for 
> the IS-SUB-SET parameter. Define LEVEL=BASIC to be UTC-only and no 
> RRULES, then follow Doug's suggestion and send only LEVEL=BASIC when 
> you don't know the capabilities at the other end.
>
IS-SUB-SET means the sender has more instances they did not send.
Where LEVEL=BASIC only implies they might have more unsent  instances 
(or not).

-- 

-------------- 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/0f89b4f3/smime.bin

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Fri Oct 29 06:17:23 2004

On October 29, 2004 12:07 am, Doug Royer wrote:
> Mark Swanson wrote:
> >Here's a thought:
> >
> >The simple/basic version of ICalendar would not use timezones and
> > everything is in UTC.  Applications that implement the simple version
> > would have a big warning sticker that described the limitation of two
> > people/recur/cross midnight problem.
> >
> >and larger/distributed organizations (and/or people) could use software
> > that implements the full (perhaps more expensive) version.
>

I covered that case (distributed organizations and/or people).

> that can be specified in UTC, even when the DTSTART propertyt is not.

Actually, the more I think about it I think having a basic/lite version of 
iCalendar will fail unless the lite features are at lest the same as the list 
of features supported by Outlook. Really, if you can't interoperate with 
Outlook then I see no point.

Cheers.

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Fri Oct 29 10:20:33 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041029/bb7859cc/smime.obj

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 29 11:07:19 2004

[email-masked] wrote:

>Default has to be current behavior to accomidate existing iCalendar 
>generators. 
>
>  
>
So far no three vendors have the same  default behaviour across the 
board. That's the point
of making this a starndard.

-- 

-------------- 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/20041029/298c1293/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 29 11:08:55 2004

>Outlook then I see no point.
Outlook can handle this subset of 2445. In fact this is how in many 
cases they
store the appointments already.

-- 

-------------- 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/20041029/d748f7cc/smime-0001.bin

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Fri Oct 29 11:19:26 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041029/2090441a/smime.obj

---

From: jeffrey at skyhouseconsulting.com (Jeffrey Harris)
Date: Fri Oct 29 11:36:41 2004

Hi Folks,

I'm sorry, I'm just not following how an RRULE like "1PM every Monday" 
will work in UTC, when the user is in a timezone whose UTC offset 
changes with DST.  Seems like this will fail about this time of year 
regardless of whether I'm interacting with people in different 
timezones.  Am I missing something?

Sincerely,
Jeffrey

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Fri Oct 29 12:14:55 2004

On October 29, 2004 2:08 pm, Doug Royer wrote:
> >iCalendar will fail unless the lite features are at lest the same as the
> > list of features supported by Outlook. Really, if you can't interoperate
> > with Outlook then I see no point.
> >
> >Cheers.
>

I know Outlook can handle this subset of 2445... Perhaps I wasn't clear 
enough. I'll try again:

I see no point in having a lite/basic version of iCalendar unless the 
lite/basic version includes the most common and useful parts of 2445 as 
implemented by Outlook. Timezones, RRULEs (including dealing with specific 
rrule instances), and others fall in this category. 

Cheers.

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Fri Oct 29 12:25:22 2004

> timezones.  Am I missing something?

Well, I have this exact model working in production and someone in EST can 
schedule RRULEs with someone in PST just fine - even crossing EDT/EST 
boundaries. The caveat is that you can't cross the midnight boundary as 
previously described. Perhaps you could post the steps you took to test this?

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Fri Oct 29 14:02:35 2004

Hi Mark,

--On Friday, October 29, 2004 3:25:21 PM EDT -0400 Mark Swanson 
<[email-masked]> wrote:

> Well, I have this exact model working in production and someone in EST
> can  schedule RRULEs with someone in PST just fine - even crossing
> EDT/EST  boundaries. The caveat is that you can't cross the midnight
> boundary as  previously described. Perhaps you could post the steps you
> took to test this?

Perhaps you can post the VEVENT objects for that so we can see how it works 
with UTC only. Personally I do not see how it can, but I'm prepared to be 
persuaded otherwise...

-- 
Cyrus Daboo

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Fri Oct 29 14:17:52 2004

> previously described. Perhaps you could post the steps you took to test this?

That only works because ET and PT have the same DST transition rule.  You
can't correctly share RRULEs with people in Europe, or Australia, say.  (You
probably even run into trouble with people in Arizona.)

-- 
Jonathan Lennox
[email-masked]

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 29 14:31:43 2004

> timezones.  Am I missing something?

A fact is that not all vendors support the same recurrence rule sets. 
That's one issue.

By expanding the instances before sending them we can then transport objects
that can be used by everyone.  Each expanded instance includes its start
time in UTC using the existing property RECURRENCE-ID which
already allows for its TZID to be different from the DTSTART TZID.

Assume the original 2445 vevent of :

    BEGIN:VEVENT
    UID:A-1
    DTSTART;TZID=US/Pacific:  ...29 cot 2004 at 1 pm...      <-- 
Original in US/Pacific
    RRULE:  ... repeat daily for 100 days ...
    ...
    END:VEVENT

Now the proposal is not to eliminate recurrence rules entirely. It is to 
allow the
transfer of information in a way that can be used by any vendor. And iCAL
already has such a mechanism to describe each individual instance and 
that is
the RECURRENCE-ID property. (Exactly what recurrence rules will be
supported to be defined separately)

So, now when the sender does not know if the recipient can process  
recurrence
rules (Which are defined as optional in 2446), they instead send an 
equivalent set
of objects that are also 2445 compliant.

Here I am including my proposed EXTENSION property and IS-SUB-SET
parameter, and the RECURRENCE-ID is UTC  update to that proposal. In
addition, by setting the IS-SUB-SET parameter to TRUE, the recipient now
knows that they can do a REFRESH later and get the other 95 instances.
(lines wrapped for clarity). Note that these objects are 100% 2445/2446
valid while at the same time allowing vendors that do not support any
recurrence properties to  completely interoperate.

So when the sender does not know if the recipient understands
recurrence rules, they send the same information in a 100%
2445 compatible way. Note that RECURRENCE-ID is in UTC
for each expanded instance sent.

    BEGIN:VCALENDAR
    VERSION:2.0
    EXTENSIONS: ...the number for RFC-recurrences...      ** sender says 
they support this

    BEGIN:VEVENT
   UID:A-1
    DTSTART;IS-SUB-SET=TRUE                                            
** more unsent instances exist.
        ;TZID=US/Pacific: ...29 OCT 2004 at 1 pm ...                    
            ** Still in original US/Pacific
    RRULE: ... repeat daily for 100 days ...
    RECURRENCE-ID;TZID=UTC: ...29 OCT 2004 at 7 am...          ** Time 
in UTC
    ...
    END:VEVENT

     BEGIN:VEVENT
    UID:A-1
    DTSTART;IS-SUB-SET=TRUE
        ;TZID=US/Pacific: ...30 OCT 2004 at 1 pm ...
    RRULE: ... repeat daily for 100 days ...
    RECURRENCE-ID;TZID=UTC: ...30 OCT 2004 at 7                  ** Time 
in UTC
    ...
    END:VEVENT

    BEGIN:VEVENT
    UID:A-1
    DTSTART;IS-SUB-SET=TRU
        ;TZID=US/Pacific: ...29 OCT 2004 at 1 pm ...
    RRULE: ... repeat daily for 100 days ...
    RECURRENCE-ID;TZID=UTC: ...31 OCT 2004 at 7                   ** 
Time in UTC
    ...
    END:VEVENT

    BEGIN:VEVENT
    UID:A-1
    DTSTART;IS-SUB-SET=TRUE
        ;TZID=US/Pacific: ...29 OCT 2004 at 1 pm ...
    RRULE: ... repeat daily for 100 days ...
    RECURRENCE-ID;TZID=UTC: ...01 NOV 2004 at 7                   ** 
Time in UTC
    ...
    END:VEVENT

    BEGIN:VEVENT
    UID:A-1
    DTSTART;IS-SUB-SET=TRUE
        ;TZID=US/Pacific: ...29 OCT 2004 at 1 pm ...
    RRULE: ... repeat daily for 100 days ...
    RECURRENCE-ID;TZID=UTC: ...02 NOV 2004 at 7                   ** 
Time in UTC
    ...
    END:VEVENT

Summary: Valid 2445 objects were sent in a way that a non-recurrence
rule application can understand and the recipient was informed (1) that
the sender does support recurrence rules and (2) there are more instances
in this set that can be fetched with a REFRESH at a later time.

It solves the problem of how many instances to expand or if to
support infinite repeating objects.

And it transfered the effective start time of each instances sent
regardless of the recpients time zone.

-- 

-------------- 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/20041029/2a408785/smime.bin

---

From: jeffrey at skyhouseconsulting.com (Jeffrey Harris)
Date: Fri Oct 29 14:37:14 2004

Hi Mark,

> previously described. Perhaps you could post the steps you took to test this?

OK, I hadn't done any research on how real live clients are dealing with
RRULE and timezones, so I spent a little time with an Outlook .ics file.

I guess it's not true that there's a problem if people in the same time
zone use UTC without a VTIMEZONE, Outlook at least just assumes any
vCalendar file without a timezone must have been created in your DST
regime and changes the offset for DST whether that was intended or not.

That works for people who don't deal with anyone in Indiana, but it
doesn't if someone in Chicago is collaborating with someone in
Indianapolis, most of Indiana doesn't observe DST.

If I export an RRULE in Outlook for someone in Indianapolis, then remove
the VTIMEZONE component, then import it in the Chicago timezone, Outlook
assumes I didn't REALLY mean that my RRULE didn't observe DST.  RFC2445
does say any RRULE which crosses a DST shift must include a VTIMEZONE,
so I guess what I created isn't actually a valid iCalendar file...

I'm not seeing how RRULEs without timezones can get around this problem.
  But I'd love to be proved wrong, it would make my life much easier!

Sincerely,
Jeffrey

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 29 14:39:51 2004

>rrule instances), and others fall in this category. 
The point is (1) interopability with others. and (2) finding
the correct subset.

-------------- 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/20041029/958106e2/smime-0001.bin

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Fri Oct 29 14:55:37 2004

On October 29, 2004 5:17 pm, Jonathan Lennox wrote:

> can't correctly share RRULEs with people in Europe, or Australia, say. 
> (You probably even run into trouble with people in Arizona.)

Yep. Good catch Jonathan.

I'm shortly going to uncomment my forceUTC() code and let my TimeZone code 
path be the standard codepath again so everything works perfectly. I've been 
meaning to do this anyway because of a UTC-related issue with Outlook.

ScheduleWorld is free, and if anyone is interested simply use it to observe 
the transition change scenario. I'm no longer interested in this direction as 
I have fully working timezone code available. The current UTC-based codepath 
will be in production for at least another week.

Cheers.

P.S. Even with a DST transition difference problem some folks still might find 
it appealing.

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Fri Oct 29 15:22:41 2004

> The point is (1) interopability with others. and (2) finding

OK. I still seem to be incorrectly getting my point across. It doesn't matter; 
it was just a brain fart about interoperability with the only "others" that 
matter: Outlook (probably Lotus Notes too).

Cheers.

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Oct 29 15:45:09 2004

> matter: Outlook (probably Lotus Notes too).

That matter: _to you_ (or your customers, whatever).

While we are also interested in Outlook compatibility, it is equally 
important for us to have compatibility with Mozilla Calendar, Kontact, 
Evolution or Chandler. And to have interoperability with other 
solutions which currently do not implement iCalendar because getting 
started is quite hard (this covers a _huge_ number of existing 
solutions).

Yes, we need a "non-basic" standard which includes the things which are 
supported by Outlook, probably almost the complete current spec and a 
lot of clients will implement that (eg Kontact and Evolution).
But besides that a basic spec, which only supports a certain set of 
features (and eg restricts itself to UTC) allows us to significantly 
lower the entry barrier to the standard. This would be IMO a very good 
thing.

As a simple example take Bugzilla. It currently doesn't implement iCal. 
It doesn't need recurrences nor does it require timezones in the 
server. Nevertheless it would be great to be able to publish _and_ 
process tasks in an iCalendar format.
Currently it would need to implement the full iCal spec (aka a full 
scheduling solution) which is out of question while implementing the 
UTC based variant should be almost trivial.

best regards,
   Helge

PS: I have no religious issues with Outlook (we even provide an own 
MAPI storage provider), but "other" solutions are equally, if not more 
important in the broader scope of calendaring.
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Fri Oct 29 16:24:04 2004

> UTC based variant should be almost trivial.

It would be great. All sorts of wonderful new things would happen from such 
interoperability.

> important in the broader scope of calendaring.

As an iCalendar client/server provider, I didn't make my statement lightly:-)

Perhaps I haven't understood what folks on this list were trying to accomplish 
with the lite version. I couldn't see how _I_ could use a lite version, and 
hadn't thought of the Bugzilla example until you just mentioned it. eBay 
might be another example. I can see why you previously mentioned RRULEs may 
not be needed, and why timezones would not be necessary for a number of apps. 
I think I assumed folks on this list were thinking of Outlook-like 
applications only.

Cheers.

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Oct 29 16:37:06 2004

On Oct 30, 2004, at 1:24, Mark Swanson wrote:
> with the lite version.

Well, I'm not the list, this is just my opinion. We currently have no 
events/tasks sharing mechanism which works on a lower level which leads 
to no interoperability at all for a lot of solutions.
And even those which implement the full spec seem to have 
interoperability issues.

> I couldn't see how _I_ could use a lite version, and
> might be another example.

Yes, and loads of other stuff (viewing/editing blog entries in a 
calendar is another one). A lot of things are bound to time and can be 
represented as vevents or vtodos.

> I can see why you previously mentioned RRULEs may

Even for Outlook like applications RRULE's are not strictly necessary, 
recurrencies can be done in other ways, even "on top of the UTC-only 
base spec". Most OpenSource groupware servers I know implement 
recurring events as individual (but connected) events.
So the client is responsible for "evaluating" the RRULE and the 
server/store only needs to know that they belong together (and maybe 
keep some hint on how the construction was initially done).

regards,
   Helge

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Fri Oct 29 16:52:02 2004

There are also the use cases I've discussed with people who work on 
Atom and XMPP
  Atom:
  - publish the timestamp of a blog post in a iCalendar-compatible way
  - publish the location  (ditto)
  - use a blog post to advertise an event
XMPP:
  - use XMPP as a transport for alarms (make your IM-enabled device make 
a sound)
  - send an invitation over XMPP to a calendar application
  - negotiate a mutually free time by exchanging free-busy time

All of these cases, however, require an XML format compatible with the 
fairly-standard ways Atom and XMPP use namespaces.

Lisa

On Oct 29, 2004, at 4:24 PM, Mark Swanson wrote:

> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: TimHare at comcast.net ([email-masked])
Date: Fri Oct 29 19:26:52 2004

>Default has to be current behavior to accomidate existing iCalendar

I disagree with this statement - current generators do not generate a 
'basic' set of iCalendar items.
I also disagree with 'interoperate with most things Outlook can do'.

In my opion,  existing generators could, without huge changes, transform a 
more-complex set of items into a simpler, iCal-Basic set.
For example, it shouldn't be difficult to create a set of VEVENTs from a 
recurrence rule, to send to an "outside" client whose capabilities are 
unknow - a generator probably already has this expansion function to expand 
incoming recurrence rules.

And, as Helge Hess said, there are other use cases which don't need the 
complexity of RRULEs and timezones.

Tim Hare