Subject: [Ietf-calsify] Proposed Charter

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Mon Mar 28 17:55:54 2005

Based on the discussion at the Calsify BOF in Minneapolis, a bunch of 
us (those who volunteered at the time) have worked on the draft WG 
charter below.

Some notes:
  - The iCalendar revision work, although it  may be challenging work, 
is at least well understood in terms of scope and deliverables.
  - The transition work which I attempted to characterize in a separate 
email is not so well scoped out and it's not clear yet what specific 
proposals might emerge, if any, so this charter would need to be 
revised when the specific proposals become clear or do not appear after 
a period.
  - The XML work which seemed to be supported in the BOF (but nobody 
actually took consensus) was not supported in the group of people 
working on this charter, so it appears as "out of scope".

-- Lisa 

----

Calendaring and Scheduling Standards Simplification (calsify)

Chair(s):
TBD

Applications Area Director(s):

Ted Hardie <[email-masked]>
Scott Hollenbeck <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: 
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/

Description of Working Group:

The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, 
and
2447 were released in November 1998, and further described in RFC 3283.
They were designed to progress the level of interoperability between
dissimilar calendaring and scheduling systems. The Calendaring and
Scheduling Core Object Specification, iCalendar, succeeded in 
establishing
itself as the common format for exchanging calendaring information 
across
the Internet. On the other hand, only basic interoperability as been 
achieved
between different scheduling systems.

The Calsify working group is chartered to:

(1) Publish the interoperability issues that have arisen between
     calendaring and scheduling systems, as well as document the usage of
     iCalendar by other specifications.

(2) Revise the Calendaring and Scheduling standards to advance the
     state of interoperable calendaring and scheduling by addressing
     the published interoperability issues. As far as it is possible, the
     working group will ensure backwards compatibility with widely 
deployed
     implementations and other specifications that use it.

(3) Clarify the registration process for iCalendar extensions (i.e.,
     the current core object specification only provides a template
     to register new properties).

(4) Advance the Calendaring and Scheduling standards to Draft Standard.

(5) Work on transition (upgrade or versioning) mechanisms for calendar
     data exchange.

Proposing an XML representation or transformation of iCalendar
objects is out of the scope of this working group.

Goals and Milestones:

TBD - Submit "Problems in Calendaring and Scheduling Standards".
TBD - Submit RFC2445bis.
TBD - Submit other revised documents.

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Mar 28 18:34:01 2005

I think this is great and THANKS for the hard work!

Lisa Dusseault wrote:
> Based on the discussion at the Calsify BOF in Minneapolis, a bunch of us 
> (those who volunteered at the time) have worked on the draft WG charter 
> below.
> 
> Some notes:
>  - The iCalendar revision work, although it  may be challenging work, is 
> at least well understood in terms of scope and deliverables.
> proposals might emerge, if any, so this charter would need to be revised 
> when the specific proposals become clear or do not appear after a period.

...

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Doug.vcf
Type: text/x-vcard
Size: 293 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050328/a5aed5ef/Doug.vcf

Date: Mon, 28 Mar 2005 19:33:53 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Proposed Charter
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------070200010605010704000605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I think this is great and THANKS for the hard work!

Lisa Dusseault wrote:
> Based on the discussion at the Calsify BOF in Minneapolis, a bunch of us 
> (those who volunteered at the time) have worked on the draft WG charter 
> below.
> 
> Some notes:
>  - The iCalendar revision work, although it  may be challenging work, is 
> at least well understood in terms of scope and deliverables.
> proposals might emerge, if any, so this charter would need to be revised 
> when the specific proposals become clear or do not appear after a period.

...

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070200010605010704000605
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------070200010605010704000605--

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Date: Mon, 28 Mar 2005 17:55:45 -0800
Subject: [Ietf-calsify] Proposed Charter

Some notes:

-- Lisa 

----

Chair(s):
TBD

Mailing Lists:

Goals and Milestones:

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Date: Mon, 28 Mar 2005 11:06:54 -0800
Subject: [Ietf-calsify] Transition issues and iCalendar, iMIP, iTIP

At the BOF and since then in discussing the charter with various people 
(draft charter to come soon), various people have tried to nail down 
the issue of what "upgrade" or "versioning" features we need to work 
on.  Using any concrete word seems to be overly specific but maybe the 
word "transition" will do:  we should try to find ways such that 
iCalendar usage scenarios can include the ability to  transition to 
newer versions, or to or from alternative formats.

I find it hard to nail down the transition issue because I don't want 
to nail any one approach into place until we've had a number of ideas 
to consider.  This seems like one of those design situations where 
there are a large number of possible solutions (or if not solutions, 
then at least incremental improvements) and we want to get a sampling 
of the approach space.  I don't think I have anything near the total 
reasonable number of approaches in my head.

That said, here's a start at sampling that space:
  - We could add capabilities advertisement to iMIP.  Clients sending 
iMIP messages (containing some base format) could advertise via a new 
mail header or iCalendar attribute their ability to handle other 
formats besides the base format.
  - We could add the ability to transport alternate representations 
within iCalendar. An iCalendar version "2.1" document could contain an 
iCalendar version 3.0 document, and a client could discard the base 
document and unpack and use only the more advanced format if it was 
able to.  This could be backward compatible.
  - We could modify iMIP to allow multipart MIME messages and add some 
logic about what the multipart means and which part to use.
  - we could specify LDAP attributes or WebDAV properties that allow 
iTIP clients to advertise supported formats, together with the 
destination address to use.

All of these approaches solve slightly different problems (and some 
cause new problems) and I'm sure people have very different ideas about 
what are the most important problems to solve and how to do that.  
Before we get into that, can we extend this list with other approaches 
or variations?

Lisa

Date: Sat, 12 Mar 2005 17:16:00 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?

Hi Doug,

--On Saturday, March 12, 2005 12:16:38 PM -0700 Doug Royer <[email-masked]> 
wrote:

> If I made an online survey or form and made it available that contained
> all of the MUST, SHOULD, ... would anyone fill it out for their product
> knowing the results would be made public to this list?

The results from the 2004 Calconnect interop do contain a 2445 compliance 
table which other vendors could easily adapt:

<http://www.calconnect.org/interop/8-2004-results.pdf>

-- 
Cyrus Daboo

Date: Sat, 12 Mar 2005 22:35:51 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] radical simplifications and the "ietf process"

NB - What follows constitutes my take on the BOF last thursday and
may or may not match the notes from the meeting.

At the BOF there seemed to be clear consensus to pursue work towards
draft standard status for the core ical specifications (which entails
actually defining what constitutes the 'core'). For those of you not
familiar with the terminology, progressing a set of documents to draft
standard means among other things that interoperability reports from
vendors guide clarification and/or ellimination of features from the
specifications.

This means lots of work but if done right will result in a set of
specifications which is more in line with what people have been
able to implement in practice while also increasing the chances of
interoperability in the future. A word of warning though: ime there
is no such thing as a quick fix to IETF documents. Those who hope
for a drive-by edit of a set of RFCs may be disapointed.

	MVH leifj

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Sat, 12 Mar 2005 20:24:05 +0100

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

Am Samstag, 12. M=E4rz 2005 20:16 schrieb Doug Royer:
> If I made an online survey or form and made it available that contained
> all of the MUST, SHOULD, ... would anyone fill it out for their product
> knowing the results would be made public to this list?

I would for KOrganizer.

Reinhold

--nextPart1968482.eGbFP1i1BH
Content-Type: application/pgp-signature

--nextPart1968482.eGbFP1i1BH--

Date: Sat, 12 Mar 2005 12:16:38 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070608090701000903000707
Content-Type: multipart/mixed; boundary="------------020500080104010602090309"

This is a multi-part message in MIME format.
--------------020500080104010602090309
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tim Hare wrote:
> I've got to agree with Cameron on this one - get some products out the 
> door which interoperate at some level we can use! Speaking as an end 
> user of a couple of different products, and knowing how my work 
> organization works, I've got to say this to the vendors present:

This only works when the vendors publish what they do and do not do.
So far each person that wants to know must figure it out. The CalConnect
results only tell us if those that participate can talk to each other.
It does not tell us why things fail (not done, done badly, hard to
understand in the spec, ...). When it reaches some level iCal will
be moved from proposed standard to standard. So far that seems to be
the level of granularity produced.

So, if the vendors want to go through all of the MUST, MUST NOT, SHOULD,
and SHOULD NOT in iCal, iTIP, and iMIP and publish their compliance,
then we can use that model and consider it.

Right now it is just a idea that has no published paper or specification
to consider.

If I made an online survey or form and made it available that contained
all of the MUST, SHOULD, ... would anyone fill it out for their product
knowing the results would be made public to this list?

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------020500080104010602090309
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------020500080104010602090309--

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

--------------ms070608090701000903000707--

Date: Sat, 12 Mar 2005 08:24:29 -0800
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
CC: [email-masked]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Reply-To: [email-masked]

I would like to support Tim's observations about interoperability and 
its effect.  So often the proprietary vs open/interoperable debate, 
focused on market share, looks like obsessing on the comparative slice 
percentage of a fixed-diameter pie, as opposed to a perhaps narrower 
wedge of a much larger pie. 

We are in a world where nobody has just one product for anything due to 
mergers and acquisition, or simply multiple fiefdoms and departments.  
To say nothing of non-enterprise purposes such as event publication, 
personal calendars, etc.

What gets overlooked in the proprietary discussions about getting an 
enterprise to convert everyone to the same product, thus avoiding 
interoperability concerns, is the freeze effect on the customer of a 
conversion - any conversion.  Even if the organization sees it through, 
at the end they spend a bundle, lose months of otherwise productive 
time, and at best wind up where they started.  If the money and other 
resources could be put towards growth, better service, or anything 
useful to the bottom line, the pie can grow and so do all the individual 
pieces.

And thanks for the reference to the Consortium, TIm.  Naturally I agree 
with your recommendation.

Dave Thewlis, Executive Director
The Calendaring and Scheduling Consortium

Tim Hare wrote:

> I've got to agree with Cameron on this one - get some products out the 
> door which interoperate at some level we can use! Speaking as an end 
> user of a couple of different products, and knowing how my work 
> organization works, I've got to say this to the vendors present:
>
>
> Interoperability is NOT going to cost you market share, it may drive 
> sales up.
>
>
> Yes, I know that making things standards-compliant means an 
> organization can pull the plug on your stuff and replace it with a 
> competitor's stuff. But that's going to happen either because of 
> price, which is some organizations trumps technology every time; 
> because of features other than interoperability, like (for a really 
> bad example) animated alarm cartoons; or because of crappy code that 
> breaks all the time. It's not going to happen because your software 
> plays nice with others. Developers - this of course isn't really aimed 
> at you but at those who make decisions about where your resources are 
> applied.
>
> And if I could write to all of the marketing folks in your companies: 
> join the Calendaring & Scheduling Consortium and help get this done. 
> Making people's calendar lives nicer would be a great part of the 
> "marketing conversation" we hear about so much these days. In fact, if 
> any of you want to send me e-mail addresses for decision-makers, I 
> will try to send them a reasoned plea about this.  I'm not a 
> Consortium member yet myself (I'm saving my box tops up) but I believe 
> in this enough to work on and think about this in my personal time 
> anyway.
>

Date: Sat, 12 Mar 2005 09:45:11 -0500
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: RE: [Ietf-calsify] Re: What's wrong with more radical simplification?

I've got to agree with Cameron on this one - get some products out the door 
which interoperate at some level we can use! Speaking as an end user of a 
couple of different products, and knowing how my work organization works, 
I've got to say this to the vendors present:

Interoperability is NOT going to cost you market share, it may drive sales up.

Yes, I know that making things standards-compliant means an organization 
can pull the plug on your stuff and replace it with a competitor's stuff. 
But that's going to happen either because of price, which is some 
organizations trumps technology every time; because of features other than 
interoperability, like (for a really bad example) animated alarm cartoons; 
or because of crappy code that breaks all the time. It's not going to 
happen because your software plays nice with others. Developers - this of 
course isn't really aimed at you but at those who make decisions about 
where your resources are applied.

And if I could write to all of the marketing folks in your companies: join 
the Calendaring & Scheduling Consortium and help get this done. Making 
people's calendar lives nicer would be a great part of the "marketing 
conversation" we hear about so much these days. In fact, if any of you want 
to send me e-mail addresses for decision-makers, I will try to send them a 
reasoned plea about this.  I'm not a Consortium member yet myself (I'm 
saving my box tops up) but I believe in this enough to work on and think 
about this in my personal time anyway.

At 02:20 PM 3/10/2005, Cameron Stillion wrote:
>I wish I could be at the BOF today...
>
>If possible, I'd like to communicate to the participants one thing that
>I think warrants repeating.  The calsify effort should be a practical
>one - and by that, I mean that it should be focused on doing something
>that will be meaningful to vendors whose iCal implementations will
>benefit from in the immediate future.  While I applaud the philosophical
>design approaches espoused in many of the "more radical" approaches to
>iCal, I must assert that anything along the radical edge is going to
>count against us in the practical department.  If we can rally around a
>*small* number of changes to the currently proposed standard, get it to
>become an actual standard, and call it done (Shrink wrap it! Ship it!) -
>then we have accomplished something no other iCal body has been able to
>do for many years.  This standard should be very close to what exists
>today, especially in shipping code.  Ideally, vendors would have a short
>list of discrepancies to fix in order to become standards compliant, and
>most interop issues would be eliminated, or at least mitigated.  Once
>we've accomplished that, I believe that we are free to take more daring,
>radical, or revolutionary approaches toward the standard. But for now, I
>think we are held somewhat captive by our past on this one,
>unfortunately - if we took the wrong approach before, let's understand
>that.  But first, let's make this thing a standard.  If we don't do it
>soon, I fear that the ad-hoc standard will trump all of our discussions,
>and we will have no real say in what "_standard_ iCal support" actually
>means.
>
>Probably more than my .02 worth...
>
>Cameron
>
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Nathaniel
>Borenstein
>Sent: Thursday, March 10, 2005 9:50 AM
>To: Reinhold Kainhofer
>Cc: [email-masked]
>Subject: Re: [Ietf-calsify] Re: What's wrong with more radical
>simplification?
>
>Well, here it is two hours before the BOF and I'm finally catching up on
>the email, but I can't resist commenting on this:
>
>Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare:
>  > ... I want calendaring to be just as simple as e-mail is now -
>
>On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote;  > Hehe, you
>chose the wrong example here. Do you know how complex the  >
>specification for email is (in particular the mime spec and all the
>various  > encodings possible)? iCalendar is trivial compared to those
>specs...
>
>Actually, the reality is both more interesting than this *and*
>potentially a model for the current situation.
>
>In designing MIME, we were faced with an incredible complexity of
>potential uses and applications.  As such, we largely retreated from
>specifying formats for *any* of them.  Instead, we focused on basic
>syntactic and encoding requirements for a tremendously extensible
>format, defined a few core types that we thought were obviously
>necessary, and left the rest to be done as future extensions.  By now, a
>paper copy of all the MIME extension specifications would probably come
>in multiple volumes (and would, of course, include all the iCal
>specs).   I am rather glad that we didn't try to do all that work in a
>single specification!
>
>I see the ongoing work of data format specification as being, for all
>intents and purpose, fractal.  Whatever we define today, people tomorrow
>will be trying to extend it in multiple, unforeseeable directions.  The
>wisdom of the 80/20 rule is that it is a good heuristic for working with
>fractally complex problems:  1.  Solve 80%
>of the problem facing you.  2.  Look deeper at the remaining 20%.  3.
>Return to step 1.  (It doesn't always work, you have to break out of it
>occasionally, but it's a good default strategy.)
>
>In the case of the ical standards, we have a historical failure to
>follow this model; the format tried to do so many things that it had
>trouble clarifying even some simple ones.  Thus, our current dilemma.
>I don't doubt the need for some way to express recurrence.  I do doubt
>that there is a simple or obvious solution, or even that there is a
>single solution; in the long run, we may need multiple languages for
>specifying RRULES, to support non-Western or non-Terran calendars, for
>example.  But we're not qualified today to plan the details of working
>with the Ganymede Colony's calendaring system.  Thus, when I pipe up
>about getting rid of recurrence entirely, what I'm really saying is that
>this is what we should have done in the first place, and only started
>worrying about specific recurrence types (as opposed to the general
>architectural notion of recurrence) once we had done a good job of the
>initial 80% of the problem (including the architectural place of
>recurrence and other "extension" mechanisms).
>
>Our current "cleanup" efforts should at least try to approximate the
>results of having done things in a more evolutionary manner.  That's
>hard to do, because you almost want to "unlearn" some of the things you
>think you already know you need while focusing on the core.  But I think
>it's our best hope for clarity and consensus.  -- Nathaniel
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]

Tim Hare
Interested Bystander, Non-Inc. 

Date: Sat, 12 Mar 2005 09:24:32 -0500
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Simplification, recurrence, other issues

Since I am a "quotee" I feel compelled to clarify my comment: I fully 
understand the underlying complexity of things (I work with z/OS for 
example, and I have in the past supported OfficeVision/MVS a very model of 
medium complexity). What I meant by my comment was: people just "walk up to 
e-mail and use it" now, they don't think about it so much (because so many 
developers thought about it and worked on things like MIME); calendar 
should be that way - people should use it intuitively.

Nathaniel used the phrase "recurrence type" - and maybe that's an idea... 
we've been thinking of various levels of iCalendar, but maybe for 
recurrences we want the object to identify its own level?  For examples:

  RRULE;RTYPE=Mars-Syntax: {Some syntax defined by those angry Martians who 
didn't like the basic one}
  RRULE;RTYPE=Ganymede-Syntax: {Some syntax defined by the Ganymedians 
(and/or their pals the Ganymeans and Ganymaximums but I digress)}
  absence of RTYPE implying RDATEs only

It does NOT improve simplification, so should be in a higher-level 
iCalendar, but perhaps it does improve the recurrence rule problem? There 
would also need, in iTIP or follow-on, need to be a response meaning "I 
don't get this syntax".  Maximum implementations could send the recurrence 
rules in several (perhaps the most popular in terms of sales) syntaxes at 
the same time since the receiver would pick only the syntax they'd like.

And now for something completely different:

Should we be careful to use iCalendar in our posts rather than iCal to 
avoid confusion with Apple's product? Not for copyright/trademark concerns 
but I'd like to be clear about what iCalendar the protocol/format does 
versus what iCal the product does with it.

And last but not least: I've lost some e-mail due to a computer failure. 
There's one issue from Calsify that I would like someone to explain to me 
OFF the list, if they would:  Why, in an iCalendar-Basic using only UTC 
times, would timezones matter on recurrence rules with participants in 
different timesones/daylight savings time areas? I seem to recall some 
discussion, and a valid reason, but I can't remember it and I'd like to. 
So, if anyone has a concise explanation, please send it to me... thanks.

At 12:50 PM 3/10/2005, Nathaniel Borenstein wrote:
>Well, here it is two hours before the BOF and I'm finally catching up on 
>the email, but I can't resist commenting on this:
>
>Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare:
> > ... I want calendaring to be just as simple as e-mail is now -
>
>On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote;
> > Hehe, you chose the wrong example here. Do you know how complex the
> > specification for email is (in particular the mime spec and all the various
> > encodings possible)? iCalendar is trivial compared to those specs...
>
>Actually, the reality is both more interesting than this *and* potentially 
>a model for the current situation.
>
>In designing MIME, we were faced with an incredible complexity of 
>potential uses and applications.  As such, we largely retreated from 
>specifying formats for *any* of them.  Instead, we focused on basic 
>syntactic and encoding requirements for a tremendously extensible format, 
>defined a few core types that we thought were obviously necessary, and 
>left the rest to be done as future extensions.  By now, a paper copy of 
>all the MIME extension specifications would probably come in multiple 
>volumes (and would, of course, include all the iCal specs).   I am rather 
>glad that we didn't try to do all that work in a single specification!
>
>I see the ongoing work of data format specification as being, for all 
>intents and purpose, fractal.  Whatever we define today, people tomorrow 
>will be trying to extend it in multiple, unforeseeable directions.  The 
>wisdom of the 80/20 rule is that it is a good heuristic for working with 
>fractally complex problems:  1.  Solve 80% of the problem facing 
>you.  2.  Look deeper at the remaining 20%.  3.
>Return to step 1.  (It doesn't always work, you have to break out of it 
>occasionally, but it's a good default strategy.)
>
>In the case of the ical standards, we have a historical failure to follow 
>this model; the format tried to do so many things that it had trouble 
>clarifying even some simple ones.  Thus, our current dilemma.
>I don't doubt the need for some way to express recurrence.  I do doubt 
>that there is a simple or obvious solution, or even that there is a single 
>solution; in the long run, we may need multiple languages for specifying 
>RRULES, to support non-Western or non-Terran calendars, for example.  But 
>we're not qualified today to plan the details of working with the Ganymede 
>Colony's calendaring system.  Thus, when I pipe up about getting rid of 
>recurrence entirely, what I'm really saying is that this is what we should 
>have done in the first place, and only started worrying about specific 
>recurrence types (as opposed to the general architectural notion of 
>recurrence) once we had done a good job of the initial 80% of the problem 
>(including the architectural place of recurrence and other "extension" 
>mechanisms).
>
>Our current "cleanup" efforts should at least try to approximate the 
>results of having done things in a more evolutionary manner.  That's hard 
>to do, because you almost want to "unlearn" some of the things you think 
>you already know you need while focusing on the core.  But I think it's 
>our best hope for clarity and consensus.  -- Nathaniel
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]

Tim Hare
Interested Bystander, Non-Inc. 

Content-Class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Thu, 10 Mar 2005 11:20:58 -0800
From: "Cameron Stillion" <[email-masked]>
To: "Nathaniel Borenstein" <[email-masked]>, "Reinhold Kainhofer" <[email-masked]>
Cc: [email-masked]

I wish I could be at the BOF today... 

If possible, I'd like to communicate to the participants one thing that
I think warrants repeating.  The calsify effort should be a practical
one - and by that, I mean that it should be focused on doing something
that will be meaningful to vendors whose iCal implementations will
benefit from in the immediate future.  While I applaud the philosophical
design approaches espoused in many of the "more radical" approaches to
iCal, I must assert that anything along the radical edge is going to
count against us in the practical department.  If we can rally around a
*small* number of changes to the currently proposed standard, get it to
become an actual standard, and call it done (Shrink wrap it! Ship it!) -
then we have accomplished something no other iCal body has been able to
do for many years.  This standard should be very close to what exists
today, especially in shipping code.  Ideally, vendors would have a short
list of discrepancies to fix in order to become standards compliant, and
most interop issues would be eliminated, or at least mitigated.  Once
we've accomplished that, I believe that we are free to take more daring,
radical, or revolutionary approaches toward the standard. But for now, I
think we are held somewhat captive by our past on this one,
unfortunately - if we took the wrong approach before, let's understand
that.  But first, let's make this thing a standard.  If we don't do it
soon, I fear that the ad-hoc standard will trump all of our discussions,
and we will have no real say in what "_standard_ iCal support" actually
means.

Probably more than my .02 worth...

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nathaniel
Borenstein
Sent: Thursday, March 10, 2005 9:50 AM
To: Reinhold Kainhofer
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical
simplification?

Well, here it is two hours before the BOF and I'm finally catching up on
the email, but I can't resist commenting on this:

Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare:
 > ... I want calendaring to be just as simple as e-mail is now -

On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote;  > Hehe, you
chose the wrong example here. Do you know how complex the  >
specification for email is (in particular the mime spec and all the
various  > encodings possible)? iCalendar is trivial compared to those
specs...

Actually, the reality is both more interesting than this *and*
potentially a model for the current situation.

In designing MIME, we were faced with an incredible complexity of
potential uses and applications.  As such, we largely retreated from
specifying formats for *any* of them.  Instead, we focused on basic
syntactic and encoding requirements for a tremendously extensible
format, defined a few core types that we thought were obviously
necessary, and left the rest to be done as future extensions.  By now, a
paper copy of all the MIME extension specifications would probably come
in multiple volumes (and would, of course, include all the iCal 
specs).   I am rather glad that we didn't try to do all that work in a 
single specification!

I see the ongoing work of data format specification as being, for all
intents and purpose, fractal.  Whatever we define today, people tomorrow
will be trying to extend it in multiple, unforeseeable directions.  The
wisdom of the 80/20 rule is that it is a good heuristic for working with
fractally complex problems:  1.  Solve 80% 
of the problem facing you.  2.  Look deeper at the remaining 20%.  3.   
Return to step 1.  (It doesn't always work, you have to break out of it
occasionally, but it's a good default strategy.)

In the case of the ical standards, we have a historical failure to
follow this model; the format tried to do so many things that it had
trouble clarifying even some simple ones.  Thus, our current dilemma.  
I don't doubt the need for some way to express recurrence.  I do doubt
that there is a simple or obvious solution, or even that there is a
single solution; in the long run, we may need multiple languages for
specifying RRULES, to support non-Western or non-Terran calendars, for
example.  But we're not qualified today to plan the details of working
with the Ganymede Colony's calendaring system.  Thus, when I pipe up
about getting rid of recurrence entirely, what I'm really saying is that
this is what we should have done in the first place, and only started
worrying about specific recurrence types (as opposed to the general
architectural notion of recurrence) once we had done a good job of the
initial 80% of the problem (including the architectural place of
recurrence and other "extension" mechanisms).

Our current "cleanup" efforts should at least try to approximate the
results of having done things in a more evolutionary manner.  That's
hard to do, because you almost want to "unlearn" some of the things you
think you already know you need while focusing on the core.  But I think
it's our best hope for clarity and consensus.  -- Nathaniel

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

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical simplification?
Date: Thu, 10 Mar 2005 12:50:10 -0500
To: Reinhold Kainhofer <[email-masked]>
Cc: [email-masked]

Well, here it is two hours before the BOF and I'm finally catching up 
on the email, but I can't resist commenting on this:

Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare:
 > ... I want calendaring to be just as simple as e-mail is now -

On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote;
 > Hehe, you chose the wrong example here. Do you know how complex the
 > specification for email is (in particular the mime spec and all the 
various
 > encodings possible)? iCalendar is trivial compared to those specs...

Actually, the reality is both more interesting than this *and* 
potentially a model for the current situation.

In designing MIME, we were faced with an incredible complexity of 
potential uses and applications.  As such, we largely retreated from 
specifying formats for *any* of them.  Instead, we focused on basic 
syntactic and encoding requirements for a tremendously extensible 
format, defined a few core types that we thought were obviously 
necessary, and left the rest to be done as future extensions.  By now, 
a paper copy of all the MIME extension specifications would probably 
come in multiple volumes (and would, of course, include all the iCal 
specs).   I am rather glad that we didn't try to do all that work in a 
single specification!

I see the ongoing work of data format specification as being, for all 
intents and purpose, fractal.  Whatever we define today, people 
tomorrow will be trying to extend it in multiple, unforeseeable 
directions.  The wisdom of the 80/20 rule is that it is a good 
heuristic for working with fractally complex problems:  1.  Solve 80% 
of the problem facing you.  2.  Look deeper at the remaining 20%.  3.   
Return to step 1.  (It doesn't always work, you have to break out of it 
occasionally, but it's a good default strategy.)

In the case of the ical standards, we have a historical failure to 
follow this model; the format tried to do so many things that it had 
trouble clarifying even some simple ones.  Thus, our current dilemma.  
I don't doubt the need for some way to express recurrence.  I do doubt 
that there is a simple or obvious solution, or even that there is a 
single solution; in the long run, we may need multiple languages for 
specifying RRULES, to support non-Western or non-Terran calendars, for 
example.  But we're not qualified today to plan the details of working 
with the Ganymede Colony's calendaring system.  Thus, when I pipe up 
about getting rid of recurrence entirely, what I'm really saying is 
that this is what we should have done in the first place, and only 
started worrying about specific recurrence types (as opposed to the 
general architectural notion of recurrence) once we had done a good job 
of the initial 80% of the problem (including the architectural place of 
recurrence and other "extension" mechanisms).

Our current "cleanup" efforts should at least try to approximate the 
results of having done things in a more evolutionary manner.  That's 
hard to do, because you almost want to "unlearn" some of the things you 
think you already know you need while focusing on the core.  But I 
think it's our best hope for clarity and consensus.  -- Nathaniel

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] radical simplification, too
Date: Thu, 10 Mar 2005 12:50:07 -0500
To: [email-masked]

+1.  And given the inherent tendency of humans to get confused over 
time zones, a sophisticated implementation might actually use this to 
double-check, and raise a red flag when it believes that the two 
specifications are not, in fact, identical.  -- Nathaniel

On Feb 14, 2005, at 3:16 PM, Doug Royer wrote:

>
> Another idea is that we make a new parameter (say R-FYI) that *if*
> set to true in an RRULE property means that the RDATE's should
> be used and that RRULE is just FYI. So you could say in effect,
> and the ORGANIZER wants to convey the fact that the meeting is
> weekly, but look at the RDATE's for the real instance times.
>
> Now we can keep the organizers intent when implementations care,
> and for those that do not care, here are the real instance
> times in RDATEs.
>
> Preston Stephenson wrote:
>> Just a few comments.
>> It would be nice to have a list of iCal properties that were defined 
>> explicitly.
>> Be it an iCal lite or an iCal best practices.
>> If we could come to a consensus of what they were,
>> I would be more willing to make the project I work on fit into that 
>> consensus.
>> If we get into the more difficult ones such as rrule,
>> I'm constrained by the architecture of our application.
>> I'm limited to fanning out the recurrence rule to a reasonable number 
>> of occurrences in the future.
>> It would nice to support infinite occurring rules, but I don't see it 
>> happening anytime soon.
>> All I'm saying is if rrule was part of the iCal basic, I could only 
>> support it with certain restrictions.
>> It would be nice to have a set of iCal properties that could be 
>> supported in all cases.
>> Thanks.
>> Preston
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
> -- 
> Doug Royer                     | http://INET-Consulting.com
> -------------------------------|-----------------------------
>
>               We Do Standards - You Need Standards
>
> <Doug.vcf>_______________________________________________
> Ietf-calsify mailing list
> [email-masked]

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Re: Comments on radical simplification and bumping the version
Date: Thu, 10 Mar 2005 12:26:09 -0500
To: [email-masked]

+1.  Also, we can specify that in the case of a "true" infinite 
meeting, it is the responsibility of the initiating server to send out 
a "renewal" at the end of the one/five/hundred year period.

On Feb 14, 2005, at 11:42 AM, Elias Sinderson wrote:

> Curt Ellmann wrote:
>
>> I agree that one year is too short-- what is the problem with 
>> infinitely
>> recurring events?  There are plenty of examples of events that are
>> infinitely recurring-- holidays, anniversaries, and other 
>> celebrations.
>>
> I only suggested one year as a matter of conjecture - the limit could 
> be five years, or ten, for that matter, as long as there is a limit 
> which allows a /finite/ expansion of recurring events. Note that this 
> was in response to Doug Royers observation that "the only noticable 
> issue is infinate recurring entries." I will also note that the 
> cannonical examples provided for infinitely recurring events have been 
> all-day events, which do not suffer from the timezone issues that have 
> been identified. As per Dougs' suggestion, the inclusion of a property 
> which indicates that a METHOD:REFRESH should be done in the future 
> seems like a good idea; simply a way to say 'and so on' or 'sync again 
> later'. I cannot think of a situation where a client would need to get 
> the infinity of recurrences in a single sync and not be able to sync 
> again in the future. Further, regarding the question of the duration 
> placed as an upper bound, allowing any given implementation to set 
> its' own upper bound on recurrences rather than having it rigidly 
> declared in the specification would make it possible for devices with 
> limited profiles to play along as well.
>
> It may be useful to step back from this issue for a minute and try to 
> identify use cases that require scheduling of recurring events (or any 
> event), e.g., five years out. Neither Hotels nor airlines will allow 
> one to place reservations that far in advance. The most difficult 
> restaraunt to dine at in California (French Laundry) only takes 
> reservations several months (4?) out. Business meetings are never 
> arranged in this matter, and it only seems a matter of convenience to 
> say that this meeting will recur infinitely rather than specify an end 
> date several years away. As I mentioned before, even so called 
> 'infinitely recurring' weekly project meetings are (semi)regularly 
> rescheduled to accomodate attendees constraints and other recurring 
> meetings that are scheduled. If anyone can provide a use case which 
> requires an infinitely recurring event which is not an all day affair 
> (such as holidays, birthdays, anniversaries, etc.), please provide it. 
> Extra credit will be given if it isn't some freaky and contrived edge 
> case, but occurs frequently enough that it would be an honest 
> inconvenience to a user to schedule seperate events.
>
> Deprecating infinitely recurring events and placing a sensible upper 
> bound as suggested would allow recurring events to be represented as 
> either a RRULE or as a finite sequence of events, and would sidestep 
> the issues related to timezones that have been raised previously on 
> the list. It would seem that the benefits of this simplification 
> greatly outweigh the downside of rescheduling a meeting every couple 
> years (if it lasts that long) or similar. Further, if RRULEs become an 
> optional part of the specification, as has been suggested before, this 
> approach would allow interoperability where one system implements 
> RRULEs and the other doesn't, as there won't be a problem in an 
> infinite expansion of events.
>
>
> Cheers,
> Elias
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Michiel 
>> van
>> Leeuwen
>> Sent: Saturday, February 12, 2005 2:58 PM
>> To: [email-masked]
>> Subject: [Ietf-calsify] Re: Comments on radical simplification and 
>> bumping
>> the version
>>
>> Elias Sinderson wrote:
>>
>>> Would it be reasonable to deprecate infinitely recurring events and 
>>> place an upperbound of, say, one year on recurring entries?
>>
>> I think it isn't such a great idea, becasue one year is a magic 
>> number. Why one year, and not two years?
>>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]

Date: Thu, 10 Mar 2005 10:20:02 -0600 (CST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: IETF calsify <[email-masked]>
Cc: 
Subject: [Ietf-calsify] calsify BoF today

A reminder that we'll be having the calsify BoF at IETF 62 today at 1300 
CST.  The BoF agenda is at:

   http://ietf.org/ietf/05mar/calsify.txt

The Jabber chat room is:

   [email-masked]

See

   http://www.xmpp.org/ietf-chat.html

for info on how that works.

There's also audio streaming from all the IETF WG sessions this time, see

   http://videolab.uoregon.edu/events/ietf/

for info on that.  We'll do our best to have the discussion happen via the 
microphone and the chat room.

Intro presentation (thank you Cyrus) can be got from:

   http://staff.washington.edu/rlmorgan/misc/IETF-62-calsify-BOF-intro.sxi
   http://staff.washington.edu/rlmorgan/misc/IETF-62-calsify-BOF-intro.ppt

in OO and Powerpoint respectively.  If anyone else has a presentation 
please send it to me before the meeting if possible.

  - RL "Bob"

Date: Fri, 04 Mar 2005 10:14:37 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Cc: 
Subject: [Ietf-calsify] Jabber chat room for BOF

FYI A Jabber IM chat room has been setup for the BOF next week. So those 
that will not be present can participate that way if they desire. The 
jabber address is:

[email-masked]

-- 
Cyrus Daboo