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

From: [email-masked] (Robert Herriot)
Date: Thu, 4 Sep 1997 18:31:46 -0700

> From [email-masked] Thu Sep  4 17:52:06 1997

> 
> Umm... you are assuming that the LPD gateway would need to use
> job numbers?  I just checked the RFC1179 and it appears that
> the term 'number' is really 'identifier'.  Thus the URI could be
> the identifier.  Now classically we have been using the
> "numerical portion of the control/data identifier" as the job number.

Yes, I am assuming a gateway which talks to REAL LPD print systems,
which all use integer identifiers.  I don't believe I need to plan for
hypothetical RFC1179 gateways which might use something else.

---

From: Roger K Debry <[email-masked]>
Date: Fri, 5 Sep 1997 09:06:54 -0400

I agree with Jay that this seems like a clean approach.  However,
if I've understood all of the arguments, I thought that dictating the form
of the URL was a no-no. On the other hand, if a PARTICULAR IMPLEMENTATION,
such as NT, requires a 32-bit integer job ID to be consistent with its existing
APIs, then there should be no reason why THAT implementation could not
use the approach that Jay suggests to easily map to an internal integer job
identifier.

I know that this may not solve the problem for a gateway somwhere in the
middle, but it does seem to me that for a particular server implementation
this works fairly well.

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 09/05/97 06:56
AM ---------------------------

        ipp-owner @ pwg.org
        09/04/97 10:06 PM
Please respond to [email-masked] @ internet

To: Robert.Herriot @ Eng.Sun.COM @ internet
cc: ipp @ pwg.org @ internet
Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs?

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

Robert Herriot wrote:
>
> 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: [email-masked]
Date: Fri, 5 Sep 1997 08:12:31 -0700 (PDT)

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

This looks like the right way to handle this.  If you want to have
control,  then you will have to enforce this in the specification.

I would suggest that you restrict the 'printer name' to 32 characters,
and the job number to a value represented by a 32 bit number.

Patrick Powell

---

From: Paul Moore <[email-masked]>
Date: Fri, 5 Sep 1997 11:03:53 -0700

We discussed this at the august meeting. You cannot extract the jobid
from the job-URI. Remember a 'particluar implmentation' has no meaning
for things visible in a wire protocol. There is both the client and the
server - if the url is to be in a specifc format then both sides must
agree to this. The only way that this would work is if we mandated the
url format (which we discussed doing and voted against)

> -----Original Message-----
> From:	Roger K Debry [SMTP:[email-masked]]
> Sent:	Friday, September 05, 1997 6:07 AM
> To:	[email-masked]

---

From: [email-masked]
Date: Fri, 5 Sep 1997 12:50:41 -0700 (PDT)

One of the ways that problems such as format for URI's for printing
can be handled is to issue an 'Informational' RFC that describes
a 'Best Practices' type of condition.

I do not see a conflict with the IPP RFC in doing this.  It would,
in fact,  probably be a good way to handle the issues of 'particular
URI formats for portability'.

Also,  an informational RFC and 'Best Practices' is not binding...
just gentle hints.

Patrick Powell

> From [email-masked] Fri Sep  5 11:39:50 1997
> From: Paul Moore <[email-masked]>
> To: "'Roger K Debry'" <[email-masked]>, [email-masked]
> Subject: RE: IPP>MOD Why use Job-Id instead of Job-URI for Jobs?
> Date: Fri, 5 Sep 1997 11:03:53 -0700
>

---

From: Paul Moore <[email-masked]>
Date: Fri, 5 Sep 1997 14:01:36 -0700

this is not an Informational RFC thing - either the client code can
depend on the jobid being derivable from the URL or it cannot. There is
no halfway house.

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, September 05, 1997 12:51 PM
> To:	[email-masked]; Paul Moore; [email-masked]

---

From: [email-masked] (Robert Herriot)
Date: Fri, 5 Sep 1997 15:30:21 -0700

> From [email-masked] Fri Sep  5 08:31:46 1997
> 
> Bob, can you clarify a few things for me please? It would help me understand
> your write-up.
> 
> My questions noted with <RKD>
> 
> <RKD> Why would the IPP client bypass the gateway and send an lpq
> <RKD> directly to the printer? It seems to me that an IPP client
> <RKD> would always use IPP. Are you describing a pathological case
> <RKD> here? Why would an IPP client (or and end user for that matter)
> <RKD> even suspect that the real printer would even understand lpq?

RGH: It is more a matter that an end-user may be printing from many 
RGH: different applications, some using IPP and others using LPD to
RGH: the same printer. The user may not even be aware of the route each
RGH: application takes to the printer. But the user may look at all  
RGH: jobs through a single print queue window. 

RGH: This answer applies to all of your questions that pertain to this
RGH: issue. 

> mechanism for the gateway to inform the client of the Job-Id.
> 
> <RKD> The following is to clarify normal lpr/lpd operation ...
> <RKD> So, an lpr request always generates a job-id on the client,
> <RKD> but sometimes it gets ignored (I assume then that the server
> <RKD> assigns the job-id. But there is no way for the server to tell
> <RKD> the client what id it assigned. Did I get it right?

RGH: Yes, you got it right, the server may use the client's job-Id or it
RGH: may create its own job-Id. When the server changes the job-Id, the
RGH: client can determine this only by using heuristics with the 'lpq' 
RGH: to match the queued jobs with jobs known to have been submitted.
RGH: Yes, LPD has its problems. 
> 
> <RKD> How does the client know whether or not the id it assigned
> <RKD> is valid? What happens if it cancels the job with the client
> <RKD> assigned id? Does it get told that the id is invalid? This
> <RKD> seems pretty flaky to me.

RGH: If the client uses its job-Id, the server will assume that the job-Id
RGH: is the server's Job-Id. Yes, it is flaky. That's one of the reasons
RGH: for IPP.

> required by LPD.
> <RKD> In the previous case, it sounded like the client could never
> <RKD> depend on the job id it assigned anyway. Why does it do so here?
> <RKD> Why doesn't the gateway ignore the client assigned id as in
> <RKD> the previous case, and force the client to do an lpq?

RGH: The issue is that the gateway has to use some integer Job-Id and the 
RGH: Job-URI does not satisfy the requirement. So the gateway either
RGH: creates a Job_Id or uses the client one. In either case, the gateway
RGH: must associate that Job-Id with the Job-URI and it is a number that
RGH: bears no relation to the Job-URI assigned by the IPP server.
> <RKD> Actually, I NEVER think of the job as belonging to the printer.
> <RKD> Most of the shared printers we use here in IBM are in printer
> <RKD> pools. I never know which one it will print on. I think of my
> <RKD> job as an object that (hopefully) the system knows how to
> <RKD> handle. When I cancel or query a job, I tell the client, and
> <RKD> let it worry about everything from there on. As a user I don't
> <RKD> care.
> 
> REDIRECTION
> 
> <RKD> Certainly you can remember either a URI or a job-id.
> <RKD> I think Randy's point was that using a URI, HTTP provides an
> <RKD> easy way to do redirection. Using a job-id, we would have to
> <RKD> invent a scheme that was IPP specific.

RGH: In the teleconference we discussed that fact that if a client
RGH: accesses a Job-URI which requires redirection, the server
RGH: needs to know when to delete the mapping between the old and the
RGH: new job-URI. Is it immediately after the first query? Is it after
RGH: the job has completed? Each of these strategies has problems.
RGH: In other words, the Job-URI solves only one small piece of the 
RGH: problem. 
> <RKD> Why don't you think it is well understood?

RGH: Because of the problems I cite above and because it has not been
RGH: fully implemented in DPA implementations.

> <RKD> One last question ... if we take the course of adopting a job-id,
> <RKD> how do we rationalize the notion of the job being an object? In
> <RKD> my mind, the only object we are left with is the printer object,
> <RKD> because now all operations are on the printer. For example, we
> <RKD> no longer provide the URI of the job and tell it to cancel itself.
> <RKD> We send the operation to the printer and tell it to cancel the job.
> <RKD> Ditto for querying job attributes. The operation goes to the printer.
> <RKD> In my mind, this very fundamental change forever dictates the way
> <RKD> IPP will deal with jobs. If we ever want to imagine the job as a
> <RKD> real object with a life of its own, that can be moved around the
> <RKD> network (whether it be for load balancing, recovery, etc.), queried,
> <RKD> cancelled, indepdendent of where it lives, then we ought not to
> <RKD> bind it now to a printer and lose it's identity as an object.

RGH: I see no reason why an object cannot be named by the pair
RGH: (printer-URI, job-Id).  The name and the object are separate
RGH: concepts. The name is just a way to reference the object.
> 
> <RKD> I think that Jay's suggestion to allow an implementation to create
> <RKD> job URI's by cleverly using the integer job id's currently supported
> <RKD> by existing system API's is a fine way to solve the problem for most
> <RKD> cases. The standard doesn't require URLs to be created that way,
> <RKD> but neither should it dis-allow it if it makes life easier for a
> <RKD> particular implementation.
> <RKD> does it

RGH: In Redmond, we considered and rejected the idea of having a Job-URI
RGH: that could be parsed into its constituent printer-URI and Job-Id.
RGH: It is certainly OK for a gateway to parse Job-URIs that it created,
RGH: but according to our decision, it is not OK for a client to parse
RGH: the job-URI from some server because they syntax of a Job-URI is
RGH: unspecified.

---

From: Paul Moore <[email-masked]>
Date: Fri, 5 Sep 1997 16:19:06 -0700

It was felt that a URl syntax would be highly specifc to a server
implementation - ISAPI, ASP, CGI, .....
Specifying it would constrain the implementation

> From:	Jay Martin [SMTP:[email-masked]]
> Sent:	Friday, September 05, 1997 3:21 PM
> To:	Robert Herriot
> Cc:	[email-masked]
> > But Microsoft clients cannot assume that all IPP servers will be
> > Microsoft servers. Thus the client has no sure way to parse the
> > Job-URI.
> 
> So again I ask: exactly why can't (or shouldn't) we standardize on
> a Job URI syntax?  (I really regret not being able to have made the
> Redmond meeting.)
> 
> 	...jay
>

---

From: [email-masked] (Robert Herriot)
Date: Fri, 5 Sep 1997 16:59:31 -0700

> From [email-masked] Fri Sep  5 16:21:30 1997
> 
> Robert Herriot wrote:
> > 
> 
> 
> > Even if we did specify the syntax for a Job-URI, there is still the
> > problem that its printer-URI constituent might be different from
> > the printer-URI to which the job was submitted.  That is also a
> > problem for a gateway because a gateway assumes that a job is named by
> > the printer to which the job was submitted plus a job-Id. If the
> > job-printer is different, the gateway would have to "remember" that.
> 
> I believe this is a different issue that should not be confused with
> the issue of standard URI syntax definitions.
> 

I disagree.  A parseable Job-URI would still be a problem for gateways.
That is, they would still need a job submitted to Printer P to have
a job identification of (P,n) where n is some integer.

---

From: [email-masked]
Date: Mon, 8 Sep 1997 21:27:23 -0700 (PDT)

> From [email-masked] Fri Sep  5 17:37:43 1997
> Date: Fri, 5 Sep 1997 16:59:31 -0700
> From: [email-masked] (Robert Herriot)
> To: [email-masked], [email-masked]

Actually, there would need (P,s) where s is a STRING or even a set of tokens.
Most implementations assume that s is either the user name or a job 'number'
but that is purely a matter of implementation.

Patrick Powell

---

From: [email-masked] (Robert Herriot)
Date: Tue, 9 Sep 1997 14:10:27 -0700

> From [email-masked] Tue Sep  9 13:53:49 1997
> 
> > Can you give a few details? Do you maintain a mapping table? If so,
> > what triggers the removal of entries? Or do you use an extended attribute
> > in the print job to hold the mapping?
> 
> Uhhh...  I believe that I will leave it as an exercise for the user.
> Let's just say that there is a variety of ways that one might do it;
> certainly either of the solutions that you hint to above might work.
> I could even imagine one or two more.
> 
> I do not mean to be too mysterious, but it seems sufficient to me
> that there are implementations in the field today that solve a
> similar problem.
> 

I ask these questions because the two most obvious solutions that I cite
above have problems in the IPP context.

The gateway cannot use some extended attribute to store the LPD Job-Id in
because an IPP server would discard attributes it doesn't support.

The gateway has difficulty using a mapping table because the IPP
notification is weak (email only).  A gateway would have to resort to
polling in order to determine what jobs can be removed from its mapping
table.  This works, but its not a nice solution, and it doesn't scale
well.

I assume that DAZEL doesn't have these restrictions.

Bob Herriot

---

From: Tom Hastings <[email-masked]>
Date: Tue, 9 Sep 1997 18:23:53 PDT

>because an IPP server would discard attributes it doesn't support.

Well, we certainly could add a "job-client-id" attribute to IPP, so that
gateways would have a place to store an opaque "handle" in an IPP job.
That seems a simple solution to help gateways and is something we
have in DPA as the "job-client-id" and the Job MIB as the jobSubmissionID
table which is a map from the client's id to the server's jmJobIndex.

>table.  This works, but its not a nice solution, and it doesn't scale

The current Model document has more than 'mailto' scheme.  It has 'http'
and 'ftp'.  (Where is SENSE when we need it?).  I agree that polling isn't
a nice solution, but lets make notification work.

---

From: [email-masked] (Robert Herriot)
Date: Wed, 10 Sep 1997 11:07:08 -0700

> From [email-masked] Tue Sep  9 19:01:45 1997
> 

I have specifically avoided suggesting that we add a job-client-id job
attribute because it would have to be mandatory in order to offer a
solution to an LPD-to-IPP gateway. I don't think it is reasonable for
all implementations to support such an attribute, and I don't want to
support it for an IPP-to-LPD gateway because the gateway would then
have to maintain state for a client that sends it to the IPP-to-LPD
gateway.

---

From: [email-masked]
Date: Mon, 15 Sep 1997 17:24:47 -0700 (PDT)

> From [email-masked] Fri Sep 12 16:34:10 1997
> Date: Tue, 09 Sep 1997 15:40:39 -0500
> From: Jim Walker <[email-masked]>
> To: Robert Herriot <[email-masked]>
> Cc: [email-masked]
> 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.

I remember discussions in June where this was addressed at length.
The results of the discussion was that there was overwhelming need
to have LPD/Microsoft/Whatever be able to gateway to IPP.

There was almost no indication that the opposite (IPP to whatever)
was desireable, necessary, etc.  This was on the basis that the newer
protocols/facilities may have options/capabilities that are impossible to
support in the older ones.

Now you may be able to have users RESUBMIT jobs to the older systems,
but note that this is not the same as having an IPP system translate
them.

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