As a strategy for SDP overall, I wouldn't spend a heck of alot of time
figuring out how to put SDP onto legacy interfaces (like serial). The cost
to produce versus the benefit to be gained just doesn't work out. Leave it
to niche companies or proprietary solutions. (I'm hoping no one is shipping
20mA current loop interfaces on their devices ;) ;) )
Randy
At 05:29 PM 5/6/98 -0700, Robert Herriot wrote:
>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
>>
>>
>>
>>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
>>
>