Subject: Re: SDP> Re: SDP, IPP>PRO Proposal for TIPSI-like protocol

From: Harry Lewis <[email-masked]>
Date: Wed, 6 May 1998 23:19:43 -0400

Bob, hypothetically, your approach seems ideal. I just wonder about the degree
of difficulty we're placing on the embedded device. Is IP overkill? If IP is
the natural solution for every type of physical layer, why isn't P1394 doing it
(I think they are using a serial bus protocol)?

Since we're only trying to accommodate printing, print control and
notification... is a generalized communications protocol, like IP, really a
better solution than a well defined SDP packet?

Harry Lewis - IBM Printing Systems

[email-masked] on 05/06/98 06:36:08 PM
Please respond to [email-masked]
To: Harry Lewis/Boulder/IBM@ibmus
cc: [email-masked], [email-masked]
Subject: Re: SDP> Re: SDP, IPP>PRO Proposal for TIPSI-like protocol

Harry,

You are correct, my assumption is that there is a socket-like layer for any
type of
connection that we connect a printer to and that IPP rides on top of this
layer.  This assumption is true for TCP/IP and for parallel connection with
1284.4 support. If we encounter a connection, such as serial where that is
not the case, then we must define a similar layer to implement sockets, which
hopefully borrows a lot from 1284.4. [Question to 1284.4 experts: could it
work with serial or USB with very few changes?]

In effect, I want the socket layer to handle the issues of multiplexing and
read/write blocking and let the IPP layer concentrate on printer operations
transmitted over a virtual connection.

Bob Herriot

At 04:52 PM 5/6/98 , you wrote:
>One thing it would buy is a simpler (than 1284.4) way to flow IPP over bidi
>parallel - no? Isn't this basically what Lexmark has found? I'm confused why
>TIPSI has a packet structure, Lexmark was shipping it on parallel and then .4
>was invented - maybe some background could help (I always thought it was to
>flow SNMP over parallel ;-). If it's true that the .1 packet is only still
>there for legacy I might buy Bob's argument. But I suspect .4 is a much more
>complex implementation.
>
>Bob, doesn't your proposal say we would have to invent a transport (if not
>already there) to "IPize" every physical layer (ex. serial)?
>
>Harry Lewis - IBM Printing Systems
>
>
>
>[email-masked] on 05/06/98 05:32:34 PM
>Please respond to [email-masked]
>To: [email-masked]
>cc: [email-masked]
>Subject: SDP,* IPP>PRO Proposal for TIPSI-like protocol
>
>
>I just finished scanning IEEE 1284.3 and IEEE1284.4.* The most interesting
>part is Chapter 8 "Service Provider Interface (SPI)" in IEEE 1284.4.* This
>chapter describes a "Berkeley Sockets-compatible interface for clients and
>servers to access the services provided by 1284.4".
>
>So if I understand the intent of 1284.4, it is to provide a layer that
>supports sockets over parallel connections. All we need to do in IPP is
>reference sockets for TCP/IP and 1284.4 and we don't have to worry about the
>issues at that layer.
>
>So, I conclude that we don't need to packetize IPP or do much of what is
>proposed in Roger and Harry's paper. Instead, we can send IPP directly on
>sockets layered on top of TCP/IP or 1284.4.* There are a few easy-to-solve
>dangling
>issues, such as chunking for document data and intermediate acknowledgement
>when attributes are verified for PrintJob. But otherwise IPP stays as is.
>
>If you disagree with my conclusions, I would like to know what the
>TIPSI-like packetizing layer provides that sockets don't also provide?
>
>Bob Herriot
>

---

From: Robert Herriot <[email-masked]>
Date: Thu, 07 May 1998 12:29:13 -0700

I am not suggesting that we define IP or TCP/IP over serial. Rather, I am 
suggesting that IPP be sent via sockets and that if sockets are not 
available for some connection, such as serial, that we define a lower layer 
that supports a sockets implementation.  We then have two clean layers -- 
one that supports sockets and the other (IPP) that assumes socket support.

As I said in my last email, I would hope that the 1284.4 design would work 
on serial and USB with very few changes.  But I leave it to others to tell 
me how hard it would be to make 1284.4 work on serial and USB.

Bob Herriot