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

From: "Griffith, Adrian, CON, OASD(HA)/TMA" <[email-masked]>
Date: Tue, 10 Nov 1998 09:59:09 -0500

i am interested in building a calendar system that spans the globe. it will
support a VERY large hospital system (us military). it must interact with
firewallls appropriately.

adriang (newbie)

> ----------
> From: 	Mark Horton[SMTP:[email-masked]]
> Sent: 	Tuesday, November 10, 1998 8:17 AM
> To: 	[email-masked]'
> 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
>

---

From: Dan Hickman <[email-masked]>
Date: Tue, 10 Nov 1998 09:26:46 -0600

To correct myself in my last email, I was referring to the HTTP/NO HTTP debate.  Not HTML :-).

Regards,
Dan Hickman
Rockin' Software
[email-masked]
http://www.rockinsoftware.com

---

From: Dan Hickman <[email-masked]>
Date: Tue, 10 Nov 1998 09:22:25 -0600

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

> -----Original Message-----
> From: Mark Horton [mailto:[email-masked]]
> Sent: Tuesday, November 10, 1998 7:17 AM

---

From: "Mark D. Anderson" <[email-masked]>
Date: Thu, 12 Nov 1998 09:50:57 -0800

My $.02 on this thread...

1) The issue of firewalls and the ease of security configuration
for "the IS guy" is a red herring. So is most of the debate
about what is a proper "http extension".
Considering the incredible amount of uncontrolled stuff that is
already going through GET and POST requests, this is a drop in
the bucket. Real ACL control for web sites doesn't happen at the
router (beyond blanket source ip filtering); it happens in the web
server config. That said, iCap might think about using http but
on a different port (this is what IPP is doing), but i'm not 
convinced there is a real case for even that. iCAP will have to
have its own ACL as well (assuming no re-usable web standard shows up).
iCAP should use a PEP-related header in http; that should be
enough for the MIS and http extension mavens.

2) http will have to fix any transport problems it has.
it is so widely deployed for so many purposes, that i can't believe
there would be a reason based on its transport characteristics to
choose another protocol. http 1.1 was a step up, and http ng looks like it
will be another. iCap just has to be careful to keep its content
inside the envelope (unlike for example webdav, which is polluting
http headers for no clear reason).

3) iCap does have a use for http-specific features.
caching *will* be useful -- for the schedule of really popular
people, for community events, for entertainment schedules, and
so on. redirection will also be useful.

-mda

---

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Thu, 12 Nov 1998 18:41:49 -0800

Chris,

I have trouble understanding why a HTTP proxy makes it harder to traverse a
firewall.  The proxy is there for a reason.  First, companies want to make
it difficult for unauthorized access across a firewall.  Second, the proxy
allows caching and single-instancing of requests.  Could you elaborate on
"your experience"?  In my experience, an HTTP proxy is precisely the entity
that allows traversal of a firewall in a way that the administrator can
manage.

The next thing I'm confused about is the alleged distinction between a
transfer protocol and an access protocol.  Are you really suggesting that
the big gulf between access and transfer is querying?  What about a protocol
which does transfer as well as query?  I don't see a clear semantic
difference.  The "Transfer" in HTTP could well be "Access" -- HTTP is a
hypertext access protocol. 

The IMAP "disconnected-model" client took four years to arrive because IMAP
has a complex model which was difficult to implement.  How long did it take
for various web clients to spring up using the HTTP disconnected model?  

You'll have to explain more clearly how caching and proxying are so much
more complicated when I'm getting calendar items than when I'm retrieving
web pages.  I would think that web pages are more complex to cache because
many of them have code, whether on the server or client.  Web pages also
pull in changing content from other web pages.  In contrast, calendar items
are simple to cache/proxy because they change in fewer ways, less often.

Lisa

-----Original Message-----
From: Chris Newman [mailto:[email-masked]]
Sent: Monday, November 09, 1998 4:19 PM
To: Tony Small (Exchange)
Cc: [email-masked]'
Subject: RE: Use of HTTP as a base for protocols (CAP)

On Fri, 6 Nov 1998, Tony Small (Exchange) wrote:
> Our customers want a CAP that can efficiently
> traverse firewalls (not all the time, of course, but on a need by need
> basis.)

In my experience, an HTTP proxy makes it harder to traverse a firewall.

> If someone in my company is accessing a calendar outside a
> firewall, it would make perfect sense to store that information in the
cache
> so that it could be accessed efficiently later by another user in my
> company.  We certainly don't want to build a CAP where access hits a brick
> wall any time a firewall is involved, or where caching of information by a
> proxy server becomes a technical problem.  There are very specific
customer
> benefits to proxying and caching as well.  Proxying allows customers to
> reach data outside their corporation, and caching saves customers
bandwidth,
> and as we know, bandwidth = $$$.

I'm afraid that caching/proxying for an access protocol is a problem of a
completely different order of magnitude than a relatively simple transfer
protocol like HTTP.  Let me put it this way: the IMAP4 protocol (a fairly
low-end access protocol relative to CAP), first published in 1994,
describes something called "disconnected operation" which is the
foundation for caching in an access protocol.  It has taken four years for
the _first_ standards-compliant commercial disconnected client to appear.
And a disconnected client is a simple case of the proxy-cache problem
since there's only one user of the cache.  CAP will be at least an order
of magnitude more complex because the data model is so much more complex
than Internet email.

> To the second point, CAP is a Calendar transfer protocol as much as it is
a
> Calendar Access Protocol.  This seems like only a semantic distinction.
> When I "access" someone else's calendar data, that data is being
> "transfered" to my computer.  You could even fairly think of HTTP as a
> hypertext access protocol (HTAP :), which defines how people access
> information over the Internet.  

It's quite useful to make a clean semantic distinction between a
"transfer" and an "access" protocol.  A transfer protocol is used to fetch
entire objects so they can be operated on locally.  An access protocol
gives the client first-class access to objects on the server, including
searching, selecting and possibly sorting.  Yes, a transfer protocol
(e.g., POP3) is a subset of an access protocol (e.g. IMAP4), but an access
protocol has much more complex semantics and is relatively harder to
cache, especially with write/search/sort semantics.

Furthermore, an access protocol largely obviates the need for a
proxy-cache, as it supplies adequate semantics for the user to fetch only
what they need.  The complexity of a proxy-cache for an access protocol
probably far outweighs any minor bandwidth savings.

I don't think proxy-caches with CAP is the requirement.  Having a way to
access public event announcement calendars via a large-scale distribution
model seems like the underlying requirement.  But I'm dubious that the
proxy-cache model has proved more efficient in practice than other models
such as the modern NNTP distribution model. 

		- Chris