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.
SAI> The goal for IPP is to have a single protocol in, not various protocols
SAI> defined and identitifed as "interface URLs" The Printer MIB
SAI> channel type arguments ought to remind us of that mess
>
> 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.
SAI> It is just not within scope to solve the operator and administrator
SAI> problems with IPP. This has been discussed and I feel has
SAI> reached consensus. EVERYONE realizes a need for this function
SAI> ality, but we do not need to standardize on this. This is Internet
SAI> Printing, not Intranet Printing. End users want to print to URLs
SAI> which can't be done today. Operators can manages printers and
SAI> printing subsystems within their systems today. So let's solve the
SAI> problem that has not been solved. If IPP is wildly successful, then
SAI> we can add other operator and administrator features later.
Scott