Paul Moore proposed an alternative to the Resource Object proposal that Ira
McDonald and I presented as the last PWG-IPP meeting in September. The
counter proposal uses a '1setOf collection' attribute syntax for Printer
attributes instead of introducing Resource objects with sub-typing. I've
updated the counter proposal in discussions with Paul and have down-loaded
We'd liked to discuss it on the mailing list this week, at the IPP telecon
this Wednesday, and at the PWG-IPP meeting next Thursday, 12/7/00, in San
Diego. We'd like to compare it to the Resource Object proposal:
Here is the beginning of the counter proposal:
1 Introduction and Summary
Use '1setOf collection' attributes to describe fonts, media, paper
trays, downloaded JPEGs, ICC Color Profiles, macros, .... Some of these
resources can be down-loaded into the Printer, some can be installed by
means outside the IPP protocol, and some can be properties or
characteristics of the Printer as it comes from the vendor or is
configured by the administrator when the Printer is installed. Some of
these resources can have associated opaque binary data, such as font
data, while others consist solely of attributes.
These collection attributes are retrieved using the regular
GetPrinterAttributes operation, since they are ordinary collection
attribute with an attribute syntax of '1setOf collection'. More than one
can be asked for in a request. All of the members of all of the rows are
returned (as per the current collections spec). Note: according to the
collection spec the "xxx-supported" Job Template attributes usually have
the attribute syntax: '1setOf type2 keyword', rather than '1setOf
collection'. The keywords indicate which member attributes are
supported for the collection and the corresponding "xxx-supported"
indicate the values supported for each "xxx" member attribute. For such
Job Template attributes, a new naming convention is introduced: "xxx-
rows" for the Printer attributes with the attribute syntax of '1setOf
The "xxx-rows" (1setOf collection) attributes are never returned by Get-
Printer-Attributes unless they are explicitly asked for (i.e., they are
never included in groups or 'all', since there would be too much data in
the response). A single row can be queried using a new Get-Printer-
Collection operation described in the next section.
The following new operations are defined for use with '1setOf
- Get-Printer-Collection-Rows - return rows of a '1setOf collection
Printer attribute based on a simple filter supplied by the client
- Add-Printer-Collection-Row - add a row to a '1setOf collection'
- Delete-Printer-Collection-Row - delete a row of a '1setOf
collection' Printer attribute
- Modify-Printer-Collection-Row - modify a row of a '1setOf
collection' Printer attribute
- Get-Printer-Collection-Row-Data - same as Get-Printer-Collection-
Row, and in addition get the row's associated opaque data.
- Set-Printer-Collection-Row-Data - same as Set-Printer-Collection-
Row, and in addition set the row's associated opaque data.
For consistency all six operations have an Operation Attributes Group
and a Printer Attributes Group in each request and response. The
response always includes all of the member attributes of each row
returned. In addition to the usual request operation attributes for a
Printer operation, all six operations MUST include:
"collection-attribute" (type2 keyword) - which identifies the
collection attribute to be affected. For example:
"collection-attribute" = 'font-rows-supported' or "collection-
attribute" = 'tray-rows-supported'