IPP currently defines three roles:
1. Job Submitting End User
A human end user who submits a print job to an IPP Printer. This person may
or may not be within the same security domain as the Printer. This person may
or may not be geographically near the printer.
2. Operator
A human user who carries out the policy established by the Administrator and
controls the day to day running of the print system.
3. Administrator
A human user who established policy for and configures the print system
These roles are not necessarily mutually exclusive, especially if you consider
that IPP is supposed to scale from desktop printers to book printing-on-demand.
I would map the existing and proposed operations to these roles as follows: (
"-": current, "+": proposed)
Job Submitting End User
- Print-Job
- Print-URI
- Validate-Job
- Create-Document
- Send-Job
- Send-URI
- Get-Printer-Attributes
- Get-Jobs
- Cancel-Job
- Get-Job-Attributes
- Hold-Job
- Release-Job
- Restart-Job
+ Set-Job-Attributes
+ Reprocess-Job
Operator
- Pause-Printer
- Resume-Printer
- Purge-Jobs
+ Disable-Printer
+ Enable-Printer
+ Shutdown-Printer
+ Restart-Printer
+ Cancel-Current-Job
+ Pause-Current-Job
+ Resume-Job
+ Promote-Job
+ Space-Current-Job
Administrator
+ Set-Printer-Attributes
+ Reset-Printer
I think what we've been loosely calling Admin ops are in most cases really
Operator ops.
If you want to put Set-Printer-Attributes and Reset-Printer into the Printer MIB
instead of IPP, I guess I could live with that. Howerver, implicit in that
decision is the assumption that the person most likely to be setting printer
attributes is the one that runs a network management system (an SNMP client like
Cabletron Spectrum or HP Openview) instead of the one that runs an IPP client.
While that might be true in a distributed environment, it is probably false in a
personal printer environment or a production printing environment.
-Carl
"Wagner,William" <bwagner at digprod.com> on 08/19/99 10:05:29 AM
To: Carl Kugler/Boulder/IBM at IBMUS, ipp at pwg.org
cc:
Subject: RE: RE: IPP> OPS - Issues/suggested resolutions to IP
First, I guess one of my problems is that I do not know what the intentions
of these operations are, how they are intended to be used and where they
stop. Surely, functions like "reset to factory" (if it is what it appears
to be)seems quite appropriate to SNMP. That is why I ask for some statement
of the purpose of the administrative operations; i.e., a charter defining
the intent, reason and bounds of the activity, that as been agreed to.
Second, I have consistently maintained that whether this is an IETF working
group or PWG project group is a detail that makes no difference to me or I
suspect, many others. Whatever the group feels conformable with. That goes
for MIBs or IPP extensions. IETF red tape should not be a reason to not
approach things in a public and orderly way.
Bill W.
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Thursday, August 19, 1999 11:28 AM
To: ipp at pwg.org
Subject: Re: RE: IPP> OPS - Issues/suggested resolutions to IP
Well, I'd like to see your proposal for doing these operations with
SNMP. Or are you saying we should form some BOFs and commitees first,
wait for a few IETF cycles, and perhaps produce something a few years
from now?
original article:http://www.egroups.com/group/ipp/?start=6203
> Tom,
>> Many thanks for your through response. I am not a DPA veteran and I
suppose
> I never fully grasped that IPP was intended as another crack at what
DPA had
> attempted. And it would appear that I was not paying enough attention
to the
> background portions of the IPP specification so that this intention
was made
> clear to me. Rather, I have thought of IPP as a job submission
mechanism,
> with enough feedback to the user to allow device selection and
monitoring
> and job related features selection. Being more on the networking
side, my
> bias is toward using SNMP as the device administrative mechanism. We
all
> have spent several years working toward the goal of printer
management by
> SNMP, and I think that there has been substantial success in that
area. I
> fail to see the desirability of establishing yet another mode of
device
> management.
>> Also, my consideration of IPP as dealing with a logical printer
rather than
> a physical printer is a somewhat pragmatic one. I think it unlikely
that I
> will be dealing with many IPP-only printers in the foreseeable
future. There
> are still several very well entrenched job submission
protocols/applications
> that will be supported for some time yet. The typical physical printer
> contains several printservers or logical printers, of which IPP is
only one.
> Therefore, while one can stretch the interpretation of the charter
and say
> that IPP might include the ability to manage the IPP server, it does
not
> seem appropriate to give IPP control over a device which also
supports LPD,
> PServer, PAP, FTP, Port9100, and several other print services. Indeed,
> because the intention of using IPP as a general printer device
management
> mechanism is not at all clearly stated in the existing charter, I
think I am
> perhaps not the only one who is confused by the proposed
administrative
> operations, and uncertain to what they reasonably apply and how they
are to
> be used.
>> If the industry (in the form of a PWG subgroup or an IETF BOF
group)wishes
> to establish IPP as a printer device management mechanism (or a
general
> imaging device management mechanism) to supplement or replace SNMP, it
> should scope out and state this intent. Then we will all have a
better idea
> of what we are trying to do and why. But I think you would agree that
there
> must be some guidelines to a new venture of this sort.
>> Bill Wagner
>>>>> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Wednesday, August 18, 1999 12:06 PM
> To: Wagner,William; ipp
> Subject: RE: IPP> OPS - Issues/suggested resolutions to IPP Additional
> Adm in Operations [debate about whether to add them to IPP]
>>> Bill,
>> Sorry not to respond to your mail earlier. I find it puzzling to be
arguing
> whether IPP is supposed to apply to logical printers versus physical
> printers (and to which our charter allows). When we started out on
IPP,
> those of us who had some implementation experience with ISO DPA,
wanted to
> learn from that experience and to make IPP simpler than ISO DPA. ISO
DPA
> did have both a logical printer object and a physical printer object.
> However, having both complicated the semantics with some benefits and
some
> problems.
>> So in doing IPP, we simplified the Printer object so that it can
represent
> either a logical device or a physical device. But there is only one
object
> that accepts IPP requests. This decision is documented in the IPP
Model and
> Semantics document itself (where agreements should be documented, so
that
> there is no mis-understanding):
>> Section 2.3
>> A Printer object can represent either one or more physical output
devices or
> a logical device which "processes" jobs but never actually uses a
physical
> output device to put marks on paper. Examples of logical devices
include a
> Web page publisher or a gateway into an online document archive or
> repository. A Printer object contains zero or more Job objects.
>>>> Furthermore, the model picture in Section 2.1 shows the Printer object
> embedded in the output device, where the IPP Printer object is surely
> representing the output device:
>> embedded printer:
> output device
> +---------------+
> O +--------+ | ########### |
> /|\ | client |------------IPP------------># Printer # |
> / \ +--------+ | # Object # |
> | ########### |
> +---------------+
>>>> and in Section 12.2.3 defining "Supports"
>> The set of values in any of the supported value attributes is set
> (populated) by some administrative process or automatic sensing
mechanism
> that is outside the scope of this IPP/1.1 document. For
administrative
> policy and control reasons, an administrator may choose to make only a
> subset of possible values visible to the end user. In this case, the
real
> output device behind the IPP Printer abstraction may be capable of a
certain
> feature, however an administrator is specifying that access to that
feature
> not be exposed to the end user through the IPP protocol. Also, since
a
> Printer object may represent a logical print device (not just a
physical
> device) the actual process for supporting a value is undefined and
left up
> to the implementation. However, if a Printer object supports a
value, some
> manual human action may be needed to realize the semantic action
associated
> with the value, but no end user action is required.
>> For example, if one of the values in the "finishings-supported"
attribute is
> 'staple', the actual process might be an automatic staple action by a
> physical device controlled by some command sent to the device. Or,
the
> actual process of stapling might be a manual action by an operator at
an
> operator attended Printer object.
>> For another example of how supported attributes function, consider a
system
> administrator who desires to control all print jobs so that no job
sheets
> are printed in order to conserve paper. To force no job sheets, the
system
> administrator sets the only supported value for the
"job-sheets-supported"
> attribute to 'none'. In this case, if a client requests anything
except
> 'none', the create request is rejected or the "job-sheets" value is
ignored
> (depending on the value of "ipp-attribute-fidelity"). To force the
use of
> job start/end sheets on all jobs, the administrator does not include
the
> value 'none' in the "job-sheets-supported" attribute. In this case,
if a
> client requests 'none', the create request is rejected or the
"job-sheets"
> value is ignored (again depending on the value of
"ipp-attribute-fidelity").
>>>>> So I find this debate about whether or not operations on IPP objects
can
> have effect on the actual device puzzling. If an operation on an IPP
> Printer object does something like pause it or shut it down, then
that is
> intended to have some effect on the actual device.
>> I also find it puzzling to debate about our charter as to whether it
> includes logical versus physical printers. I don't see anything like
that
> in our charter.
>> The reason why I found it "natural to add Administrative operations"
is
> because an IPP implementation already has a path to the device with
> security, authorization, etc., and a state model that can reflect the
effect
> of such administrative operations. We also heard from Microsoft that
their
> experience of supporting devices using two protocols: SNMP Printer
MIB and
> port 9100 (or LPD) had so many problems that they wanted a single
protocol
> to do both. In doing a printer protocol we need to consider the
clients
> that will be supporting our devices as well as our own
implementations. The
> print vendors can't go it alone.
>> While we could add these administrative operations to SNMP by writing
some
> more MIBs, I prefer that we add these administrative operations to the
> protocol that can do job submission, job query, and device query,
namely,
> IPP. SNMP will never do job submission.
>> Comments?
>> Tom
>> -----Original Message-----
> From: Wagner,William [mailto:bwagner at digprod.com]
> Sent: Tuesday, July 27, 1999 08:30
> To: 'Hastings, Tom N'; ipp
> Subject: RE: IPP> OPS - Issues/suggested resolutions to IPP Additional
> Adm in Operat ions
>>> A point of confusion remains as to whether the newly proposed
administrative
> functions apply to the IPP logical printer (the print object
identified in
> the IPP specifications), or to the physical printer device. There is
nothing
> in the charter having to do with physical device management. Or,
perhaps I
> have missed an unpublished charter under which the group is now
operating? I
> have been assuming that any IPP reference to printer was to the IPP
Printer
> Object. Operations like "pause printer" can be assumed to apply to a
logical
> printer. However, it seems something of a stretch to consider
operations
> such as shutting down power on a logical printer. It certainly
appears that
> others are thinking of the operations as being performed on the
physical
> device in some, if not all cases.
>> Tom contends that "it is natural" that IPP do printer [device]
management. I
> see nothing natural about it; IPP does what the group specifies that
it
> does. If the group decides that IPP should do device management,
then this
> should be stated (and bounded) in a PWG or IETF charter. And it must
be
> clearly stated whether an operation applies to the IPP Printer object
or to
> the physical printer. But this intent should not be left up to the
> interpretation of the reader.
>> Indeed, I now wonder if Printer Attributes in general refer to the
logical
> or physical printer; if a printer can do 4-up printing in PostScript
but
> does not recognize this as a Job Template attribute, is number-up
printing a
> supported attribute? If it is an attribute of the logical printer,
why does
> the spec maintain that it may be document-format (printer language)
> dependent?
>> William A. Wagner (Bill Wagner)
> Director, OEM Technology
> DPI Imaging Division
> NETsilicon Inc.
> 411 Waverley Oaks Road, #227
> Waltham, MA 02452
> Telephone 781-398-4588
>>> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Monday, July 26, 1999 8:49 PM
> To: ipp
> Subject: IPP> OPS - Issues/suggested resolutions to IPP Additional
Admin
> Operat ions
>>> Title: Issues in IPP/1.0 & 1.1 Additional Administrative
Operations,
> 7/19/1999
> From: Tom Hastings
> Date: 7/26/1999
> File: ipp-ops-admin-issues-990726-th.doc
>> I've added Carl's and my suggested resolutions to all of these issues,
> preceded by CK> or TH>, respectively. The dates indicate a mail
message on
> the subject.
>> Here are the collected issues that are embedded in the "IPP/1.0 & 1.1
> Additional Administrative Operations, 7/19/1999, that was posted at:
>>ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-admi
> n-990719.doc
>ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-admi
> n-990719.pdf
>ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-admi
> n-990719-rev.doc
>ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-admi
> n-990719-rev.pdf
>> ISSUE 1: Can a client determine the values of "when" that are
supported
> for operations (Pause-Printer, Reset-Printer, Shutdown-Printer, and
> Pause-Current-Job)?
>> TH> Just add a "when-values-supported" that applies to all of the four
> operations supported, with the exception of Pause-Current-Job. For
> Pause-Current-Job, only the 'now' and 'after-current-copy' have any
> meaning, so the other two values ('after-current-job' and 'after-all')
> don't apply.
>> ISSUE 2: Can we add just one Printer Description attribute:
"settable-
> attributes" or do we need a "printer-settable-attributes" and a "job-
> settable-attributes" Printer Description attributes? What if the
> Interpreter and/or the Document object become real objects, would we
> need to add "interpreter-settable-attributes" and "document-settable-
> attributes" Printer Description attributes?
>> TH> Replace the "settable-attributes" Printer Description attribute,
> with three Printer Description attributes: "printer-settable-
> attributes", "job-settable-attributes", and "interpreter-settable-
> attributes". The latter for those implementations that have different
> values for Printer attributes in the Get-Printer-Attributes and Set-
> Printer-Attributes operations, depending on the value of the
"document-
> format" operation attribute supplied by the client. If and when we
get
> a Document object, then we can add a "document-settable-attributes"
> Printer Description attribute.
>> ISSUE 3: Ok that the "printer-controls-other-protocols" Printer
> Description attribute is just a boolean, or do we need a list of
> operations that affect non-IPP protocols?
>> TH> It would be more flexible to allow per-operation control, so
change
> from "printer-controls-other-protocols" Printer Description attribute
to
> "operations-affecting-other-protocols (1setOf type2 enum). The values
> are defined by the "operations-supported (1setOf type2 enum)"
operation.
>> ISSUE 4: Is IPP intended for printer management. The issue is still
> undetermined?
>> TH> I think it is natural and so far there is not much overlap with
any
> MIB. If and when we do get overlap, we need to make sure that the
> semantics are the same.
>> ISSUE 5: Do we need a way to get and/or set the "xxx" attribute for
all
> Interpreter objects in one Get-Printer-Attributes or Set-Printer-
> Attributes operation? Or is it sufficient for a client to provide the
> equivalent functionality by stepping through all the values of the
> "document-formats-supported" with repeating the Get or Set operation?
>> TH> Its sufficient for the client to perform the "all" function.
>> ISSUE 6: Ok to add the Interpreter object, even though it doesn't
solve
> all of the attribute constraint problems. At least it gives us a more
> object-based description of the semantics. When we do add some sort
of
> Printer Description attribute that enumerates combinations of Job
> attribute values that may not be used in combination (like PPD file
> constraints), it can include the "document-format" attribute among
them.
> So introducing the Interpreter object in no way precludes a complete
> constraint description mechanism in the future.
>> TH> Yes, its good modeling and doesn't change the IPP/1.0 and IPP/1.1
> syntax or semantics.
>> ISSUE 7: Why not have a separate out-of-band 'not-settable' value, so
> that the client can distinguish between the cases of the attribute
isn't
> supported versus the attribute is supported, but is not settable?
True,
> the client can query the "settable-attributes" to see which attributes
> can be set, before or after issuing the Set-Printer-Attributes
> operation.
>> TH> I think that providing a separate out-of-band code is useful,
since
> a reply could contain both unsupported attributes and ones that were
> supported, but are not settable in this implementation.
>> ISSUE 8: Is the "non-process-run-out" operation attribute really
needed
> at all or can the default behavior for Reset-Printer be defined to be
to
> perform non-process run out (for continuous and cut sheet printers)?
>> CK 7/19/99: Remove the concept of non-process-run-out from all
> operations, but add a new operation that performs non-process run-out.
> This operation will be useful for web printers. Call this operation:
> Run-Out-Printer?
>> ISSUE 9: What state does the Printer comes back up on
Restart-Printer
> and how can the client control?
> Possible alternatives:
>> a. Restart-Printer always brings the Printer up Disabled
("printer-
> is-accepting-jobs" = 'false') and Paused ("printer-state" =
> 'stopped', and "printer-state-reasons" = 'paused') which is the
> state that Shutdown-Printer leaves the Printer in. Then the
> operator issues Enable-Printer and Resume-Printer when want to
> restore normal operation. The client can automatically issues
> these addition 2 operations depending on GUI options.
Advantages:
> This is the simplest to implement, allows new states to be added
> without changing the Restart-Printer operation, and can have the
> same GUI interface as b:
>> b. Add a REQUIRED operation attribute to Restart-Printer,
something
> like "printer-condition" with values: 'disabled-and-paused',
> 'enabled-and-paused', and 'enabled-and-idle'.
>> TH 7/26: Remove the Shutdown-Printer 'standby' mode concept.
Shutdown-
> Printer always powers off eventually. Also remove Restart-Printer
> operation all together. Instead change the Disable-Printer and
Enable-
> Printer operations to Disable-Operations and Enable-Operations, so
that
> individual operations are enabled and disabled independent of the
state
> of the Printer and don't otherwise affect the state of the Printer.
>> ISSUE 10: Is the "non-process-run-out" operation attribute really
> needed at all or can the default behavior for Restart-Printer be
defined
> to be to perform non-process run out (for continuous and cut sheet
> printers)?
>> CK 7/19/99: Remove the concept of non-process-run-out from all
> operations, but add a new operation that performs non-process run-out.
> This operation will be useful for web printers. Call this operation:
> Run-Out-Printer?
>> ISSUE 11 - Need to look at life cycle of the Printer versus
> standby/power-down and the other operations that can be accepted.
There
> can be appreciable time between acceptance of this operation and when
> the final state of the printer, either standby or powered down is
> reached. Is it ok for non-submission operations to continue to be
> accepted during this time? May need 'moving-to-shutdown'. What about
> 'moving-to-standby'?
>> TH> Add 'moving-to-shutdown' which the Shutdown-Printer sets
> immediately (analogous to 'moving-to-paused'). Then the 'shutdown'
> values means that the shutdown has completed (and is only meaningful
to
> a server implementation that hosts the Printer object). Thus the
server
> can still respond to a Get-Printer-Attributes operation after the
> Printer is shutdown as stated in IPP/1.1.
>> ISSUE 12: Is the "non-process-run-out" operation attribute really
> needed at all or can the default behavior for Shutdown-Printer be
> defined to be to perform non-process run out (for continuous and cut
> sheet printers)?
>> CK 7/19/99: Remove the concept of non-process-run-out from all
> operations, but add a new operation that performs non-process run-out.
> This operation will be useful for web printers. Call this operation:
> Run-Out-Printer?
>> ISSUE 13: It isn't clear which type of checkpointing is being
suggested
> for synchronize: checkpoint a stream or checkpoint in a job that is
on a
> disk file in the printer.
>> CK 7/19/99: Suggest that it means checkpoint the job to disk, such
that
> processing can be resumed in the future. Get all the counters and
> whatever from the output device and save that information persistently
> so that the job might be resumed in the future.
>> ISSUE 14: Do we really need the "synchronize" operation attribute for
> the Shutdown-Printer operation or can synchronization be the default
> behavior of the Shutdown-Printer operation? It is not clear why this
> would ever be false? If it never makes sense to be 'false', can we
> remove it altogether?
>> CK 7/19/99: "synchronize" is set to false in exceptional conditions;
> like when a previous attempt to shutdown with "synchronize" 'true'
hung
> (should never happen but apparently it does sometimes). This could be
> automated with some kind of timeout mechanism, but we chose to give
the
> operator direct control.
>> So change the default behavior from 'false' to 'true' when the client
> omits the "synchronize" operation attribute.
>> ISSUE 15: Is the current job automatically restarted when the Printer
> is restarted? Or does some client have to issue a Restart-Job
> operation?
>> The question is moot, if we remove the Restart-Job operation, as
> suggested:
>> TH 7/26: Remove the Shutdown-Printer 'standby' mode concept.
Shutdown-
> Printer always powers off eventually. Also remove Restart-Printer
> operation all together. Instead change the Disable-Printer and
Enable-
> Printer operations to Disable-Operations and Enable-Operations, so
that
> individual operations are enabled and disabled independent of the
state
> of the Printer and don't otherwise affect the state of the Printer.
>> ISSUE 16: Why isn't non-process-run-out automatic on a continuous
form
> printer? When would an operator want to cancel the job and NOT run
out
> the last sheets.? It would be simpler to require process-run-out when
> canceling the current job (for continuous and cut sheet printers).
>> CK 7/19/99: Remove the concept of non-process-run-out from all
> operations, but add a new operation that performs non-process run-out.
> This operation will be useful for web printers. Call this operation:
> Run-Out-Printer?
>> ISSUE 17: Is the "non-process-run-out" operation attribute really
> needed at all or can the default behavior for Pause-Current-Job be
> defined to be to perform non-process run out (for continuous and cut
> sheet printers)?
>> CK 7/19/99: Remove the concept of non-process-run-out from all
> operations, but add a new operation that performs non-process run-out.
> This operation will be useful for web printers. Call this operation:
> Run-Out-Printer?
>> ISSUE 18: Do we really need the "synchronize" operation attribute or
> can synchronization be the default behavior of the Pause-Current-Job
> operation?
>> CK 7/19/99: "synchronize" is set to false in exceptional conditions;
> like when a previous attempt to shutdown with "synchronize" 'true'
hung
> (should never happen but apparently it does sometimes). This could be
> automated with some kind of timeout mechanism, but we chose to give
the
> operator direct control.
>> So change the default behavior from 'false' to 'true' when the client
> omits the "synchronize" operation attribute.
>> ISSUE 19: Is the Space-Current-Job reasonable to perform when the
> current job is in the 'processing' state when paper is still moving?
>> CK 7/20/99: We can do Space-Current-Job while the printer is stopped,
> paused, or running.