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

Shepherd, Michael MShepherd at crt.xerox.com
Tue Jan 11 10:07:58 EST 2000


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