Subject: [IPTEL] supporting CPL versions

From: dENIS Vandersteene <[email-masked]>
Date: Thu, 24 Aug 2000 11:57:58 +0200

Hi there,

    Are we supposed to support all the versions of CPL (00,01,02) on the
servers side, or, as I guess, do we just have to support the latest
version of the draft, and refuse any CPL-script compliant to an older
version? (this is important as the time-switch has been completly
changed).

    thanks,

        dENIS

--
Denis Vandersteene
Software Engineer
Indigo Software
50 Rue Wiertz
Brussels, 1050 – Belgium
Tel. +32 2 230 35 94
[email-masked]
http://www.indigosw.com
--------------------------------------------

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: James Undery <[email-masked]>
Date: Thu, 24 Aug 2000 11:15:16 +0100

> version? (this is important as the time-switch has been completly

Hopefully this will become irrelevant once the Internet Draft becomes a RFC,
however I hope the problem of the complexity of time zones can be resolved.
The solution I favour is a far simplified version where the script specifies
an offset (say from GMT) and the problem of time zone changes is addressed
by re-registering. I think this is acceptable because unlike calendar events
where it is reasonable to expect events to be stored for years, I don't see
registrations of scripts lasting that long (in the case of users scripts).
This would simplify CPL dramatically yet still allow intelligent end points
to readjust scripts when time zone changes occur if required.

James Undery

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Aug 2000 09:47:08 -0400

> to readjust scripts when time zone changes occur if required.

There are two major complexities in the current time switch, actually.
The timezone issue is one of them, and another is the recurrence rules.
Nearly as I can tell, it is pretty much impossible to answer the
question "is the current time within the interval of one of the
repititions of the event" without computing all of the start times for
the event repitions after dtstart, and then checking if the current time
is within the duration of each event. This quickly leads to tons of
computations as the current time gradually moves farther away from the
dtstart value. Maybe I'm wrong (I wish i were).... this is based on the
libical implementation which apparently does this kind of thing.

I understand the desire to be compatible with iCal, but I fear that no
one will implement this thing completely, and even fewer folks will
implement it correctly. Is there any way to simplify and retain some
level of interoperability with ical? What if we keep the time and
duration formats, and allow for repition, but eliminate the "by*"
parameters which is most of the nightmare of this thing?

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: James Undery <[email-masked]>
Date: Thu, 24 Aug 2000 15:49:21 +0100

> The timezone issue is one of them, and another is the recurrence rules.

Definitely.

> parameters which is most of the nightmare of this thing?

From a quick first glance this would appear to be a good solution, however, I am
less convinced about simplifying recurrence this way, principally because I like
the idea of specifying the last concepts like "the last friday of the month". I
also understand that compatibility with iCalendar may be nice from a philosophical
viewpoint, but, as a CPL implementor it is too complex for my needs and I would
prefer to return to something closer to the syntax of draft 01 for time nodes.

James Undery

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Aug 2000 00:55:09 -0400

> prefer to return to something closer to the syntax of draft 01 for time nodes.

I agree, although I'll note that this syntax does not, AFAIK, allow you
to say things like "the last Friday of every month". 

We could always add support for iCal style time switches in the next
revision of CPL, which could then support both.

This does lead to another interesting question we need to address before
finishing CPL - extensibility. What is the means by which we will be
able to add new tags later on? Should we have a version number in there?
Should servers simply reject scripts with tags or attributes they don't
know? Can we make use of XML namespaces to manage these things?

-Jonathan R.

---

From: James Undery <[email-masked]>
Date: Fri, 25 Aug 2000 10:08:44 +0100

> to say things like "the last Friday of every month".

From what I can recall there was a suggestion in the "implementation notes" about using
negative numbers in a similar way to the "by*" parameters in version 02.

> revision of CPL, which could then support both.

This would be nice as I'd like first CPL RFC to be a simple as it need be and then
problems with backward compatibility in future versions would be minimised. (When CPL is
in use and we have a better idea of how it is to be used in practise.)

> know? Can we make use of XML namespaces to manage these things?

This is definitely an important issue that needs to be addressed, firstly I'd like to
note we do have a version number in the DOCTYPE tag, however, is it possible to do
something similar to HTML where unknown tags (or the tag and all enclosed tags) are
ignored. I not sure that this suggestion is a great idea though, currently I reject
anything I don't understand which at least means the script should always do what was
intended, but could make scripts a pain to generate (until the RFC is out).

Before I mention XML namespaces, I must admit I don't really understand them, however,
superficially appear to be used to allow tags from multiple documents to be included
another document. The problem with using namespaces with CPL is that a lot of knowledge
about tags is outside of a schema yet must be provided in order to execute a script
containing the tags. (Assuming the tag is reachable via an execution path.) Using
namespaces to allow use of tags as they were defined in previous versions would be
possible (although this would mean backward compatibility wasn't built-in originally).
However, when it comes to unknown tags it would still be impossible to run the script
(although now we could at least parse it if the namespace URI pointed to a DTD or
schema).

I hope these rambling make some sense

James Undery

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Aug 2000 11:29:04 -0400

I don't think versioning is sufficient, for the same reason that
versioning doesn't work too well on any existing protocol, except as a
wholesale replacement (IPv4 to IPv6). For the time problem, this is even
harder, since you end up with either two different versions of the CPL
(bad) or have both time switches in the CPL, with messy results. One
solution would be a tag similar to how frames work in HTML, where you
can say something like

<if you support this feature>
this feature
</>
<if you don't support this feature>
some older stuff
</>

This may be necessary since you may need to compose the missing feature
of several nested conditions, for example.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: James Undery <[email-masked]>
Date: Fri, 25 Aug 2000 17:14:45 +0000 (GMT)

> of several nested conditions, for example.

The problem there is that isn't how frames work, although, to use the
frames idea how about

<subaction id="newflashytags>
	New flashy tags
</subaction>

<incoming>
	<magictag ref="newflashytags>
		Old style tags
	</magictag>
</incoming>

And add the rule similar to HTML that unknown tags and their attributes
are ignored, but anything within the tags passed though and parsed. i.e.
in the above fragment if you understood "magictag" tags you execute the
new code, otherwise you execute the base CPL tags.

James Undery