Subject: FW: The IESG and iCalendar use of HTTP

From: "Tony Small (Exchange)" <[email-masked]>
Date: Tue, 20 Oct 1998 16:27:03 -0700

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

Specifically:

- The draft raises the point of complexity.  Do we want to use an existing
protocol which would require us to document features we don't need - and
require vendors to implement them.  The draft specifically mentions
persistent connections, byte ranges, content negotiation, and cache support.
Fortunately for supporters of HTTP, a CAP would require such features
anyway.  So using HTTP would save a lot of time in protocol design (and
implementation time for those vendors which already support the protocol,
including IBM, Netscape, Sun, Oracle, and Microsoft.)

- In the section on Overhead, the draft states that HTTP's protocol overhead
can make HTTP a poor choice.  But the draft goes on to state that, "On the
other hand, the connection setup overhead can become negligable if the
layered protocol can utilize HTTP/1.1's persistent connections..."  Since it
is important that CAP use persistent connections anyway and they are widely
deployed in HTTP/1.1, CAPs use of the underlying HTTP mechanisms is totally
consistent with the needs of CAP and the correct use of HTTP.

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

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

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.

Tony Small
Microsoft

-----Original Message-----
From: Doug Royer [N6AAW] [mailto:[email-masked]]
Sent: October 10, 1998 10:23 PM
To: [email-masked]
Subject: The IESG and iCalendar use of HTTP

After reading what is below - PLEASE don't say that I am not in favor of
HTTP+iCalendar, I do not think its an issue one way or the other. I am
just exploring the options and attempting to address the issues
of iCalendar over HTTP.

I have exchanged some email with the HTTP-WG chair:

	"Larry Masinter" <[email-masked]>
	
His response leads me to think that the IESG and HTTP-WG
will object to iCalendar data over HTTP.

If you have not already read what Larry pointed me at...

	draft-iesg-using-http-00.txt
	 
...you should. It is the IESG's opinion of overloading HTTP.	

The other more upsetting issue is the strong view by the HTTP-WG chair
that "draft-cohen-gena-p-base-01.txt" (notification in HTTP), is
an example of what HTTP should NOT do. I am not sure if he
objects to the idea - or to the document as written.

Flames to the bit bucket please :-)    I am only the messenger.

In the short term we can still make CAP progress. There are issues
to be solved that are independent of the transport used.

So - those proposing and those who are strongly in favor of iCalendar
over HTTP. You might start organizing and evangelizing your opinions to
the HTTP-WG.

I think it might be useful for the proponents of iCalendar over HTTP to
write a document addressing the issues in draft-iesg-using-http-00.txt .
Submit it to the CALSCH-WG, then when that (fun :-) debate settles,
take the document to the HTTP-WG and start negotiating. I think it
might also need to address the issues of iCalendar notification.
Any volunteers?

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/dougr.html
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Chris Newman <[email-masked]>
Date: Fri, 30 Oct 1998 11:14:36 -0800 (PST)

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

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

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

> 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