IPP Team,
I am having trouble sending notes to the ipp mailing list via my email
system so I'm resending the attached note on Job Templates to the ipp
mailing list just to be safe.
Keith
=========================================================================
Date: 16 December 1996, 12:47:45 CST
From: kcarter at vnet.ibm.com
To: ipp at pwg.org
cc: kcarter at vnet.ibm.com
Subject: Job Templates
IPP Team,
In my opinion, Job Template objects should not be supported in IPP 1.0
because doing so increases the complexity of the IPP print model
and solution. Instead, IPP should allow an application to query a
Printer Object for attributes/values used to submit a print job (called
"Job Submission Attributes" in this note). An application can then
present each attribute, its default value and its supported values to
the end-user who can either accept or modify the default value for
each attribute when submitting a print job. Furthermore, since an
administrator can assign multiple Printer Objects to an output device,
the administrator can setup different default Job Submission Attributes
for different users or groups of users who use the same output device.
Issues with Job Templates
-------------------------
Several issues with Job Templates have been identified in document
ftp://ftp.pwg.org/pub/pwg/ipp/contributions-for-discussion/
job-template-issues.pdf. Here is my view of the major issues with
Job Templates (in no particular order):
1. Support for unique Job Template objects per Printer Object
implies storage and management of these objects. For
example, an IPP implementation must determine how to create,
manage and control access to Job Templates across users.
IPP becomes further complicated if a Job Template object can
be used across multiple Printer Objects. For example, Printer
Objects must reference their Job Templates and, if a Job
Template is deleted, all Printer Objects that use that Job
Template must be updated to not use that Job Template.
2. If an administrator changes the output device(s) (and potentially
printer driver) assigned to a Printer Object which is a print
queue, then all Job Templates assigned to the Printer Object
might now be invalid because of the physical attributes of the
new output device(s).
3. It is not clear to me how user friendly Job Templates will be to
end-users. The customers I deal with view the Printer Object,
complete with Job Submission Attributes, as their target for
print operations. A Job Template URL as a target for printing
does not seem as straightforward to me and implies that these
URLs must now be entries in a directory so users can locate these
Job Template URLs for printing.
4. Since a Printer Object may be a physical output device, how do
these devices handle Job Templates?
Proposed Job Submission Attributes
----------------------------------
Job Submission Attributes include:
- Job Sheet Attributes (6.2.4)
- Notification Attributes (6.2.5)
- Job Scheduling Attributes (except job-print-after) (6.2.6)
- Job Production Attributes (except page-select) (6.2.7) plus:
* content-orientation (6.2.8.14)
* color (y/n for color printers)
* collate (y/n)
- Attributes for Conversion of Text and HTML Files (6.2.8)
Get-Attributes Request for Job Submission Attributes
----------------------------------------------------
The following method might be used for an application to obtain
the Job Submission Attributes from a Printer Object:
Selector Printer URL
Requested Attributes job-submission:
This approach allows an application to obtain the Job Submission
Attributes without having to specify each attribute in the request
thereby reducing the size of the request and providing a mechanism
to return additional attributes in the future if the list of Job
Submission Attributes changes.
Get-Attributes Response for Job Submission Attributes
-----------------------------------------------------
Attr-Name ":" Attri-value CR LF
Attri-value = 1#Value where the first value is the default value for the
attribute in the Printer Object and any following values in the list are
valid selections for the Printer Object.
This approach allows an application to obtain the list of Job Submission
Attributes plus the default value and valid values for each attribute in a
single request to minimize network overhead. The application can then
present a user interface to show the end-user the valid attributes, the
default value for each attribute and, if an end-user chooses, the valid
values for each attribute.
Your thoughts?
Have a super day!
Keith