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

From: Scott Isaacson <[email-masked]>
Date: Fri, 07 Mar 1997 10:53:49 -0700

My comments are preceded by a SAI>

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