I like option 4.
However, I think the inhale-job/exhale-job option actually needs two new
operations: Get-Job (not Get-Job-Data, because it also gets the
attributes), and Get-Document (for multi-doc jobs).
-Carl
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/18/2000 02:19:53 PM
To: Carl Kugler/Boulder/IBM@IBMUS, "Hastings, Tom N"
<hastings@cp10.es.xerox.com>
cc: Michael Sweet <mike@easysw.com>, ipp@pwg.org
Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and P
rinter Admin (Set2) spec
I agree that the following language is too restrictive:
> This operation is limited to redirecting a job to another
> Printer on the same server.
How about something like:
Which Printers the Printer supports for the Redirect-Job operation is
indicated by the values of the "redirection-printers-supported" (1setOf
uri)
Printer Description attribute. An implementation MAY limit the list of
Printers to ones on the same "server" and/or in the same security domain.
Now, if a Printer implementation actually solves the security problem of
delegation of access control and also is implemented to become a client and
perform a Create-Job on any other Printer on the network, then we have 4
alternatives for the spec:
1. Only have one operation and probably change its name back to Move-Job,
since it MAY (but NEED NOT) make a copy of the Job and submit it to another
Printer (on another host). Then use the new 'any' OOB to indicate an
implementation that is willing to move the job to any other Printer.
2. Have two operations, one called Redirect-Job and has a limited list and
a
second operation, called Move-Job. If Move-Job is implemented, the Printer
MUST support sending the job to any Printer on the network.
ISSUE: Or is there an in between implementation, where there are several
servers in the same security domain, to the Printer has to be like a client
and send the job to another network node, but since it is in the same
security domain, it is straightforward to do. If there is the in-between
case, then just having a single operation (alternative 1) makes the most
sense, since implementers are free to limit the Printers or not, depending
on server and/or security considerations.
3. Don't have either of these operations, but instead as suggested by Carl,
have a single operation that gets the Job and its data, say, Get-Job-Data,
from the Printer. Then the client can submit the job to any Printer (at
the
cost of two transfers of data, rather than one) using Create-Job. Then the
client cancels the old copy of the job using Cancel-Job.
4. Have Redirect-Job for redirection between Printers on the same "server"
(or security domain), i.e., where a copy is not needed (or the security
problems are manageable), and Get-Job-Data (plus Create-Job and Cancel-Job)
for moving a job from any Printer to any other Printer.
Comments?
Tom
-----Original Message-----
From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
Sent: Tuesday, July 18, 2000 09:38
To: Hastings, Tom N
Cc: Michael Sweet; ipp@pwg.org
Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
P rinter Admin (Set2) spec
Tom wrote:
...
>>For the Redirect-Job, the "redirection-printers-supported" Printer
>Attribute
>>is all that is necessary for a Printer to indicate to which other
Printers
>>it is willing to redirect output. We don't need to introduce a Server
>>object to help with the simple Redirect-Job that redirects jobs among
>>Printers on the same server.
>>
>Then I don't think you need to introduce a little 's' "server", either.
>It's an implementation detail whether or not the
>"redirection-printers-supported" are on the same server. You only need to
>specify the protocol. If an implementation can meet the spec, it doesn't
>matter how it does it. You don't need to specify an architecture
involving
>a "server". (If there is a reason that "server" is important, then I'm
>still not getting it.)
>
>TH> I think you are getting it. We don't need to introduce the concept of
>"server" at all for Redirect-Job. All that is necessary is that a Printer
>(object) be able to enumerate the Printers to which it is willing to
>redirect a job. A Printer indicates this list in the values of its
>"redirection-printers-supported".
>
This then brings us back around to my original point, which is that this
wording in the spec is too restrictive:
> This operation is limited to redirecting a job to another
> Printer on the same server.
For example, in our case, we should be able to redirect a Job to any
Printer on a server that's in the same "namespace" (or "cell"), even though
a namespace may contain multiple servers.
-Carl
This archive was generated by hypermail 2b29 : Tue Jul 18 2000 - 18:05:14 EDT