Subject: RE: Finding PKIX Servers!

From: Andrew Probert <[email-masked]>
Date: Fri, 12 Feb 1999 12:55:57 +1100

Yeah .. apologies, my typing was in haste, I know HTTP is over IP.

I meant to allude to simplicity of the transport i.e. you can Telnet to a
Web server and hand-type HTTP protocol, so the underlying comms is very
simple, but you are pushing a lot of stuff up into the HTTP application.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	EKR [SMTP:[email-masked]]
> Sent:	Friday, February 12, 1999 11:15 AM
> To:	Andrew Probert
> Cc:	'Phillip M Hallam-Baker'; David P. Kemp; [email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
> Andrew Probert <[email-masked]> writes:
> > > I don't see a need therefore to use LDAP or X.500 as the transfer
> > > protocol for OCSP. Not only is HTTP considerably more efficient,
> > > the much vaunted data model and replication protocols are a poor
> > > match for the particular needs of an online status protocol.
> > > 
> > 	[Andrew Probert]  Well .. HTTP is an overlay of simple verbs GET,
> > POST over Telnet, with some service controls and it is certainly a
> simple
> > protocol. 
> I don't know where you get the idea that HTTP is an overlay over
> TELNET. It most certainly is not. HTTP runs over a TCP connection,
> as does TELNET, yes, but that doesn't make HTTP an overlay over TELNET
> wny more than FTP is. RFC-854 specifies all sorts of stuff that HTTP
> doesn't have any notion of, including some terminal behavior, control
> information, etc.
> 
> -Ekr
> 
> -- 
> [Eric Rescorla                                   [email-masked]]

---

From: EKR <[email-masked]>
Date: 11 Feb 1999 20:53:28 -0800

> Yeah .. apologies, my typing was in haste, I know HTTP is over IP.
Uh, not to be difficult, but not over IP either. Over TCP.

> simple, but you are pushing a lot of stuff up into the HTTP application.
It's not the simplicity of the transport that's the issue. There
are plenty of protocols that run directly over TCP that can't be
hand-typed (SSL comes to mind.) The simplicity comes in because
it's ASCII text. 

IMHO, as a protocol implementor, this is a major advantage, both
from the perspective of debugging and of implementing.

-Ekr

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Fri, 12 Feb 1999 11:36:25 -0500

> Uh, not to be difficult, but not over IP either. Over TCP.

No, HTTP is layered on a transport layer which provides an 8 bit clean,
reliable connection. In the early days we used DECNET to a significant
degree (the DEC IP stack cost extra at the time!).

As a matter of fact, in those days I thought the OSI based Decnet
phase V was going to replace IP - mainly because of the address
space exhaustion issue. That was before firewalls, NAT and DCHP.

> > simple, but you are pushing a lot of stuff up into the HTTP application.

Actually, the idea we had was to remove the unnecessary work from
the application. FTP's twin connection is far more complex for any
application to manage than the HTTP 'idempotent request' model.
Similarly the LDAP BIND operation achieves nothing of real value.

The 'complexity' of HTTP/1.1 is due to the caching model. No other
retrieval protocol I am aware of has any caching model - the applications
were too busy performing unnecessary operations such as BIND and UNBIND.
Caching is not a particular burden on applications however.

Even with every 1.1 boondoggle, HTTP is by far the most straightforward
protocol to implement at the application level.

In retrospect I think that the confusion that HTTP ended concerned
the interface between the authentication/authorization model (an
application concern) and the transport connection. For some reason it
was assumed to be a good idea to keep TCP/IP sessions going
indefinitely - instead of simply caching the access control context
at each end.

Unfortunately some folk took this a bit far, maybe Eric can remember
the name of that chap from Chicago who he used to work with who had
the idea of downloding every image in a page as a separate TCP/IP
connection. That was definitely a bad idea!

		Phill