Re: UTC

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".

Re: UTC

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 

XML format?

Is anyone thinking about doing an XML format for calendaring and 
scheduling data?

Peter

RE: comments on -02

Free/Busy is a property of the user/owner of the calendar more than 
anything else; in essence I really want a logical AND of all of my 
free/busy time so that none of my events, personal or business, get 
overbooked. In iCalendar, however, we have to represent those at the 
VCALENDAR level.  I am cross-posting this to the calsify list, because it 
really belongs there - my view is that we ought to establish a standard for 
the granularity of a free/busy time map (15 minutes would be my choice), 
and then just exchange a "bit map" of the time between two dates that are 
requested as the endpoints - call it a VBUSYMAP deliverable as other binary 
objects are, in Base64.  Then, scheduling a meeting might go something like 
this:

Organizer to each attendee: Show me your free/busy map between date X and 
date Y.
Each attendee: here is the VBUSYMAP of my time
Organizer then finds (hopefully) a time when all are free, and sends out 
meeting requests for that time;or, finding no acceptable time, picks two 
different dates and tries again.

This, to me, simplifies and shortens the scheduling process. Your code 
doesn't have to parse all of the VFREEBUSY items. In fact, an 
implementation can choose to maintain the map in whatever backing store it 
uses, and keep it updated as VEVENTS are added or removed.

At 08:36 PM 10/6/04, Cameron Stillion wrote:
>But if you don't want to be scheduled, that means you want the time to
>appear as if you are "scheduled" already... Right?  You can do this now
>by putting an appointment on your calendar marked as "OOF" - and the
>free/busy view of this event will clearly mark this as already taken.
>

Re: XML format?

Please look at: http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt

Suggestions and opinions are appreciated.

At 09:38 PM 10/6/04, Peter Saint-Andre wrote:
>Is anyone thinking about doing an XML format for calendaring and
>scheduling data?
>
>Peter
>
>_______________________________________________
>Ietf-calsify mailing list
>Ietf-calsify <at> osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Re: XML format?

In article <6.1.1.1.0.20041006222713.0285b490 <at> mail.comcast.net>,
 TimHare <at> comcast.net wrote:

> Please look at: 
> http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt

Thanks, I'll have a look at that.

/psa

Re: comments on -02

I don't see why a bit map has any advantages over a free busy summary 
with begin/end times for each busy blocks.  And the begin/end 
timestamps have some advantages: they're human-readable (or at least 
developer/debugger readable), and don't require us to choose an 
arbitrary maximum granularity (why fifteen minutes? why not five? one?  
Can I negotiate granularity?).

The calendar agent can always translate begin/end times into a bitmap 
for summarization -- that's implementation-dependent.

I have a prejudice against binary formats, too :)

Lisa

On Oct 6, 2004, at 7:25 PM, TimHare <at> comcast.net wrote:

> Free/Busy is a property of the user/owner of the calendar more than 
> anything else; in essence I really want a logical AND of all of my 
> free/busy time so that none of my events, personal or business, get 
> overbooked. In iCalendar, however, we have to represent those at the 
> VCALENDAR level.  I am cross-posting this to the calsify list, because 
> it really belongs there - my view is that we ought to establish a 
> standard for the granularity of a free/busy time map (15 minutes would 
> be my choice), and then just exchange a "bit map" of the time between 
> two dates that are requested as the endpoints - call it a VBUSYMAP 
> deliverable as other binary objects are, in Base64.  Then, scheduling 
> a meeting might go something like this:
>
> Organizer to each attendee: Show me your free/busy map between date X 
> and date Y.

Re: comments on -02

Lisa Dusseault wrote:

> I don't see why a bit map has any advantages over a free busy summary 
> with begin/end times for each busy blocks.  And the begin/end 
> timestamps have some advantages: they're human-readable (or at least 
> developer/debugger readable), and don't require us to choose an 
> arbitrary maximum granularity (why fifteen minutes? why not five? 
> one?  Can I negotiate granularity?).

I agree. VFREEBUSY is already in effect a bit map represented in ASCII.

>
> ...

--

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
Doug <at> Royer.com                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

_______________________________________________
Ietf-caldav mailing list

Proposed TOC for new iCal-Basic draft

I took the TOC from 2445 and tweaked it.

I propose that we take 2445 and only change what we agree
needs to be changed and split out several of the objects as
noted below (This list does not include typo changes)

First collum key:

 +----> 'R' = Remove - this section gets removed or tagged as deprecated.
 |
 |----> 'M' = Modify - Modify text for clarity.
 |
 |----> 'N' = New item - new section to be added.
 |
 |----> 'D' = Document in separate RFC.
 |
 |                Proposed Table of Contents for iCal-Basic
 |
 V

           1 Introduction
           2 Basic Grammar and Conventions
            2.1 Formatting Conventions
            2.2 Related Memos
            2.3 International Considerations
           3 Registration Information
            3.1 Content Type
            3.2 Parameters
            3.3 Content Header Fields

RE: [Ietf-caldav] comments on -02

--On 2004-10-6 10:25 PM -0400 TimHare <at> comcast.net wrote:

> my view is that we ought to establish a standard for the granularity
> of a free/busy time map (15 minutes would be my choice)

I disagree with this. Calendaring is much more than just scheduling 
meetings (with people). I can see using iCal and friends to schedule 
runtime on computing clusters, or access to radio astronomy telescopes, 
or many other resources where fine-grained access times are 
appropriate. We should not be placing any form of social restrictions 
on the protocols like this. They must be left as open ended as possible 
so as to preclude us having to revisit the specifications in the near 
term because we didn't anticipate a use for them.

--lyndon