Subject: IPP> Job Templates (Retry)

From: [email-masked]
Date: Tue, 17 Dec 1996 14:44:21 -0500

Classification:
Prologue:
Epilogue:

Keith, If I understand your comments correctly, I think that this is similar to
the approach that Steve Gebert has taken in his prototype, and similar to my
thoughts. I suggested that the job attributes returned by synthesised by the
Printer to include defaults and policy as well.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/17/96 12:37
PM ---------------------------

        ipp-owner @ pwg.org
        12/17/96 12:24 PM

To: ipp @ pwg.org@internet
cc:
Subject: IPP> Job Templates (Retry)

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

---

From: [email-masked] (Robert Herriot)
Date: Tue, 17 Dec 1996 18:18:41 -0800

If one of the formats returned is HTML form, you get what you want, a
collection of attributes, a default value, and many attributes with a list of
potential values. In the HTML form, the default value need not be the
first.

Bob Herriot

> From [email-masked] Tue Dec 17 11:24:21 1996
> From: [email-masked]
> Date: Tue, 17 Dec 96 12:22:40 CST
> To: [email-masked]
> Sender: [email-masked]
> Content-Length: 4690
> X-Lines: 115
> 
> IPP Team,
>