Wouldn't it be better to leave it up to the administrator to assign access
to different operations as they see fit? The flexibility for configuring
the printing system would be greatly enhanced.
my 2 cents...
Mike
| -----Original Message-----
| From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
| Sent: Thursday, August 19, 1999 2:37 PM
| To: Wagner,William
| Cc: ipp@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
|
|
|
| "Wagner,William" <bwagner@digprod.com> on 08/19/99 10:05:29 AM
|
| To: Carl Kugler/Boulder/IBM@IBMUS, ipp@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@us.ibm.com [mailto:kugler@us.ibm.com]
| Sent: Thursday, August 19, 1999 11:28 AM
| To: ipp@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@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.
|
|
|