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@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@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.