>>>>
<excerpt>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.
</excerpt><<<<<<<<
How unique does the identifier has to be? By client, by server, or
globally?
>>>>
<excerpt>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.
</excerpt><<<<<<<<
Sounds like it would be enough if the client can recognize it as
unique?
<excerpt>>>>>
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?
</excerpt><<<<<<<<
This sounds good, but you still have not explained why we want it and
what potential use we would have of it? I assume the intent is to keep
several related operations together, but is that not also important for
the server to know about?
>>>>
<excerpt>
Randy
</excerpt><<<<<<<<
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com