> From rturner@sharplabs.com Mon Sep 15 19:48:18 1997
> Date: Mon, 15 Sep 1997 19:24:26 -0700
> From: Randy Turner <rturner@sharplabs.com>
> To: ipp@pwg.org
> 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: scott_isaacson@novell.com
> > >W: http://www.novell.com
> > >************************************************************
> > >
> > >>>> Robert Herriot <Robert.Herriot@Eng.Sun.COM> 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