RE: Use of HTTP as a base for protocols (CAP)

[Dan Hickman <rockinsoftware@xxxxxxxxxxxxxxxxxx>]

I envision a much greater use of shared calendars.  There will be a 
multitude of shared event calendars (not personal calendars) that will be 
available on public and semi-public ICAP servers.  Things such as sporting 
events, concert schedules, important dates in history, club calendars, 
business schedules and timelines, conference schedules, holiday lists, etc, 
etc, etc.

The ability to point to a public/semi-public calendar server, browse events 
and import the ones you want into your calendar is a great benefit of 
iCal/ICAP that should not be overlooked.

Don't get me wrong.  I am definitely not a proponent of adding any special 
proxy-cache handling to the protocol, I just wanted to point out the need 
to have anonymous and shared access to calendar stores.  K.I.S.S. should be 
our motto here.  Base functionality should come first.

As a note, I whole heartedly agree with Rob Earhart's suggestion that we 
first focus on the operations that need to be supported and the data that  
 needs to be passed and then worry about the wire protocol later.  I think 
things have gotten sidetracked with all this HTML/NO HTML debate.

Regards,
Dan Hickman
Rockin' Software
dhickman@rockinsoftware.com
http://www.rockinsoftware.com


> -----Original Message-----
> From: Mark Horton [mailto:mark@lucent.com]
> Sent: Tuesday, November 10, 1998 7:17 AM
> To: 'ietf-calendar@imc.org'
> Subject: Re: Use of HTTP as a base for protocols (CAP)
>
>
> I'd expect that the vast majority of calendar accesses are people
> accessing their own calendar, although an important but small
> minority of accesses come from others browsing your calendar.
> It ought to be very rare for these accesses to go through a firewall,
> as the servers will typically be inside any firewall.
>
> But this is all moot.  If you want to be able to use proxy, just
> use TCP rather than UDP.  You can proxy any TCP port, not just 80.
> There are proxy-tized versions of telnet, ftp, finger, IRC, etc.
>
> 	Mark