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:
>> 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
>> 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
>> 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
> 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
>> 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'