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

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

Patrick Powell (papowell@dickory.sdsu.edu)
Wed, 5 Mar 1997 17:20:31 -0800 (PST)

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@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