Subject: Re: IPP> Protocol encoding addition...

From: JK Martin <[email-masked]>
Date: Wed, 21 May 1997 18:51:30 -0400 (EDT)

In response to Randy's newly proposed addition you wrote:

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

It's not important (nor even useful) for the server to know about such
client-specified transaction IDs.

Client-specified transaction IDs can be found in lots of different
protocols, including SNMP and CPAP.  As Randy pointed out, it helps
the client match responses to previous requests.  This allows a
client to post multiple requests at one time--without waiting for
the responses in a synchronous manner--then later match the responses
once they arrive from the server.

Good idea, Randy, although such transaction IDs probably won't be of
much use in the HTTP-mapped implementation scenario.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Harry Lewis <[email-masked]>
Date: Thu, 22 May 1997 20:09:16 -0400

In the job MIB spec we have defined jmJobSubmissionID formats which could serve
the same pourpose as these transaction ID's.

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

>How unique does the identifier has to be?  By client, by server, or
>globally?

Here is an excerpt from the MIB:

        The value of jmJobSubmissionIDIndex should be one of the
        registered format types.  The first two octets of the string
        shall indicate which registered format is being used.  The agent
        shall assign a string of registered format (00) for any job
        without a Job Submission ID.  The format values registered so
        far are:

          Format
          Number   Description
          ------   ------------
          00       Set by the agent when neither the client nor the
                   server assigned a job submission ID.

          01       octets 3-10:  8-decimal-digit random number
                   octets 11-32: last 22 bytes of the jobName attribute

          02       octets 3-10:  8-decimal-digit sequential number
                   octets 11-32: Client MAC address

          03       octets 3-10:  8-decimal-digit sequential number
                   octets 11-32: last 22 bytes of the client URL

          ..       to be registered according to procedures of a type 2
                   enum.  See section 7.3 on page 18.

        NOTE - the job submission id is only intended to be unique
        between a limited set of clients for a limited duration of time,
        namely, for the life time of the job in the context of the
        server or device that is processing the job.  Some of the
        formats include something that is unique per client and a random
        number so that the same job submitted by the same client will
        have a different job submission id.  For other formats, where
        part of the id is guaranteed to be unique for each client, such
        as the MAC address or URL, a sequential number should suffice
        for each client (and may be easier for each client to manage).
        Therefore, the length of the job submission id has been selected
        to reduce the probability of collision to a very low number, but
        is not intended to be an absolute guarantee of uniqueness.

Harry Lewis - IBM Printing Systems