Subject: Oslo assignments

From: [email-masked]
Date: Tue, 27 Jul 1999 21:37:16 GMT

This is a quick note to update everyone on some assignments from Oslo. 
Based on the following feedback from our AD, Patrik, we will be working on 
a quick RFC to help people understand what is required to implement 
calendaring protocols.  Here's an excerpt from his note:

I suggested in Oslo that a (short) RFC was to be produced by the wg which
presents what the minimal requrements needed when passing around iCalendar
events via email (as a suggestion). I.e. something which can be used when 
I
want to for example invite the two of you to a meeting. What is it my and
your software need to handle? CAP is not needed, as the calendar software
we use doesn't have to really share calendars to make this working. I.e. a
minimalistic approach to calendaring. That paper would explain the first
step, for "the little people", how good CALSCH specifications are, and
hopefully make more people use it. This is for example what the SKI team
and others need when publishing event information on the web.

Then, the CAP way of solving things is more complicated, and more powerful
of course, but not needed for all kind of usage. That is, as I see it, the
proffessional version of internet calendaring.

In Oslo, Bob Mahoney and Alex Taler volunteered to work on this draft.  We 
worked on an outline which I will post in another note.  Please provide 
feedback on that outline and state what needs to be included, removed, 
etc.

---

From: Doug Royer <[email-masked]>
Date: Tue, 27 Jul 1999 15:18:20 -0700 (PDT)

> From: [email-masked]
> To: [email-masked]
> 
> >> (From Patrik?)

It was my understanding after talking to Greg FitzPatrick that they
are not emailing around PUBLISH's.  They wanted people to view a web
site.  So I guess they could have the links point to iCalendar (MIME)
objects that could be downloaded.

However that does not solve all of their problems.  There is still no
standard way for a user to get that downloaded iCalendar object into
their calendar.  That is why CAP exists.

> of course, but not needed for all kind of usage.That is, as I see it, the

True its not always needed.  However just like email prior to IMAP and
POP; all calendar stores are vendor specific and you can not book
yourself onto a public calendar.  There would have to be programs
written to extract one vendors calendar data out, and store it into
your format (the classic N-to-N matrix problem).

I thought one of the SKI project goals was to be able to book time on
a calendar?

Some will argue that email solves this problem.  Just create an email
alias that some automatic process works on and 'does things'.  This is
okay for smaller calendars where there is not much conflict over time
slots.  Can you imagine the problems if a customer were to ask for
VFREEBUSY on a public calendar, the email is sent, a reply comes back
in a few minutes.  They send in a scheduling request, only to find
that all items have been booked in that 2-3 minutes.  CAP is the only
proposal for interactive booking of appointments.  Email may work fine
for interpersonal calendaring.  I do not think iMIP address the
booking needs of e-commerce, commercial, and public calendars.

So in that sense it is a professional version of calendaring.  However
I think internet calendar users are going to want to interact with those
professional calendars.  Thus we need CAP.

> etc

I would suggest that it also list the limits of an iMIP only
implementation. Off of the top of my head:

	(1) Scaleability. Piping all request through email
	    will only increase the delay for scheduling request and
	    incress the likehood of failed requests.
		
	(2) Hit and miss approach to scheduling (lets send the request
	    and see if we get that time slot). If not lets send
	    another one (see #1).

	(3) iMIP Spam. If iMIP is the only or best way to schedule
	    mail, you can get a whole new level of SPAM. (Go to
	    the we sell you something meeting - iCalendar attached).
	
	(4) CAP address authentication and access lists. iMIP does not.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked]
Date: Wed, 28 Jul 1999 14:54:59 GMT

Doug, I think this short RFC that Patrik has asked for is an excellent 
idea and is actually something I sort of wanted when I first started 
working on CAP.  It's a good kind of "guide to implementors" and one of 
the things I feel it will do is show exactly where CAP fits.  I believe 
that's one of the handicaps of this protocol - a lot of people don't 
really understand what it is and the gap it fills.  This simple RFC will 
do much to help people understand how all the pieces fit together and how 
to implement each piece.

---

From: [email-masked]
Date: Wed, 28 Jul 1999 15:44:16 GMT

Pat:
Suggest everyone take a hard look at the examples in iMIP. They explain 
each of these examples that Patrick asked for.
-- Frank

---

From: [email-masked]
Date: Wed, 28 Jul 1999 18:57:25 GMT

Doug:
Don't want to get into a long pro/con on iMIP but there is some weakness 
>                    incress the likehood of failed requests.

I have worked both on a client/server and email based C&S product team. 
The issue of failed requests is common to both implementation approaches. 
The server is often down for what ever reason. Mail can get lost due to 
bad email addresses, down MTAs etc. This argument is a wash. There is 
nothing here related to "scalability". It is more of an issue of 
"availability". 
 
>                     and see if we get that time slot). If not lets send
Assuming the deployment of CAP is impacted by enterprise "comfort" with 
giving CREATE access rights to "strangers", I would guess that even with 
CAP, you will be left with issuing iTIP REQUEST commands through CAP. This 
would make this issue a wash too.

>                    the we sell you something meeting - iCalendar 
attached).

See above. You are going to get calendar SPAM, no matter whether your 
calendar address is an iMIP or a CAP form of URI. 

>                (4) CAP address authentication and access lists. iMIP 
does not.
Right. Some would call this a "pro" for iMIP ;-)
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 Jul 1999 12:30:47 -0700 (PDT)

> From: [email-masked]
> Date: Wed, 28 Jul 1999 18:57:25 GMT
> 
> Doug:
> >                    increases the likelihood of failed requests.
> 

In the sense of multiple requests for retry when multiple users are
competing for the same resource and many overworked SMTP gateways.
And that fact that the MX record may direct your iMIP message via
paths unknown to you.  Through auto reply aliases, vacation programs,
list expanders, and other agents not yet aware if iMIP.  The makes
scaleability difficult to predict.

I see reliability the same as you. Independent of iMIP or CAP.

> would make this issue a wash too.

Yes. But without CAP there is no such thing as interactive scheduling
at all. Example, if I want to reserve a time slot on a public calendar
it is possible to do that in email. It is not possible to do that
interactively in email.

> calendar address is an iMIP or a CAP form of URI. 

True, however there are NO VCARs in iMIP. So your agent might
not know to filter them out. And iMIP authentication does not exist.
[email-masked]' can not authenticate with CAP as proposed.

> Right. Some would call this a "pro" for iMIP ;-)

True - I was not posting a list of when you want iMIP. I was posting
a list of when you want CAP. There *IS* a need for iMIP. I simply
wanted to point out there is a need for CAP and I think that a
beginners guide to iCalendar needs to point to the limitations
and problems that CAP solves.

-Doug

---

From: [email-masked]
Date: Wed, 28 Jul 1999 20:19:30 GMT

Pat: 
Right-on! I agree that we need a summary draft, like this. Lots of 
pictures and examples.
-- Frank

[email-masked]
Sent by: [email-masked]
07/28/99 10:54 AM

        To:     Doug Royer <[email-masked]>
        cc:     [email-masked], (bcc: Frank Dawson/CAM/Lotus)
        Subject:        Re: Oslo assignments