Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs?

From: [email-masked]
Date: Tue, 16 Sep 1997 11:16:23 -0700 (PDT)

Note:
  As I have said,  I think there is a separate issue of Printers
and Spoolers for the IPP protocol.  Gateways are EXPLICITLY spoolers.
Now you can incorporate or try to incorporate spooler functionality
into a printer,  but you should note that the 'server' that everybody
seems to be referring to is,  to me, at least,  a PRINTER server
and not a SPOOLER server.

> From [email-masked] Mon Sep 15 19:48:18 1997
> Date: Mon, 15 Sep 1997 19:24:26 -0700
> From: Randy Turner <[email-masked]>
> To: [email-masked]
> Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs?
> 
> I will try and emphasize my position on LPD gateways by saying that
> I don't consider the LPD-to-IPP gateway case to be a common case
> for gateways. As I have stated previously, it gives no value to
> LPR/LPD clients to gateway to IPP because they are still
> funneling(filtering) their requests through the same front end
> interface.  The kind of technology we are delivering for IPP version
> 1.0 is oriented towards the user, so outfitting end users (clients)
> with IPP as soon as possible should (IMHO) be the goal for deployment
> of IPP.

I disagree.  I feel that LPD->IPP gateways will be needed for
various compatibility reasons,  as there are a very large number of
folks out there who have LPR/LP type of implementations and want to
get the services available with IPP type of control,  but do not want
to upgrade/change their printing mechanisms on ALL the hosts under
their control.  I might note that IPP Spoolers are currently not part
of the IPP protocol,  so we are simply having an academic discussion,
right?

> 
> Also, administrators should not be deinstalling their current base
> of LPR/LPD services. IPP will supplement, not replace, LPD during
> a transition phase.

If I was to think about designing a spooler,  I would start with
a IPP spooler and then design in LPD to IPP translation.  But this is
a design decision.  You could also have separate queues for each job
(LPR/IPP) type as well.

> 
> I do see a need for IPP-to-LPD gateways because IPP servers (operating
> as spoolers on WinNT or Unix systems), might want to connect directly
> to network printers using TCP/IP, and the most commonly deployed
> embedded TCP/IP printing solution within printers is
> LPD.

While this is the most commonly 'deployed' method,  I think that most
folks would use the 'TCP/IP socket' to the print engine to transer jobs,
especially if you wanted to emulate things like status information, etc.

>   We would like to include the existing installed base of
> network printers in IPP configurations, but we don't want to have
> to upgrade their firmware to do this.  Therefore, allowing IPP
> servers to transfer print jobs into the LPD environment is something
> I think needs to happen. Dropping data and control files into LPD
> spool directories from an IPP server is pretty easy on Unix systems.
> I'm not positive about Windows/NT based LPD services but I would
> imagiine that this is also fairly straightforward.
> 

Been there, done, that.  Trivial.

> Also, concerning Roger's comment about delaying Job-URIs into
> Version 2.0,  I think
> 
> the URI is one of the only really new features of network printing
> we are offering and I would really like to see it available in
> version 1.0; among other things, its the job URI that will allow
> easy deployment and integration of IPP over other transports other
> than HTTP, which is something I think we all are thinking about
> for the future.
> 
> Also, converning Patrick Powell's comments about the movement of
> jobs using URIs, this feature is only one of the features that job
> URI provides so we shouldn't focus on this one aspect of functionality
> (even though we get it for free with the adoption of the URI concept,
> and its not hard to envision its use regarding the movement of
> jobs).
> 
> Randy
> 
> 
> 
> Tom Hastings wrote:
> 
> > I too am trying to understand Bob's third alternative and do not have
> > an opinion.
> >
> > However, there is a variation on Bob's third alternative that might be
> > less of a burden on IPP servers, while providing the same benefit to
> > supporting IPP under current APIs and in gateways.
> >
> > The idea is basically to have only job-uri as the access point for jobs, but
> > require an additional attribute that a client can supply a 32-bit job
> > id in and the server just stored it away.  So instead of the client or
> > gateway having to store the job-id
> > to job-uri map, the map is stored in the IPP server.  This solves the
> > stale data problem, because the map information is kept as long as the
> > job exists in the server and no longer.
> >
> > This approach is what ISO DPA has in its job-client-id attribute.
> >
> > This is the strategy that we are using in the IETF Job Monitoring MIB
> > with the jmJobSubmissionID table which accepts any client id as an input
> > index and returns the job-id that the server/agent is using.
> >
> > The only issue left is how does a client or gateway find a job
> > with a particular job-id?
> >
> > There are two ways:
> >
> > One way would be to add the job-id as an optional input filter attribute to the
> > Get-Jobs attribute which takes the Printer URI as input, not a JOB URI
> > and the client would get back the job.  This would put the burden on
> > the server of being able to access jobs in two ways, but only on Get-Jobs
> > which is a search anyway.
> >
> > The Get-Attributes operation would continue to require the job-uri.
> >
> > So a client could either:
> > (1) cache the job-uri and use it for subsequent Get-Attributes or Cancel-Job
> > (2) always use Get-Jobs operation to perform a Get-Attribtes for a particular
> >     job and use Get-Jobs operation first to get the job-uri in order to do the
> >     Job-Cancel.
> >
> > The other way, would be to put the burden completely on the client
> > (by only mandating that the IPP server support the "job-client-id" 32-bit
> > attribute and just passively store the attribute supplied by the client).
> >
> > Then the client must use a Get-Jobs with the
> > "requested-attributes"='job-client-id,job-uri' and get all of the
> > mapped pairs back and find the URI it needs to use in the IPP operation
> > on a job: Get-Attribute or Cancel-Job.
> >
> > With either way, the map is kept in the IPP server.
> >
> > Comments?
> >
> > Tom
> >
> > At 08:53 09/09/97 PDT, Scott Isaacson wrote:
> > >Bob did a good job at introducing and summarizing the issues associated with
> > >the "open minded" idea of having both Job IDs and Job URIs.  I am really
> > >trying to have an open mind and think new thoughts, but my gut reaction and
> > >continued perception (even after reading Bob's message) is that it is too
> > >cumbersome, and not very elegant.  It does not really solve the problems
> > >unless we force ALL Printer implementation to support the passing in and
> > >then passing back out of this helper attribute.  That seems ok, but when
> > >implementations must support operations either being addressed to a Printer
> > >(P), or a Job (J), or a Printer plus ID (P,s), and then respond in Get-Jobs
> > >etc with both (J) and (P,s), that sounds very un-ok.
> > >
> > >Let's either fish or cut bait.
> > >
> > >Scott
> > >
> > >
> > >************************************************************
> > >Scott A. Isaacson
> > >Print Services Consulting Engineer
> > >Novell Inc., 122 E 1700 S, Provo, UT 84606
> > >V: (801) 861-7366, (800) 453-1267 x17366
> > >F: (801) 861-4025, E: [email-masked]
> > >W: http://www.novell.com
> > >************************************************************
> > >
> > >>>> Robert Herriot <[email-masked]> 09/05 5:59 PM >>>
> > >It was suggested at the last teleconference that we should have both
> > >Job-URIs and Job-Ids.  This email looks at the pros and cons of that idea.
> > >
> > >I want to make it clear at the outset of this email, that I am not taking
> > >a position on whether we should have both. Rather I want to explore what
> > >the ramifications are if we have both.
> > >
> > >The following are what I think the characteristics of such a solution are.
> > >
> > >If we decide to have both Job-URIs and Job-Ids, all IPP servers MUST
> > >support both; otherwise, we are in worse shape than with just one of
> > >them from all servers. Client MUST be free to use whichever they want.
> > >
> > >For Print-Job, it doesn't matter whether a client specifies whether it
> > >wants a Job-URI or Job-ID, or whether the server returns both.  In both
> > >cases, the server has to deal with both and the client has to be aware
> > >of the choice. So for this discussion, let's assume that the server
> > >would return both.
> > >
> > >For Get-Attributes and Cancel-Job, a server must implement these
> > >operations for both Job-URIs and Job-Ids.  The target may be a Job-URI
> > >or the target may be a Printer-URI with a Job-Id attribute.
> > >
> > >Both Job-URI and Job-Id attributes are mandatory. Thus a client can
> > >query for either via Get-Jobs or Get-Attributes.
> > >
> > >The following discusses how this solution works with various gateways.
> > >This solution works well in Win32 because it would use the Job-Id only.
> > >It also works well for IPP-to-LPD gateways and LPD-to-IPP gateways.
> > >
> > >The IPP-to-LPD gateways work well because the Job-Id and Job-URL
> > >are both easy to support. So, acting as an IPP server, the gateway can
> > >easily support both together.
> > >
> > >The LPD-to-IPP gateway is easy to support with Job-Ids, so such a
> > >gateway, as a client of a IPP server, would use only the Job-Id and
> > >would ignore the Job-URL.
> > >
> > >So from a legacy point of view, the solution with both Job-URIs and Job-Ids
> > >is as good as the Job-Id solution only.
> > >
> > >But now we need to examine what this change means for server
> > >implementations.
> > >
> > >With this change servers would have a bit more work to do because they
> > >would have to offer two ways to do the same thing.  Moreover, it is
> > >mandatory that if they support a particular operation, they must
> > >support both Job-URIs and Job-Id.  That may be a burden that some
> > >implementors won't like -- more code for some abstract future payback.
> > >
> > >I expect that for most IPP servers its Job-URIs will always consists of
> > >its Printer-URI and a Job-Id so the server can easily convert between
> > >Job-URIs and Job-Ids with no architectural additions.
> > >
> > >But for servers that want the Job-URI to reference some remote host,
> > >the solution is more complicated because operations, such as
> > >Get-Attributes and Cancel-Job will go to the remote host when the
> > >client uses the Job-URI and these same operations will go to the
> > >Printer when the client uses the Printer-URI and Job-Id.  Such servers
> > >will have to deal with forwarding issues and the fact that a Job-URI
> > >that references a remote host does not guarantee that all traffic goes
> > >there because client that use the Job-Id will still come to the original
> > >printer.
> > >
> > >
> > >
> > >As I said at the beginning of this email, I take no position on this
> > >proposal.  Rather I offer it as the beginning of a discussion.
> > >
> > >I would like others to comment on whether this proposal solves the
> > >problem, or adds too much complexity to servers for the payback.
> > >
> > >
> > >Bob Herriot

---

From: Randy Turner <[email-masked]>
Date: Tue, 16 Sep 1997 12:48:59 -0700

PAPowell said:
>their control.

You're going to find that mapping IPP semantics (control file, job reject codes, etc.)
is going to be very difficult to do, especially given the diverse LPR/LPD
environments. I think administrators would much rather transition to IPP than
invest a large amount of time shoe-horning these users into the new environment.
There current implementations are working fine, and I think we are only talking
about Unix clients making up the bulk of these end users. The user interface
available with unix-based LPR/LPD clients doesn't even handle the fact that
a job can be refused for the vast majority of possible reasons that an IPP server
might issue. The LPR interface only handles any errors dropping the file into the
spool directory. The LPD daemon writes any errors into an administrative log
file that must be looked at to determine if and why a job might not have printed.
Its just not realistic to expect massive amounts of gateway code to be written
for LPR/LPD clients, only to give them the ability to know whether their job
can be printed (i.e., VALIDATE_JOB), which is the only feature of IPP that
I could see LPR/LPD clients utilizing. The existing interface just doesn't allow
any interactivity with the job submission process.

LPR/LPD -to- IPP is not how I think IPP will be deployed; we need a rich user
interface (GUI, http-capable, etc.) to really take advantage of what we are
offering. Also the Windows print provider interface seems to also provide all
of these capabilities to GUI-based windows clients.

> I might note that IPP Spoolers are currently not part

We haven't restricted IPP to either spoolers or print servers, and we shouldn't
preclude either implementation.

Randy
(I hope my email messages are easy to read now, I re-configured my
email client to not wrap all of my text)