--------------62A5254C4C1E8C680E0AAF07
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I would like to propose an additional encoding field that would be
included in the
application/IPP body for IPP requests. This additional field would
be a
"transaction identifier" field. IPP clients would generate a
unique transaction identifier
to be included with each request. The IPP server would not do any
processing or
interpretation of the transaction identifier. Instead, the
IPP server would just include
this transaction identifier on the response message to the original
request.
The client would then use the received transaction identifier to
match this response to
the original request that it generated previously. While this field
may or may not be
utilized by HTTP transport implementation, it could definitiely be
used by raw
IPP implementations directly over TCP ports for request pipelining
and verification of
responses.
The additional field would be a 32-bit binary field in big-endian
byte order. This
field would appear immediately after the initial version number
and IPP general
header. Before any attributes or data.
Comments?
Randy
--------------62A5254C4C1E8C680E0AAF07
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML><BODY>
<UL>I would like to propose an additional encoding field that would
be included in the
application/IPP body for IPP requests. This additional field
would be a
"transaction identifier" field. IPP clients would generate a
unique transaction identifier
to be included with each request. The IPP server would not do any
processing or
interpretation of the transaction identifier. Instead, the IPP server
would just include
this transaction identifier on the response message to the original request.
The client would then use the received transaction identifier to match
this response to
the original request that it generated previously. While this field may
or may not be
utilized by HTTP transport implementation, it could definitiely be
used by raw
IPP implementations directly over TCP ports for request pipelining
and verification of
responses.
The additional field would be a 32-bit binary field in big-endian byte
order. This
field would appear immediately after the initial version number and
IPP general
header. Before any attributes or data.
Comments?
Randy
</UL>
</BODY>
</HTML>
--------------62A5254C4C1E8C680E0AAF07--