Ron,
Lets cover your issues at the telecon today. See my comments.
Tom
-----Original Message-----
From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
Sent: Monday, January 10, 2000 17:20
To: Hastings, Tom N
Cc: ipp
Subject: Re: IPP> OPS - Set-Job-Attributes and Set-Printer-Attributes
spec posted for 1/12/2000 telecon
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.
TH> I agree that it is too bad that the Set operations don't start until
page 13 of a 24 page spec. However, what is new about
"printer-message-from-operator" and
"job-message-from-operator" is having them as operation attributes in all
the operator operations, including IPP/1.1 operations. We could move them
and the associated "printer-message-time", "printer-message-date-time", and
"printer-message-operation" (if it stays) to a separate specification and
just have the simple sentence that you suggest about IPP/1.1
"printer-message-from-operator" and
"job-message-from-operator" Printer and Job Description attributes.
Other comments: (line numbers from the version with revisions)
1. The paragraph starting on line 46 is not complete.
TH> The sentence should be something like:
This document contains only the Set-Printer-Attributes and
Set-Job-Attributes operations which have been removed from the Set2
operation document [ipp-set2].
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.
TH> ISSUE: Should we remove the "printer-message-operation" which records
the operation id that set the "printer-message-from-operator":
6.5 printer-message-operation (type2 enum)
This READ-ONLY Printer Description attribute identifies the operation that
was used to change the Printer's "printer-message-from-operator" by the
operator using any operation where the client supplied the
"printer-message-from-operator" operation attribute (see section 5.1) or
explicitly set using the Set-Printer-Attributes operation (see section 9.1).
This attribute allows the users to know which operation was used to change
the "printer-message-from-operator" attribute when it was last set.
The standard enum values are those defined for the "operations-supported"
Printer Description attribute (see [ipp-mod] section 4.4.15).
Note: This attribute helps users better understand the context for the
"printer-message-from-operator".
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.
TH> The example is:
As another example, if the "ipp-versions-supported" Printer Description
attribute (see [ipp-mod] section 4.4.14) is settable in a particular
implementation, then changing its value with a Set-Printer-Attributes
operation MUST affect the protocol versions that are accepted or rejected.
Such an implementation will need to be able to reject values for versions
that it contains no code support for.
ISSUE: Should we remove it? Is it incorrect?
4. Lines 473 to 477: A Printer object is not necessarily an
Interpreter object.
TH> Agreed. So we need to clarify. Here is the text:
Thus the target of a Get-Printer- Attributes or Set-Printer-Attributes
operation is both the Printer object and the Interpreter object identified
by the "document-format" operation attribute supplied by the client. Except
for Get-Printer-Attributes and Set-Printer-Attributes, there are no other
operations with the Interpreter object as a target. See [ipp-mod] section
3.2.5.1 "Get-Printer-Attributes Request".
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?