I was just trying to show how the proposed ops fit into the existing IPP model.
Certainly each operation could be assigned its own access rights. Not only
that, but the proposed ops are OPTIONAL extensions and could be disabled
entirely or not implemented in the first place. If you don't like 'em , you
don't have to build 'em.
Meta-discussion:
Is there any way to register proprietary extension operations, or do we just
pick a number from 0x4000-0x8FFF at random and hope we don't collide?
Looking at the model doc, it looks like the only choices are to either get an
extension approved or take your chances in the private extension range.
-Carl
"Shepherd, Michael" <MShepherd at crt.xerox.com> on 08/19/99 02:01:40 PM
To: Carl Kugler/Boulder/IBM at IBMUS, "Wagner,William" <bwagner at digprod.com>
cc: ipp at pwg.org
Subject: RE: RE: IPP> OPS - Issues/suggested resolutions to IP
In an IPP implementation, can't each operation be individually assigned the
desired accessibility? I'm not sure if your mapping of operations into
three roles is just what is intended (but not required) or if we are
proposing to tie these operations to these roles.
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 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
|||| "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-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.
|||