Subject: [Ietf-calsify] Re: What's wrong with more radical simplification?

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Thu Mar 10 11:21:15 2005

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: TimHare at comcast.net (Tim Hare)
Date: Sat Mar 12 06:45:21 2005

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.

>it's our best hope for clarity and consensus.  -- Nathaniel

Tim Hare
Interested Bystander, Non-Inc.

---

From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Sat Mar 12 08:24:29 2005

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

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Mar 12 11:16:57 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050312/dc90c664/smime-0001.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sat Mar 12 11:24:15 2005

Am Samstag, 12. M?rz 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050312/1ccb3c46/attachment.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Sat Mar 12 14:16:06 2005

Hi Doug,

> 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