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

From: "Tony Small (Exchange)" <[email-masked]>
Date: Fri, 6 Nov 1998 13:27:33 -0800

Chris, thanks for your response.  It's always valuable to get a different
viewpoint on a solution.

One thing you said especially surprised me:
"If CAP was a Calendar transfer protocol and needed proxy-cache semantics,
then I'd say it's a slam-dunk to layer it on top of HTTP.  But CAP has
neither of thos properties."
 
There's no reason to assume that CAP does not need proxy-cache semantics.
In fact, it's fair to assume the exact opposite. Our customers need full
proxy support for a CAP.  Our customers want a CAP that can efficiently
traverse firewalls (not all the time, of course, but on a need by need
basis.)  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 = $$$.
 
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.  
 
So given that, HTTP may be, as you describe it, a "slam dunk" for CAP.

Also, you make an interesting point that HTTP-CAP would draw upon less
pre-existing experience from the IETF than perhaps another protocol.  I
don't think this (and the difference would go one way or the other depending
completeley on whos experience you are talking about) is a valid reason to
choose one protocol over another.  HTTP is not "very complex" as you
describe.  It's simply thorough, widely implemented and well thought out.
In the end, our customers should come first, and we should be looking for
the best protocol that will meet our customers' increasingly demanding
needs.

Thanks Chris again for your input.

Tony

> 	-----Original Message-----
> 	From: Chris Newman [mailto:[email-masked]]
> 	Sent: October 30, 1998 11:15 AM
> 	To: Tony Small (Exchange)
> 	Cc: [email-masked]'; Keith Moore
> 	Subject: Use of HTTP as a base for protocols (CAP)
> 
> 
> 	On Tue, 20 Oct 1998, Tony Small (Exchange) wrote:
> 	> Doug, your mail makes an important point.  Using a protocol
intelligently is
> 	> just as important as choosing which protocol to use.  Keith's
document
> 	> provides the working group with a good framework within which to
start
> 	> thinking about leveraging an existing protocol (in this case,
HTTP). 
> 
> 	Keith's document is great, but it's missing a lot.  (I'm cc'ing
Keith
> 	because I'm going to discuss some issues his document missed, please
trim
> 	headers appropriately on reply).
> 
> 	We now have two classes of application protocols: connection based
and
> 	object based.
> 
> 	SMTP, NNTP, and HTTP are connection-based MIME-object transfer
protocols. 
> 	SMTP is MIME store-and-forward.  NNTP is MIME flood-distribution.
HTTP is
> 	MIME proxy-cached. 
> 
> 	This is cool -- each distribution model has different levels of
> 	complexity, speed, reliability and efficiency-per-recipient.  SMTP
is
> 	simple, reliable, slow and inefficient for high numbers of
recipients.
> 	NNTP is fairly simple (albeit harder to set-up), a bit less
reliable,> 
> 	slow, but efficient for high numbers of recipients.  HTTP is very
complex,
> 	even less reliable, fast (when it works), and efficient if
recipients are
> 	clustered behind proxies.
> 
> 	We've started to create object-processing protocols which are
layered on
> 	top of this infrastructure.  I'd consider "the web", iTIP, and vCard
as
> 	some examples of this trend.  In general, I think this isn't a bad
trend,
> 	although I'll be interested to see how iTIP works in practice since
this
> 	"object model" is still quite new.
> 
> 	When choosing HTTP or some other MIME-based tranfer protocol as the
base
> 	for a new protocol, there are a number of subtle design
implications:
> 	(1) The IETF has far more design experience with connection-based
> 	    protocols than with MIME-object based protocols.  So the choice
to
> 	    do an object-based protocol means it will be harder to get
right.
> 	    Take a look at how hard it was to get MHTML working and that is
orders
> 	    of magnitude simpler than CAP will be.
> 	(2) An object-based protocol has an extra layer that a connection
based
> 	    protocol doesn't.  The "avoid unnecessary layers" design
principle
> 	    dictates that a connection based protocol should be used if it
> 	    suffices.
> 	(3) We know how to do object-transfer over MIME, but have very
little
> 	    experience with object-access via MIME.
> 	(4) Some transfer protocols fail to properly distingush the envelope
> 	    (information about the transfer) from the headers
(meta-information
> 	    about the object).  HTTP botched this.  SMTP got it mostly
right.
> 	    NNTP is currently sufficiently restricted in use that it's not 
> 	    a problem.  This can cause architecture problems.
> 
> 	If CAP was a Calendar transfer protocol and needed proxy-cache
semantics,
> 	then I'd say it's a slam-dunk to layer it on top of HTTP.  But CAP
has
> 	neither of thos properties. 
> 
> 	I was on the design teams for IMAP and ACAP and have followed LDAP
as its
> 	popularity increases.  I'd be glad to share the lessons I learned
about
> 	building an access protocol with CAP.  Those lessons will be far
more
> 	useful if CAP is also a connection-based protocol.  Of course, CAP
will be
> 	very different from IMAP (or the others) because access protocols
need to
> 	be carefully structured around the characteristics of the data they
> 	access, but it will need similar design choices and models.
Layering CAP
> 	on HTTP as an object-protocol would discard many of the lessons from
> 	IMAP/ACAP/LDAP and be charting new territory. 
> 
> 	> - On the issue of security, the draft advises that TLS may not be
adequate
> 	> security for a layered protocol.  If we go with HTTP, we are not
limited to
> 	> TLS.  We can use Digest authentification, an existing HTTP
security
> 	> mechanism, which would provide CAP with RFC-approval ready
security.
> 
> 	I still think HTTP's security situation is poor.  TLS provides
> 	connection-based privacy, and HTTP authentication provides
single-object
> 	based authentication.  While I'm a supporter of digest
authentication, it
> 	has yet to prove itself in the field.  There's no framework for
> 	connection-based authentication, which would be preferable for CAP
--
> 	instead each exchange has to be separately authenticated.  I also
*really*
> 	don't want HTTP proxies involved in CAP.  The security implications
of
> 	that make me uncomfortable.
> 
> 	HTTP is also largely restricted to the ISO 8859-1 charset in
> 	authentication protocols.  In addition, it requires support for RFC
2047
> 	encoding in order to support international characters in headers.
> 
> 	On the flip side, security for a new protocol is now much easier --
just
> 	do a SASL and STARTTLS profile and you have very flexible
connection-based
> 	security.  A SASL-based protocol can use the revised verion of
HTTP-digest
> 	which fixes the charset restriction in addition to many other> 
> 	authentication protocols such as Kerberos that are currently
unavailable
> 	in HTTP.
> 
> 	> - The draft makes a good point that "New standards-track protocols
-
> 	> including those using HTTP - must not attempt to circumvent users'
firewall
> 	> policies."  CAP over HTTP can meet this by distinguishing between
different
> 	> methods.  The firewall itself can then make the appropriate
decision.
> 
> 	Actually, CAP over HTTP would have to use a separate port, not only
to
> 	avoid circumventing firewalls, but also to prevent proxies from
> 	interfering with the protocol.
> 
> 	> Once again, it's not just choosing a protocol for CAP - it's
choosing a
> 	> protocol and then applying it wisely.  It's great that we can
start
> 	> exploring these issues towards the goal of a great Calendar Access
Protocol.
> 
> 	One of the great things about the IETF is the pool of experience
which one
> 	can draw upon if one knows how to ask.  Making CAP a
connection-based
> 	protocol will maximize the use of this experience, while layering
CAP on
> 	top of HTTP will minimize such use.
> 
> 			- Chris

---

From: Chris Newman <[email-masked]>
Date: Mon, 09 Nov 1998 16:19:23 -0800 (PST)

On Fri, 6 Nov 1998, Tony Small (Exchange) wrote:
> Our customers want a CAP that can efficiently
> 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

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.

> 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

---

From: Rob Earhart <[email-masked]>
Date: Mon, 9 Nov 1998 23:22:57 -0500 (EST)

On Fri, 6 Nov 1998, Tony Small (Exchange) wrote:
> proxy support for a CAP.

  I'm unconvinced that an HTTP proxy will do a good job as a CAP proxy;
the operations one performs on hypertext and the operations one
performs on calendar objects don't seem at all similar.

> company.

  I think I'm losing, here; I'm not sure why another user in your company
would be accessing the same calendar.

  It seems like this wouldn't be an issue for CAP.  Even when people have 

> We certainly don't want to build a CAP where access hits a brick

  So, if I understand this, you want to use HTTP because it's easier to
make it go through a firewall.

  Actually, I though that firewalls were *supposed* to act as a brick wall
with regards to any new protocol; that that was sort of the point.  

> HTTP is not "very complex" as you describe.  It's simply thorough,
> widely implemented and well thought out. 

  (I beg to differ.  HTTP was initially a simplistic hack; "write the
operation you want and the name of what you want to manipulate down a TCP
pipe, and get back an HTML object."  Over time, it's accumulated more
hacks, as people have used it for more and more things far beyond its
original scope.  I've written an HTTP server and I've written an HTTP
client; although HTTP's semantics are fairly straightforward, CAP will
have different semantics, and HTTP's syntax is downright ugly to
implement. 

  HTTP is ubiquitous because the idea of ubiquitous hypertext was a good
one, and because new clients and servers needed to be backwards compatible
with existing web clients and servers.  It's not ubiquitous because it's
good.)

> the best protocol that will meet our customers' increasingly demanding

  I think we can all agree on this one--I just don't think that HTTP is
the best protocol here. :-)

  (Ideally, we'd take the requirements document, decide on the set of
operations one might perform on a calendar store, and *then* worry about
how those operations are represented on the wire; it'd be similar to
creating the iTIP abstraction, followed by iMIP and iRIP.)

  )Rob

---

From: Rob Earhart <[email-masked]>
Date: Tue, 10 Nov 1998 08:00:25 -0500 (EST)

(Sorry about that--I must've hit "Send" instead of "Postpone".  It was
late... :-)

>   It seems like this wouldn't be an issue for CAP.  Even when people have 

  So, to complete that thought... I was under the impression that most
people would be accessing their own calendars; even if they have a
seperate calendar server outside of work, it doesn't seem like caching
calendars would be worthwhile.

  I can invent some situations in which it might be useful, but they seem
relatively far-fetched; it doesn't seem worth adding the complexity of a
caching/proxy layer to the protocol.

  (So, what'm I missing?  :-)

> with regards to any new protocol; that that was sort of the point.  

  To finish this one: I understand the desire to be able to drop in new
software and have it just work, but I think that cramming more things onto
port 80 just to get them through firewalls is poor protocol design; you're
really just creating a market for a firewall which can sniff the HTTP
stream and allow only requests that the firewall admin knows are safe.  We
might as well make it easy for admins, and just make it another port, to
be enabled or disabled at will. 

  I'd rather not be at war with people running firewalls; it's easier for
them to upgrade individual machines than it is for us to deploy a new
protocol which gets around whatever they're doing to block questionable
traffic. 

  )Rob

---

From: Mark Horton <[email-masked]>
Date: Tue, 10 Nov 1998 08:17:28 -0500

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: Pat Egen <[email-masked]>
Date: Tue, 10 Nov 1998 09:37:18 -0500

I've been following some of the discussions here regarding the access to
calendars through firewalls.  Here's a perspective from the corporate
side.  As Rob notes in his comments, firewalls are put in place as
protection and we are defeating the purpose if we are looking for ways
"around" them.  And in answer to Mark's comments here, I disagree that it
will be a "small minority" of accesses to other calendars.  Here's an
example of what goes on in a large company/organization.  You have your
calendar with you - on paper. That's the norm.  When you are out on the
road and you are trying to find someone back at the office (classic sales
force model), having access to a calendar, whether it be a master one or
via a search is critical.  I know a lot of vendors say "we'll give you a
free time search option.  However, for those organizations used to being
able to see someone's full calendar, that's not acceptable.  And as more
and more people are working from home or out of a car, being able to see
calendars is even more vital.

So, we need to be careful and not think that access via the Internet is
only going to be to one's own personal calendar.  Not at all.