One key point to remember is, is that I don't think we need to be taking
TIPSI and modifying it. If you don't use it as is, then you are not
compliant with TIPSI, and I think a lot of the benefit of using TIPSI is
the fact that it exists as an interoperable standard specification.
My next draft which I am working on adds client "pull" functionality and
cleans up the transport header. I hope to have it out by tomorrow, and I
will have copies (hardcopy) at the meeting.
Randy
-----Original Message-----
From: Roger K Debry [SMTP:rdebry at us.ibm.com]
Sent: Friday, April 03, 1998 12:49 PM
To: ipp at pwg.org
Subject: IPP> Host to device
I have read both Randy's TCP/IP mapping document and Don's
TIP/SI
mapping document. I have to admit that I haven't spent a lot of
time trying
to write down a detailed proposal, but I make the following
observations:
A lot of work went into TIP/SI to develop a host to device
protocol which
was transport independent. In particular, it runs on both TCP/IP
and a
IEEE 1284 parallel port. It outlines all of the rules for
handling out of band
communications, continuation, and acknowledgements.
A lot of work has also gone into developing a model for
submitting and
anaging print jobs in IPP. The model reflects current thinking
in this area
and has taken into account parallel work on Printer and Job MIB.
Although Don would probably not approve, one could take the
TIP/SI
packet structure (including the TIP/SI packet header), as
defined
today but with new commands (below), and carry an IPP payload
with it.
Now we don't have to re-invent flow control, data stream level
acks,, etc.
The TIP/SI LU becomes the IPP Job ID
The TIP/SI payload becomes the IPP message
The IPP commands are used in TIP/SI as shown:
o Print-Job would not be used in host-to-device
o Create-Job replaces the TIP/SI Start job command
o Validate-Job would not be used in host-to-device
o Get-Printer replaces the TIP/SI RDC and RIC commands
o Get-Jobs replaces the TIP/SI JC-QJC command
o Send Document and Send URI go to the LU
A sample job submission flow would look like:
1. Connect
2. Start Session (as is in TIP/SI)
3. Create-Job (response is IPP job ID)
4. Send Document (destination bit = LU,
LU# = IPP Job ID)
5. End-Job (as is in TIP/SI)
6. End-Session (as is in TIP/SI)
7. Disconnect
This is very high level and obviously not completely thought
through, but it seems to me that we ought to be able to leverage
al ot of good, hard work and marry these two ideas together to
come up with a version of IPP for host-to-device that meets all
of Paul Moore's requirements. Thoughts???
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080