IPP> OPS - Issues/suggested resolutions to IP

IPP> OPS - Issues/suggested resolutions to IP

IPP> OPS - Issues/suggested resolutions to IP

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Fri Aug 20 00:12:42 EDT 1999


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



More information about the Ipp mailing list