Subject: RE: IPP> review of IPP documents

From: Paul Moore <[email-masked]>
Date: Mon, 1 Jun 1998 09:32:05 -0700

Excellent point. So why the heck are we using HTTP for IPP?

> -----Original Message-----
> From:	Ned Freed [SMTP:[email-masked]]
> Sent:	Friday, May 29, 1998 6:49 PM
> To:	Keith Moore
> Cc:	Paul Moore; 'Keith Moore'; [email-masked]; [email-masked]
> Subject:	Re: IPP> review of IPP documents
> 
> > You miss the point.  The fact that people already have port 80 proxies
> > installed doesn't matter.  There's no way that we're going to
> standardize
> > IPP on port 80 - HTTP already has that port, and IPP is a different
> > service than HTTP.
> 
> > Once upon a time, a lot of people had email only access to the Internet.
> > That wasn't an good reason for forcing every service to run over email.
> 
> My favorite example is email over FTP. We'd still be doing email that way
> if we hadn't deployed a new email service on a separate port.
> 
> 				Ned

---

From: James Walker <[email-masked]>
Date: Tue, 02 Jun 1998 08:33:13 -0500

> Excellent point. So why the heck are we using HTTP for IPP?

Although one could take this as a facetious response, it always seems
to me be an important question worth asking again.  If IPP and others
are approved as standard application protocols built on top of HTTP,
then this is a green flag that HTTP is an acceptable transport for
application protocols.  And we will see more.

So, is the IETF supporting (even encouraging ?) application protocols
to be built using HTTP as a transport?  Or are these protocols that
are currently being developed (IPP, WebDAV, etc) just considered test
cases to see if the idea will fly?

> > if we hadn't deployed a new email service on a separate port.

...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Jun 1998 17:17:40 -0400

> application protocols.  And we will see more.

Yes.  There's a lot of interest in layering other things over HTTP,
for reasons including:

mindshare
firewall/proxy/NAT compatibility
leveraging SSL/TLS
ease of prototyping using CGI and/or client libraries

However, several different uses of HTTP tend to pull the protocol in
several different directions, and potentially use it in ways that
conflict with one another.  For example, you don't want a request or
response header used slightly differently by X-over-http than by
Y-over-http, because this might confuse proxies, or require slight
tweaks to client libraries.  Similarly for use of HTTP error codes by
different protocols.  And you want to make sure that firewalls can
distinguish X from Y.

HTTP is already very complex, and having lots of special cases for
different protocols doesn't make it any simpler.

> cases to see if the idea will fly?

I see IPP as breaking new ground in this area.  Ideally, IETF should
have an RFC with guidelines for how to layer protocols on top of HTTP
(and TLS), so that future groups won't have to suffer as much as IPP.

WebDAV is a special case...because it's basically manipulating web
pages, I see it as an extension to the HTTP service rather than a
separate protocol layered on top of HTTP.

Keith