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:
ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/draft-ietf-ipp-get-resource-01-000901.
doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/draft-ietf-ipp-get-resource-01-000901.
pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/draft-ietf-ipp-get-resource-01.txt
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@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?
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 14:23:24 EDT