R.
At 11:18 PM 4/27/98 -0400, don@lexmark.com wrote:
>
>Here's where I agree:
>
>IEEE Std 1284.1 uses the same concept to allow access to MIB objects. We
>including then entire OID string which allow access to any MIB including
>private extensionsm MIB 2, etc. This has worked out very well allowing
>using common code in the printer and presenting a single, unified
>presentation of printer status and configuration without having to worry
>about reconcilling two different name spaces. Additionally since the OID
>decoding code is already in the printer, the implementation was easy and
>small -- no need to carry lots of string constants around for comparisons.
>
>Here's where I disagree:
>
>Microsoft and many others need a single protocol to submit jobs and to
>manage printers from a server, no matter how the printer is connected:
>
>- Parallel
>- Serial
>- 1394
>- IPX/SPX
>- TCP/IP
>- AppleTalk
>
>So how do we reconcile the need to submit jobs and manage the printers
>using one protocol and what Scott Isaacson said:
>
>SAI> I see SNMP being used to MANAGE the printer. I do not see using IPP
>SAI> to MANAGE the printer. I see IPP as being a protocol that an end user
>SAI> uses (or an application on behalf of an end user) to query the printer
>SAI> for characteristics and capabilities that help in requesting options
>or
>SAI> or formatting the job and then submitting the job and tracking and
>SAI> simple management of that job (just query and cancel).
>
>If everyone agrees that IPP should NOT be used to manage the printer, then
>we cannot meet the requirement stated above using IPP. That's why we
>called it SDP (Server to Device Protocol) -- it's got to be fully usable
>(read and write) so the server can fully understand and control the state
>of the printer.
>
>This really isn't hard. If we are going to meet the requirements then we
>have to either:
>
>1) Extend IPP to allow job submission and full management
> and control
>2) Document the straightforward mapping of IPP to IEEE Std 1284.1
> which already provides the management and controls features
> needed
>3) Create something new.
I would add two other possible options...others on the DL are welcome to
chime in with their own options.
4) Do nothing (for now). Deploy IPP 1.0 and let real world requirements
start accumulating. I really prefer this option, since I think we are
REALLY jumping the gun with this effort. With recent comments on the DL, I
think its very important that we concentrate on getting IPP 1.0 "out the
door" and deployed. We shouldn't appear to be splintering our focus. I do
think we need to consider notifications for IPP, but beyond that I would
say any presumptions on our part about what else is "needed" by customers
is very premature.
5) Consider new transport mappings for IPP, possibly for interfaces such as
1284,1394, USB, and others for which IP is not yet ubiquitous.
Randy
>
>Are there choices I'm missing?
>
>**********************************************
>* Don Wright don@lexmark.com *
>* Product Manager, Strategic Alliances *
>* Lexmark International *
>* 740 New Circle Rd *
>* Lexington, Ky 40550 *
>* 606-232-4808 (phone) 606-232-6740 (fax) *
>**********************************************
>