Since we're only trying to accommodate printing, print control and
notification... is a generalized communications protocol, like IP, real=
ly a
better solution than a well defined SDP packet?
Harry Lewis - IBM Printing Systems
owner-sdp@pwg.org on 05/06/98 06:36:08 PM
Please respond to owner-sdp@pwg.org
To: Harry Lewis/Boulder/IBM@ibmus
cc: ipp@pwg.org, sdp@pwg.org
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 th=
is
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 operat=
ions
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 confus=
ed 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 w=
as to
>flow SNMP over parallel ;-). If it's true that the .1 packet is only s=
till
>there for legacy I might buy Bob's argument. But I suspect .4 is a muc=
h 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
>
>
>
>owner-ipp@pwg.org on 05/06/98 05:32:34 PM
>Please respond to owner-ipp@pwg.org
>To: sdp@pwg.org
>cc: ipp@pwg.org
>Subject: SDP,* IPP>PRO Proposal for TIPSI-like protocol
>
>
>I just finished scanning IEEE 1284.3 and IEEE1284.4.* The most interes=
ting
>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 i=
s
>reference sockets for TCP/IP and 1284.4 and we don't have to worry abo=
ut 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-s=
olve
>dangling
>issues, such as chunking for document data and intermediate acknowledg=
ement
>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
>
=