Subject: RE: IPP> Re: IPP over TCP

From: Babak Jahromi <[email-masked]>
Date: Wed, 11 Dec 1996 16:03:11 -0800

>
>No, Alex is entirely correct, IPP should not be concerned with the transport
>protocol other than having some requirement such as needing "a reliable
>stream
>orientated protocol" (e.g., TCP) over which it can be sent. Using TCP
>directly
>is far simpler than HTTP and HTTP is sent over a TCP connection anyway (it
>doesn't have to be though, it just wants a reliable byte-stream as most appl-
>ication level protocols) so you get less work not more. 

Whether it is more or less work depends on your point of view, and where
you are in the food chain. As I said before, any viable Interenet client
technology for PCs, be it from Netscape, Microsoft, etc. better have
easy to use APIs that let you sit on top of HTTP (if they don't, the
printer vendors won't have to worry about supporting them because they
won't make it in the market place anyway). This means that it would be
easier to write a component (in our case a printing component) that
speaks HTTP, than one that dives down to TCP. Again, I have the point of
view of a PC developer, not a printer manufacturer. 

>
>IPP's reliable stream connection *could* be implemented using a combination
>of HTTP POST methods to a CGI program that understands IPP content contained
>within the entity posted but that should be independent of the actual IPP
>specification (i.e., if you really want to write it up then have another
>draft or an appendix, don't clutter IPP with it). This approach would let
>people use IPP without re-configuring their firewalls and send documents
>over HTTP to some service that makes its IPP service available in this way
>but this should be separated from the base protocol spec.

I bet most implementaions would end up using HTTP as you described. i.e.
HTTP will always be in our face. So why not accept it and make it
official?

Babak

---

From: Randy Turner <[email-masked]>
Date: Wed, 11 Dec 1996 16:08:34 -0800

Then there is the compromise solution: Do the spec and make it
transport independent (1 document), and then publish multiple
documents, each outlining a mapping to a specific transport so
the method is "standardized" for interoperability purposes
(documents 2 through n ), where 'n' is the number of transport
mappings we want to "standardize".

Another set of documents could also include a specification for
locating IPP services via one or more directory service
implementations.

I think separating the work of the working group into multiple
documents gives us a change to produce quality output with
realistic scope in a consistent timely fashion. Something like
every 4 to 6 months we have a draft document (somewhat final)
that includes a specification outlining functionality in
one of the functional classes I outlined above.

Randy

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]

---

From: Alex Bochannek <[email-masked]>
Date: Wed, 11 Dec 96 17:01:46 PST

I am glad to hear support for my position. Let's table it for today
and bring it up at the BOF tomorrow. We'll see how people feel about
it then.

Alex.