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:moore at cs.utk.edu]
> > Sent: Thursday, July 02, 1998 6:06 PM
> > To: Robert Herriot
> > Cc: Keith Moore; Scott Isaacson; Paul Moore; ipp at pwg.org;
> > moore at cs.utk.edu> > 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
> >
>