Subject: IPTEL spec and iCalendar

From: [email-masked]
Date: Thu, 25 Jan 2001 05:47:36 +0000

The IESG is reviewing the draft-ietf-iptel-cpl draft, which uses iCal time 
spec for occurances of events. They use a subset of the iCal specification 
and we need to know if this is valid. Basically, if the phone people have 
problems with the spec, we in the calendar group also should have 
problems.

We need to have people on the list go look at the draft 
"draft-ietf-iptel-cpl" and see if we see potential problems/issues.

We have been asked if we handled recurrence rules during interoperability 
testing.  I told our AD that this was not done in the first pass.  WE know 
recurrence rules are going to be a challenge.  Here's probably yet another 
one as well.

Also, if anyone can provide a brief description of what part of recurrence 
rules must be implented to be compliant with ical, it would be helpful. 
I'll forward that on to the iptel people. 

Thanks for your help.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Jan 2001 08:16:14 +0100

>"draft-ietf-iptel-cpl" and see if we see potential problems/issues.

It is extremely important that this is done in a timely fashion. The 
document has passed last call in the IETF, and I as AD was suprised 
that noone from this wg did send in any comments. The spec do use 
your specification, and you should have _some_ comments I thought.

Anyway, because of this, I personally blocked the document in the 
IESG until I get comments from you in this wg.

I expect comments no later than tuesday next week, or I have to make 
a decision that "no comments" from this wg during last call really 
means that you don't feel we might end up in interoperability 
problems in the future between ical and cpl applications.

    Patrik

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

---

From: John Stracke <[email-masked]>
Date: Thu, 25 Jan 2001 10:48:48 -0500

Patrik Fältström wrote:

> that noone from this wg did send in any comments.

Was there a mechanism to tell us that it used iCalendar? Near as I can
tell, it was not mentioned on the calsch list; and I don't think the I-D
announcements mention what specs the draft references.  So, to catch
everything that references iCalendar, we'd have to read all the I-Ds that
come out; I don't think any of us has time for that.

I don't mean to be argumentative; I will go and read it now.  I just
don't think it's surprising that we didn't catch it earlier.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"The Elliot 903 was the first portable I ever   |
[email-masked]|used, though it needed a furniture van to *make*|
|                |it portable." --Will Rose                       |
\=================================================================/

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Jan 2001 17:15:25 +0100

>come out; I don't think any of us has time for that.

Grep is your friend.

You (in the most undefined way possible) is a wg which defined 
Calendar properties for use on the Internet. If I were you, I would 
check all different wg's and I-D's for any kind of references to the 
definitions you use, or where what you have done could be used.

There are reasons we have an IETF wide last call.

Who should else do it?

>I don't mean to be argumentative; I will go and read it now.

Thanks.

    paf

---

From: John Stracke <[email-masked]>
Date: Thu, 25 Jan 2001 11:44:26 -0500

Patrik Fältström wrote:

> >Was there a mechanism to tell us that it used iCalendar?
>
> Grep is your friend.

Point taken.  :-) I'll dust off the procmail manpage.

|eCal Corp.      |World domination should never be left to chance.|
[email-masked]|                                                |

---

From: John Stracke <[email-masked]>
Date: Thu, 25 Jan 2001 11:43:39 -0500

[email-masked] wrote:

> The IESG is reviewing the draft-ietf-iptel-cpl draft, which
> uses iCal time spec for occurances of events. They use a subset
> of the iCal specification and we need to know if this is valid.
> Basically, if the phone people have problems with the spec, we
> in the calendar group also should have problems.

OK, some points:

   * They use DATE-TIME values in their "time nodes", but specify
     that they may not contain the timezone, since the timezone
     is specified at a higher level.  I think this is probably
     OK.
   * They do not actually reference the iCalendar recurrence rule
     spec; they define their own which imitates it, except:
        o In order to make sure that no two instances of an event
          overlap, they:
             + forbid the duration of a repeating event to be
               greater than 24 hours,
             + forbid "freq" to be "secondly", "minutely", or
               "hourly",
             + do not support "bysecond", "byminute", "byhour".
        o In order to make sure they can evaluate the expression
          in O(1) time, they do not support "count" or
          "bysetpos".
             + The problem is that, in order to apply count or
               bysetpos, you have to expand the recurrence set,
               which could take an arbitrary length of time.

I think these changes may be reasonable for the problem domain
they were trying to solve, but it is certainly not compatible
with iCalendar.

> Also, if anyone can provide a brief description of what part of
> recurrence rules must be implented to be compliant with ical,
> it would be helpful.

Um...it's all of them, isn't it?

This is potentially a problem.  The motivation they give for
using the iCalendar model is:

     This allows CPLs to be generated automatically from
     calendar books.  It also allows us to re-use the
     extensive existing work specifying time intervals.

Clearly, if they don't support the full RRULE syntax, they can't
meet the first goal.  Forbidding the sub-day recurrences may be
OK (they're unlikely to be used often), but count and bysetpos
are likely to be used regularly.  To translate such a repeating
event into a CPL, one would have to enumerate all the instances.
On the other hand, for code that's meant to run in telephony
switches, that may be better than supporting rules that take O(N)
time to evaluate.  But what they *could* do is support count and
bysetpos, and enumerate the instances once, when the CPL is
loaded, rather than each time it's executed.

In the reverse direction--CPLs being turned into iCalendar
objects--I don't see a problem; it's a subset.  However, there
will be a problem if they go from iCalendar to CPL and back; if
the original iCalendar object uses count or bysetpos, then the
one generated from the CPL will be expanded with a long list of
RDATEs rather than being the original rule.  This means that, if
you want to use something that manipulates iCalendar to edit your
CPLs, things are going to work sort of OK when you first create
the CPL, but get messy when you go back and edit it.

Also, one nit: they keep referring to iCalendar as "iCal".  Not
important--certainly not important enough to hold up the Draft on
its own--but it'd be nice to change if other changes are going to
be made anyway.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Do not suspect that I am not human.          |
[email-masked]|                                             |
\==============================================================/

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Jan 2001 18:38:32 +0100

>its own--but it'd be nice to change if other changes are going to

This is easy. Changes like this I can request at the RFC Editor.

Remember: Don't filter what you think is needed changed or not. Let 
me know everything you want changed, why, and of course with weights.

The rest I don't comment on. I let you on the list think about it.

Good comments, and exactly what I found :-)

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Jan 2001 18:28:23 +0100

>Point taken.  :-) I'll dust off the procmail manpage.

Sorry I forgot the smiley.

I am partly serious and partly very laid-back as you seem to understand.

We all have some kind of responsibility of reviewing things that ends 
up as RFC's. Yes, I am the last line of defence (against publicing 
stupid things) together with the other individuals in the IESG, but I 
am very scared if you all trust me. All Area Directors are humans 
(even if I understand you sometimes ask if that is the case...).

If nothing else, you should know by now that I don't know everything!!! ;-)

I even appreciate if you send me a note IF you review something, just 
anything, send me a mail with the name of the I-D, and specifics you 
think, and ALSO if you like it.

You don't even have to do it during last call!

    paf

---

From: John Stracke <[email-masked]>
Date: Thu, 25 Jan 2001 17:45:05 -0500

> Point taken.  :-) I'll dust off the procmail manpage.

Tonight or tomorrow, I'm going to set up a tool to monitor the I-D
announcements and look for interesting ones.  I'm thinking of having
the calsch-related ones it finds go to the calsch list.  Anybody
object?

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |In the country of the blind, the one-eyed man is|
[email-masked]|in therapy.                                     |
\=================================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 25 Jan 2001 17:44:17 -0600

It seems to me that monitoring the announcements and passing along important
ones would be a useful tool, might want to be shared with other working
groups as well - if this problem is occurring with the iCalendar standard, I
have to assume that other standards have and are having the same problem,
different groups using or modifying a standard without reference back to the
standards groups.

Just a thought on my part.

Shannon

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Thursday, January 25, 2001 4:45 PM
To: [email-masked]
Subject: Re: IPTEL spec and iCalendar
Importance: High

---

From: John Stracke <[email-masked]>
Date: Fri, 26 Jan 2001 09:52:52 -0500

"Shannon J. Clark" wrote:

> groups as well

That did occur to me, but I don't want to have to keep the tool running for
everybody in the world.  I'll probably ask my boss's permission to release the
tool under the GPL.

|eCal Corp.      |This space intentionally not left blank.     |

---

From: "Shannon J. Clark" <[email-masked]>
Date: Fri, 26 Jan 2001 11:49:51 -0600

John,

It seems to me that such a tool might be a good thing to have running
directly at the IETF and/or IMC main mailing list servers - basically what I
am envisioning is a tool that for each group that is currently set up, and
for all future groups that are created a set of defining terms is created:

	For the Calendaring and Scheduling group this could be a list such as:
iCalendar, iCal, vCalendar, vCal, CAP, iMip, iTip, iRip, and the specific
RFC #'s that we cover.

Each group would then maintain this list as a list of "What our topics are/
What needs to be addressed by us"

The software would then monitor the following items - announcements of new
RFC's and drafts (including a mechanism to probably scan the documents
themselves as well as the announcements w/links?). Potentially this same
software could watch the other group mailing lists for discussions that
touch upon this group's interests (along the line of - hey should we use the
iCalendar standard in our work...) - the actions taken by the application
could differ depending on the mailing list it is monitoring -

	Perhaps announcements and other drafts that reference one of this group's
areas of responsibility could be immediately brought to the attention of
this group, discussions of our standards on other groups might just be
brought to certain individuals?

It feels like a tool that once created the various groups won't know how
they worked before it was available.

Shannon

-----Original Message-----
Sent: Friday, January 26, 2001 8:53 AM

That did occur to me, but I don't want to have to keep the tool running for
everybody in the world.  I'll probably ask my boss's permission to release
the
tool under the GPL.

---

From: John Stracke <[email-masked]>
Date: Fri, 26 Jan 2001 13:23:37 -0500

"Shannon J. Clark" wrote:

> directly at the IETF and/or IMC main mailing list servers

Perhaps, but it's not up to me.  I'm going to write the tool to be extensible like
this (even for my own use, I want to watch for more than just iCalendar); but I
don't know if it either the IETF or the IMC has the spare computrons to have it
watch for N+1 different patterns.

|eCal Corp.      |Solipsists have all the fun.                 |

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 26 Jan 2001 22:37:36 +0100

>watch for N+1 different patterns.

Don't forget to resolve the issue with the cpl document though. Pat, 
can you see that a dialogue starts between your people and the cpl 
people so this gets resolved?

I.e. it all started with the cpl people was told by me to contact you.

   paf

---

From: George Babics <[email-masked]>
Date: Sun, 28 Jan 2001 16:29:59 -0500

[email-masked] wrote:
> 
> The IESG is reviewing the draft-ietf-iptel-cpl draft, which uses iCal
> time spec for occurances of events. They use a subset of the iCal
> specification and we need to know if this is valid. Basically, if the
> phone people have problems with the spec, we in the calendar group
> also should have problems.
> 

  - They recommend using the Olson database on timezones. However, it
    should be noted that it is incomplete.

  - iCalendar does not have a notion of "floating" times for recurrence
    rules. A local time zone must be specified. This is the only
inconsistency
    that I found with iCal. For their purposes they need not be
consistent,
    however they may want to note this difference.

> 
> We have been asked if we handled recurrence rules during
> interoperability testing.  I told our AD that this was not done in the
> first pass.  WE know recurrence rules are going to be a challenge.
>  Here's probably yet another one as well.

  We still have some unresolved issues with recurrence rules.

  Eric has a list of iCalendar issues at:

    http://www.softwarestudio.org/iCal/2445Issues.html

  Having a quick glance at the list revealed that CPL may
  also encounter issues with the "BYXXX" parameters.

> recurrence rules must be implented to be compliant with ical, it would
> be helpful.  I'll forward that on to the iptel people.

  One must implement all parts of recurrence rules to be compliant with
iCalendar.  There are no different levels of support.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 29 Jan 2001 04:05:55 +0100

>     however they may want to note this difference.

I would like to see them reference the spec _you_ do in this wg, full stop.

Is it possible to negotiate (or whatever) to a situation when that is possible?

Has anyone contacted the cpl guys (Pat?)?

   paf