IPP> Protocol encoding addition...

IPP> Protocol encoding addition...

Randy Turner rturner at sharplabs.com
Wed May 21 18:01:44 EDT 1997


--------------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--



More information about the Ipp mailing list