Parallel Interface(1284-1994):
SDP
-------
1284.4
-------
1284.3
-------
1284-1994
IEEE 1394-1995:
SDP
-------
SBP-2
-------
1394 TransactionLayer
-------
1394-1995
Universal Serial Bus (USB):
SDP
-------
1284.4
-------
USB LinkLayer
-------
USB Device Driver
RS232-Serial:
SDP
--------
1284.4
--------
(Reliable Link Layer) Choose one of (PPP,DDCMP,etc)
In each of the above mappings, I have included a 1284.4 layer, which could
expose a socket layer to which you could implement SDP. In the 1394 case, I
specified SBP-2 using the 1394PWG working group's printing profile, which
could easily expose a socket-level interface to an application protocol
like SDP.
By the way,
When we talk about the "P" device in SD"P", I am assuming that the device
is very low cost, and does not contain any web management capability (via
an embedded web server), and does not have any type of local area network
(ethernet, token-ring, etc.) interface.
Randy
At 11:19 PM 5/6/98 -0400, 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. 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
>>
>