Subject: IPP>MOD Why use Job-Id instead of Job-URI for Jobs?

From: [email-masked] (Robert Herriot)
Date: Thu, 4 Sep 1997 14:27:25 -0700

I will try to explain why the Job-URI is harder to support than the
Job-Id for an LPD gateway. I will also explain why the requirements
that call for a Job-URI are not well enough understood to be
requirements.

ANALYSIS OF JOB-URI VS JOB-ID

For the gateway, there are two directions: IPP-to-LPD and LPD-to-IPP.

I have two goals for these gateways.  They should 
   1) be stateless: which means that gateways get all their information
      from the downstream server rather than storing information about
      jobs in the gateway.
   2) provide values to the client that are the same (possibly after a
      conversion algorithm) as the client could get from bypassing the
      gateway, which means gateways pass information without converting
      it or converting it in an algorithmic fashion that a client can
      apply an inverse function to. This provision is important because
      some applications on a client may use the gateway and others may
      bypass it.

The Job-URI is hardest to support in the LPD-to-IPP direction because
it fails to meet goal #1 above (it requires state). There is no simple
way to algorithmically map the IPP Job-URI to an LPD Job-Id because the
Job-URI is opaque.

The Job-URI solution for both directions fails to meet goal #2 because
it has the problem of exposing both Job-Ids and Job-URIs to a user for
the same set of jobs and there is no conversion algorithm.

Now for the two gateway directions for both Job-Id and Job-URI.

First let's examine the IPP-to-LPD gateway where the gateway returns a
Job-Id.  The gateway creates the job-Id for LPD when it receives a
Print-Job operation. It then returns the LPD job-Id to the IPP client
as the value of the Job-Id. This Job-Id is the same one that Cancel-Job
uses to specify the job to cancel.  When a client performs Get-Jobs,
the Job-Ids in the lpq reply to the gateway become the values of the
Job-Id attribute in the Get-Jobs response.  If the client sends an lpq
directly to the printer, bypassing the gateway, it sees the same
values for Job-Ids.

Next, let's examine the IPP-to-LPD gateway where the gateway returns a
Job-URI.  The gateway creates the job-Id for LPD when it receives a
Print-Job operation. It then returns to the IPP client the Job-URI
which consists of the printer-URI and the LPD Job-Id.  This Job-URI is
the same one that Cancel-Job uses to specify the job to cancel. Because
the gateway composed the Job-URI, it can parse it into the printer-URI
and job-URI. When a client performs Get-Jobs, the Job-Ids in the lpq
response to the gateway are composed with the printer-URI to form the
value of each Job-URI in the Get-Jobs response.  If the client sends an
lpq directly to the printer, bypassing the gateway, it sees the job's
Job-Ids rather than their Job-URIs. So the client gets different values
for identifying the jobs and the client cannot convert between Job-URI
values and Job-Id values because the rules for composing Job-URIs are
not specified.

Next, let's examine the LPD-to-IPP gateway where the gateway returns a
Job-Id.  The gateway client creates an job-Id which the gateway ignores
because the IPP server creates its own Job-Id. Existing LPD servers
sometimes ignore the Job-Id value requested by the client. LPD provides no
mechanism for the gateway to inform the client of the Job-Id. The
client must use the lpq command to get Job-Ids.  When a client performs
an lpq, the Job-Ids in the Get-Jobs reply to the gateway become the
values of the lpq response.  This Job-Id from lpq is the same one that lprm
command uses to specify the job to cancel. If the client sends a
Get-Jobs directly to the printer, bypassing the gateway, it sees the
same values for Job-Ids.

Finally, let's examine the LPD-to-IPP gateway where the gateway returns
a Job-URI.  The gateway client creates a job-Id. The gateway either
remembers this Job-Id or creates its own because the IPP server creates
a Job-URI which has no direct relationship to the integer Job-Id
required by LPD. When a client performs an lpq, the Job-URIs in the
Get-Jobs reply to the gateway must be mapped to the Job-Id for the lpq
response.  When the gateway receives an lprm command, it must map the
received Job-Id to the IPP Job-URI required for Cancel-Job.  If the
client sends a Get-Jobs directly to the printer, bypassing the gateway,
it sees Job-URIs which have no relation to the Job-Id's that it sees via
the gateway.  There are two ways to handle the mapping. Either the
gateway maintains its own internal table which it must update when jobs
complete or it needs a scratch-pad attribute in the job where it can store
the Job-Id.  The latter case would require that servers not throw away 
unsupported attributes and a search of the mapping would require that the
gateway perform a Get-Jobs.

QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION

Now that I have presented the problems that the Job-URI presents, I
now would like to question its touted advantages.  I have heard two.

   1) It allows for redirection more easily
   2) It allows for better load balancing

I address both below and conclude that Job-URI's aren't necessary with
our current understanding of requirements.

I also wonder if Job-URIs that are unrelated to the Printer-URI
containing the job will confuse users who are exposed to them.  A user
thinks of a job as belonging to a printer. So if a Job is identified by
the Printer-URI that the user selected and some number, that seems to
me like a simpler concept.

REDIRECTION

Whether a job is represented uniquely by Job-URI or (Printer-URI,Job-Id), 
either of these "names" references some host somewhere and when a job
moves, that host has to keep track of where is has moved to, and when
to delete the reference. It would seem to me that either Job-URI or 
(Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even
when they move.  So either should suffice in this case and since Job-Id
is easier for legacy connections, Job-Id is the better solution.

In my opinion, the redirection of print jobs is a research area
that is not well enough understood for us to be creating requirements
for a standard.

LOAD BALANCING

The idea is that the Job-URI may reference a different host than the
Printer-URI references so that references to the job don't load the
print server.  

There may be other solutions, such as clustering of Web servers, which
solve the problem without the added complexity of Job-URIs.

This problem is way beyond the 80% solution we are striving for and is
also a research area that is not well enough understood for us to be
creating requirements for a standard.

---

From: Jay Martin <[email-masked]>
Date: Thu, 04 Sep 1997 23:53:02 -0400

Bob,

Thanks for the rebuttal info on this issue.  You continually point
out this basic desire/premise/goal:

	IPP job id == LPD job id

You gave lots of good examples, paying particular attention to
exposure issues with end users.  In fact, my reading of your message
makes me come away believing that consistent end user visibility is
extremely high on the priority list...maybe even #1.

This may be.  (I'm not sure, myself.)  However, if the exposure of
job ids is so critical, then why don't we also insist on:

	IPP printer name == LPD printer name

I've been assuming all along that an IPP printer name would appear
to an end user as something like:

	http://host.domain/printer/<name>

(Or any one of five bazillion permutations on the URL theme.)

However, in LPD land, a "printer" is almost always a "simple" name,
such as: laser1, plot3, mkt, lp3, etc.  Simple sequences of just
letters and numbers (usually), with possibly a sprinking of hyphens,
underscores, etc.  However, almost never is the name constructed as
a series of sub-tokens assembled in a hierarchical fashion.  (Sure,
it can be done...but it just *isn't* commonly done in real practice.)

Aren't you concerned with that kind of shift in visibility, too?

Of course, one can always assume some sort of standard (de facto)
mapping mechanism, whereby the "simple" name is always the last token
of the URL string:

	http:://host.domain/printer/laser1 == laser1

If this is good enough, then why can't the same be true for job
ids, eg:

	http://somewhere.net.domain/subsys/server3/345 == 345

If nothing else, then such a simple job id mapping mechanism can be
standardized for IPP "printers" front-ending LPD queues.  Even in the
non-LPD case, this kind of job identification looks pretty clean:

	http:://host.domain/printer/laser1/345

This kind of approach looks real clean to me, but maybe I'm just a
bit too close to the code, if you know what I mean.

I must be missing something, right?  Thanks for your insights.

	...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: Jim Walker <[email-masked]>
Date: Tue, 09 Sep 1997 15:40:39 -0500

Some comments on these IPP<->LPD gateway discussions...

... I agree with Scott that the gateway between IPP and legacy
    systems should *not* be the driving force behind our design.

... There seems to be a base assumption that mapping a from a
    LPD job identifier (integer) to an IPP job URL is a difficult
    problem.  I would assert that it is not.  We have a gateway
    that has been in existence for four years now that solves this
    exact problem: it maps from the LPD job identifiers to an opaque
    printer-independent job identifier.

    And folks, it wasn't that hard to do.

later...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX