The attachment is a synopsis of my thinking on the current
job-URI/job-ID issue.
Let me know if you can't read the attachment.
Randy
--------------BAC48DC27EEA630E5822BCF5
Content-Type: text/plain; charset=us-ascii; name="ipprat.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="ipprat.txt"
I have looked into the Microsoft spooler API over the last 2 days and
have come up with the following conclusions. The Microsoft Spooler
architecture (at least for Win95) contains an AddJob() function that,
along with other information, returns a job identification value (DWORD)
which is a 32-bit value. This value is instantiated internal to the
spooling subsystem. This DWORD value (job-ID) is what is used to refer
to the job in other API calls.
When you request an IPP server to create a job, it allocates resources
and also assigns a unique job-ID to reference that job. This job-id can
either be a URI or an INTEGER. Regardless of the choice of a job-id
format, it looks like a win95 IPP client will always need to maintain
a mapping between the win95-created job-id and the IPP server-created
job-id.
As far as LPD gateways, much of the "bypass" logic mentioned in Bob's
earlier message, where an LPD client bypasses the gateway for
some reason is pathological and references a very high-sigma
case.
I don't think the architecture of legacy gateways should severely
impact the nature and flexibility of what we are designing. It might
seem hard to believe, but more than one vendor I know of is planning
on native IPP support for distributed internet/intranet printing.
Alot of what we have in the model as far as negotiation of features
and best-effort philosophies is not supported by legacy print systems
but we have included it because someone "might" want to do this type
of print-feature verification. The capabilities of legacy systems
should not dictate the architecture of what we are doing, unless what
we are proposing absolutely breaks existing print systems, and IMHO,
nothing that we have proposed does this.
The flexibility of job URIs with regards to server design and protocol
scalability are not "difficult to understand". If we are designing a
printing protocol what will be constrained to a particular size
environment, then alot of the rationale for scalability disappears. But
if what we are proposing is to allow IPP to scale from small departmental
environments all the way up to enterprise internetworks, then we need to
consider scalability, and server-generated job URIs are a really good
way to do this.
Some examples of the type of flexibility and scalability follow:
The syntax of a URI/URL is:
scheme: <scheme-dependent parameters>
For an HTTP scheme URL, the following syntax is observed:
HTTP://<host>:<port>/path-name-to-resource;parameters?query
For flexibility and scalability, the IPP server may elect to vary
any of the HTTP scheme fields (host, port, pathname, parameters) depending
upon IPP server policy. An authenticating IPP server may distribute jobs
to different hosts for load balancing depending upon what value the "host"
field is set to on the returned job-URI. These jobs may not only be
distributed to different physical host machines, but possibly differently
configured IPP servers running on the same host, but at different port
numbers. These multiple server threads can either be started at boot
time or dynamically spawned by a particular master IPP server thread so
the IPP service burden floats with the actual amount of job load
being handled.
For a particular centralized IPP server, the URL might be:
HTTP://ipp.kinkos.com/main
This URL would be the target of initial print job requests by potential
clients.
Also, in a directory services environment, an administrator might only
want to maintain very few entries in the directory for key IPP servers,
then let those servers distribute jobs as needed to other secondary
servers. This eases the burden of maintaining directory entries for
every possible IPP-capable printer on the network.
Some other types of job distribution can occur when a particular site has
IPP servers installed on large file servers or enterprise servers, as well
as IPP services embedded in some subset of printers on the network. The
server-based IPP implementation might be very robust and support all the
features of IPP (both mandatory and optional), and provide spooling
services. This key IPP server might handle all of the complex
negotiation and other features of IPP, while a much lighter weight
version of IPP exists in the printer. This would allow access to the
printer by complex printing clients that fully utilize IPP (through the
master server), as well as simple clients that only want to do very basic
printing (they can use IPP to print directly to the printer if they so
desire).
Along with the job-URI, the authenticating IPP server may elect to embed
into the parameters section some key information regarding the job owner,
or possibly some type of server-dependent job-index or key that facilitates
easy access to job accounting or other job managment information. Again,
these fields are basically opaque to the IPP client.
There was also rationale in my previous comments to the fact that URI
specifications and HTTP allow dynamic redirection of print jobs. The
redirection of print jobs may be a result of administrative operator
intervention, or used to provide some level of fault tolerance if
a particular job is redirected due to some printing device becoming
unavailable. Again, using HTTP redirects allows the client to follow
this redirection easily. In practice, any caching of the previous
job URI by the client, or by a gateway, would have to be refreshed.
This is less of an issue with clients than it might be for a gateway.
But IMHO this solution is far better than designing an entirely new
solution of our own, just for IPP.
Getting back to the LPD gateway problem, while I am writing this, Jay's
mail message stating that "there is no way for an LPD client to know
what job id was created on job submission" echoes a conversation Jay
and I had on the phone earlier. RFC 1179 states that the only way an
LPD client knows how to reference a job is by executing a subsequent
LPQ request and obtaining a list of jobs and hoping that the LPD server's
job list contains enough unique information for the end user to pick out
his or her job from the list. Note that the design of this protocol was
that a human end user would be doing this. LPD servers can return whatever
format they want for the job list, and human intuition can easily parse
the returned information to pick out the correct job ID (hopefully). But
when a machine has to do this, it becomes a much more difficult task.
I always thought that the only time we would be gateway'ing between LPD
and IPP would be in the case of a server-based implementation of IPP;
wherein an IPP server takes requests from an IPP client and possibly
converts the user's request into an equivalent LPR request to some
legacy server (or printer).
I don't consider the scenario of an LPD client talking over the network
to a IPP server to be a viable scenario. For transitional purposes,
administrators should not be tearing down their existing printing
environments, in this case, we don't have to worry about actually
converting LPD control file attributes to IPP equivalents; because each
site's existing LPD environment works fine as it is.
I think what we have to worry about are server-based IPP implementations
that have to map IPP client requests to whatever existing legacy print
environment is in use for a particular OS environment, whether it be
the Microsoft spooler interface, or a Unix LP or LPD environment.
Let me know if I'm missing a key scenario here...(I'm sure you will :)
I am hoping that IPP<->LPD gateway philosophy is geared towards providing
some type of "transition" to native IPP.
I am also trying to figure out if Jay's proposal to at least add one
"known" field to the job-URI string, that being the last field in the string
is the "job-index", is violating too much of the idea of client opacity to
the job-URI syntax.
--------------BAC48DC27EEA630E5822BCF5--