Subject: [Ietf-calsify] Simplification

From: TimHare at comcast.net ([email-masked])
Date: Mon Aug 16 17:53:34 2004

I'd like to start off this list by asking questions regarding calendar 
"simplification".

1. Is the intent to re-examine RCF2445/6/7?
2. Is the intent to make implementation simpler?
3. Is the intent to make use simpler (may conflict with #2).
4. Is the intent to make implementation more wide-spread?
5. Is the intent to make inter-operation better?
6. What are the perceived issues with the current RFCs?

Getting a consensus answer to these questions, I feel, will give the list a 
"level set" from which to work. My goal, as a user-sometimes-developer 
(i.e. I can program for a living but calendar coding I'm not paid for), is 
to get _some_  interoperable calendar thing working, sometime before:

BEGIN: VEVENT
DTSTART:  39541231T1100Z
SUMMARY: Tim's memorial service
END: VEVENT

:-)

Seriously, this is the kind of thing that, once it gets rolling and people 
use it, they will get to a point where it's like plumbing to them. Sort of 
the situation is for e-mail today; with all its flaws, we just take it for 
granted. I want calendaring to be like that.

Tim Hare
Interested Bystander, Non-Inc.

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Sat Aug 21 16:10:36 2004

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:

> 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

---

From: TimHare at comcast.net ([email-masked])
Date: Mon Aug 23 05:17:00 2004

Would it be profitable to take the existing specs for 2445/2446/2447 and 
have some discussion about "levels" into which various parts would go? For 
example (I am _not_ definitevly advocating these, this is an example off 
the top of my head):

Level 0 - mandatory for simplest implementations. VEVENTS (but not all 
properties?), METHOD. no CAP support?, no recurrence rules. If One query 
supported (if any) - GET-CAPABILITY, to which it replies "I don't know 
nuthin' about interoperation, leave me alone".  A standalone calendaring 
system for one user, basically?

Level 1 - adds VTODOs, perhaps other METHODs, iTIP/iMIP?  Exchanges lists 
of dates instead of recurrence rules.

Level 2 - Adds CAP support, GET-CAPABILITY check for recurrence languages 
ala Nathaniel's suggestion, recurrence set exchange?

I'm sure the levels need quite a bit of refining, but I think it might be 
worthwhile to sort the RFCs and their contents into bins in this way.

Tim Hare

---

From: arnaud.quillaud at sun.com (Arnaud Quillaud)
Date: Mon Aug 23 11:02:55 2004

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?: [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
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Dave.Thewlis at calconnect.org (David C. Thewlis)
Date: Mon Aug 23 11:16:47 2004

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

*********** REPLY SEPARATOR  ***********

On 8/23/2004 at 11:02 Arnaud Quillaud wrote:

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

---

From: Libby.Miller at bristol.ac.uk (Libby Miller)
Date: Mon Aug 23 11:19:51 2004

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

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/

---

From: Libby.Miller at bristol.ac.uk (Libby Miller)
Date: Mon Aug 23 11:27:22 2004

> nothing of terribly disruptive.

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

---

From: pregen at egenconsulting.com ([email-masked])
Date: Mon Aug 23 12:09:01 2004

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:

> > 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.
> 
> >> De : [email-masked] [mailto:ietf-calsify-
> >> Envoy? : samedi 21 ao?t 2004 16:10
> >> ? : [email-masked]
> >> Cc : [email-masked]
> >> Objet : Re: [Ietf-calsify] Simplification
> >>

---

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

I like this way of thinking about it, but I also wonder if some of this 
is just the difference between a MUST and a MAY...

I like the idea of restructuring the documents, but I'm not sure I know 
what they should look like.  It would be awfully nice if the document 
set started with a 20-30 page overview document that one could read 
first and really understand how the other parts fit together.  In fact, 
I would posit that if we could write that first, the others would be a 
lot easier to write.  -- Nathaniel

On Aug 23, 2004, at 8:10 AM, [email-masked] wrote:

>
>
> Would it be profitable to take the existing specs for 2445/2446/2447 
> and have some discussion about "levels" into which various parts would 
> go? For example (I am _not_ definitevly advocating these, this is an 
> example off the top of my head):
>
> properties?), METHOD. no CAP support?, no recurrence rules. If One 
> query supported (if any) - GET-CAPABILITY, to which it replies "I 
> don't know nuthin' about interoperation, leave me alone".  A 
> standalone calendaring system for one user, basically?
>
> Level 1 - adds VTODOs, perhaps other METHODs, iTIP/iMIP?  Exchanges 
> lists of dates instead of recurrence rules.
>
> Level 2 - Adds CAP support, GET-CAPABILITY check for recurrence 
> languages ala Nathaniel's suggestion, recurrence set exchange?
>
> I'm sure the levels need quite a bit of refining, but I think it might 
> be worthwhile to sort the RFCs and their contents into bins in this 
> way.
>
>
> Tim Hare

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Wed Aug 25 16:05:46 2004

Having support levels is not at all like MUST vs SHOULD -- instead it's 
different groupings of MUST.  With levels defined,  there would be text 
like "A client advertising support for Level 1 MUST support VTODOs... A 
client supporting Level 2 MUST handle blah blah blah ..."  It makes for 
a limited set of different capability support selections, rather than  
unlimited variability among implementations.

The problem with levels, in iCalendar, is really that there's no way of 
finding out what level an agent supports - so there's nothing about the 
levels that helps other agents interoperate.

Lisa

On Aug 25, 2004, at 3:31 PM, Nathaniel Borenstein wrote:

> I like this way of thinking about it, but I also wonder if some of 
> this is just the difference between a MUST and a MAY...
>
> I like the idea of restructuring the documents, but I'm not sure I 
> know what they should look like.  It would be awfully nice if the 
> document set started with a 20-30 page overview document that one 
> could read first and really understand how the other parts fit 
> together.  In fact, I would posit that if we could write that first, 
> the others would be a lot easier to write.  -- Nathaniel
>
>> and have some discussion about "levels" into which various parts 
>> would go? For example (I am _not_ definitevly advocating these, this 
>> is an example off the top of my head):
>>
>> Level 0 - mandatory for simplest implementations. VEVENTS (but not 
>> all properties?), METHOD. no CAP support?, no recurrence rules. If 
>> One query supported (if any) - GET-CAPABILITY, to which it replies "I 
>> I'm sure the levels need quite a bit of refining, but I think it 
>> might be worthwhile to sort the RFCs and their contents into bins in 
>> this way.
>>
>>
>> Tim Hare