Tom,
These are my comments regarding the Set operations. If you'd like to
discuss, please call me at home this afternoon (315-524-3013).
Line 201 & 251: "factory-settings" - I like that this operation attribute is
applicable to only Get-Printer-Attributes. Is it ok that the user is
restricted to getting either the factory settings or the regular IPP
attributes, but not both, in the same operation? Are these factory-settings
somehow inherently kept in the printer's implementation? Does IPP specify
how are they stored? Should the factory-settings be READ-ONLY IPP
attributes?
Line 216: Typo - second "printer-message-time" should be
"printer-message-date-time"
Line 252: "factory-settings" continued: This operation attribute is
OPTIONALLY supported by the printer, but I maintain that there MUST be a way
for at least an administrator to get the factory settings - if for nothing
more than for providing an Admin Tool with a list of available options to
display. If a printer loses the ability to advertise a certain feature,
loses that feature all together.
Line 320: I agree with Ron. I don't see the value of this attribute.
Wouldn't knowing 'who', not 'how', created the printer message be more
interesting? "printer-message-info" could have a Name + phone number for
instance.
Line 353: How does an administrator set up his own attribute value
conflicts? For instance, a printer implementation may allow duplexed
transparencies, but the admin wants to reject this type of job.
Issue 04 comment: Can we use out-of-band "no-value"?
Issue 05 comment: This would be nice though. Just set the attribute to be
the new list of values sans the undesired value. If "finishings-supported"
is set to "staple" and "bind", to remove "staple" you would do a
Set-Printer-Attributes with just "bind". Also specify in the spec how you
add a value to a multi-valued attribute...if you want to set "trim", do you
just do a Set-Printer-Attributes with "trim", or do you have to include all
currently set values in the operation ("staple", "bind", "trim")?
Issue 07 comment: Seems ok to me
Issue 08 comment: This may be useful. "true" could mean 'set all or fail',
"false" could mean 'set what you can'
Lines 576-577: What if the job submitter incorrectly specified these
attribute in the job creation? Must he cancel and resubmit the job? What's
the reason why these aren't settable?
Thanks,
Mike
| -----Original Message-----
| From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
| Sent: Monday, January 10, 2000 5:36 PM
| To: ipp
| Subject: IPP> RESEND: OPS - Set-Job-Attributes and
| Set-Printer-Attributes spec posted for 1/12/2000 telecon
| Importance: High
||| Some people did not receive this mail message, so I'm sending
| it again.
|| Tom
|| > -----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:
| >
| >
|ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-0| 00103.pdf
| >
|ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-0| 00103.doc
| >
|ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-0| 00103-rev.pd
| > f
| >
|ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-0| 00103-rev.do
| > c
| >
| > 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?
| >
| >
| >
|