Subject: RE: CPL: Summary of what it is

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Aug 2001 01:05:32 -0400

> -----Original Message-----
> From: David L. Nicol [mailto:[email-masked]]
> Sent: Friday, August 10, 2001 5:54 PM
> To: John Stracke
> Cc: Henning Schulzrinne; Jonathan Lennox; [email-masked];
> [email-masked]
> Subject: Re: CPL: Summary of what it is
> 
> 
> John Stracke wrote:
> > 
> > In addition, using the database approach means that you can
> > spread the computation work
> 
> Please delete now if you don't want to get yelled at.
> 
> 
> How or what ever, these discussions are off topic!  A standard
> is an inclusive minimum!  The preferability of different 
> implementation options is off topic! Provide support for multiple
> methods (such as error messages on recurrance expression complexity)
> and let the CS implementors decide how they want to do it!

I agree. This thread was really starting to get me nervous. Requiring an
implementation to be built in a certain way in order to deal with a problem
within a specification itself seems to be a mistake. If computation about
whether the current time fits within a recurrence cannot be done in a
reasonable time bound, then that is the problem that needs to be fixed.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Bob Mahoney <[email-masked]>
Date: Mon, 13 Aug 2001 08:29:48 -0400

CALSCH Folks-

I think the questions about the assumptions underlying CPL were 
useful in allowing us to better understand the background of the 
problem.  But it would be best if we return to the question of 
whether we can accommodate the changes that have been requested in 
our work.

-Bob

---

From: John Stracke <[email-masked]>
Date: Mon, 13 Aug 2001 14:05:16 -0400

Jonathan Rosenberg wrote:

>Requiring an
But that statement already makes assumptions about implementation and 
about the spec: you are assuming a priori that the spec is broken and 
the implementation is correct.  I have pointed out that you can solve 
the problem by changing the implementation instead, trading storage 
(which is cheap) for CPU (which is expensive).

If I'm wrong, and such an implementation is not feasible, then say so.

-- 
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Diplomacy: The art of letting someone else have|
[email-masked]|your way                                       |
\================================================================/

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Aug 2001 16:29:43 -0400 (EDT)

> (which is cheap) for CPU (which is expensive).

This transformation -- turning the computationally-complex representation
into the computationally-cheap one -- is *itself* computationally expensive,
of course.

If the assumption is that access to recurrence information happens often,
and modifications to it happen only rarely, this is a valid optimization.
But this isn't true for all usage scenarios.

(It's also not true for the "prevent hostile or stupid users launching DoS
attacks" case.  What if some software bug causes someone's script to be
uploaded every five seconds?)

Now, admittedly, I've already gone a little ways down this path, for the
COUNT -> UNTIL transformation.  This is why, in my "defined SHOULD-strength
limits" proposal, COUNT values are one of the things that would be bounded.

Do you strongly object to the "SHOULD-strength limits" proposal, where we
define minimal implementation limits for RECUR interoperability?  It seems
to me like it'd solve everyone's concerns quite easily, but for some reason
there's been a lot of silence about it, and a moderate amount of complaint,
for reasons I don't really understand.

(This isn't to say that the storage-for-CPU implementation choice isn't a
reasonable one.  But I don't think it solves the problem I'm trying to
address.)

-- 
Jonathan Lennox
[email-masked]

---

From: John Stracke <[email-masked]>
Date: Mon, 13 Aug 2001 16:45:48 -0400

>into the computationally-cheap one -- is *itself* computationally expensive,
Yeah, but it's not done on the critical path in call processing.

>define minimal implementation limits for RECUR interoperability?
>
I think I do.  The problem I have with it is that I believe it'll 
actually hurt interop.  Most of the time, when you create an iCalendar 
object, you have no idea what the recipient's CUA will be able to 
handle.  This means that a properly cautious CUA will stick to the 
minimal subset.  A CUA that uses anything outside the minimal subset 
will be taking the chance that the recipient's CUA will misinterpret the 
object.  For example, if BYSETPOS were outside the minimal subset, and I 
sent an event to occur on the last Friday of the month, some recipients 
might see it as every Friday.

If we want to define a subset, we should throw out all the features 
outside the subset.  That's my ideal outcome; but I've been getting a 
lot of pushback from people who want those features.  My second choice 
is to come up with a way you guys can use RECUR as is.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"I said no camels! That's 5 camels! Can't you|
[email-masked]|count?" -- Indiana Jones & TLC               |
\==============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Mon, 13 Aug 2001 18:49:37 -0500

> might see it as every Friday.

This objection is nonsense.  Consider SMTP as a model:  SMTP has a 
robust method of declaring which optional add-ons any given SMTP 
server can do, and a default minimal behaviour to fall back to when
the extension doesn't work quite right.  I compose an e-mail and hand it
off to my MUA.  My MUA contacts the local MTA and negotiates the
transfer method and follows through on the negotiated method.

CAP follows SMTP in having central servers and user agents.  In a world
where CSes have different capabilities, I could tell my CUA that I am going
to be in my office from nine AM to six PM except 12:30 to 1:30 every
weekday except holidays on a list with a well-known name
(HOLIDAYS-US-FEDERAL
for instance) and the CUA would negotiate with the local CS as to what the
best way to upload that to the CS would be: as several thousand indivudual
availabity/nonavailability events or as one big expandable expression,
and furthermore does the CS know about the list of holidays or does it need
to have it listed explicitly.

> is to come up with a way you guys can use RECUR as is.

A standard is NOT the specifications document for a product.

-- 
                                           David Nicol 816.235.1187
"Tomato!"

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Aug 2001 14:50:56 -0400

David L. Nicol wrote:

(I've mostly taken to ignoring this guy, because he has no clue, but 
I'll make an exception in this case.)

>John Stracke wrote:
>
>>The problem I have with it is that I believe it'll
>robust method of declaring which optional add-ons
>
[...]

>CAP follows SMTP
We are *not* talking about CAP.  We are talking about iCalendar.  In 
general, there is no backchannel from recipient to sender.  If you had 
actually read what I wrote, you would understand this.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |He wondered if Elli was going to buy that    |
[email-masked]|explanation. His taste for heavily-armed     |
|                |girlfriends did have its drawbacks.          |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Aug 2001 15:11:59 -0400

> I'll make an exception in this case.) 

Oh my god, I meant to delete that.

Please excuse me.  That was much too insulting; I wrote it while 
irritated by something else.  This is extremely embarassing, especially 
given that part of the reason I've been skipping David L. Nicol's posts 
is that he said something I found insulting--to have dropped down to a 
similar level is mortifying.  It is not the case that he has no clue; 
it's just that I have grown tired of his take on credentials, and felt 
that he was ignoring the obvious in the one particular post I was 
replying to.

Time to cut back on caffeine again.

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |All your problems can be solved by not caring!|
[email-masked]|                                              |
\===============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Tue, 14 Aug 2001 14:27:11 -0500

> I'll make an exception in this case.)

A masterful paraphrase!

-- 
                                           David Nicol 816.235.1187
"Tomato!"

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 14 Aug 2001 14:43:50 -0500

A client recently suggested a "feature" that as far as I know (haven't
exhaustively searched the old archives) been addressed.

They would like to be able to define an event - which will then be made
"open" to a number of people - but with a preset limit.

i.e. the event could be published and/or people "invited" - but after some
set limit further attendees would not be allowed.

Obviously a particular calendar server could implement such a feature by way
of an X-param and careful handling of input flow - so my question is as
follows:

One - is such a feature already part of CAP or iCalendar (but I have
overlooked it?)

Two - is such a feature a part of any pending proposal - such as SkiCal? -
especially with PUBLISHED events ala SkiCal I could see a need for the
ability to set an upper limit on attendees for a given event (with
implementations being able to control what happens on reaching the limit -
perhaps just a message back to the user - or perhaps some other more dynamic
action such as generating a new instance of the event in question - though
this would then have other concerns...

In light of the recent discussions about the differences between iCalendar
and CAP etc. I think this type of functionality is yet another example of
something that would (could) work one way in a connected mode (CAP, iTip) in
a similiar but slightly different manner in a messaging mode (iMIP) but may
be highly problematic in a "pure" iCalendar mode (where iCalendar files or
other forms may be exchanged but no messaging service exists between
clients - for example an iCalendar file available on a website - obviously
in that case it would be highly unlikely to be able to handle this type of
feature.

Also - this raises a question about why PUBLISH events MUST not have
attendees - obviously for many PUBLISHED events that makes perfect sense
(i.e. a TV Schedule) - but for something like a PUBLISHED class it might not
make as much sense.

One option might be to force a generation of an invitation - so not a
PUBLISHED event but an invited one - but that seems potentially  very
clunky - especially is you need to "invite" far more people than will in
fact ATTEND. (and raises workflow questions about what additional messages
need to be exchanged between attendees - a published event is nice in that
it may not require that people who plan on attending the event also receive
modifications and changes that are changes to the list of who is attending
(especially in the current mode where published events can not have attendee
lists)

I look forward to comments and suggestions,

thanks all,

Shannon

Shannon Clark
President, JigZaw Inc
www.jigzaw.com
[email-masked]