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

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

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

harryl at us.ibm.com harryl at us.ibm.com
Wed Jan 12 11:23:42 EST 2000




>Are these factory-settings somehow inherently kept in the printer's
>implementation?  Does IPP specify how are they stored?

Typically, factory setting are stored in NVRAM or ROM. They represent a
fail safe means of re-establishing a baseline of device operation.

>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.

I don't necessarily agree, since factory settings are not volatile. Also,
"factory-settings" would be the actual initial values, not necessarily a
list of all the features as your comment (above) seems to indicate.

Harry Lewis
IBM Printing Systems




"Shepherd, Michael" <MShepherd at crt.xerox.com>
Sent by: owner-ipp at pwg.org
01/11/00 08:07 AM


        To:     "Hastings, Tom N" <hastings at cp10.es.xerox.com>, ipp
<ipp at pwg.org>
        cc:
        Subject:        RE: IPP> RESEND: OPS - Set-Job-Attributes and
Set-Printer-Attribu tes spec
posted for 1/12/2000 telecon

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?
| >
| >
| >
|






More information about the Ipp mailing list