Subject: Re: Can we fix BYSETPOS?

From: [email-masked]
Date: Mon, 11 Jun 2001 18:32:58 -0400

Jonathan responded with:
>As we've discussed before on these lists, we have two choices when it 
comes
>to dealing with absurd statuses:
>
>1. Let each implementation decide what it isn't going to handle.
>2. Let the standard limit what implementations have to support.
>
>The problem with choice 1 is that it effectively abandons 
interoperability.

Well unless you expect _every_ implementation to implement every feature/option the exact same way then 
this is not really a problem.  We would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP (or... ) since every implementation 
implements only a fixed set of features and we would never have a 
migration case since the set never grows w/o _every_ implemenation 
concurrently rolling it out... 

Ok, the sarcasm was a bit heavy there but I got stuck in a 2.5 hour mtg 
today for no reason so Im a bit punchy.  But the logic that "If my engine 
does not like Feature X of a protocol for some reason so it wont be able 
to interop with others that do" is simply a myth if the protocol plans 
ahead and provides ways for conveying this back (hence some of the 
REQUEST-STATUS values in iTIP).  By having a negotiation mechanism in the 
protocol you increase your interop chances/abilities, not decrease them. 
Otherwise LDAP, TLS, SASL, or RFC 1869 and other protocols that have put 
in such mechanisms would be as interoperable as they are now.

>If I generate a calendar object, I have *no idea* whether any given 
server
>is going to be able to deal with it correctly, or is going to reject it.

Before we accept that most CUAs are going to actually generate and use 
some of these "absurd" entries I'd contest the fact that they would to 
begin with.  The existing C&S CUAs from CalConnect do a decent job of not 
actually generating some of the overly complex, nasty or "absurd" entries 
so is it realistic to think that the current or immediately pending crop 
of CUAs are going to generate them?  Probably not.  Even if someone redid 
an OpenSource C&S app to generate them; its not likely to be the SOP we 
will find in day to day usage.

For the CPL case the CUA / CS has some restrictions on what it will be 
able to accept (ie: no sub-day recurrences) but is that an "absurd" case 
like "repeating every second of every day of the year" or a more realistic 
case like "The walking tour of Boston begins at 9:00AM and again at 1:00PM 
EST".  The CPL worlds requirements are such that it cannot accept 
(currently) some kinds of real world examples (not absurdities) and that 
is fine; its part of their model of things.  In the future there will be 
other models that do not have those restrictions (ie: SKiCAL). 

Does this mean that a SKiCAL 'valid' (or 'correct' or pick your own term) 
object is not valid in the CPL context??  Perhaps for now but that may 
change as Moores law takes over or the requirements / restrictions of CPL 
evolve.

So some may ask why not just remove the "absurd" stuff now but keep in 
mind that our recurrence grammar is intended to be reusable by anyone else 
(ie: SKiCAL, CPL, etc) and to be flexible enough that any future needs are 
not going to force us to make wholesale changes.  To this end, removing 
stuff that could be abusive or absurd given our current expectations but 
that could be valid later on is just an excercise in frustration for the 
future updaters. 

>Remember, RFC 2445 is a data format.  You're not always running in an
>environment where you're going to get back a REQUEST-STATUS to try to
>negotiate a sensible representation.  Consider an "Export as iCalendar"
>option, for instance.

Again this last bit assums that some to-be-written CUA will actually 
generate internally (and use??) an absurd case and I challenge that 
assumption.  Sure, it is possible to build a CUA that is purposely nasty 
but is that a realistic norm or a "what about" kind of exception to the 
rule??

I am also considering the case that the recurrence model is the only part 
of iCalendar that is adopted (ie: the data actually sent is NOT in 
iCalendar format entirely).  This too relies on the actual underlying transport/protocol to plan for a 
negotiation or request/response kind of mechanism when dealing with these 
abusive critters.  Is that an issue for iCalendar to deal with or an issue 
for each reusing implementation/protocol??

>Thus, the track I've been advocating -- and I think a lot of the other
>people here have agreed with me -- is that we instead have to limit the
>things the specification allows.

Its one thing to put the restrictions in the 'base' definition in 
iCalendar.  Its another to put them in any derivative works.  I see no 
issue w/CPL putting restrictions on what they can accept (and I'd hope 
they do it with some planning for future growth or system improvements). I 
do see an issue in putting in restrictions that make the grammar 
incomplete in the base work. 

Putting logical restrictions on value sets like BYSETPOS is between -366 
and 366 for a FREQ=DAILY but -31M and +31M for SECONDLY, etc. is something 
I think should be done.  There are some logical limits to the values given 
some conditions; I just dont agree w/the proposals to remove some of the 
actual conditions.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Jun 2001 19:10:33 -0400 (EDT)

On Monday, June 11 2001, "[email-masked]" wrote to "Jonathan Lennox, Alan Davies, [email-masked]" saying:

> >comes to dealing with absurd statuses:
> >
> Well unless you expect _every_ implementation to implement every
> feature/option the exact same way then this is not really a problem.  We
> would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP
> (or... ) since every implementation implements only a fixed set of
> features and we would never have a migration case since the set never
> grows w/o _every_ implemenation concurrently rolling it out...

iCalendar COS isn't like IMAP4 or SMTP.  iCalendar COS is like RFC822 or
HTML.  It's a data format.

iTIP is like IMAP4 or SMTP.  It's a transaction protocol.

When RFC822 was extended with MIME you got "If you can see this, your mail
reader doesn't understand MIME" blocks, and large unreadable blobs of
base64-encoded text.  When HTML was extended with frames, you got <noframes>
sections that were supposed to contain equivalent content, but actually
contained "Netscape Now!" buttons.

Or, in other words, extensibility in data formats is almost always painful.

Now, mind you, sometimes you need to have your data formats be extensible.
However, when you do this, experience seems to have shown that the right
thing to do is to have the thing say, up front, "I'm an extended-X.  I may
look like an original-X, but I'm not, so if you don't know what an
extended-X is, give up now."

This also means that you need a clear distinction between "original-X" and
"extended-X."  Having them shade vaguely into each other is a bad idea.

> REQUEST-STATUS values in iTIP).

If there's a protocol which is specific to your application, yes.

Are you saying I shouldn't be able to e-mail you an iCalendar object, or to
put it on my web page?

> will find in day to day usage.

Oh, absolutely.  I reached this point of view by worring about entries
generated by actively hostile adversaries, who want to launch a
denial-of-service attack on my server by feeding me input that makes me fall
over.  If you're not worried about this case, things are not nearly so much
of a problem.  (Though I would say that current experience in the Internet
seems to indicate that you *do* have to worry about this.)

> other models that do not have those restrictions (ie: SKiCAL). 

My original model of CPL was to define a number of restrictions on what a
CPL script had to accept.  This was where the IESG got all up in arms --
"you're breaking interoperability with iCalendar!"  Okay, I figured,
interoperability with iCalendar on (moderately) complex or pathological
cases is important, so we need a good definition of what's allowed and
what's too complex or pathological.  But now I'm hearing that CalSch
*doesn't* want to define this, that each implementation is allowed to pick
its own definition of complex and pathological events.

So I find myself in the situation that I'm told I have to be fully
interoperable with a number of implementations which aren't fully
interoperable with each other.  This is ... challenging.

Is this group willing to say, definitively:

   Every iCalendar CS or CUA implementation is allowed to pick its own
   definition, aribitrarily, of what event descriptions are too complex for
   it to handle, and refuse to handle such event descriptions.  Such
   implementations are still fully compliant implementations of RFC 2445 and
   its successors.

If so, I'll just resurrect the last CPL draft with some minor editorial
changes, tell the IESG about the CalSch working group consensus, and be on
my way to Proposed Standard.  However, I suspect the IESG would have
*serious* concerns with this statement.  (And I don't think the group would
be willing to say it, anyway.)

As I mentioned in my earlier mail, I think the following statement would be
much more generally acceptable:

   Every compliant iCalendar CS or CUA must be able to correctly understand
   a certain basic subset of event descriptions, defined by the
   specification.  They may also understand more general event
   descriptions.
   Compliant iCalendar CS or CUAs should not generate event descriptions
   beyond the basic subset unless they know that all receivers of the event
   can understand them correctly.
   Profiles of iCalendar can declare that a larger subset of iCalendar is
   required for that profile.

> but is that a realistic norm or a "what about" kind of exception to the 

Some of both.  If I'm writing a powerful CUA, I want to know what sorts of
things I should *avoid* generating to prevent a CS from choking.  (For
instance, I know of calendaring applications that refuse to deal with events
with more than 500 or so repetitions.  I don't think these applications
currently make any claim to iCalendar support -- they're just vCalendar, or
something proprietary, I think -- but it's the sort of thing you have to
worry about.) 

-- 
Jonathan Lennox
[email-masked]