[Ietf-calsify] Simplification

[Libby Miller]

On Mon, 23 Aug 2004, 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.

I'd be extremely interested in this. We've done some work on testcases 
for RDF iCalendar[1] by collecting iCalendar outputs from different 
producers (Apple iCal, Evolution, Mozilla etc) and then converting them 
to RDF. Any more testcases that are available that might help us work 
out if a subset of iCalendar is in common use would be tremendously 
useful (we often get this as a request, because our work roundtrips to 
iCalendar from the RDF version).

Libby

[1] http://www.w3.org/2002/12/cal/test/

>
>> -----Message d'origine-----
>> De : ietf-calsify-bounces at osafoundation.org [mailto:ietf-calsify-
>> bounces at osafoundation.org] De la part de Nathaniel Borenstein
>> Envoyé : samedi 21 août 2004 16:10
>> À : TimHare at comcast.net
>> Cc : ietf-calsify at osafoundation.org
>> 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 at 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 at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>