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