<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff 
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV>Tom -</DIV>
<DIV>While the Resource object seems like a potentially useful discussion topic, 
I'm not sure that I see the relationship between several of the proposed 
sub-types and IPP.&nbsp; For example, how would a client use IPP to position an 
image stored in a library on the device correctly in a printed document?&nbsp; 
Aren't the PPML folks over at PODI working on a document schema based on XML to 
solve the general class of variable data printing problems?&nbsp; I know I would 
benefit from a more complete discussion of where you are headed with this, since 
at first glance it seems contrary to the principle of separating job submission, 
management, and monitoring protocol (IPP) from document content.</DIV>
<DIV>I guess my real question is "Are you trying to define a general purpose 
printer resource selection mechanism by extending IPP syntax?"&nbsp; If you are, 
I'd suggest that you also consider additional resources typically associated 
with color printers, such as ICC profiles, Color Rendering Dictionaries, and 
other by-products of print engine characterization, including (but not limited 
to) halftone screens (possibly implemented as threshold arrays) and grey balance 
transforms (possibly implemented as 1-D lookup tables).&nbsp; Such resources can 
be downloaded into a printer, selected from a pre-existing store in the printer, 
or even uploaded from the printer for use by a host based RIP (there is existing 
standard PDL syntax to accomplish the first two operations, but I don't know of 
any standard method for accomplishing the latter).</DIV>
<DIV>Eric Random<BR>Core Technology<BR>Peerless Systems<BR>(310) 
297-3251<BR>(310) 727-5715 - Fax<BR><A 
"Hastings, Tom N" &lt;hastings@cp10.es.xerox.com&gt; 05/09/00 11:16AM 
&gt;&gt;&gt;<BR>We have discussed several times on the IPP telecons about adding 
a new<BR>Resource object.&nbsp; This mail note is a sketch of the idea to see if 
there is<BR>support for developing an IPP spec along these lines.&nbsp; The 
reason to being<BR>this idea up now is because of the discussion of the Print 
Driver Extension.<BR>The Resource object approach would allow a way to install 
print drivers on<BR>the Printer and to Get Print Drivers from the Printer to 
install on a<BR>client.&nbsp; It would allow a Printer to have more than one 
print driver, say<BR>one for each of a number of different OS platforms and/or 
PDLs.<BR><BR>Should the Resource object be an agenda topic for the New York City 
IPP WG<BR>Meeting, 5/17-18?<BR><BR><BR>Here is the sketch of the Resource object 
idea and its operations:<BR><BR>The Resource object is a generic container 
object for a number of sub-typed<BR>objects.&nbsp; The Resource object would 
have a number of operations defined.<BR>Each operation would include an 
operation attribute that identifies the<BR>object sub-type in question.&nbsp; 
Then implementers could define new sub-types<BR>easily without having to invent 
new operations.<BR><BR>There are some attributes common to all sub-types, such 
as the<BR>"resource-name", "resource-sub-type", 
"resource-owner",<BR>"resource-creation-date-time", etc., and a lot that are 
specific to a<BR>particular sub-type.&nbsp; Some sub-types will also have opaque 
data associated<BR>with each object instance (such as fonts, forms, images, and 
print drivers),<BR>and others will only have attributes (such as 
media).<BR><BR>The initial list of sub-types include:<BR><BR>media - Just 
attributes which define the media characteristics.&nbsp; So the<BR>client can 
query the media library and the administrator can add new media<BR>and define 
their characteristics<BR>fonts - attributes and the PDL data<BR>forms - 
attributes and the PDL data<BR>logos - attributes and the PDL data<BR>images - 
attributes and the PDL data.&nbsp; high resolution images can be put<BR>into a 
shared image library and called out from a number of documents<BR>print drivers 
- attributes and the opaque data is the executable code<BR><BR>The operations 
would include:<BR><BR>Create-Resource - the client specifies the resource type 
and a user-friendly<BR>name for it that is used in all subsequent operations, 
including Job<BR>Submission operations (Print-Job, Create-Job, 
Send-Document).&nbsp; A lease time<BR>is also requested (just like our 
Subscription objects) and the Printer<BR>returns the lease time granted (which 
may be infinite meaning no need to<BR>renew or finite, meaning that the client 
must renew the lease, else the<BR>resource will be 
deleted).<BR><BR>Delete-Resource - delete the named resource of the indicated 
sub-type<BR><BR>Renew-Resource - renews the lease, in case it wasn't 
infinite<BR><BR>Get-Resource-Attributes - returns the requested (or all) 
attributes of a<BR>specified resource type and instance.<BR><BR>Get-Resources - 
returns the requested (or all) attributes of a specified<BR>resource type that 
matches the supplied filter criteria consisting of any of<BR>the resource 
attributes.&nbsp; Here the filtering is more complex than we have<BR>for 
Get-Jobs or Get-Subscriptions operations, since the client could filter<BR>on 
any of the resource attribute values.&nbsp; For example, a client 
could<BR>request all of the media that has a "media-size" equal to particular 
pair of<BR>x and y dimensions and get back the other resource attributes of any 
matched<BR>media instances.&nbsp; <BR><BR>Get-Resource-Data - returns the opaque 
data for those resources for which<BR>the data is not copyrighted, 
etc.<BR><BR>These operations are very similar to the Subscription object 
operations that<BR>the IPP WG has nearly approved for notification.&nbsp; The 
only differences are:<BR>Subscription Ids are assigned by the Printer as 
numbers, while resource<BR>object instances have user friendly names assigned by 
the creator.&nbsp; Both<BR>have leases, but Subscription leases are expected to 
be much shorter<BR>(minutes, hours) and handled by the software, not the user, 
while Resource<BR>objects leases are much longer (days, weeks, months), though 
both can be<BR>infinite depending on SA policy, and the user or administrator 
explicitly<BR>creates the Resources.&nbsp; Also Resources are known to users and 
administrators<BR>and are managed by them. Also Subscriptions don't have any 
complex filtering<BR>in the query requests.<BR><BR>[We don't want to merge 
Subscriptions into Resources, just illustrate their<BR>similarities]<BR><BR>It 
will also allow the administrator to set up policy on who can create<BR>which 
kinds of resources and for how