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

From: [email-masked] (Robert Herriot)
Date: Fri, 5 Sep 1997 18:24:06 -0700

> From [email-masked] Fri Sep  5 18:15:34 1997
> 
> Bob,
> 
> Some of your discussion assumes that the use of the integer job-id
> and printer-uri combination would be included in operations to the
> original printer-uri.
> 
> What if we included the integer job-id as an attribute within the
> operation, and after job submission and assignment, all operations
> were directed at the job-URI. The server handling the job-URI would
> then notice that the request is specifying an integer job-ID and
> it would use that instead of the information derived from the
> URI string?
> 
> Randy
> 

Your suggestion wouldn't work for the LPD-to-IPP gateway because it
assumes that the target for all operations is the Printer specified by
the LPD operation. The gateway can easily take the LPD
(printer-name,Job-Id) and produce an IPP (Printer-URI,Job-Id), but it
cannot produce an IPP Job-URI.  I suspect the same problem exists for
the win32 library.

It is necessary that the Job-URI and the (Printer-URI,Job-Id) be
separate interfaces at potentially different hosts in order for this 
proposal to work.

Bob Herriot 
> 
> 
> 
> Robert Herriot wrote:
> > 
> > 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: Scott Isaacson <[email-masked]>
Date: Tue, 09 Sep 1997 09:53:36 -0600

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.

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.

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.

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.

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.

there because client that use the Job-Id will still come to the original
printer.

Bob Herriot

---

From: "CN=Roger K Debry/OU=Boulder/O=IBM@IBMUS@IBMLMS01"@us.ibm.com
Date: Mon, 15 Sep 1997 18:14:56 -0400

This may be a real cop-out, but one SIMPLE approach is to declare that for
version 1.0
of IPP, Job-ID is what you get . . . period.

Then leave the door open for version 2.0 to add a Job-URL IF and WHEN it is
determined
that customers need the flexibility/scalability that Job-URL adds.  In stage
II, it wouldn't
seem too difficult to add a query to see if a server supported JOB-URL.

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/15/97 04:04
PM ---------------------------

        ipp-owner @ pwg.org
        09/15/97 03:35 PM
Please respond to [email-masked] @ internet

To: SISAACSON @ novell.com @ internet
cc: ipp @ pwg.org @ internet, Robert.Herriot @ Eng.Sun.COM @ internet
Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs?

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

---

From: [email-masked]
Date: Wed, 17 Sep 1997 08:22:32 -0700 (PDT)

> From [email-masked] Tue Sep 16 15:49:16 1997
> Date: Tue, 16 Sep 1997 15:23:12 -0700
> From: Randy Turner <[email-masked]>
> To: [email-masked]
>  PAPowell wrote:
> ..snip..
> >The LPRng interface quite happily delivers errors.
> >And note that it is free, compiles and runs on just about any UNIX system
> >with TCP/IP networking, and there is even an NT port (Don't ask, it wasn't
> >pretty).
>
> The context of our LPR/LPD gateway has been constrained on the widely
> deployed version that come shipped with Sun, HP, IBM, and other Unix
> boxes, which is more or less based on RFC 1179 (with vendor extensions)
> and for which the line mode interface I was referring to is the predominant
> interface.

Are you saying that it will ONLY work with these versions and the vendor specific
(and undocumented...) extensions?  Or am I missing something here?
Not trying to be sarcastic,  just trying to find out the basic intent.

Patrick