Subject: [Ietf-calsify] Simplification

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Mon Aug 23 19:08:37 2004

This is great.  We should definitely use the interop results to gauge areas in need of clarification.

I will say that the discussions that have ensued on this alias seem (to me) to be very focused on specific schema elements and though we have questioned their value and clarity, I have not seen any general devaluing of the spec as a whole.  I believe everyone here values iCal and wants to see it reach standard.  Hence the need to "cut the fat" off of the current document.

As Nathaniel has stated, the excitement surrounding this is a positive thing, and indicative of the desire we all share to bring this document out of obscurity, and into the sparkling light of "published standard". 

cameron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 23, 2004 12:09 PM
To: Libby Miller
Cc: [email-masked]; [email-masked]
Subject: Re: RE : [Ietf-calsify] Simplification

Past history can be found at both www.calsch.org and at www.calconnect.org.  I will be posting the results of the recent interop along with a summary of what worked and what basically is not supported by any vendor.  while only two vendors were at the most recent interop, several have partipated at other interops and there are indeed several things that do work in iCalendar, iMIP and iTIP.  Therefore, we don't want to through away what is working.  If the spec was not working, I would not be able to accept and reply to the calandar invites I am receiving today from another vendor's products.  Those invites are indeed working and working well.  So, that means some of the spec is working as designed.  At this last interop, I went one step further and went through each and every MUST/SHOULD/MAY and the NOTs as well and flagged what worked/did not work. 
 My plan to to post this detail along with past results in a summary document that hopefully other vendors will reply to and say  - yes, we support that and no we don't support this... etc.  That should provide a foundation on which to build the simplified spec.  I expect to have this document done by 9/3.  I'll put a note here on the list as to where the file resides.  It will probably be a link off of www.calconnect.org.

[email-masked] wrote on 08/23/2004 14:19:23:

> 
> 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 : [email-masked] [mailto:ietf-calsify- 
> >> [email-masked]] De la part de Nathaniel Borenstein 
> >> Envoy? : samedi 21 ao?t 2004 16:10 ? : [email-masked] Cc : 
> >> [email-masked] 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, [email-masked] 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
> >> [email-masked]
> >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> >
> >
> > _______________________________________________
> > 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

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Wed Aug 25 15:11:53 2004

We're in violent agreement.  In particular, I haven't heard *anyone* 
say that the iCal model or format is hopeless, but I've heard just 
about *everyone* say that it's overly complex.  Hence my (consciously 
extreme) default position, which is that we should get rid of every 
feature and option that we can live without, and add nothing unless it 
enables a larger simplification.  -- Nathaniel

On Aug 23, 2004, at 10:08 PM, Cameron Stillion wrote:

> I will say that the discussions that have ensued on this alias seem 
> (to me) to be very focused on specific schema elements and though we 
> have questioned their value and clarity, I have not seen any general 
> devaluing of the spec as a whole.  I believe everyone here values iCal 
> and wants to see it reach standard.  Hence the need to "cut the fat" 
> off of the current document.
>
> As Nathaniel has stated, the excitement surrounding this is a positive 
> thing, and indicative of the desire we all share to bring this 
> document out of obscurity, and into the sparkling light of "published 
> standard".
>
> cameron
>
>
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Past history can be found at both www.calsch.org and at 
> www.calconnect.org.  I will be posting the results of the recent 
> interop along with a summary of what worked and what basically is not 
> supported by any vendor.  while only two vendors were at the most 
> recent interop, several have partipated at other interops and there 
> are indeed several things that do work in iCalendar, iMIP and iTIP.  
> Therefore, we don't want to through away what is working.  If the spec 
> was not working, I would not be able to accept and reply to the 
> calandar invites I am receiving today from another vendor's products.  
> Those invites are indeed working and working well.  So, that means 
> some of the spec is working as designed.  At this last interop, I went 
> one step further and went through each and every MUST/SHOULD/MAY and 
> the NOTs as well and flagged what worked/did not work.
>  My plan to to post this detail along with past results in a summary 
> document that hopefully other vendors will reply to and say  - yes, we 
> support that and no we don't support this... etc.  That should provide 
> a foundation on which to build the simplified spec.  I expect to have 
> this document done by 9/3.  I'll put a note here on the list as to 
> where the file resides.  It will probably be a link off of 
> www.calconnect.org.
>

---

From: Doug at Royer.com (Doug Royer)
Date: Wed Aug 25 15:44:53 2004

Yes. I think the way to go is to split into several drafts (I do not 
care about the
order or priority at this time):

   1)  iCAL + VEVENT + VALARM
   2) VTODO
   3) VJOURNAL
   4) Time Zones
   5) iMIP
   6) Scheduling

-- 

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

-------------- 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/20040825/97d3b8b3/smime-0001.bin