I am not suggesting that we define IP or TCP/IP over serial. Rather, I am=20
suggesting that IPP be sent via sockets and that if sockets are not=20
available for some connection, such as serial, that we define a lower layer=
=20
that supports a sockets implementation. We then have two clean layers --=20
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=
=20
on serial and USB with very few changes. But I leave it to others to tell=
=20
me how hard it would be to make 1284.4 work on serial and USB.
Bob Herriot
At 08:19 PM 5/6/98 , Harry Lewis wrote:
>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
>>>>owner-sdp at pwg.org on 05/06/98 06:36:08 PM
>Please respond to owner-sdp at pwg.org>To: Harry Lewis/Boulder/IBM at ibmus>cc: ipp at pwg.org, sdp at 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 this
>layer.=A0 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
>>>>>>>>owner-ipp at pwg.org on 05/06/98 05:32:34 PM
>>Please respond to owner-ipp at pwg.org>>To: sdp at pwg.org>>cc: ipp at pwg.org>>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
>>>=20