IPP> MOD - I've posted some issues: isstnh03.doc .pdf-Re

IPP> MOD - I've posted some issues: isstnh03.doc .pdf-Re

IPP> MOD - I've posted some issues: isstnh03.doc .pdf-Re

JK Martin jkm at underscore.com
Fri Mar 21 12:24:26 EST 1997


Roger,


You might view it as "an implementation choice"...but what about the
poor user?


Specifically, if the system administrator changes the job defaults
between the time the job is submitted and the time the job starts being
processed for printing (ie, when you would do dynamic binding), then
the job may very well not be processed the way the user expected.


Recall that the user can list the target printer's default attributes
prior to submission, and then submit the job, believing that the
defaults are acceptable.


How would you guard against (ie, protect the user from) this situation?


	...jay


----- Begin Included Message -----


From: Roger K Debry <rdebry at us.ibm.com>
To: <ipp at pwg.org>
Subject: Re: IPP> MOD - I've posted some issues: isstnh03.doc .pdf-Re
Date: Fri, 21 Mar 1997 12:13:16 -0500


Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080


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 at 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 ipp-owner at pwg.org Fri Mar 21 10:03 EST 1997
From: Roger K Debry <rdebry at us.ibm.com>
To: <ipp at 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 at 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 -----








----- End Included Message -----



More information about the Ipp mailing list