>Are these factory-settings somehow inherently kept in the printer's
>implementation? Does IPP specify how are they stored?
Typically, factory setting are stored in NVRAM or ROM. They represent a
fail safe means of re-establishing a baseline of device operation.
>I maintain that there MUST be a way for at least an administrator
>to get the factory settings - if for nothing more than for providing
>an Admin Tool with a list of available options to display. If a
>printer loses the ability to advertise a certain feature, loses that
>feature all together.
I don't necessarily agree, since factory settings are not volatile. Also,
"factory-settings" would be the actual initial values, not necessarily a
list of all the features as your comment (above) seems to indicate.
IBM Printing Systems
"Shepherd, Michael" <MShepherd at crt.xerox.com>
Sent by: owner-ipp at pwg.org
01/11/00 08:07 AM
To: "Hastings, Tom N" <hastings at cp10.es.xerox.com>, ipp
<ipp at pwg.org>
Subject: RE: IPP> RESEND: OPS - Set-Job-Attributes and
Set-Printer-Attribu tes spec
posted for 1/12/2000 telecon
These are my comments regarding the Set operations. If you'd like to
discuss, please call me at home this afternoon (315-524-3013).
Line 201 & 251: "factory-settings" - I like that this operation attribute
applicable to only Get-Printer-Attributes. Is it ok that the user is
restricted to getting either the factory settings or the regular IPP
attributes, but not both, in the same operation? Are these
somehow inherently kept in the printer's implementation? Does IPP specify
how are they stored? Should the factory-settings be READ-ONLY IPP
Line 216: Typo - second "printer-message-time" should be
Line 252: "factory-settings" continued: This operation attribute is
OPTIONALLY supported by the printer, but I maintain that there MUST be a
for at least an administrator to get the factory settings - if for nothing
more than for providing an Admin Tool with a list of available options to
display. If a printer loses the ability to advertise a certain feature,
loses that feature all together.
Line 320: I agree with Ron. I don't see the value of this attribute.
Wouldn't knowing 'who', not 'how', created the printer message be more
interesting? "printer-message-info" could have a Name + phone number for
Line 353: How does an administrator set up his own attribute value
conflicts? For instance, a printer implementation may allow duplexed
transparencies, but the admin wants to reject this type of job.
Issue 04 comment: Can we use out-of-band "no-value"?
Issue 05 comment: This would be nice though. Just set the attribute to be
the new list of values sans the undesired value. If
is set to "staple" and "bind", to remove "staple" you would do a
Set-Printer-Attributes with just "bind". Also specify in the spec how you
add a value to a multi-valued attribute...if you want to set "trim", do
just do a Set-Printer-Attributes with "trim", or do you have to include
currently set values in the operation ("staple", "bind", "trim")?
Issue 07 comment: Seems ok to me
Issue 08 comment: This may be useful. "true" could mean 'set all or
"false" could mean 'set what you can'
Lines 576-577: What if the job submitter incorrectly specified these
attribute in the job creation? Must he cancel and resubmit the job?
the reason why these aren't settable?
| -----Original Message-----
| From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
| Sent: Monday, January 10, 2000 5:36 PM
| To: ipp
| Subject: IPP> RESEND: OPS - Set-Job-Attributes and
| Set-Printer-Attributes spec posted for 1/12/2000 telecon
| Importance: High
||| Some people did not receive this mail message, so I'm sending
| it again.
|| > -----Original Message-----
| > From: Hastings, Tom N
| > Sent: Wednesday, January 05, 2000 15:33
| > To: 'ipp'
| > Subject: OPS - Set-Job-Attributes and Set-Printer-Attributes spec
| > posted for 1/12/2000 telecon
| > I've extracted the Set-Printer-Attributes and Set-Job-Attributes and
| > related items from the Set2 spec and have posted it here
| for review on the
| > mailing list and at the 1/12/2000 telecon:
| > f
| > c
| > We agreed at the December IPP WG meeting that we needed to
| do more work
| > between each IPP WG meeting in order to make more progress on the
| > Notification and Administrative operations. We agreed to have some
| > sub-groups work between the meetings. We agreed to do this
| via telecon,
| > rather than traveling. We also agreed that the entire
| mailing list would
| > be advised of any meetings or telecons, so that anyone can attend.
| > However, it was the understanding that the sub-group members would
| > thoroughly review any documents during a one week period
| prior to any
| > meeting or telecon.
| > The following people volunteered to help progress the work between
| > meetings for the Administrative operations:
| > Peter Zehler, Harry Lewis, Michael Wu, Tom
| Hastings, and Ron
| > Bergman
| > We did not appoint a Set operations sub-group, but believed
| that it would
| > include this group and more. Of course anyone else is
| welcome. Please
| > send comments to the DL before the meeting next Wednesday,
| > That will help progress the meeting. The SLP template is
| also on the
| > agenda.
| > Meeting details:
| > Time: January 12, 2000 10:00 - 12:00 PST (1:00 - 3:00 EST)
| > Phone: 1-888-749-8496 (8*534-8273 for Xerox folks)
| > Passcode: 86037#
| > Here is the abstract:
| > This document specifies 2 additional OPTIONAL operations
| for use with the
| > Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1
| > [ipp-mod, ipp-pro]. These operations are the Set-Printer-Attributes
| > operation that operators/administrators may perform on a
| Printer object
| > and the Set-Job-Attributes operation that end-users may
| perform on their
| > jobs and operators/administrators may perform on any job,
| depending on
| > circumstances.
| > The Interpreter object is added for those implementations
| that make a
| > distinction on the values of some Printer attributes
| depending on the
| > document-format, such as "resolution-supported".
| > Two operation attributes: "printer-message-from-operator"
| (text) and
| > "job-message-from-operator" (text) are included to set the
| > IPP/1.1 Printer and Job Description attributes with the
| same names. A
| > "factory-settings" (boolean) operation attribute is added to the
| > Get-Printer-Attributes operation.
| > New Printer Description attributes are added:
| > printer-settable-attributes (1setOf type2 keyword)
| > job-settable-attributes (1setOf type2 keyword)
| > printer-message-time (integer(MIN:MAX))
| > printer-message-date-time (dateTime)
| > printer-message-operation (type2 enum)
| > A new status code is added: 'client-error-attributes-not-settable'.
| > Finally, the 'not-settable' out-of-band attribute value is
| added for use
| > with the Set-Printer-Attributes and Set-Job-Attributes operations.
| > The scope of IPP, is characterized in RFC2526 "Design Goals for an
| > Internet Printing Protocol". It is not the intent of this
| document to
| > revise or clarify this scope or conjecture as to the degree
| of industry
| > adoption or trends related to IPP within printing systems.
| It is the
| > intent of this document to extend the original set of
| operations - in a
| > similar fashion to the Set1 extensions which referred to
| IPP/1.0 and were
| > later incorporated into IPP/1.1.
| > This document is intended for registration following the
| > procedures of IPP/1.0 [RFC2566] and IPP/1.1 [ipp-mod]. This version
| > contains only the Set-Printer-Attributes and
| Set-Job-Attributes operations
| > which have been removed from the Set2 operation document.
| > There are 8 issues, most of which were raised at the IPP WG
| meeting in
| > December:
| > ISSUE 01 - Is there a better way to model the Printer
| attributes that
| > depend on the interpreter (that is still compatible with
| IPP/1.1)? It
| > should be clear to the operator whether the Set-Printer-Attributes
| > operation is affecting all interpreters or just the one
| specified by the
| > "document-format" operation attribute (or its default)?
| There have been
| > suggestions to have "xxx-exceptions" (collection) Printer
| > attributes where "xxx" is the document-format that indicate for each
| > interpreter explicitly which Printer attributes are
| specialized for it.
| > For example: "application-postscript-exceptions" (collection) and
| > "application-vnd-hp-pcl-exceptions (collection). Or have a
| > "set-all-interpreters" (boolean) Set-Printer-Attributes operation
| > attribute that sets all interpreters.
| > ISSUE 02 - Should the attribute names be modified (e.g.,
| with a unique
| > suffix) to identify them as "factory defaults"? At the IPP
| WG meeting,
| > some individuals thought that this would make some of the
| factory default
| > handling easier to specify/implement. Also, some of the
| attributes could
| > be prefixed/suffixed to indicate that they are [only] applicable to
| > specific document formats. Although preliminary discussion appears
| > encouraging, the topic was deferred for more detailed examination.
| > ISSUE 03 - While reviewing the Set-Printer-Attributes
| operation at the IPP
| > WG meeting, it was suggested that a more general mechanism should be
| > defined for handling and supporting side effects - such as modifying
| > values of any related attributes.
| > ISSUE 04 - How does a client indicate in a
| Set-Job-Attributes operation
| > that a Job attribute is to be removed from the Job object?
| At the IPP WG
| > meeting, there was general agreement that the protocol
| should support the
| > ability to "unset" values.
| > ISSUE 05 - There is no need to be able to remove a
| particular attribute
| > value from a (multi-valued) attribute, is there?
| > ISSUE 06 - Removing an attribute from a Printer is not
| needed, correct?
| > ISSUE 07 - Is it OK that Set-Job-Attributes validates
| independently from
| > how the "ipp-attribute-fidelity" operation attribute had
| been supplied in
| > the Job Creation operation? Its not currently stored with
| the Job object.
| > ISSUE 08 - For simplicity, is it OK that we don't have an
| > "ipp-attribute-fidelity" operation attribute for the
| > operation, so that the behavior is as if it were supplied
| with the 'true'
| > value?