RE: IPP> regarding "ipp:" (I spoke too soon...)

[Ron Bergman <[e-mail]>]

Josh did an excellent job of expressing my concern regarding Keith Moore's
and the IETF's position on a new scheme for ipp.

It appears that the IETF prefers to "munge" HTTP and it's data content
into one layer.  Then why is a "content-type" field needed?  An why 
just selectively apply this rule?

I have read the many emails over the last several months, and I have
seriously tried to understand the IETF's position.  But some how I still
do not get it.  Why is HTTP not HTTP when the content-type is IPP?


	Ron Bergman
	Dataproducts Corp.
 

On Thu, 2 Jul 1998, Josh Cohen wrote:

> see below>>>>
> > -----Original Message-----
> > From: Keith Moore [mailto:[e-mail]]
> > Sent: Thursday, July 02, 1998 6:06 PM
> > To: Robert Herriot
> > Cc: Keith Moore; Scott Isaacson; Paul Moore; [e-mail];
> > [e-mail]
> > Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) 
> > 
> > But SWAP aside, my feeling is that the only protocols that should
> > use the http: scheme are those which operate on the same data
> > sets as traditional HTTP.  So WebDAV counts, as does probably DASL.
> > Other uses of http:, like for instance iCalendar or EDI, are dubious. 
> > 
> 
> I dont beleive that a new scheme is appropriate nor a new TCP port.
> 
> I always thought that the scheme in the URL indicated which protocol
> you are actually speaking on the wire.  IPP *is* speaking HTTP.
> It just has a different "service" than HTML, GIF, etc content
> or GET/HEAD semantics.
> 
> How about if different services layered on HTTP are differentiated
> at a within the HTTP layer.  Looking at IPP/SWAP/ or DAV from the
> TCP layer should make it appear to be HTTP.
> When examining the message at the HTTP layer, it should appear
> to be IPP/SWAP/DAV service.
> 
> In an analogy, lets look at HTTP as being TCP and TCP being where IP is.
> (wait.. just give me a sec, I know this sounds wierd)
> So, TCP differentiates itself from another IP protocol such as 
> UDP by using a different protocol number, right ?
> When a new service/protocol is built on top of TCP, do 
> we expect the IP layer to understand it, or do we expect the TCP
> layer to understand differentiation?  I beleive it is
> TCP. 
> 
>   So, you wouldnt ask a new service built on top of TCP
> to allocate a new IP protocol number, would you ?
> 
> To make IPP, which is a layer on top of HTTP to expose
> its differentiation at the TCP layer breaks the abstraction
> layer.  TCP is, in a sense, delegating the differentiation to the
> HTTP layer, just like IP delegates to TCP to inspect port #s.
> 
> Another analogy is RPC.  If a firewall wants to filter all
> protocols on TCP ports, and it chooses to allow RPC, it must
> be all or nothing.  To selectively filter RPC it must have
> an RPC proxy in the firewall.
> 
> This is the scenario I beleive is common for HTTP.  If you
> want to selectively allow certain HTTP messages of certain
> URL types, methods, or content-types, you must employ a proxy
> or device that can parse the HTTP layer.
> 
> > Keith
> > 
>