Subject: IPP> Protocol encoding addition...

From: Randy Turner <[email-masked]>
Date: Wed, 21 May 1997 15:01:44 -0700

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

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 21 May 1997 15:28:13 PDT

At 03:01 PM 5/21/97 PDT, Randy Turner wrote: 

<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 

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 

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: [email-masked]

---

From: Larry Masinter <[email-masked]>
Date: Wed, 21 May 1997 15:35:13 PDT

I'm dissatisfied with "application/ipp" as the name for the
Internet media type registration, because it's somewhat
redundant (i = internet in an internet protocol) and misdirected
(the content is not a 'protocol', it's a description of a
print job used in one protocol but useful possibly in others).

So I suggest renaming it: application/print-job. That is,
an 'application/print-job' is a description of a job that the
sender wants the recipient to print.

It might be possible to send one of these in an internet fax,
or in just regular email. You're designing it to work
in a particular kind of messaging (one in which the result
of the message is something that lets you query status and
modify the job later), but it's just a message.

As far as a 'transaction identifier' that Randy Turner was
proposing, I thought that the transaction was a resource, and
that you would identify it using a uniform resource identifier
(aka URI aka URL).

A 'raw IPP' shouldn't be so raw as to not allow interaction
with printer resources using ipp://host URLs instead of http://host
URLs, but for the most part, which protocol you were using
would just be determined by the name of the scheme.

Larry
--
http://www.parc.xerox.com/masinter