At the IPP telecon today we reached the following agreements on the "Job and
Printer Set Attributes" specification, dated January 21, 2000.
Please send any comments on these agreements to the IPP DL.
1. Set-Job-Attributes operation (section 4, 2nd paragraph)
We agreed to add some statement that the preferred method for a client to
use to indicate the target job is using the "printer-uri" (uri) and "job-id"
(integer(1:MAX)), as opposed to the "job-uri" (uri). This is because the
"ipp" scheme in URIs will be associated in user's minds with Printers, not
Jobs. Also mapping the "job-uri" to other protocols is more difficult than
the "job-id", since the former is a URI and the latter is a 32-bit integer.
Such a statement should also be added to the Implementer's Guide for all Job
operations.
2. Set-Printer-Attributes operation:
ISSUE 01 - MUST the client supply "document-format" operation attribute when
supplying "document-format-varying-scope" with a 'single-document-format'
value? If yes, then this paragraph goes away.
We agreed to simplify Set-Printer-Attributes further:
a. We eliminated the "document-format-varying-scope" operation attribute.
b. If the client supplies the "document-format" operation attribute in the
Set-Printer-Attributes operation, then the settings apply only to that
document format. If the client omits the "document-format" attribute, then
the settings apply to all document formats.
We also agreed that the client MUST NOT supply a "document-format" =
'application/octet-stream', since that document format is really the dynamic
union of the document formats that the implementation is able to auto detect
as specified in [ipp-mod] Get-Printer-Attributes definition.
3. Get-Reset-Printer-Attributes (section 4.3) renamed to
Get-Printer-Supported-Values
ISSUE 02: There could be a separate operation Get-Allowed-Printer-Attributes
for determining allowed values. This operation would return the same value
as Get-Reset-Printer-Attributes for "xxx-supported", but would return
allowed values rather than the Reset value for other attributes. We have
not yet seen a need for such an operation because the spec provides rules
for inferring the allowed values except for "xxx-supported" values.
We agreed to reduce the scope of this operation so that it only deals with
"xxx-supported" attributes. It does not deal with resetting any attributes.
What is reset will be dealt with in the Administrative Set2 operations as a
companion to the Reset-Printer operation.
The new name of the operation will be Get-Printer-Supported-Values. It has
the same operation attributes and attribute groups as
Get-Printer-Attributes, but only returns "xxx-supported" attributes. If a
client requests any other attribute it will be returned as an unsupported
attribute.
The "printer-settable-attributes" and "job-settable-attributes" attributes
are renamed to add the "-supported" suffix, so that they are returned with
this operation.
The "printer-settable-attributes-supported" attribute MAY have itself in the
list if the implementation supports this attribute being itself settable,
i.e., so that the administrator can remove some of the values in order to
make some settable attributes become read-only. We probably need to add a
Note to this effect, just in case an implementation wants to allow this.
4. The 'any-value' out of band value (section 8.2)
ISSUE 03: Should the 'any-name' value be a keyword with special behavior or
a new type of value, such as an out-of-band value? This document has been
written as an out-of-band value.
We changed this token to be a new attribute syntax, called 'ipp-syntax',
instead of being either a keyword or an out of band value. The 'ipp-syntax'
attribute syntax will have two fields:
a. an IPP attribute syntax, such as integer, keyword, name, boolean
b. boolean indicating whether the attribute can be multi-valued or not.
This new attribute syntax will be used in returning "xxx-supported" values
by the Get-Attribute-Supported-Values operation in order to indicate what
values an administrator can set with the Set-Printer-Attributes operation.
For example, this new attribute syntax will be able to indicate that an
"xxx-supported" attribute can be set with any name or any boolean values.
The definition of the Get-Printer-Supported-Values will indicate that the
attribute syntax returned for each "xxx-supported" attribute has the
following fixed transformation from the attribute syntax returned by the
Get-Printer-Attributes operation:
Get-Printer-Attributes Get-Printer-Supported-Attributes
'boolean' 'ipp-syntax' (boolean, single-valued)
'integer' 'rangeOfInteger'
'name' 'ipp-syntax' (name, multi-valued)
...
These additions will make it possible for an implementation to indicate what
values an administrator can set for such attributes as:
"job-priorities-supported" (rangeOfInteger(1:100))
"job-hold-until" (1setOf (type3 keyword | name(MAX))
"copies-supported" (rangeOfInteger(1:MAX))
"finishings-supported" (1setOf (keyword | name(MAX))
"page-ranges-supported" (boolean)
"number-up-supported" (1setOf integer(1:MAX) | rangeOfInteger(1:MAX))
"media-supported" (1setOf (type3 keyword | name(MAX)))
"color-supported" (boolean)
"job-k-octets-supported" (rangeOfInteger(0:MAX))
"job-impressions-supported" (rangeOfInteger(0:MAX))
"job-media-sheets-supported" (rangeOfInteger(0:MAX))
Bob and I will update the spec and send out this week or early next week for
the New Orleans IPP meeting, 2/9/00 and 2/10/00 IPP WG meeting.
Tom