It actually seems simpler to me to "dynamically" bind to defaults. Otherwise it
seems that I
have to "fill-in" the blanks for every job when I spool it. Dynmaically
binding allows me to
not touch the job attributes when the job is spooled but "fill in" the blanks
when the job
actually starts to print. This would seem to be an implementation choice.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 03/21/97 10:06
AM ---------------------------
jkm @ uscore.underscore.com
03/21/97 09:23 AM
To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org@internet
Subject: Re: IPP> MOD - I've posted some issues: isstnh03.doc .pdf-Re
Roger,
Are you suggesting that you'd like to see vendors have the ability
to implement *dynamic* binding of default job attributes rather than
the suggested *static* binding approach?
If this is what you are suggesting, what is the motivation?
...jay
----- Begin Included Message -----
From: Roger K Debry <rdebry@us.ibm.com>
To: <ipp@pwg.org>
Subject: Re: IPP> MOD - I've posted some issues: isstnh03.doc .pdf-Re
Date: Fri, 21 Mar 1997 09:58:18 -0500
Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry@us.ibm.com
phone: 1-303-924-4080
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.
RKD> Could this be implementation defined?
----- End Included Message -----