iCalendar simplification

This is perhaps our chance to get more data.

- archives are at 
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Libby

---------- Forwarded message ----------
Date: Mon, 23 Aug 2004 19:23:26 +0100 (BST)
From: Libby Miller <Libby.Miller@bristol.ac.uk>
Subject: Re: RE : [Ietf-calsify] Simplification



On Mon, 23 Aug 2004, David C. Thewlis wrote:

> The results of the previous interops are on the Calconnect.org website --
> go to *Past Interops*.  Results from the just-completed Interop on 29-30
> July should be available shortly -- we're waiting for some final
> information from the testers.  It will be submitted to the IETF and posted
> on the Calconnect.org website as soon as it is complete, probably not this
> week but hopefully next week.  I would agree that thinking there was
> "nothing worth keeping in the old specs" would be quite unfair, to say
> nothing of terribly disruptive.
> 
> Dave Thewlis
>

Thanks for this.
For us, rather than a summary, public versions of any iCalendar data files 
would be really really useful as we're interested in which bits of VEVENT (say) 
are supported, for example.

best wishes,

Libby


> *********** REPLY SEPARATOR  ***********
> 
> On 8/23/2004 at 11:02 Arnaud Quillaud wrote:
> 
>> Do we have the results of the latest (and previous) ical interop meetings
>> published somewhere ?
>> If those are detailed enough, couldn't we use them as a basis to determine
>> what is working/not working, implemented/not implemented in the
>> ical/itip/imip specs ?
>> After reading all the messages on this list, one may start to think that
>> there is nothing worth keeping in the old specs which is probably quite
>> unfair. A summary of the interop meeting might help us decide how far we
>> want to go while rewritting the calendar rfcs.
>> 
>> Arnaud
>> 
>>> -----Message d'origine-----
>>> De : ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-
>>> bounces@osafoundation.org] De la part de Nathaniel Borenstein
>>> Envoyé : samedi 21 août 2004 16:10
>>> Objet : Re: [Ietf-calsify] Simplification
>>> 
>>> Boy, you get 5 days behind and the party starts without you....  over
>>> 70 messages already!
>>> 
>>> I have a couple of comments on this week's discussion, and I'll try to
>>> separate them into the right threads for continuity.  I'll start with
>>> my take on Tim Hare's excellent questions:
>>> 
>>> On Aug 16, 2004, at 8:47 PM, TimHare@comcast.net wrote:
>>> 
>>>> I'd like to start off this list by asking questions regarding calendar
>>>> "simplification".
>>>> 
>>>> 1. Is the intent to re-examine RCF2445/6/7?
>>> 
>>> Yes.  In the light of six years of implementation experience, I believe
>>> that it is time to rewrite those RFC's, simplifying and correcting
>>> them, and clarifying the requirements for a "minimal" or "conformant"
>>> ical implementation.
>>> 
>>> In particular, I think that in addition to the substantive changes we
>>> have been and are discussing, the RFC's should be restructured, with
>>> optional features described in separate documents wherever possible.
>>> 
>>>> 2. Is the intent to make implementation simpler?
>>> 
>>> Yes, certainly at least the "minimum implementation" can be simplified
>>> greatly.  I am going into this -- as I would encourage everyone to do
>>> -- with the hypothesis that there is nothing wrong with iCal that can't
>>> be fixed by making it simpler.  That may be proved wrong, but let's
>>> make adding features a last resort.  Once the base specs work, we can
>>> add optional features till the cows come home.  As a (partially baked)
>>> example of how we might do this, see my upcoming message on "Mandatory
>>> Sets, Optional Rules".
>>> 
>>>> 3. Is the intent to make use simpler (may conflict with #2).
>>> 
>>> Yes.  While I agree that it may conflict, I suspect that it rarely
>>> will.  (For an example of this, see my upcoming message about Sets &
>>> Rules.)
>>> 
>>>> 4. Is the intent to make implementation more wide-spread?
>>> 
>>> Oh, yes.  But indirectly -- that is, we're clearly working on the
>>> implicit hypothesis that problems with the spec have been a major
>>> barrier to adoption.  So we're here to fix the spec, not to generate PR
>>> to encourage implementation.
>>> 
>>>> 5. Is the intent to make inter-operation better?
>>> 
>>> The intent, in my mind, is to make inter-operation *possible* beyond a
>>> few rather simple cases.
>>> 
>>>> 6. What are the perceived issues with the current RFCs?
>>> 
>>> There's probably need for me to answer this one, as the discussion is
>>> well under way.  But the following are my primary issues:
>>> 
>>> -- The specs are too complex for most implementors.
>>> 
>>> -- The specs include many features that have been ignored and are
>>> therefore untested.
>>> 
>>> -- The specs retain several ambiguities, particularly around recurrence
>>> rules.
>>> 
>>> I'm really gratified to see the enthusiasm with which this discussion
>>> has begun.  Now let's try to simplify some more.  -- Nathaniel
>>> 
>>> _______________________________________________
>>> Ietf-calsify mailing list
>>> Ietf-calsify@osafoundation.org
>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>> 
>> 
>> _______________________________________________
>> Ietf-calsify mailing list
>> Ietf-calsify@osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> 
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify@osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify