Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution

From: John Stracke <[email-masked]>
Date: Mon, 07 May 2001 12:48:21 -0400

[email-masked] wrote:

> Not being in Minnesota, I can not be sure of all that was
> discussed.  However, I really am reluctant to see us "step
> back" a draft in order to make it fit a smaller model such as
> telephony.

Yeah, but RECUR is too big for calendaring, too.

> There will always be new technology that comes along after a
> draft has been produced.  What happens in those situations?
> They don't rewrite the draft - they build new drafts that add
> on to or enhance the draft. I don't think they step the drafts
> backwards.

It can happen, I think; there's no law that says that the Draft
Standard has to be a superset of the Proposed Standard.  In fact,
there's at least one case where RFC-2026 mandates that features
be removed:

     The requirement for at least two independent and
     interoperable implementations applies to all of the
     options and features of the specification.  In cases in
     which one or more options or features have not been
     demonstrated in at least two interoperable
     implementations, the specification may advance to the
     Draft Standard level only if those options or features
     are removed.

(RFC-2026, 4.1.2, second paragraph.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Brought to you by the letter Q.              |
[email-masked]|                                             |
\==============================================================/

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 07 May 2001 12:53:25 -0400

John Stracke wrote:

> (RFC-2026, 4.1.2, second paragraph.)

This is actually quite common. Unless the WG con point to two
interoperable implementations of a feature, that feature is history. (It
might appear in a separate draft, to progress along the standards track
independently.) The whole point of Proposed status is to ferret out the
things that are truly useful in practice, rather than progressing
grab-bags of ideas that seemed good at some point or another.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 12 May 2001 13:09:14 +0200

The IESG is as a whole greatly concerned about the lack of ability to
resolv the issues between the CPL spec and the spec which CALSH wg is
working on.

As responsible AD for the Calsh wg, I hereby ask the Calsh Wg to
concentrate on this topic as the number one issue. It seems that you don't
understand the seriousness of earlier requests from IESG.

I don't see any other action items being worth working on until the CPL
issues are resolved.

This "not" is what blocks the whole work with CPL which an important
ingredience in the architecture of IP Telephony.

   Regards, Patrik Faltstrom
   Co-Area Director, Applications Area

--On 01-04-26 00.29 -0400 [email-masked] wrote:

> 
> Not being in Minnesota, I can not be sure of all that was discussed.
> However, I really am reluctant to see us "step back" a draft in order to
> make it fit a smaller model such as telephony.  I don't believe that is
> the best thing to do here.  There are already vendors implementing or
> attempting to implement iCalendar and making what appears to be such a
> big change could potentially throw a monkey wrench in a process that is
> finally starting to move - i.e. interoperability.  Those of you on the
> list need to speak up on this comment about reducing the complexity of
> recurrence rules.  If anything happens it needs to be a new RFC.  There
> will always be new technology that comes along after a draft has been
> produced.  What happens in those situations?  They don't rewrite the
> draft - they build new drafts that add on to or enhance the draft. I
> don't think they step the drafts backwards.  I ma! y ! be wrong - some
> one step up and throw rocks at me if I'm reading this incorrectly.
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652 

Patrik Fältström <[email-masked]>                         Cisco Systems
Consulting Engineer                                  Office of the CSO
Phone: (Stockholm) +46-8-6859131            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 13 May 2001 10:35:45 +0200

> there's at least one case where RFC-2026 mandates that features

Removing features when going from Proposed to Draft is not uncommon at all.
It is one way of seeing that everything in the RFC is implementable and
implemented and one find this out if nothing else while doing
interoperability tests.

   paf

---

From: Alan Davies <[email-masked]>
Date: Mon, 14 May 2001 13:00:12 -0400

I don't know how these issues are usually resolved, but it
seems that the discussion came to a standstill, as many
ideas were suggested but noone really pushed for any one
solution.

Here's a look at 3 candidate outcomes to this issue:

1. iCalendar uses the RRULE subset suggested in the CPL spec.

2. CPL adopts the full iCalendar RRULE grammar.

3. iCalendar doesn't change RRULE, iptel uses it's own
    RRULE subset.

Most on the Calsch list seemed to be fine with 2. or 3., but
some are opposed to 1. as it would break compatibility with
existing implementations. Some think that 1. would be good
for iCalendar though, as it's RRULEs are overly complex at
the moment.

The authors of CPL don't seem to consider 2. to be viable,
as 0(1) computation of a given time within an RRULE is of
prime importance to them. iCalendar RRULEs don't satisfy
this, within the scope of our combined mathematical abilities
at any rate.
http://www.imc.org/ietf-calendar/mail-archive/msg06220.html

Patrik seems to prefer a solution somewhere between 1. and 2.
He implied that the IESG wouldn't be overjoyed with with 3.,
but may be willing to accept it.
http://www.imc.org/ietf-calendar/mail-archive/msg06466.html

So where do we go from here?

--Alan

---

From: "Shannon J. Clark" <[email-masked]>
Date: Mon, 14 May 2001 12:41:35 -0500

A fourth option that I have suggested before - but does have a number of
issues with it, is that the RRULE's are separated from the iCalendar draft
and are made into a separate draft.

This has some advantages:

One - the resulting iCalendar draft is simplified which should help adoption

Two - Issues specific to reoccurrence rules can be dealt with in isolation
from a particular problem set (i.e. iCalendar) - this certainly includes
whether the rules can be resolved in O(1) or not.

Three - The reoccurrence rules would be available for use in new problem
domains where the full iCalendar is inappropriate - to use examples that
have been suggested here, as a possible grammar for reoccurrence rules for
cache refresh schedules.

To keep initial drift between standards to a minimum the first version of
the RRULES spec could be exactly what is present in the current iCalendar
spec.

(it has been observed previously here that the RRULES are one of the "only
things that make iCalendar special" - I beg to differ, and if this is the
case, it is an argument for moving them to a separate document.)

Shannon

Shannon J. Clark
JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Alan Davies
Sent: Monday, May 14, 2001 12:00 PM
To: [email-masked]
Subject: Re: Calsch and CPL discussions

--Alan

---

From: John Stracke <[email-masked]>
Date: Mon, 14 May 2001 14:06:10 -0400

> One - the resulting iCalendar draft is simplified which should help adoption

Actually, I suspect it would hurt adoption, because a calendar data model
without recurring events is not very useful.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |"If it failed then, there's no reason to think|
[email-masked]|we can't make it fail now." -- Colin Benson   |
\===============================================================/

---

From: Bob Mahoney <[email-masked]>
Date: Mon, 14 May 2001 14:38:37 -0400

Patrik-

Pat and I have spoken about this, as well as some of the calsch 
document editors, and we're making a resolution of this question our 
highest priority.

We think we have a couple of outstanding questions not yet answered 
by CPL, and we're going to try and refresh those to the list.   Also, 
one of the document editors (Eric Busboom) is going to try and call 
Jonathan today and discuss the issue.

In short: Message Received, and we're working on it.

-Bob

---

From: "Shannon J. Clark" <[email-masked]>
Date: Mon, 14 May 2001 13:59:20 -0500

I didn't mean to imply that the iCalendar would then not have a reoccurrence
rules - that would indeed not be very useful at all.

Rather, I mean to suggest that iCalendar USE reoccurrence rules which are
themselves defined in a separate document. That is, the iCalendar spec would
be spec that uses the RRULES, which would be available to be used by other
specs or used separately by applications.

Thus the revised iCalendar spec would be a simpler document which used the
RRULES by reference, rather than by definition.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Monday, May 14, 2001 1:06 PM
To: [email-masked]
Subject: Re: Calsch and CPL discussions

---

From: John Stracke <[email-masked]>
Date: Mon, 14 May 2001 15:27:31 -0400

"Shannon J. Clark" wrote:

> That is, the iCalendar spec would

I don't see how that would be useful, though; if you want to incorporate RECUR,
you really need most of the machinery of iCalendar.  You may not need, say,
COMMENT, or ATTENDEE, but it'll be easier to leave those out than to reinvent
RRULE, RDATE, EXRULE, EXDATE, DTSTART, DTEND, TZID, VTIMEZONE, and all the
rest.

> RRULES by reference, rather than by definition.

But, if you have to use the external document, then things aren't simpler,
they're harder, because you have to keep chasing pointers.  Worse, if people
don't realize they have to go find the RECUR definition, then we can wind up
with noncompliant implementations.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Some days, it just doesn't pay to gnaw through|
[email-masked]|the straps.                                   |
\===============================================================/

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 16 May 2001 07:01:23 +0200

> In short: Message Received, and we're working on it.

Thanks!

  paf