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:
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-000103.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-000103.docftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-000103-rev.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-000103-rev.doc
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, 1/12/2000. 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 corresponding
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 registration
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 Description
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 Set-Job-Attributes
operation, so that the behavior is as if it were supplied with the 'true'
value?