Subject: IPP> Re: IPP over TCP

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

Harry,

I am sure you don't mind that I copy the list on this reply.

I do not currently have a writeup other than what I outlined in my
email yesterday but I believe it would be absolutely trivial to
restructure the draft to move references to HTTP into a more generic
transport mechanism appendix.

With regards to transport over TCP, the comment I have is basically
that HTTP as a transport in my opinion does not gain you
anything. Encoding in MIME is a different issue since that would also
allow transport over email, but specifying HTTP (or more precisely,
only the HTTP POST command) does require you to track changes in the
protocol, adhere to it's limitations, and you still need to modify
browsers and servers to make use of it.

IPP simply needs clear-channel communication between client and server
and a two-way TCP connection is the easiest way to go (I also think
one should be able to run IPP over serial and parallel ports, but
that's a different story). If you want IPP to fit nicely into the Web
framework (even if it's just for PR reasons), you specify the ipp://
access method which will go to TCP port 380(?).

There really isn't much that you need to specify for the "TCP
transport module" other than port numbers and mapping to a URL method
if you want to, but one thing I personally would really like is to
specify a how long the TCP session sticks around. This way, you do not
have to continuously set up and tear down TCP sessions for every
single command you want to send to the printer (HTTP
syndrom).

Alex.

> Alex, unfortunately, I am not able to make it to the BOF, but I am very
> interested in understanding more about your IPP over TCP proposal. I
> think your recommendation for an appendix is a good one.
> 
> Will you be posting your proposal, or is there another way for me to aquire
> your writeup?
> 
> We will have an IBM rep at the BOF (Roger DeBry). If all else fails, I will
> ask Roger for a copy of whatever he picks up or his notes.
> 
> Good luck at the BOF!
> 
> Harry Lewis - IBM Printing Systems

---

From: [email-masked]
Date: Tue, 17 Dec 1996 11:57:05 -0500

Classification:
Prologue:
Epilogue:

Ithink we did agree at the BOF to write up at least three or four RFCs
1) The overall print model and IPP print operations (the bulk of the current
document)
2) The MIME encoding for IPP
3) Mapping to at least HTTP
4) The use of LDAP

I believe that it is important that we proceed in parallel with most of this
work -- it is important to keep the entire context in mind and ensure ourselves
that the pieces in fact do fit together. However, I am opposed to the thinking
that we should allow IPP to be mapped to "n" different transports. We ought to
pick ONE and push it as THE standard. Otherwise we'll have RFC 1169 or DPA all
over again -- a common model but no common implementations.  I'm not opposed to
writing up and perhaps prototyping several possibilities, but we ought to use
our prototype experience and look to some of our key partners, such as
Microsoft and/or Netscape to guide us on a single best approach.

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/17/96 09:47
AM ---------------------------

        ipp-owner @ pwg.org
        12/11/96 05:15 PM
Please respond to [email-masked]@internet

To: babakj @ MICROSOFT.com@internet
cc: ipp @ pwg.org@internet
Subject: Re: IPP> Re: IPP over TCP

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: [email-masked]
Date: Tue, 17 Dec 1996 11:59:43 -0500

Classification:
Prologue:
Epilogue:

I agree with Babek!  I think we ought to proceed with HTTP as our preferred
direction.  With support (and hopefully implementation) from Microsoft I think
that the HTTP arguments we headr at teh BOF will die away.

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/17/96 09:57
AM ---------------------------

        ipp-owner @ pwg.org
        12/11/96 05:02 PM

To: andy @ research.canon.com.au@internet
cc: ipp @ pwg.org@internet, abochann @ cisco.com@internet, harryl @
vnet.ibm.com@internet
Subject: RE: IPP> Re: IPP over TCP

>
>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