Mike,
I think you are correct, and I assume that Carl only used this
classification as a set of hints on how the operations are likely to be used
by the different categories of users, without suggesting that they would be
firm rules.
Carl-Uno
> -----Original Message-----
> From: Shepherd, Michael [mailto:MShepherd at crt.xerox.com]
> Sent: Thursday, August 19, 1999 1:02 PM
> To: 'kugler at us.ibm.com'; Wagner,William
> 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.
> |
> |
> |
>