[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Use of HTTP as a base for protocols (CAP)
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,
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.
> -----Original Message-----
> From: Mark Horton [mailto:firstname.lastname@example.org]
> Sent: Tuesday, November 10, 1998 7:17 AM
> To: 'email@example.com'
> 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.