The two key points Roger mentions that I find to be worthy of serious
analysis/understanding by the IPP group:
- Perhaps most folks don't know this, but an LPD client has
NO WAY OF LEARNING THE JOB ID ASSIGNED BY THE LPD SERVER for a
job the client has submitted to the server. (Sad, but very true.)
This is where I believe some of the assumptions presented by Bob
kinda fall apart real fast.
- Why on earth would a given client want to switch between using
LPD and IPP? Somehow Bob makes one believe this is commonly
desired functionality, but I just don't get it. Again, the
presented assumptions appear to fall short. (Paraphrasing an
age-old verse, "Give unto IPP what is IPP's, and give unto LPD
what is LPD's"... ;-)
Right now I'm sitting on the fence on which "side" to take on this
issue. I fully understand Roger's desire for elegance in casting the
Job as a real object; I also understand Randy's desire to use URI's
for Job object references to facilitate distributed operation. Both
of these desires seem like Good Things to me...as long as developers
don't have to pay too high a price for them.
I'm probably not the only one in the PWG having this simple #1 goal:
Ship products to make MONEY. (No altruism here, mind you... ;-)
To that end, I almost always prefer simplicity, PARTICULARLY when
we're talking about version 1.0 of any given spec.
It seems to me that the Job ID approach is inherently simpler.
However, digging deeper down leads me to believe that the Job URI
approach is just plain simple, too...as long as reasonable constraints
are placed on URI construction.
Maybe I'm missing something in my understanding of certain legacy
technologies, but I just don't understand the various messages
claiming that Job IDs *must* be used to facilitate legacy systems;
the arguments in those messages just don't describe enough of the
inherent problems in dealing with URI's on those systems.
Sorry for the long post, but one last question (since I couldn't make
the Redmond meeting):
What is wrong with defining a common URI syntax, either for
Printers or Jobs?
After working four long years with the PWG, it has become pretty
obvious to me that some people just have to insist on a "no bounds"
approach to specifications. I've found that the best standards (ie,
those readily accepted and widely deployed) are usually wrought with
all kinds of constraints. Such contraints tend to both facilitate
development AND improve interoperability.
Sorry, but I think IPP needs a healthy dose of constraints to get
this animal under control.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Roger K Debry wrote:
>
> Bob, can you clarify a few things for me please? It would help me understand
> your write-up.
>
> My questions noted with <RKD>
>
> 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.
>
> <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?
>
> 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.
>
> <RKD> ditto the above question.
>
> 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.
>
> <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?
>
> <RKD> How does the client know whether or not the id it assigned
> <RKD> is valid? What happens if it cnacels the job with the client
> <RKD> assigned id? Does it get told that the id is invalid? This
> <RKD> seems pretty flaky to me.
>
> 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.
>
> <RKD> Again, I don't understand this mixed mode of operation. Why
> <RKD> would an lpr client assume that the printer on the other end
> <RKD> would understand IPP? For that matter, why would the client
> <RKD> speak IPP? For that matter, if it did speak IPP, why would
> <RKD> it need a gateway?
>
> 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.
>
> <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?
>
> 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.
>
> <RKD> Once again I question why a client would operate in this mixed
> <RKD> mode. Why would an lpr client EVER use an IPP Get-Jobs???
>
> 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.
>
> <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
>
> 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.
>
> <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.
>
> 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.
>
> <RKD> Why don't you think it is well understood?
>
> 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.
>
> <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.
>
> <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