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@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@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-o
ps-admi
> n-990719.doc
> ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-o
ps-admi
> n-990719.pdf
> ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-o
ps-admi
> n-990719-rev.doc
> ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-o
ps-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.