Classification:
Prologue:
Epilogue:
I'd like to see this proposal discussed at the PWG meeting in January -- it
would be nice if we could agree on this simplification for IPP/1.0.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/19/96 07:07
AM ---------------------------
ipp-owner @ pwg.org
12/17/96 06:20 PM
To: kcarter @ vnet.ibm.com at internet, Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org at internet
Subject: Re: IPP> Job Templates (Retry) [I like getting rid of Job Te
Keith and Roger,
I agree with the idea of getting rid of job templates for IPP V1.0.
Let me paraphrase Keith's proposal that build on Roger's:
Each URL in the Print operation specifies a Printer object.
Each URL in the Get-Attributes operation specifies either a job object
or a Printer object (but no longer a Job Template object).
I also agree with the idea of allowing more than one Printer object to
represent a single output device. When more than one Printer object
represents a single output device (or represents another Printer),
its called "fan-in". With fan-in, Printer can have different policies
specified by different sets of xxx-supported attribute values and
max-xxx-supported attribute values. The SA can set up an ACL for each
Printer that specifies which users can have access to which Printer
objects that fan-in to the same output device. So the SA can establish
separate policies for different sets of users. Some users can use the
expensive color option of the output device and others can only use the
black-and-white option.
I also like the idea of using the GetAttributes operation with a "special"
value of the requested-attributes input parameter of "job-submission" to
indicate that the requester wants all of the xxx-supported printer attributes,
but none of the other printer attributes, such as printer-name,
printer-location, etc., unless the requester also includes those attributes
in the requested-attributes input parameter to the GetAttributes operation.
Then an implementation can add additional xxx-supported attributes and the
requester automatically gets the new ones. I'd suggest changing the name of
this "pseudo" attribute from "job-submission" to "job-submission-attributes".
Finally, I like the idea of using the first value returned of each
xxx-supported attribute to mean the default value. Then the requester
can get the defaults and all supported values specified by the SA as the
policy for that Printer in one request as you point out.
NOTE: we must then specify that the *order) of attribute values is
significant in IPP.
(ISO DPA and other attribute standards specify that the order of attribute
values shall not be significant. If we want to be compatible with not making
attribute values significant, we could just as another ":default" adornment in
our State syntax, so that ":default" would be tacked onto the end of the
default value. We need to check with MIME syntax to see if we can use
the simpler idea that order matters so that we can specify that the first
value of an xxx-supported attribute is the default. In addition to being
more compact, specifying that the first attribute is the default, means
that there cannot be the error condition of no ":default" or more than
one ":default" value returned.).
If the SA policy is that there is only one value, then that value is both
the default value and the only supported value. If the Printer policy is
to support several values, then the first is the default and the remaining
are additional supported values. Then the requester can determine the
defaults without IPP having to expose the Job Template. (And implemetations
can implement defaults internally without having to have Job Templates,
if they don't want to, or they can have Job Templates internally, like ISO
DPA initial-value-job and initial-value-document objects).
Looks like a real good simplification for IPP V1.0!
Please check to see if my understanding of your proposal is the same as yours.
Thanks,
Tom
At 11:44 12/17/96 PST, rdebry at us.ibm.com wrote:
>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 at 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
>>>