I like your clarification of how defaulting happens (when a Printer
accepts a job in the Print request).
In answer to your question as to what happens if the Administrator
changes the Printer defaults after a job has been accepted (and defaulted):
There is no effect on the jobs that have already been accepted (and defaulted).
Only future jobs are affected with the new defaults. This is the simplest
to implement and for the end-user to understand. If the user queries his/her
job after it has been accepted and sees a value (that was defaulted), that
value will be the one that is used, even if the Administrator
subsequently changes the Printer's defaults.
Tom
At 09:09 03/20/97 PST, Scott Isaacson wrote:
>A simple way to solve this issue is to do the following:
>>1. The Print Request comes in to the Printer
>2. The Printer "creates" the Job objecting using:
> - Job template attributes in the print request
> - Defaults for attributes that are not in the print request
>3. Once a Job object is created, it has a FULL set of attributes
>4. When a Get Attributes is made, all attributes come back
>and there is NO info about which attributes were actually set
>in the Print Request and which attributes were defaulted by the
>printer
>>One issue that arrises is: What if a job is pending and while it is
>pending the admin changes the defaults for the Job? Does the
>end user want the defualts in place when the job was submitted
>or the defaults when it actually goes from pending to processing?
>The above rules (scenarios) says that the end user gets the defaults
>in place at submission time. That is GREAT for now. We plan
>to add modify at some later time
>>Scott
>>>>>> JK Martin <jkm at underscore.com> 03/20/97 03:11am >>>
>Tom,
>>I'm confused about Issues #79 and #81 in your document. If you are
>proposing the inclusion of the "fan-in" concept in the IPP model,
>then isn't the Printer *required* to add default attributes to the job?
>> ...jay
>>>