IPP> OPS - Issues/suggested resolutions to IP

IPP> OPS - Issues/suggested resolutions to IP

IPP> OPS - Issues/suggested resolutions to IP

kugler at us.ibm.com kugler at us.ibm.com
Thu Aug 19 11:27:41 EDT 1999


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