I am personally not in favor of this alternative.
I not even altogether happy with the original proposal, so I would like to
suggest yet another alternative that I brought up in IPP phone conference on
Wednesday this week.
I think it would be architecturally more clean and consistent with our
overall printing model to create new objects for each of the major resources
that we want to consider, e.g. one for fonts, another one for media etc. and
have separate operations for each major type of resource. This brings three
advantages over the other proposals:
1) Separate objects and operations allows for better access control
filtering in application level firewalls and gateways.
2) It allows you to use relevant syntax for each type of resource rather
than have to try to come up more generic syntax which is neutral enough to
cover a number of different resource types.
3) It is easier to find out which features are indeed supported by a printer
by looking at the list of supported operations.
The visual functionality would be the same as in the other two proposals.
Manager, Print Services
Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Wednesday, November 29, 2000 12:40 AM
To: ipp (E-mail)
Subject: IPP> RES - Summary of original Resource object with sub-typing
for com parison
I've down-loaded an 8-page summary of the original Resource object proposal
written at the same level as the 8-page counter proposal (that uses '1setOf
collection' Printer attributes, instead of Resource objects). The Resource
object summary is available at:
The -rev version shows the changes to the Counter proposal to make the
original Resource object proposal. This allows readers to compare the two
proposals directly. The two approaches are quite similar. The Resource
object proposal copies the pattern of operations for the IPP/1.1 operations
on Job objects and the recent Notification operations on Subscription
objects. The '1setOf collection' Printer attribute proposal extends the
Get-Printer-Attributes operation for (filtered) query of '1setOf collection'
rows and adds new operations for operating on rows. Here is a high level
comparison of the operations for the Resource object and the :
Resource object proposal '1setOf collection' Printer Attribute
Get multiple resource instances using a simple filter:
Get-Resources Get-Printer-Attribute with:
"resource-type" "collection-attribute" operation
any resource attribute in any column attribute in
Resource Attributes Group (new) Printer Attributes Group
All the following operations specify which (single) Resource instance with
the following input attributes:
"resource-type" "collection-attribute" operation
"xxx-name" or "xxx-id" Key Attribute in (new) Printer Attributes
Renew-Resource requires a resource-specific operation,
e.g., Renew-Image operation with a lease
Here is the Summary of the Original Resource object proposal:
Use a polymorphic generic Resource object type with sub-typing 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 Resource object attributes are retrieved using the (new)
Get-Resource-Attributes and Get-Resources operations which are modeled on
the IPP/1.1 Get-Job-Attributes and Get-Jobs operations and the
Get-Subscription-Attributes and Get-Subscriptions operations. Resource
objects that can be loaded are defined to have Resource Template attributes
(just like Job and Subscription objects), so that there are "xxx" Resource
attributes and "xxx-supported" Printer attributes.
The following new operations are defined for use with Resource objects:
* Get-Resource-Attributes - returns the requested attributes
of the identified Resource object instance.
* Get-Resources - return the requested attributes of the
Resource object instances based on a simple filter supplied by the client
* Create-Resource - add a Resource object instance to a
* Delete-Resource - delete a Resource object instance from the
* (new) Set-Resource-Attributes - modify a Resource object
instance of a Printer
* Get-Resource-Data - same as Get-Resource-Attributes, and in
addition get the object instance's associated opaque data.
* Create-Resource - same operation sets the object instance's
associated opaque data.
* Renew-Resource - update the lease time for the Resource
object instance for those Resource types that have leases.
For consistency all seven operations have an Operation Attributes Group and
a Resource Attributes Group in each request and response. The response
always includes the requested Resource object attributes. In addition to
the usual request operation attributes for a Printer operation, all six
operations MUST include:
"resource-type" (type2 keyword) - which indicates the type
of Resource, e.g., 'media', 'font', 'image', 'input-tray', 'output-bin',
Either "resource-name" (name(127)) or "resource-id"
(integer(1:MAX)) - identifies the resource object instance. The Printer
MUST support both.