Tom,
I was very surprised to see a very large percentage of this document
devoted to the attributes "printer-message-from-operator" and
"job-message-from-operator". In fact, I had to check several times
to verify these were not new attributes. I think that this is extremely
confusing and significantly detracts from the remainder of the document.
A simple statement that these attributes are not settable using the new
operations would suffice.
Other comments: (line numbers from the version with revisions)
1. The paragraph starting on line 46 is not complete.
2. Section 6.5: I don't see much value in this attribute. It is better
that the message from the operator include this information.
3. Lines 442 to 445: This seems to be a bad example, since
the rules for IPP version support are very well defined. A
Set operation should not be needed in this case. Are two
examples needed here? The first example is more than enough.
4. Lines 473 to 477: A Printer object is not necessarily an
Interpreter object.
Ron Bergman
Hitachi Koki Imaging Solutions
"Hastings, Tom N" wrote:
> 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.pdf>ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-000103.doc>ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-000103-rev.pdf>ftp://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?