IPP> RES - Updated Resource object spec down-loaded

IPP> RES - Updated Resource object spec down-loaded

IPP> RES - Updated Resource object spec down-loaded

Hastings, Tom N hastings at cp10.es.xerox.com
Thu Sep 7 14:14:19 EDT 2000

Ira and I have updated the Resource objects paper from the last meeting for
consideration at the Chicago meeting.

The Resource object is a passive object that has defined types: 'font',
'form', 'image', 'logo', and 'media'.  Some of these object types are just
attributes, such as 'media', and some include attributes and data, such as
'font' and 'image'.  Additional resource types could be defined for such
things as ICC Color Profiles, Imposition Templates, etc.

This spec does NOT contain any resource type specific attributes.  They will
be defined in separate documents, analogous to the way we've done with the
Notification spec and the Notification Delivery Method documents.

We've removed the driver download as one of the resource types, since the
IPP WG agreed at the July meeting to go with Hugo's proposal that is
specific to drivers.

We've tried to build on the models of the Job and Subscription objects and
their operations.

This spec has REQUIRED operations: Get-Resource-Attributes,
Get-Resource-Data, and Get-Resources.

We've also added a second OPTIONAL package of administrative operations:
Create-Resource, Renew-Resource, Refresh-Resource, and Delete-Resource.

The documents are available at:


Here is the Abstract:

   This document is a submission to the Internet Printing Protocol
   Working Group of the Internet Engineering Task Force (IETF).  The
   open issues in this document each begin 'ISSUE_n:'.  Comments should
   be submitted to the ipp at pwg.org mailing list.  
   This IPP Resource Objects document specifies an extension to IPP/1.0 
   [RFC-2565] [RFC-2566] and IPP/1.1 [IPP-MOD] [IPP-PRO].  This document
   extends the current IPP object model with a passive polymorphic
   object type - Resource - to support the long-term evolution of IPP.  
   This document defines:  
   - Resource object (passive polymorphic object); 
   - Resource query operations (e.g., Get-Resource-Attributes); 
   - Resource admin operations (e.g., Create-Resource); 
   - Resource template attributes (e.g., "resource-charset"); 
   - Resource description attributes (e.g., "resource-name"); and 
   - new Printer attributes (e.g., "resource-type-supported").  

There are a number of issues:

     ISSUE_1:  The target of all IPP Resource operations is always
     simply "printer-uri" and separate required operation attributes are
     used to specify resource type and name or ID.  This is like IPP
     Subscription objects but unlike the earlier IPP Job objects.
     Should we continue to follow the IPP Subscription object model?  

     ISSUE_2:  What mechanism should we use for filters, multiple Resource 
     Attribute Groups, collection, some subset of LDPA filters, other?  

   ISSUE_3:  Should we require that Resource object instances are always
   returned sorted by "resource-id" (as stated above) and not by
   "resource-name" (more user-friendly).  Should we add an operation
   attribute to control the choice of sort order?  

     ISSUE_4:  Should we make Resources more like Subscriptions (and Jobs)
     and just drop the "requested-attributes" from all of the Resource
     admin operations?  Then "requested-attributes" would only be
     permitted in the Resource query operations.  

   ISSUE_5:  This 'lazy refresh' behavior may have performance and
   'stale data' consequences for IPP Clients.  Because the manufacturer
   may also be slow to inform installed IPP Printers of a new version of
   a Resource (for update by means outside of this specification) the
   'stale data' problem may also apply to IPP Printers.  Should we add
   an operation attribute to PREVENT this 'lazy refresh' behavior?  

More information about the Ipp mailing list