Bob Herriot
> From kcarter@VNET.IBM.COM Tue Dec 17 11:24:21 1996
> From: kcarter@VNET.IBM.COM
> Date: Tue, 17 Dec 96 12:22:40 CST
> To: ipp@pwg.org
> Subject: IPP> Job Templates (Retry)
> Sender: ipp-owner@pwg.org
> Content-Length: 4690
> X-Lines: 115
>
> 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
>