Re: Oslo assignments

[Doug Royer <Doug.Royer@xxxxxxx>]

> From: pregen@egenconsulting.com
> To: ietf-calendar@imc.org
> 
> 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:
> 
> >> (From Patrik?)
>
> 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.

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.

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

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.

> 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

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
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
Pager:				Doug.Royer@Pager.Eng.Sun.com
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL