Carl,
I understand what you are saying. Although I do not necessarily agree that
extensions to IPP are the best way to address Administrator level
operations, I personally have no objection to these extensions provided that
the operations are clearly defined to be upon only the printing service
implicit in the IPP protocol and not upon the physical printer nor any other
printing service (although there may be some secondary effect upon the
printer.) For example, reset to factory may be used to set IPP attributes to
default values, but not network node parameters (such as IP address) nor
parameters for any other printing service supported by that printer. Where I
believe that additional clarification and scope definition would be
necessary is when these operations are intended to be upon the physical
printer itself.
More clearly, if the intent is to use IPP as a network device management
mechanism (as some have suggested), then this should be clearly stated and
agreed to(or not) as the understood objective before incorporation into the
general specification.
I think that your message and the additional information that Harry has
agreed to provide will help to avoid any confusion as to the intent and
scope of the proposed extensions.
Bill Wagner
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Thursday, August 19, 1999 2:37 PM
To: Wagner,William
Cc: ipp at pwg.org
Subject: RE: RE: IPP> OPS - Issues/suggested resolutions to IP
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