Subject: [Ietf-calsify] food for thought

From: TimHare at comcast.net ([email-masked])
Date: Sun Oct 31 11:40:37 2004

Maybe it's serendipity, but I was pointed to an old post at 
http://www.shirky.com/writings/evolve.html about evolvable systems as it 
relates to the Web; and it kind of struck a chord about what we're doing here.

Let's get out an iCal-Basic that everyone can create easily from what 
they've got now,  and everyone can read in with what they've got now. Even 
if it means we're passing back-and-forth larger sets of data to describe 
repeating appointments, even if it means certain appointments that cross 
timezones or daylight-savings-time changes have problems.  The thing is, if 
we can get out something that works, we can then evolve it to work 
better.  We have got to find the simplest common denominator that works, 
call that iCal-Basic, and release it. That's the four-footed fish crawling 
up on the shore... we'll get to mammals later.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Sun, 31 Oct 2004 14:31:03 -0500
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] food for thought

Maybe it's serendipity, but I was pointed to an old post at 
http://www.shirky.com/writings/evolve.html about evolvable systems as it 
relates to the Web; and it kind of struck a chord about what we're doing here.

Let's get out an iCal-Basic that everyone can create easily from what 
they've got now,  and everyone can read in with what they've got now. Even 
if it means we're passing back-and-forth larger sets of data to describe 
repeating appointments, even if it means certain appointments that cross 
timezones or daylight-savings-time changes have problems.  The thing is, if 
we can get out something that works, we can then evolve it to work 
better.  We have got to find the simplest common denominator that works, 
call that iCal-Basic, and release it. That's the four-footed fish crawling 
up on the shore... we'll get to mammals later.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Fri, 29 Oct 2004 21:04:28 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Example of the RRULE and TIMEZONE problem
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sat, 30 Oct 2004 03:04:39 -0000

This is a cryptographically signed message in MIME format.

--------------ms010103050707010204090405
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This is an example of why the timezone problem is important.
Both of these companies have large resources and can not interoperate.

    http://staff.washington.edu/oren/weblog/archives/000317.html

-- 

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

--------------ms010103050707010204090405
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010103050707010204090405--

Date: Fri, 29 Oct 2004 22:18:27 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals

At 01:20 PM 10/29/04, you wrote:
>Default has to be current behavior to accomidate existing iCalendar
>generators.

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
Interested Bystander, Non-Inc. 

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 16:51:50 -0700
To: Mark Swanson <[email-masked]>
Cc: [email-masked]

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:

> On October 29, 2004 6:45 pm, Helge Hess wrote:
>
>> 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.
>
> It would be great. All sorts of wonderful new things would happen from 
> such
> interoperability.
>
>> 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.
>
> 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.
>
>
> -- 
> 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
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Sat, 30 Oct 2004 01:37:00 +0200
To: [email-masked]

On Oct 30, 2004, at 1:24, Mark Swanson wrote:
> Perhaps I haven't understood what folks on this list were trying to 
> accomplish
> 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
> hadn't thought of the Bugzilla example until you just mentioned it. 
> eBay
> 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
> 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.

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
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 19:24:02 -0400

On October 29, 2004 6:45 pm, Helge Hess wrote:

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

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

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

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.

-- 
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: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Sat, 30 Oct 2004 00:45:01 +0200
To: [email-masked]

On Oct 30, 2004, at 0:22, Mark Swanson wrote:
> 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).

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 Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 18:22:39 -0400
Cc: 

On October 29, 2004 5:39 pm, Doug Royer wrote:
> Mark Swanson wrote:
> >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.
>
> The point is (1) interopability with others. and (2) finding
> the correct subset.

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.

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

Date: Fri, 29 Oct 2004 16:09:33 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 22:09:44 -0000

[email-masked] wrote:

>I do believe all the  vendors that attended the interop sessions agree on 
>rules and timezone. (ie more than 2)
>  
>
1) As that list and details are unpublished - this does not mean much to 
anyone at this time.

2) Not all vendors on this list or  CalDav participated. So if the 
results are ever published
     they will be valuable input, but it will not be the entire list of 
issues.

The fact that several on this list are talking about interoperability 
problems
with respect to recurring rules is the point of this discussion.

-- 

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

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 17:55:34 -0400

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

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

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.

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

To: [email-masked]
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
From: [email-masked]
Date: Fri, 29 Oct 2004 17:54:28 -0400

This is a multi-part message in MIME format...

--=_mixed 00784B8185256F3C_=
Content-Type: multipart/alternative;
	boundary="=_alternative 00784B8185256F3C_="

--=_alternative 00784B8185256F3C_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I do believe all the  vendors that attended the interop sessions agree on 
rules and timezone. (ie more than 2)

Doug Royer <[email-masked]> 
Sent by: [email-masked]
10/29/2004 05:43 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
[Ietf-calsify] Re: iCal Basic, timezone, rrule proposals

[email-masked] wrote:

>Outlook and Notes ... 2 largest (by client count) vendors do timezone and 

>rules the same

Yes - exactly,  no three vendors have the same default behavious.

-- 

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

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

--=_alternative 00784B8185256F3C_=--

--=_mixed 00784B8185256F3C_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 00784B8185256F3C_=--

Date: Fri, 29 Oct 2004 15:43:07 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:43:14 -0000

This is a cryptographically signed message in MIME format.

--------------ms020604040006020303090107
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

>Outlook and Notes ... 2 largest (by client count) vendors do timezone and 
>rules the same
>

Yes - exactly,  no three vendors have the same default behavious.

-- 

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

--------------ms020604040006020303090107
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020604040006020303090107--

Date: Fri, 29 Oct 2004 15:39:43 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:39:51 -0000

This is a cryptographically signed message in MIME format.

--------------ms060104000801010607090007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mark Swanson wrote:

>
>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. 
>  
>
The point is (1) interopability with others. and (2) finding
the correct subset.

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

--------------ms060104000801010607090007
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060104000801010607090007--

Date: Fri, 29 Oct 2004 16:37:11 -0500
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal

Hi Mark,

>>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?
> 
> 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?

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

Date: Fri, 29 Oct 2004 15:31:29 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 21:31:41 -0000

This is a cryptographically signed message in MIME format.

--------------ms020106020002000702070708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jeffrey Harris wrote:

> 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?

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.

-- 

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

--------------ms020106020002000702070708
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020106020002000702070708--

From: Jonathan Lennox <[email-masked]>
Date: Fri, 29 Oct 2004 17:17:41 -0400
To: Mark Swanson <[email-masked]>
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Cc: [email-masked]

On Friday, October 29 2004, "Mark Swanson" wrote to "[email-masked]" saying:

> On October 29, 2004 2:36 pm, Jeffrey Harris wrote:
> > 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?
> 
> 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?

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]

Date: Fri, 29 Oct 2004 17:02:28 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Swanson <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Cc: 

Hi Mark,

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

>> 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?
>
> 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: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 15:25:21 -0400

On October 29, 2004 2:36 pm, Jeffrey Harris wrote:
> 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?

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?

-- 
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: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 15:14:53 -0400

On October 29, 2004 2:08 pm, Doug Royer wrote:
> Mark Swanson wrote:
> >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.
>
> Outlook can handle this subset of 2445. In fact this is how in many
> cases they
> store the appointments already.

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.

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

Date: Fri, 29 Oct 2004 13:36:38 -0500
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal

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

> 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?

To: [email-masked]
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
From: [email-masked]
Date: Fri, 29 Oct 2004 14:18:46 -0400

This is a multi-part message in MIME format...

--=_mixed 00648CEC85256F3C_=
Content-Type: multipart/alternative;
	boundary="=_alternative 00648CEC85256F3C_="

--=_alternative 00648CEC85256F3C_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Outlook and Notes ... 2 largest (by client count) vendors do timezone and 
rules the same

Doug Royer <[email-masked]> 
Sent by: [email-masked]
10/29/2004 02:07 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals

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

-- 

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

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

--=_alternative 00648CEC85256F3C_=--

--=_mixed 00648CEC85256F3C_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 00648CEC85256F3C_=--

Date: Fri, 29 Oct 2004 12:08:46 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 18:08:54 -0000

This is a cryptographically signed message in MIME format.

--------------ms030406060206030706040602
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mark Swanson wrote:

>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.
>  
>
Outlook can handle this subset of 2445. In fact this is how in many 
cases they
store the appointments already.

-- 

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

--------------ms030406060206030706040602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030406060206030706040602--

Date: Fri, 29 Oct 2004 12:07:02 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 18:07:17 -0000

This is a cryptographically signed message in MIME format.

--------------ms020108000403080206010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

-- 

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

--------------ms020108000403080206010306
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020108000403080206010306--

To: [email-masked]
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
From: [email-masked]
Date: Fri, 29 Oct 2004 13:20:16 -0400

This is a multi-part message in MIME format...

--=_mixed 005F320785256F3C_=
Content-Type: multipart/alternative;
	boundary="=_alternative 005F320985256F3C_="

--=_alternative 005F320985256F3C_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Default has to be current behavior to accomidate existing iCalendar 
generators. 

Doug Royer <[email-masked]> 
Sent by: [email-masked]
10/29/2004 12:18 AM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals

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

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

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

-- 

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

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

--=_alternative 005F320985256F3C_=--

--=_mixed 005F320785256F3C_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 005F320785256F3C_=--

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
Date: Fri, 29 Oct 2004 09:17:17 -0400

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.
> >
> >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.
>
> The problem is not the size of your office. The problem can be the location
> of your customers and vendors.

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

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

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.

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

Date: Thu, 28 Oct 2004 22:18:33 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 04:18:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms080404060008060600010501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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

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

-- 

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

--------------ms080404060008060600010501
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080404060008060600010501--

Date: Thu, 28 Oct 2004 22:07:51 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] timezone/rrule standard/basic proposal
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 04:07:59 -0000

This is a cryptographically signed message in MIME format.

--------------ms060007040702050106020203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

>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?
>
>  
>

-- 

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

--------------ms060007040702050106020203
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060007040702050106020203--

Date: Thu, 28 Oct 2004 23:48:02 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] Re: iCal Basic, timezone, rrule proposals

>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: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Date: Thu, 28 Oct 2004 18:50:16 -0400
Subject: [Ietf-calsify] timezone/rrule standard/basic proposal

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

Date: Thu, 28 Oct 2004 11:52:04 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] iCal Basic and RRULE proposal.
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2004 17:52:15 -0000

This is a cryptographically signed message in MIME format.

--------------ms070804020008070101040507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------ms070804020008070101040507
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070804020008070101040507--

Date: Wed, 27 Oct 2004 19:52:34 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] re: Roundtable

Dave Thewlis of calconnect.org wrote to me on the subject and gave me 
permission to share what he wrote:

"Tim,

What's available right now is largely on the calconnect website - take a
look at the home page www.calconnect.org (which has "current" information)
and the publicity release after the roundtable.  Also look at the
"committees" page for a list of the technical committees agreed by the
roundtable, their purposes (VERY brief) and time schedules.  I have not
produced a "formal" meeting report (nobody has asked for one, although I
certainly could) -- it would largely say the same things as are in the
publicity statement and the committees.

There are some internal notes but they haven't been reviewed and made
comprehensible unless one was at the roundtable.
"

Tim Hare
Interested Bystander, Non-Inc. 

Date: Mon, 25 Oct 2004 22:18:19 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] report from the roundtable?

I just learned of a September roundtable about the future of calendaring 
sponsored by calconnect.org.  Does anyone know of a transcription of the 
meeting (minutes, meeting report, or anything)?

Tim Hare
Interested Bystander, Non-Inc. 

content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] RRULEs, TimeZones
Date: Thu, 14 Oct 2004 10:41:42 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

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
> 

Date: Thu, 14 Oct 2004 00:34:19 -0400
To: [email-masked]
From: [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. 

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 21:49:14 -0400

On October 13, 2004 8:04 pm, Helge Hess wrote:
> spec, its a huge gain for implementors. If its only in the base spec
> because of another - questionable! - feature, rrule's, its even more
> viable.

10 recurring swimming lessons in a row, x skating lessons in a row, and a 
number of other recurring events. Let's not forget birthdays, anniversaries, 
10:00 am weekly meetings during a crunch.
Perhaps you meant RRULEs are questionable in their current form?

> > We must not remove timezones.
>
> Me says, remove rrule's and timezones from the base spec, but ensure
> that they are still available in an extension spec from the beginning
> on.

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.

Cheers.

-- 
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: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Thu, 14 Oct 2004 02:04:16 +0200
To: [email-masked]

On Oct 14, 2004, at 1:44, Mark Swanson wrote:
> Well... duh. :-) My head was stuck where the <recurring> 
> timezone/event would
> not conflict across the 12 midnight boundary. When it does you're 
> hosed.
> Thanks to Reinhold, Helge, and Cyrus for taking the time to set me 
> straight.

Well, this is just another example why avoiding a requirement for 
timezones in the base spec will pay off.
(Political) Timezones are an incredibly complex issue (and I attribute 
my first grey hair to it ;-) If we can remove that issue from the base 
spec, its a huge gain for implementors. If its only in the base spec 
because of another - questionable! - feature, rrule's, its even more 
viable.

> I also agree localtime is not possible either.
> There is no way to calculate when the midnight boundary condition will 
> happen
> - without a timezone...
>
> We must not remove timezones.

Me says, remove rrule's and timezones from the base spec, but ensure 
that they are still available in an extension spec from the beginning 
on.
There are proper implementations and it would be a real waste to render 
them useless due to incompatible changes in the standard.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 19:44:23 -0400

On October 13, 2004 4:43 pm, Reinhold Kainhofer wrote:
>
> Yes, he'll see the event on monday. However, the event really occurs on
> Monday 01:30 CEST, which is about *Sunday afternoon* in the US. Oops.
> I really said the event is on monday - for a person in CEST. But monday in
> CEST (UTC+0200) is not necessarily monday for a person in the US!

Well... duh. :-) My head was stuck where the <recurring> timezone/event would 
not conflict across the 12 midnight boundary. When it does you're hosed. 
Thanks to Reinhold, Helge, and Cyrus for taking the time to set me straight.

I also agree localtime is not possible either.
There is no way to calculate when the midnight boundary condition will happen 
- without a timezone...

We must not remove timezones.

Cheers.

-- 
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: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 22:43:06 +0200

--nextPart1517890.xD8ELjkDY0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Mark Swanson wrote:
> On October 13, 2004 12:14 pm, Reinhold Kainhofer wrote:
> > Ahm, for two persons in two different time zones this will not work.
>=20
> It does. We'll get to it in a couple of emails I'm sure.

To be honest, I'd really love to see this work. Because then all our proble=
ms=20
would have vanished... But so far, I haven't seen=20

> > Again use the example of my last mail: every monday at 01:30 in Timezone
> > Europe/Vienna. If the start date is in summer time, the event is on sun=
day
> > 23:30 UTC. No imagine somebody in the US views this event. The event st=
art
> > day will be on a sunday, so for the US person the event will only be
>=20
> If your RRULE specifies weekly every Monday, the US person will see the
> Monday  1 second after his DTSTART, so he will see the correct Monday.

Yes, that's what he'll see, which is wrong. See below.

> I'd like to pick a different example because I read this as: you say the
> event is on Monday, then you say the US person viewing the event on a=20
> Monday is the wrong day?

Yes, he'll see the event on monday. However, the event really occurs on Mon=
day=20
01:30 CEST, which is about *Sunday afternoon* in the US. Oops.=20
I really said the event is on monday - for a person in CEST. But monday in=
=20
CEST (UTC+0200) is not necessarily monday for a person in the US!

RRULEs are highly dependent on the local time zone. If you specify a=20
recurrence on monday, this will no longer be true in general for a differen=
t=20
time zone.

And translating RRULES from local time to UTC is not possible either. E.g.=
=20
00:30 localtime on the first monday each month will be either 23:30 UTC of=
=20
the first sunday, or of the last sunday of the previous month. I don't see=
=20
any way to represent this as a RRULE in UTC.

So, to be correct, all recurrence calculation need to be done in the origin=
al=20
time zone of the event, and only then can the results be translated to the=
=20
time zone of the presentation layer.

Reinhold
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain=
er

--nextPart1517890.xD8ELjkDY0
Content-Type: application/pgp-signature

--nextPart1517890.xD8ELjkDY0--

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 21:36:57 +0200
To: [email-masked]

On Oct 13, 2004, at 18:48, Reinhold Kainhofer wrote:
> On Wednesday 13 October 2004 18:14, Reinhold Kainhofer wrote:
>> I don't think RRULES can work without some information about the time 
>> zone.
> ... which gives me an idea: How about moving the TZID parameter from 
> the
> DTSTART to the RRULE (and RDATEs)?

This is something I suggested before. The only, but significant, 
problem is that this will break compatibility with existing solutions.
I fear the latter might be a very valid reason to keep it like it is.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Wed, 13 Oct 2004 15:11:27 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Swanson <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Cc: 

Hi Mark,

--On Wednesday, October 13, 2004 2:47 PM -0400 Mark Swanson 
<[email-masked]> wrote:

>> Of course, but the presentation layer needs to know that the event was
>> created in (and is intended for) "Candian/Eastern" time.
>
> Perhaps "(and is intended for)" is also a key factor. F.E. I assume that
> someone flying to Vancouver for a meeting would ask his presentation
> layer to  display his events for that day in the Pacific timezone. I
> believe this to be  logical.

The timezone needed for 'presentation' may well be different than the 
timezone needed when editing an event. Consider: I am in EST timezone but 
want to schedule an event for a meeting next week on the west coast in PST 
- so I create the event and set the start to 12:00 pm PST - note that I 
edit it in PST not my current 'presentation' timezone of EST. If at some 
later point I want to edit it, the edit dialog should show the time in PST 
- not the current 'presentation' timezone, whatever that may be.

Thus timezone information does need to be included with event data - 
however that info only needs to be a 'hint' - the actual time can be stored 
in UTC.

Hence my earlier suggestion of having a 'TZHINT' parameter on times 
specified in UTC. That 'hint' is only needed is special circumstances, e.g. 
editing, rrule expansion - all other operations can be done with the UTC 
time without reference to it.

-- 
Cyrus Daboo

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 14:57:10 -0400

On October 13, 2004 12:14 pm, Reinhold Kainhofer wrote:
> Again use the example of my last mail: every monday at 01:30 in Timezone
> Europe/Vienna. If the start date is in summer time, the event is on sunday
> 23:30 UTC. No imagine somebody in the US views this event. The event start
> day will be on a sunday, so for the US person the event will only be

If your RRULE specifies weekly every Monday, the US person will see the Monday 
1 second after his DTSTART, so he will see the correct Monday.

-- 
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: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 14:47:47 -0400

On October 13, 2004 12:23 pm, Helge Hess wrote:
> On Oct 13, 2004, at 18:01, Mark Swanson wrote:
> >> How do you store a recurrence rule for "every monday 11:00 PST" in
> >> UTC?
> >> Due to DST shifts, 11:00 PST translates to different UTC values
> >> depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC
> >> (UTC-6) in summer).
> >
> > The key is in DTSTART. Since you have a UTC value at an instance of
> > time you
> > can compensate for the changing timezone offsets at any set instance
> > in the
> > future.
>
> Yes, if you know the timezone the event was created in. Or in other
> words, you can save the time values in any timezone, including UTC, but
> you need to specify the timezone required for DST and historic
> calculations.

It involves some work, but there is a way to do it without having to know what 
timezone the event is created in.

> > The key is the fact that the presentation layer can convert 11:00am
> > April 22,
> > 2004 Canadian/Eastern into a UTC value and back again.
>
> Of course, but the presentation layer needs to know that the event was
> created in (and is intended for) "Candian/Eastern" time.

Perhaps "(and is intended for)" is also a key factor. F.E. I assume that 
someone flying to Vancouver for a meeting would ask his presentation layer to 
display his events for that day in the Pacific timezone. I believe this to be 
logical.

> An "each Monday at 11:00 MST" is different to "each Monday at 23:00
> CET" even though the UTC starttime might match (DST rules are
> different, so a German flying to Arizona for a meeting at 11:00 MST
> will arrive at the incorrect time).

Still a presentation issue. Perhaps this will help:

1. TZ=PST, recurring monday meeting: 11:00AM created by Joe
2. TZ=EST, Bob's calendar shows a 2:00PM recurring monday meeting.
3. Bob flies to the PST timezone, and sets his presentation timezone to PST, 
which shows his meeting at 11:00AM.

If that isn't the issue Helge/Reinhold, perhaps it's a deeper issue of how 
some folks are creating instances of the recurrence set from the 
DTSTART/RRULE definition.

Cheers.

-- 
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: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 14:24:21 -0400

On October 13, 2004 12:14 pm, Reinhold Kainhofer wrote:
> On Wednesday 13 October 2004 18:01, Mark Swanson wrote:
> > The key is in DTSTART. Since you have a UTC value at an instance of time
> > you can compensate for the changing timezone offsets at any set instance
> > in the future.
> > The key is the fact that the presentation layer can convert 11:00am April
> > 22, 2004 Canadian/Eastern into a UTC value and back again.
>
> Ahm, for two persons in two different time zones this will not work.

It does. We'll get to it in a couple of emails I'm sure.

> Again use the example of my last mail: every monday at 01:30 in Timezone
> Europe/Vienna. If the start date is in summer time, the event is on sunday
> 23:30 UTC. No imagine somebody in the US views this event. The event start
> day will be on a sunday, so for the US person the event will only be
> displayed on the following monday, which is one day after it was actually
> supposed to happen...

I'd like to pick a different example because I read this as: you say the event 
is on Monday, then you say the US person viewing the event on a Monday is the 
wrong day? (or did you mean in 8 days as the following Monday?)

Next emai...

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

To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
From: [email-masked]
Date: Wed, 13 Oct 2004 12:57:39 -0400
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format...

--=_mixed 005D294285256F2C_=
Content-Type: multipart/alternative;
	boundary="=_alternative 005D294685256F2C_="

--=_alternative 005D294685256F2C_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

You have to read the DTSTART to correctly process the RRULE so leave TZID 
where it is.

Reinhold Kainhofer <[email-masked]> 
Sent by: [email-masked]
10/13/2004 12:48 PM

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] RRULEs, TimeZones

On Wednesday 13 October 2004 18:14, Reinhold Kainhofer wrote:
> I don't think RRULES can work without some information about the time 
zone.

... which gives me an idea: How about moving the TZID parameter from the 
DTSTART to the RRULE (and RDATEs)?

I'm not aware of any other places in rfc2445, that depend on the timezone 
information, so this might put the timezone problem with recurrence rules 
to 
the place it actually belongs to: To the recurrence rules.

It will be nasty to implement in GUIs, but that nastiness is already 
there... 
Basically, the user would have to specify the rrule in some timezone, and 
if 
somebody else uses a different timezone, he'll have to change the rrule in 

the original timezone, so although the event might appear at 11:30 on 
Sunday 
in his calendar, the recurrence rule might still be set to recur on 01:30 
on 
Monday (but in CEST)... 
>From a usability standpoint this is not the ideal solution, but we have 
the 
same problem at the moment, too. Actually, KOrganizer doesn't handle this 
situation well at the moment. How do other CUAs behave in that respect?

Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, 
http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot 
maintainer
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--=_alternative 005D294685256F2C_=--

--=_mixed 005D294285256F2C_=
Content-Type: application/octet-stream; name="attxokfw.dat"
Content-Disposition: attachment; filename="attxokfw.dat"
Content-Transfer-Encoding: base64

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBH
IHYxLjIuNSAoR05VL0xpbnV4KQ0KDQppRDhEQlFCQmJWeFBUcWpFd2hYdlBO
MFJBa2h6QUtEWDBMY294QStKeStrSHRQY2pScEZ0TFBTTDZnQ2FBemFvDQo4
Zk8zYytlYktWZ0NmTEQ5ck5jaWhFZz0NCj04Z3NCDQotLS0tLUVORCBQR1Ag
U0lHTkFUVVJFLS0tLS0NCg==

--=_mixed 005D294285256F2C_=--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 18:48:13 +0200

--nextPart1446937.6jAROLxlbu
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 13 October 2004 18:14, Reinhold Kainhofer wrote:
> I don't think RRULES can work without some information about the time zon=
e.

=2E.. which gives me an idea: How about moving the TZID parameter from the=
=20
DTSTART to the RRULE (and RDATEs)?

I'm not aware of any other places in rfc2445, that depend on the timezone=20
information, so this might put the timezone problem with recurrence rules t=
o=20
the place it actually belongs to: To the recurrence rules.

It will be nasty to implement in GUIs, but that nastiness is already there.=
=2E.=20
Basically, the user would have to specify the rrule in some timezone, and i=
f=20
somebody else uses a different timezone, he'll have to change the rrule in=
=20
the original timezone, so although the event might appear at 11:30 on Sunda=
y=20
in his calendar, the recurrence rule might still be set to recur on 01:30 o=
n=20
Monday (but in CEST)...=20
=46rom a usability standpoint this is not the ideal solution, but we have t=
he=20
same problem at the moment, too. Actually, KOrganizer doesn't handle this=20
situation well at the moment. How do other CUAs behave in that respect?

Reinhold
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart1446937.6jAROLxlbu
Content-Type: application/pgp-signature

--nextPart1446937.6jAROLxlbu--

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 18:23:03 +0200
To: [email-masked]

On Oct 13, 2004, at 18:01, Mark Swanson wrote:
>> How do you store a recurrence rule for "every monday 11:00 PST" in 
>> UTC?
>> Due to DST shifts, 11:00 PST translates to different UTC values
>> depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC
>> (UTC-6) in summer).
>
> The key is in DTSTART. Since you have a UTC value at an instance of 
> time you
> can compensate for the changing timezone offsets at any set instance 
> in the
> future.

Yes, if you know the timezone the event was created in. Or in other 
words, you can save the time values in any timezone, including UTC, but 
you need to specify the timezone required for DST and historic 
calculations.

> The key is the fact that the presentation layer can convert 11:00am 
> April 22,
> 2004 Canadian/Eastern into a UTC value and back again.

Of course, but the presentation layer needs to know that the event was 
created in (and is intended for) "Candian/Eastern" time.
An "each Monday at 11:00 MST" is different to "each Monday at 23:00 
CET" even though the UTC starttime might match (DST rules are 
different, so a German flying to Arizona for a meeting at 11:00 MST 
will arrive at the incorrect time).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 18:14:35 +0200

--nextPart3480088.jZzOb4mufg
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 13 October 2004 18:01, Mark Swanson wrote:
> The key is in DTSTART. Since you have a UTC value at an instance of time
> you can compensate for the changing timezone offsets at any set instance =
in
> the future.
> The key is the fact that the presentation layer can convert 11:00am April
> 22, 2004 Canadian/Eastern into a UTC value and back again.

Ahm, for two persons in two different time zones this will not work.

Again use the example of my last mail: every monday at 01:30 in Timezone=20
Europe/Vienna. If the start date is in summer time, the event is on sunday=
=20
23:30 UTC. No imagine somebody in the US views this event. The event start=
=20
day will be on a sunday, so for the US person the event will only be=20
displayed on the following monday, which is one day after it was actually=20
supposed to happen...=20
I don't think RRULES can work without some information about the time zone.

Reinhold

PS: Yes, his is a borderline-case, but a spec, which doesn't get the=20
borderline cases correct, is next to useless.
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer

--nextPart3480088.jZzOb4mufg
Content-Type: application/pgp-signature

--nextPart3480088.jZzOb4mufg--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 18:01:17 +0200

--nextPart1991365.nDJtpEQdJK
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 13 October 2004 16:21, Mark Swanson wrote:
> RRULEs already work fine when you strictly use UTC. TimeZone support is
> purely a presentation issue and does not belong in RFC 2445.

Ahm, it's not that easy. Assume you want a recurring event each monday at=20
01:30. During summer time this is (I'm in Austria, so central European Summ=
er=20
time, UTC+02:00) 23:30 on the previous sunday, in winter time this is 00:30=
=20
on the monday. The recurrence rule will have to state that it's 01:30 local=
=20
time each monday. You just cannot express this as a RRULE in UTC...

Reinhold

--nextPart1991365.nDJtpEQdJK
Content-Type: application/pgp-signature

--nextPart1991365.nDJtpEQdJK--

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 12:01:20 -0400

On October 13, 2004 10:45 am, Helge Hess wrote:
> On Oct 13, 2004, at 16:21, Mark Swanson wrote:
> > RRULEs already work fine when you strictly use UTC. TimeZone support
> > is purely
> > a presentation issue and does not belong in RFC 2445.
>
> How do you store a recurrence rule for "every monday 11:00 PST" in UTC?
> Due to DST shifts, 11:00 PST translates to different UTC values
> depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC
> (UTC-6) in summer).

The key is in DTSTART. Since you have a UTC value at an instance of time you 
can compensate for the changing timezone offsets at any set instance in the 
future. 
The key is the fact that the presentation layer can convert 11:00am April 22, 
2004 Canadian/Eastern into a UTC value and back again.

Cheers.

-- 
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: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] RRULEs, TimeZones
Date: Wed, 13 Oct 2004 16:45:39 +0200
To: [email-masked]

On Oct 13, 2004, at 16:21, Mark Swanson wrote:
> RRULEs already work fine when you strictly use UTC. TimeZone support 
> is purely
> a presentation issue and does not belong in RFC 2445.

How do you store a recurrence rule for "every monday 11:00 PST" in UTC? 
Due to DST shifts, 11:00 PST translates to different UTC values 
depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC 
(UTC-6) in summer).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 16:31:09 +0200
To: [email-masked]

On Oct 13, 2004, at 15:56, Reinhold Kainhofer wrote:
> Why is it so clear that RRULE needs to be removed?

There was a long discussion on that (UTC+RRULE) issue some weeks back 
and I had the impression that everyone agreed.

> Sure, moving to UTC would be great, but recurrence rules are such a 
> core feature to (almost) all calendar GUIs, that I don't think 
> sacrificing rrules for UTC is really
> warranted.

Recurring appointments can be done in various ways and there are 
several servers (actually almost all OpenSource servers are in that 
category!) which store recurring events as a finite set of individual 
(but connected) events for good reasons.

So, removing RRULE's improves interoperability because it matches 
non-iCal-like-RRULE servers and clients, avoids differences in RRULE 
support, and it removes a huge complexity because timezones can be 
dropped.

> For pure invitation handling, RRULEs might not be absolutely 
> necessary, but
> remember that many applications use iCalendar as their native storage 
> format
> (for example, KOrganizer, Evolution, KPilot's calendar conduits, etc.).

As mentioned before I definitely agree that RRULE's should not be 
dropped, just moved out of the core specification.
So you can still use iCalendar+RRULE-ext as the native storage format 
(nothing will change for you!).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Date: Wed, 13 Oct 2004 10:21:34 -0400
Subject: [Ietf-calsify] RRULEs, TimeZones

On October 13, 2004 8:33 am, [email-masked] wrote:
> I agree, it would be _really_ useful to have a (maintained) chart
> which outlines what RRULE features are supported by what
> implementation. Based on that chart it would be possible to make a rational
> choice of which RRULE features belong to the core specification and
> which ones not.
>
> Any ideas of how we could practically start creating this kind of a chart?

ScheduleWorld supports the entire RRULE definition.

ScheduleWorld also uses UTC for everything internally. This has greatly eased 
interoperability with limited devices and simplified the J2ME client.

RRULEs already work fine when you strictly use UTC. TimeZone support is purely 
a presentation issue and does not belong in RFC 2445.

Cheers.

-- 
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: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 15:56:56 +0200

--nextPart1270986.pGm1uimyFn
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 13 October 2004 14:45, Helge Hess wrote:
> On Oct 13, 2004, at 14:33, <[email-masked]> wrote:
> > I agree, it would be _really_ useful to have a (maintained) chart
> > which outlines what RRULE features are supported by what
> > implementation.=20

Yes, I'd like to have such a table too. Here's the current support of KDE=20
(libkcal as the base library, which supports more than KOrganizer as the=20
corresponding GUI. libkcal is also used by other applications like KPilot's=
=20
calendar conduits, the time tracking application KArm, and KNotes). I'll ha=
ve=20
to distinguish betwen KOrganizer (which provides less gui options) and=20
libkcal (which supports almost all BY* rule, although you cannot create the=
m=20
in korganizer):

libkcal does understand and can handle the following BY* rules (not all=20
combinations are understood, though. The ones neede by korganizer below are=
=20
of course best supported):
BYSECOND: somewhat
BYMINUTE: YES
BYHOUR: YES
BYDAY: YES
BYMONTHDAY: YES
BYYEARDAY: YES
BYWEEKNO: NO
BYMONTH: YES
BYSETPOS: No (but is planned, needed for first/last weekday of a month)

In KOrganizer's GUI we support the following recurrence options:
Daily: FREQ=3DDAILY
Weekly: FREQ=3DWEEKLY;BYDAY=3D...
Monthly: FREQ=3DMONTHLY
  -) on the n-th (mon|tues|..)day: BYDAY=3D...=20
  -) on the n-th day: BYMONTHDAY=3D...
Yearly: FREQ=3DYEARLY
  -) On the n-th day of month Y: BYMONTHDAY=3D11;BYMONTH=3D10
  -) On the n-th (mon|tues|..)day of Month Y:BYDAY=3D2MO;BYMONTH=3D10
  -) On the n-th day of the year: BYYEARDAY=3D285

All other recurrence rules understood by libkcal are shown in KOrganizer (i=
f=20
the FREQ>=3DDAILY), but cannot be edited.

> > Based on that chart it would be possible to make a=20
> > rational
> > choice of which RRULE features belong to the core specification and
> > which ones not.
>
> I think its already more or less clear that RRULE needs to be removed
> completely from the core spec so that we can move to UTC for the base
> spec.

Why is it so clear that RRULE needs to be removed? Sure, moving to UTC woul=
d=20
be great, but recurrence rules are such a core feature to (almost) all=20
calendar GUIs, that I don't think sacrificing rrules for UTC is really=20
warranted.=20
=46or pure invitation handling, RRULEs might not be absolutely necessary, b=
ut=20
remember that many applications use iCalendar as their native storage forma=
t=20
(for example, KOrganizer, Evolution, KPilot's calendar conduits, etc.).=20

I think it really depends on whether iCalendar is supposed to be a format=20
purely intended for invitation handling, or also as a storage format.=20
Currently, I think it's the latter, and there removing all recurrence rules=
=20
in the core spec is like removing all paragraph format settings in a word=20
processing format spec.

Reinhold

--nextPart1270986.pGm1uimyFn
Content-Type: application/pgp-signature

--nextPart1270986.pGm1uimyFn--

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 14:45:26 +0200
To: "<[email-masked]> <[email-masked]>" <[email-masked]>

On Oct 13, 2004, at 14:33, <[email-masked]> wrote:
> I agree, it would be _really_ useful to have a (maintained) chart
> which outlines what RRULE features are supported by what
> implementation. Based on that chart it would be possible to make a 
> rational
> choice of which RRULE features belong to the core specification and
> which ones not.

I think its already more or less clear that RRULE needs to be removed 
completely from the core spec so that we can move to UTC for the base 
spec.

An interesting question is whether the RRULE extension needs to have 
additional "levels" for basic / complex RRULE support.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 15:33:11 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

I agree, it would be _really_ useful to have a (maintained) chart 
which outlines what RRULE features are supported by what 
implementation. Based on that chart it would be possible to make a rational 
choice of which RRULE features belong to the core specification and 
which ones not.

Any ideas of how we could practically start creating this kind of a chart?

Best Regards, 
Veikko

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Helge
> Hess
> Sent: 13 October, 2004 14:15
> To: <[email-masked]> <[email-masked]>
> Subject: Re: [Ietf-calsify] (no subject)
> 
> 
> On Oct 13, 2004, at 8:12, <[email-masked]> wrote:
> > If you now start sending each occurence as a single VEVENT
> > with some other thing to keep them related (not necessarily 
> supported
> > by current clients), how do you think that will make you reach 
> > interoperability
> > sooner?
> 
> The huge majority of available systems are not interoperable at all. 
> Reducing complexity will make it much easier for those systems to 
> implement iCal and to ensure interoperability at a certain 
> level. This 
> level might not be sufficient for you, but it will improve the 
> situation for a lot of other users of scheduling software.
> 
> On the other side we should not break existing applications (you are 
> certainly correct that some implementations probably support 100% of 
> RRULE's). IMHO if we remove RRULE's from the core spec, we should _at 
> the same time_ have an extension spec available which implements 
> 'traditional' RRULE's.
> 
> Besides that it would be _really_ useful to have a (maintained) chart 
> which outlines what RRULE features are supported by what 
> implementation. So far I have only seen pretty broad 
> statements like "4 
> of 5 implements X".
> 
> best regards,
>    Helge
> -- 
> http://docs.opengroupware.org/Members/helge/
> OpenGroupware.org
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 13:15:13 +0200
To: "<[email-masked]> <[email-masked]>" <[email-masked]>

On Oct 13, 2004, at 8:12, <[email-masked]> wrote:
> If you now start sending each occurence as a single VEVENT
> with some other thing to keep them related (not necessarily supported
> by current clients), how do you think that will make you reach 
> interoperability
> sooner?

The huge majority of available systems are not interoperable at all. 
Reducing complexity will make it much easier for those systems to 
implement iCal and to ensure interoperability at a certain level. This 
level might not be sufficient for you, but it will improve the 
situation for a lot of other users of scheduling software.

On the other side we should not break existing applications (you are 
certainly correct that some implementations probably support 100% of 
RRULE's). IMHO if we remove RRULE's from the core spec, we should _at 
the same time_ have an extension spec available which implements 
'traditional' RRULE's.

Besides that it would be _really_ useful to have a (maintained) chart 
which outlines what RRULE features are supported by what 
implementation. So far I have only seen pretty broad statements like "4 
of 5 implements X".

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] (no subject)
Date: Wed, 13 Oct 2004 09:12:42 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

It sounds like you would be sacrificing a lot of other things at the
same time. Let me explain my own situation. I have my calendar data
on multiple devices (a PC, a bigger mobile phone I carry around at work, 
a smaller mobile phone I carry around at leisure). I synchronise the
devices periodically so that they keep in sync to each other and I use
all the devices to enter and view events in the calendar. In my calendar I
have several things that repeat: anniversaries, weekly meetings, etc.
Sometimes they do not have a specific end date, while other times they do
(say for example the projected duration of a project). Occasionally I need 
to modify these repeating things. The time of the weekly meeting may change,
or it may be changed to a biweekly meeting or the end date of the project has 
slipped and so the end date of the repeat changes. I want to do these changes from 
any one of my devices without having to go through every occurence of that 
repeating thing. For that I need a reliable synchronisation method that keeps
those repeating things related. Most of current implementations I use do
this by sending the repeating things as a single VEVENT with a RRULE
that is used to calculate the occurences of the thing in each of the
devices. If you now start sending each occurence as a single VEVENT
with some other thing to keep them related (not necessarily supported
by current clients), how do you think that will make you reach interoperability
sooner?

Veikko Punkka

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: 13 October, 2004 04:28
> To: [email-masked]
> Subject: Re: [Ietf-calsify] (no subject)
> 
> 
> Sorry - I was unclear. What I meant to say was, for 
> iCal-Basic or whatever 
> we're calling it, that a set of VEVENTs instead of using 
> RRULEs would work 
> for me, if it means that interoperability comes sooner.  It 
> sacrifices the 
> "every week forever" kind of event, but if my client and/or 
> server can 
> compute and send "every week until my projected retirement 
> date" that's 
> sufficient :-)
> 
> At 09:21 AM 10/12/04, Doug Royer wrote:
> 
> 
> >What do you mean by "single VEVENT"?
> >Do you mean that we need to start with VEVENTs?
> >
> >--
> >
> >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
> 

Date: Tue, 12 Oct 2004 21:27:37 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] (no subject)

Sorry - I was unclear. What I meant to say was, for iCal-Basic or whatever 
we're calling it, that a set of VEVENTs instead of using RRULEs would work 
for me, if it means that interoperability comes sooner.  It sacrifices the 
"every week forever" kind of event, but if my client and/or server can 
compute and send "every week until my projected retirement date" that's 
sufficient :-)

At 09:21 AM 10/12/04, Doug Royer wrote:

>What do you mean by "single VEVENT"?
>Do you mean that we need to start with VEVENTs?
>
>--
>
>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. 

Date: Tue, 12 Oct 2004 07:47:29 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULE options - VEVENT
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2004 13:47:37 -0000

This is a cryptographically signed message in MIME format.

--------------ms090502050901090008030103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

What does everyone think?

    A) Disallow all RRULEs  in a VEVENT?

    B) Allow only a simplified RRULE in  a VEVENT?

    C) Allow only one RRULE (simple or not) per VEVENT?

    D) Allow EXRULE ?

    E) Allow EXDATE?

    F) Allow RDATE?

Notes from my searching calendaring tools:

    1) All implementations can do simple non-repeating VEVENTs.
         This also includes non iCAL calendaring tools.

    2) All iCAL implementations that I can find can do:
             Daily, Weekly, Monthly

    3) Many allow:
             Yearly

    4) Many allow:
             Nth day of month.

    5)  Of the ones that allow recurring rules, all that I can find allow
           one or more of the recurring instances to be removed.

    6) Of (5) only one does it without EXDATE. And that implementation
         can not export its entries in way that almost all other 
implementations
         can import. It uses a list of objects that have to be recreated 
in order.

-- 

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

--------------ms090502050901090008030103
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090502050901090008030103--

Date: Tue, 12 Oct 2004 07:21:19 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] (no subject)
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2004 13:21:28 -0000

This is a cryptographically signed message in MIME format.

--------------ms040903040503020705060509
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

>
> I heartily agree with this - and in thinking about it, I think my 
> discussions on retaining simple recurrence rules might also need to 
> fall by the wayside. Exchanging only single VEVENTs would definitely 
> bring about interoperability between diverse implementations, which is 
> one thing that is desperately needed, and has been for at least a 
> decade - I remember discussing this stuff at SHARE 
> (http://www.share.org) in the early 1990's. 

What do you mean by "single VEVENT"?
Do you mean that we need to start with VEVENTs?

-- 

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

--------------ms040903040503020705060509
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040903040503020705060509--

Date: Tue, 12 Oct 2004 08:03:45 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] (no subject)

Cameron Stillion wrote, in part:

"... This is not to say we should paint ourselves into a corner in the most
fundamental ways, but it does mean we need to start small, get something
basic that we all can agree to, grow some real interoperability, and
THEN we can start tinkering with how to extend the standard to the
zillion other applications and possibilities. "

I heartily agree with this - and in thinking about it, I think my 
discussions on retaining simple recurrence rules might also need to fall by 
the wayside. Exchanging only single VEVENTs would definitely bring about 
interoperability between diverse implementations, which is one thing that 
is desperately needed, and has been for at least a decade - I remember 
discussing this stuff at SHARE (http://www.share.org) in the early 1990's.

I think our focus needs to narrow to: simplify to the point that 
individuals and organizations can begin to schedule with each other, no 
matter what platform they're using.   While it may seem counter-intuitive, 
I believe that this will benefit those who are vendors - I know what a boon 
it would be if my employer could schedule meetings with the many 
contractors and consultants we use. We have limited capability in that area 
now - if they have Outlook/Exchange and we have Notes, for example, there's 
some interoperability - but if a small contractor uses something like Yahoo 
for his calendaring, we may be out of luck (I say "may be" because I 
haven't researched it).

Tim Hare
Interested Bystander, Non-Inc. 

Date: Tue, 12 Oct 2004 07:54:08 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] Re: XML format?
Cc: [email-masked]

I believe XML has a lot of benefit for calendaring, also (one of the 
reasons for 
http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt). I am NO 
expert in XML but I am a believer in the benefits of markup from a long 
time ago.

I think, however, that if we're going to discuss it, we need another 
mailing list. I wouldn't want to muddle "iCalendar simplification" with 
"redoing the calendaring idea".  The RDFiCalendar folks should be invited 
as well since they've already got an XML implementation, and they tried to 
build "round-tripping" tools between that and iCalendar. My only issue with 
their implementation so far is that "I'm just a simple caveman..." and the 
theoretical aspects of why they choose to do things in certain ways,  have 
escaped me so far.

At 07:37 PM 10/11/04, Lisa Dusseault wrote:
>Peter's mail reminded me that whenever I talk about calendaring standards 
>outside the group of calendaring implementors, people always ask about an 
>XML format for calendar data.  For example, Paul Hoffman explained to me 
>last week why Atom (blog feed format) would only use XML but that if 
>iCalendar had some XML data format standards they would be happy to be 
>compliant with that for dates, durations, attendee lists or what have you.
>
>Doing a non-backward-compatible switch from iCalendar 1.0 to something 
>XML-based would certainly have a big switchover cost in calendaring 
>software.  But moving to XML would certainly have long-term synergy with 
>other standards groups, benefits in terms of fewer format parsers, greater 
>flexibility and greater interoperability.  I don't even know how we can 
>estimate when the benefits outweigh the costs, or at what rate the costs 
>would be amortized, but it does seem clear to me that the switchover cost 
>is more temporary while the benefits are longer lasting.
>
>Lisa
>
>On Oct 11, 2004, at 4:14 PM, Peter Saint-Andre wrote:
>
>>In article <[email-masked]>,
>>  [email-masked] wrote:
>>
>>>Please look at:
>>>http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt
>>>
>>>Suggestions and opinions are appreciated.
>>
>>In Section 8, you recommend using the HTTP URIs of the RFCs as XML
>>namespace names. This is potentially problematic (what happens when ther
>>are superseded?). I'd suggest XML namespace URIs in the
>>urn:ietf:params:xml:ns tree (RFC 3920 is a recent spec that uses these).
>>
>>In Section 9, your media types are off -- "application/calendar+xml" is
>>more correct. http://www.xmpp.org/specs/rfc3923.html#iana has an example
>>of a recent content-type registration of this kind. When the time comes,
>>don't forget to run your definition by the friendly folks on the
>>ietf-types list: http://www.alvestrand.no/mailman/listinfo/ietf-types
>>
>>In Section 11.1 you define a DTD. That's so old-fashioned -- all the
>>cool kids are using XML schema these days. ;-)
>>
>>That's about as far as I got. It'll be great to have an XML format for
>>calendar objects!
>>
>>Peter
>>
>>P.S. Given some of the layout oddities, it seems that perhaps you did
>>not use the XML RFC format; http://xml.resource.org/ tells you how and
>>it is highly recommended!
>>
>>_______________________________________________
>>Ietf-calsify mailing list
>>[email-masked]
>>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

From: Michael R Gettes <[email-masked]>
Subject: Re: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
Date: Mon, 11 Oct 2004 19:54:24 -0400
To: "Cameron Stillion" <[email-masked]>
Cc: [email-masked], [email-masked]

Is it reasonable to suggest community based ical or task
oriented ical?  People oriented systems might be able to
limit one set of abilities within the spec whereas others,
such as computing clusters and other areas, could use
forms of ical that allow them to their jobs as well.
Creating namespaces for ical specifications would seem
to be a logical thing to do.  Well known namespaces have
well defined specs and uses -- this allows for local
namespaces to implement other aspects of ical.

Just a thought...

/mrg

On Oct 11, 2004, at 19:30, Cameron Stillion wrote:

>
> I respectfully disagree.  Leaving a standard "as open as possible" can
> easily lead to such difficulties in interoperability as we have all
> witnessed over the past several years.  The idea for calsify, I 
> believe,
> is to actually curb the open-ended nature of iCal in favor of the more
> practical bottom line: something that works for a subset that we really
> really care about.
>
> This is not uncommon in software development, it's just that iCal is
> long due for such a refocus and simplification.  It's not so much a
> matter of Social Restrictions - it's just that the kinds of systems we
> are creating have a general purpose to them, and it is centered around
> creating calendars, sharing calendars, scheduling meetings, and other
> simple day-to-day things.  Aligning stellar cartography hardware and
> synchronizing atomic clocks are most definitely on the ragged outer 
> edge
> of our target.
>
> This is not to say we should paint ourselves into a corner in the most
> fundamental ways, but it does mean we need to start small, get 
> something
> basic that we all can agree to, grow some real interoperability, and
> THEN we can start tinkering with how to extend the standard to the
> zillion other applications and possibilities.
>
> As for your specific example -- "granularity", I can easily see a
> property emerge in a future version of iCal that specified 
> sub-15-minute
> granularity.  This would not break clients who didn't care (most of
> them, IMHO) and would be easily read and interpreted by those who did.
>
> Let's avoid getting wrapped around the axle of creating "the perfect
> calendaring standard" - I'm just hoping we can get something simple 
> that
> kind of works without too much pain and suffering.
>
>
> Cameron
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Lyndon
> Nerenberg
> Sent: Saturday, October 09, 2004 9:57 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
>
> --On 2004-10-6 10:25 PM -0400 [email-masked] 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
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Re: XML format?
Date: Mon, 11 Oct 2004 16:37:50 -0700
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]

Peter's mail reminded me that whenever I talk about calendaring 
standards outside the group of calendaring implementors, people always 
ask about an XML format for calendar data.  For example, Paul Hoffman 
explained to me last week why Atom (blog feed format) would only use 
XML but that if iCalendar had some XML data format standards they would 
be happy to be compliant with that for dates, durations, attendee lists 
or what have you.

Doing a non-backward-compatible switch from iCalendar 1.0 to something 
XML-based would certainly have a big switchover cost in calendaring 
software.  But moving to XML would certainly have long-term synergy 
with other standards groups, benefits in terms of fewer format parsers, 
greater flexibility and greater interoperability.  I don't even know 
how we can estimate when the benefits outweigh the costs, or at what 
rate the costs would be amortized, but it does seem clear to me that 
the switchover cost is more temporary while the benefits are longer 
lasting.

Lisa

On Oct 11, 2004, at 4:14 PM, Peter Saint-Andre wrote:

> In article <[email-masked]>,
>  [email-masked] wrote:
>
>> Please look at:
>> http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt
>>
>> Suggestions and opinions are appreciated.
>
> In Section 8, you recommend using the HTTP URIs of the RFCs as XML
> namespace names. This is potentially problematic (what happens when 
> ther
> are superseded?). I'd suggest XML namespace URIs in the
> urn:ietf:params:xml:ns tree (RFC 3920 is a recent spec that uses 
> these).
>
> In Section 9, your media types are off -- "application/calendar+xml" is
> more correct. http://www.xmpp.org/specs/rfc3923.html#iana has an 
> example
> of a recent content-type registration of this kind. When the time 
> comes,
> don't forget to run your definition by the friendly folks on the
> ietf-types list: http://www.alvestrand.no/mailman/listinfo/ietf-types
>
> In Section 11.1 you define a DTD. That's so old-fashioned -- all the
> cool kids are using XML schema these days. ;-)
>
> That's about as far as I got. It'll be great to have an XML format for
> calendar objects!
>
> Peter
>
> P.S. Given some of the layout oddities, it seems that perhaps you did
> not use the XML RFC format; http://xml.resource.org/ tells you how and
> it is highly recommended!
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
Date: Mon, 11 Oct 2004 16:30:10 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Lyndon Nerenberg" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: 

I respectfully disagree.  Leaving a standard "as open as possible" can
easily lead to such difficulties in interoperability as we have all
witnessed over the past several years.  The idea for calsify, I believe,
is to actually curb the open-ended nature of iCal in favor of the more
practical bottom line: something that works for a subset that we really
really care about.

This is not uncommon in software development, it's just that iCal is
long due for such a refocus and simplification.  It's not so much a
matter of Social Restrictions - it's just that the kinds of systems we
are creating have a general purpose to them, and it is centered around
creating calendars, sharing calendars, scheduling meetings, and other
simple day-to-day things.  Aligning stellar cartography hardware and
synchronizing atomic clocks are most definitely on the ragged outer edge
of our target.   

This is not to say we should paint ourselves into a corner in the most
fundamental ways, but it does mean we need to start small, get something
basic that we all can agree to, grow some real interoperability, and
THEN we can start tinkering with how to extend the standard to the
zillion other applications and possibilities.

As for your specific example -- "granularity", I can easily see a
property emerge in a future version of iCal that specified sub-15-minute
granularity.  This would not break clients who didn't care (most of
them, IMHO) and would be easily read and interpreted by those who did.  

Let's avoid getting wrapped around the axle of creating "the perfect
calendaring standard" - I'm just hoping we can get something simple that
kind of works without too much pain and suffering.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lyndon
Nerenberg
Sent: Saturday, October 09, 2004 9:57 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02

--On 2004-10-6 10:25 PM -0400 [email-masked] 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
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: [email-masked]
From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Oct 2004 17:14:52 -0600
Organization: Jabber Software Foundation
Lines: 30
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: XML format?

In article <[email-masked]>,
 [email-masked] wrote:

> Please look at: 
> http://www.ietf.org/internet-drafts/draft-hare-xcalendar-01.txt
> 
> Suggestions and opinions are appreciated.

In Section 8, you recommend using the HTTP URIs of the RFCs as XML 
namespace names. This is potentially problematic (what happens when ther 
are superseded?). I'd suggest XML namespace URIs in the 
urn:ietf:params:xml:ns tree (RFC 3920 is a recent spec that uses these).

In Section 9, your media types are off -- "application/calendar+xml" is 
more correct. http://www.xmpp.org/specs/rfc3923.html#iana has an example 
of a recent content-type registration of this kind. When the time comes, 
don't forget to run your definition by the friendly folks on the 
ietf-types list: http://www.alvestrand.no/mailman/listinfo/ietf-types

In Section 11.1 you define a DTD. That's so old-fashioned -- all the 
cool kids are using XML schema these days. ;-)

That's about as far as I got. It'll be great to have an XML format for 
calendar objects!

Peter

P.S. Given some of the layout oddities, it seems that perhaps you did 
not use the XML RFC format; http://xml.resource.org/ tells you how and 
it is highly recommended!

Date: Sun, 10 Oct 2004 08:50:55 -0400
To: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
From: [email-masked]
Cc: 
Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02

After several comments, I can see that exchanging a "bit map" of free/busy 
time has definite downsides,  so let's drop that idea.
Also, rather than continuing to cross-post I will put further discussion of 
how to simplify free/busy work  on the calsify list rather than caldav.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Sat, 09 Oct 2004 21:57:02 -0700
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: 
Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02

--On 2004-10-6 10:25 PM -0400 [email-masked] 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

Date: Thu, 07 Oct 2004 22:16:44 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Subject: [Ietf-calsify] Proposed TOC for new iCal-Basic draft
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 08 Oct 2004 04:16:56 -0000

This is a cryptographically signed message in MIME format.

--------------ms000306060902040204020406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
            3.4 Encoding Considerations
            3.5 Security Considerations
            3.6 Interoperability Considerations
            3.7 Applications Which Use This Media Type
            3.8 Additional Information
            3.9 Magic Numbers
            3.10 File Extensions
            3.11 Contact for Further Information:
            3.12 Intended Usage
            3.13 Authors/Change Controllers
           4 iCalendar Object Specification
            4.1 Content Lines
             4.1.1 List and Field Separators
             4.1.2 Multiple Values
             4.1.3 Binary Content
             4.1.4 Character Set
            4.2 Property Parameters
             4.2.1 Alternate Text Representation
             4.2.2 Common Name
             4.2.3 Calendar User Type
             4.2.4 Delegators
             4.2.5 Delegatees
             4.2.6 Directory Entry Reference
             4.2.7 Inline Encoding
             4.2.8 Format Type
             4.2.9 Free/Busy Time Type
             4.2.10 Language
             4.2.11 Group or List Membership
             4.2.12 Participation Status
             4.2.13 Recurrence Identifier Range

 D           4.2.14 Alarm Trigger Relationship
                (Document in VALARM RFC)

             4.2.15 Relationship Type
             4.2.16 Participation Role
             4.2.17 RSVP Expectation
             4.2.18 Sent By
             4.2.19 Time Zone Identifier
             4.2.20 Value Data Types
            4.3 Property Value Data Types
             4.3.1 Binary
             4.3.2 Boolean 
             4.3.3 Calendar User Address
             4.3.4 Date
             4.3.5 Date-Time
             4.3.6 Duration
             4.3.7 Float
             4.3.8 Integer
             4.3.9 Period of Time
             4.3.10 Recurrence Rule
             4.3.11 Text
             4.3.12 Time
             4.3.13 URI
             4.3.14 UTC Offset
            4.4 iCalendar Object
            4.5 Property
            4.6 Calendar Components
             4.6.1 Event Component
 
 D           4.6.2 To-do Component
                (Document in VTODO RFC)
 
 D           4.6.3 Journal Component 
                (Document in VJOURNAL RFC)

             4.6.4 Free/Busy Component
             4.6.5 Time Zone Component
 
 D           4.6.6 Alarm Component 
                (Document in VALARM RFC)

            4.7 Calendar Properties
             4.7.1 Calendar Scale
             4.7.2 Method 
             4.7.3 Product Identifier
             4.7.4 Version
            4.8 Component Properties
             4.8.1 Descriptive Component Properties
               4.8.1.1 Attachment
               4.8.1.2 Categories
               4.8.1.3 Classification
               4.8.1.4 Comment
               4.8.1.5 Description
 
 R             4.8.1.6 Geographic Position 
                (Delete this property - tag it as deprecated in iCal-Basic)

               4.8.1.7 Location
               4.8.1.8 Percent Complete
               4.8.1.9 Priority
               4.8.1.10 Resources
               4.8.1.11 Status
               4.8.1.12 Summary
             4.8.2 Date and Time Component Properties
               4.8.2.1 Date/Time Completed
               4.8.2.2 Date/Time End
               4.8.2.3 Date/Time Due
               4.8.2.4 Date/Time Start
               4.8.2.5 Duration
               4.8.2.6 Free/Busy Time
               4.8.2.7 Time Transparency
             4.8.3 Time Zone Component Properties
               4.8.3.1 Time Zone Identifier
               4.8.3.2 Time Zone Name
               4.8.3.3 Time Zone Offset From
               4.8.3.4 Time Zone Offset To
               4.8.3.5 Time Zone URL
             4.8.4 Relationship Component Properties
               4.8.4.1 Attendee
               4.8.4.2 Contact
               4.8.4.3 Organizer
               4.8.4.4 Recurrence ID

 R             4.8.4.5 Related To
                (Delete this property - tag it as deprecated - in 
iCal-Basic)

               4.8.4.6 Uniform Resource Locator
               4.8.4.7 Unique Identifier
             4.8.5 Recurrence Component Properties
               4.8.5.1 Exception Date/Times
               4.8.5.2 Exception Rule
               4.8.5.3 Recurrence Date/Times
               4.8.5.4 Recurrence Rule

 D           4.8.6 Alarm Component Properties
 D             4.8.6.1 Action
 D             4.8.6.2 Repeat Count
 D             4.8.6.3 Trigger
                (Document the above in VALARM RFC)

             4.8.7 Change Management Component Properties
               4.8.7.1 Date/Time Created
               4.8.7.2 Date/Time Stamp
               4.8.7.3 Last Modified
               4.8.7.4 Sequence Number
             4.8.8 Miscellaneous Component Properties
               4.8.8.1 Non-standard Properties
               4.8.8.2 Request Status
           5 iCalendar Object Examples
           6 Recommended Practices
           7 Registration of Content Type Elements
            7.1 Registration of New and Modified iCalendar Object 
Methods ..141
            7.2 Registration of New Properties
             7.2.1 Define the property
             7.2.2 Post the Property definition

            7.2.3 Allow a comment period
             7.2.4 Submit the property for approval
            7.3 Property Change Control

 N           x.x.x.x EXTENSIONS property
              (Document in iCal-Basic RFC)

-- 

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

--------------ms000306060902040204020406
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000306060902040204020406--

Date: Thu, 07 Oct 2004 11:36:10 -0600
From: Doug Royer <[email-masked]>
To: [email-masked], [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.45
Cc: 
Subject: [Ietf-calsify] Re: [Ietf-caldav] comments on -02
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2004 17:36:17 -0000

This is a cryptographically signed message in MIME format.

--------------ms070409010101090702000600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
-------------------------------|-----------------------------
[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

--------------ms070409010101090702000600
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070409010101090702000600--

From: Lisa Dusseault <[email-masked]>
Date: Wed, 6 Oct 2004 20:44:18 -0700
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: [Ietf-calsify] Re: [Ietf-caldav] 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, [email-masked] 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.
> 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.
>>
>> Having someone schedule you on Saturday or Sunday is really a social
>> problem though. If it is your wife, it makes sense.  If it's your
>> co-worker, then there are social checks and balances that say this 
>> won't
>> happen if it isn't appropriate.  The protocol is not meant to solve 
>> the
>> social aspect.  Clearly good software would keep this in mind and help
>> you do the right thing, but it can't know all the human 
>> implications...
>>
>> I still stand by the fact that free/busy is merely a translation of
>> events, and that anything else is unnecessarily complex with really no
>> benefit - to the standard most especially, but even more to 
>> applications
>> and systems.
>>
>>
>> cameron
>>
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of G. Barnes
>> Sent: Wednesday, October 06, 2004 10:26 AM
>> To: [email-masked]
>> Subject: Re: [Ietf-caldav] comments on -02
>>
>> On Wed, 6 Oct 2004, Lisa Dusseault wrote:
>>
>> > I could go either way on allowing users to store standalone 
>> VFREEBUSY
>> > components.  Keeping it is a small feature/flexibility; removing it 
>> is
>>
>> > a small simplification.  Who else has use cases or problems with
>> > keeping or removing that feature?
>>
>> I have a problem with removing it.  I want to be able to say, 'no one
>> can schedule me on Saturday or Sunday' (among other times).  Othewise,
>> some jerk is going to schedule a mandatory meeting at 7am Saturday.
>> Creating a VEVENT would presumably mean something shows up in my
>> calendar.
>> But I don't necessarily have an event scheduled; I just want to be 
>> left
>> alone.  The most obvious way to do this is to create a standalone
>> VFREEBUSY.
>>
>>                    Greg Barnes
>>                    Computing and Communications, University of
>> Washington
>>                    [email-masked]
>>                    (206) 685-3295
>> _______________________________________________
>> Ietf-caldav mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>>
>> _______________________________________________
>> Ietf-caldav mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

To: [email-masked]
From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Oct 2004 20:45:55 -0600
Organization: Jabber Software Foundation
Lines: 9
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: XML format?

In article <[email-masked]>,
 [email-masked] wrote:

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

Thanks, I'll have a look at that.

/psa

Date: Wed, 06 Oct 2004 22:27:37 -0400
To: Peter Saint-Andre <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] XML format?
Cc: 

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
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Date: Wed, 06 Oct 2004 22:25:15 -0400
To: <[email-masked]>, [email-masked]
From: [email-masked]
Cc: 
Subject: [Ietf-calsify] RE: [Ietf-caldav] 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.
>
>Having someone schedule you on Saturday or Sunday is really a social
>problem though. If it is your wife, it makes sense.  If it's your
>co-worker, then there are social checks and balances that say this won't
>happen if it isn't appropriate.  The protocol is not meant to solve the
>social aspect.  Clearly good software would keep this in mind and help
>you do the right thing, but it can't know all the human implications...
>
>I still stand by the fact that free/busy is merely a translation of
>events, and that anything else is unnecessarily complex with really no
>benefit - to the standard most especially, but even more to applications
>and systems.
>
>
>cameron
>
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of G. Barnes
>Sent: Wednesday, October 06, 2004 10:26 AM
>To: [email-masked]
>Subject: Re: [Ietf-caldav] comments on -02
>
>On Wed, 6 Oct 2004, Lisa Dusseault wrote:
>
> > I could go either way on allowing users to store standalone VFREEBUSY
> > components.  Keeping it is a small feature/flexibility; removing it is
>
> > a small simplification.  Who else has use cases or problems with
> > keeping or removing that feature?
>
>I have a problem with removing it.  I want to be able to say, 'no one
>can schedule me on Saturday or Sunday' (among other times).  Othewise,
>some jerk is going to schedule a mandatory meeting at 7am Saturday.
>Creating a VEVENT would presumably mean something shows up in my
>calendar.
>But I don't necessarily have an event scheduled; I just want to be left
>alone.  The most obvious way to do this is to create a standalone
>VFREEBUSY.
>
>                    Greg Barnes
>                    Computing and Communications, University of
>Washington
>                    [email-masked]
>                    (206) 685-3295
>_______________________________________________
>Ietf-caldav mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>_______________________________________________
>Ietf-caldav mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Tim Hare
Interested Bystander, Non-Inc. 

To: [email-masked]
From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Oct 2004 19:38:27 -0600
Organization: Jabber Software Foundation
Lines: 4
Sender: news <[email-masked]>
Subject: [Ietf-calsify] XML format?

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

Peter

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] UTC
Date: Sat, 2 Oct 2004 12:30:52 -0400
To: [email-masked]
Cc: [email-masked]

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