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

From: Roger K Debry <[email-masked]>
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: [email-masked]
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?

---

From: JK Martin <[email-masked]>
Date: Fri, 21 Mar 1997 11:14:59 -0500 (EST)

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 [email-masked] Fri Mar 21 10:03 EST 1997
From: Roger K Debry <[email-masked]>
To: <[email-masked]>
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

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

---

From: Roger K Debry <[email-masked]>
Date: Fri, 21 Mar 1997 12:13:16 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

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,

 ...jay

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

Classification:
Prologue:
Epilogue: Roger K deBry

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

---

From: [email-masked] (Robert Herriot)
Date: Fri, 21 Mar 1997 18:45:20 -0800

Another problem with dynamic binding is that an end-user cannot see
what is fixed (by the client) and what is floating (with respect to
printer defaults).  I don't want to suggest another adornment to tell
the user which is which. In addition,if the client forwards the job to
another printer, then the dynamic attributes will potentially change.

Bob Herriot

> From [email-masked] Fri Mar 21 09:24:58 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
> 
> 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.
>