Subject: Re: Can we fix BYSETPOS?

From: [email-masked]
Date: Tue, 12 Jun 2001 21:37:27 -0400

Jonathan, I do not believe we are hearing a "concensus" on your statement 

"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."

I think we are hearing a few voices saying it's possible that maybe is 
this is right. However, there are over 300 people who "lurk" on this list 
- I believe I need to hear a few more than 5-6 to say it's a concensus.

List, let's hear from some other listeners - do you agree with what 
Jonathan says above.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Jonathan Lennox <[email-masked]>
Sent by: [email-masked]
06/11/01 07:10 PM

        To:     [email-masked]
        cc:     Alan Davies <[email-masked]>, [email-masked]
        Subject:        Re: Can we fix BYSETPOS?

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

> 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...

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.

> 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).

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?

> 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.

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.)

> 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). 

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.

> 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??

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]

---

From: "Graham Gilmore" <[email-masked]>
Date: Fri, 15 Jun 2001 11:11:49 -0400

----- Original Message -----
From: <[email-masked]>
To: "Jonathan Lennox" <[email-masked]>
Cc: "Alan Davies" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: 12 June, 2001 21:37
Subject: Re: Can we fix BYSETPOS?

> List, let's hear from some other listeners - do you agree with what

    After some thought on the topic, I'd have to agree with .  iCalendar
is simply a data format, and only tells the implementor what the
information means, not how it must be dealt with.  I don't think
anyone's having issues parsing the data; the IPTel people are having
difficulties dealing with the full scope of the information once it's
parsed, but that would seem to be outside the scope of the RFC.  As long
as an implementation can recognize an iCalendar object, I don't see any
problem with that implementation then deciding that it doesn't want to
deal with that object ("Filter out any iCalendar whose Organizer uses a
Hotmail account," for example).

    Graham