1) 1284.4 was a standard and not just a work in progress
2) 1284.4 was deployed in all parallel environments
3) 1284.4 was deployed in other non-TCP/IP, direct connect environments
- USB
- 1394
- Serial
For the small amount of overhead that a packet header provides, I think it
is worth the price.
Don
**********************************************
* Don Wright don@lexmark.com *
* Product Manager, Strategic Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
To: sdp%pwg.org@interlock.lexmark.com
cc: ipp%pwg.org@interlock.lexmark.com (bcc: Don Wright)
bcc: Don Wright
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