IPP> OPS - Set-Job-Attributes and Set-Printer-Attributes spec posted for 1/12/2000 telecon

IPP> OPS - Set-Job-Attributes and Set-Printer-Attributes spec posted for 1/12/2000 telecon

IPP> OPS - Set-Job-Attributes and Set-Printer-Attributes spec posted for 1/12/2000 telecon

Ron Bergman rbergma at hitachi-hkis.com
Mon Jan 10 20:19:36 EST 2000


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?

More information about the Ipp mailing list