IPP> REQ - Comments/issues on Feb 17 (01a) Requirements document

IPP> REQ - Comments/issues on Feb 17 (01a) Requirements document

IPP> REQ - Comments/issues on Feb 17 (01a) Requirements document

Patrick Powell papowell at dickory.sdsu.edu
Wed Mar 5 20:20:31 EST 1997


Prof. Patrick Powell
Dept. Electrical and Computer Engineering,
San Diego State University,
San Diego, CA 92182-1309
Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577
email: papowell at sdsu.edu


On Wed, 5 Mar 1997, Tom Hastings wrote:


> Here are my comments on the Requirements document (in addition to changing
> the "WEB Browser-based" terminology).  Issues are labeled ISSUE n:
> 
> 
> 12. ISSUE 04 - Page 11, 3. IPP Scenarios, three physical configurations:
> Problem:  Has fan-out, but needs to add fan-in without adding any additional
> complexity to V1.0.  Fan-in is useful for giving different personalities
> (i.e., different defaults and different capabilites to the same output
> device, especially now that many Printer have multiple interpreters in them).
> Also fan-in allows the Administrator to specify different access control to
> different capabilities of a single output device.  To the end-user
> and to the IPP V1.0 protocol, such fan-in will be transparent and behave
> just as if each accessible Printer controlled a separate output device.
> The user might happen to notice that quering jobs on several fan-in Printers
> may show the same jobs and that the state of the fan-in Printers seems
> to change in lock-step, but that is the only end-user observable consequence
> of supporting fan-in of Printer objects to a single output device
> (or a set of fan-out output devices).
> 


I would like to note that this comment appears to be in line with my 
revised model of the Printer.  By having 'Interface URLs' corresponding 
to the various protocols for connecting to the printer,  you can have the 
fan-in capability Mr. Hastings has outlined.  Also, the queue and active 
job handler will also fit in well with this model.


> 
> 18. Page 15, 3.5 Asynchronous Nofication
> Clarify whether this is notification to an end-user (V1.0) of printer problems
> with his/her job and problems with the Printer for which his/her job is 
> pending versus (V2.0) and operator that wants notification independent of 
> whether he/she has a job submitted or not.


I have thought about the problem of asynchronous notification,   and in my
outlined changes introduced a 'Administrator' object.  This will be the 
object that is in charge of and generating notification.  Note that now 
it will have attributes, etc. that can be examined and requested.


Patrick Powell



More information about the Ipp mailing list