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

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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Jan 10 17:35:31 EST 2000


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-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.pd
> f
> ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set-operations-000103-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