#1 > -----Original Message----- > From: Harry Lewis [SMTP:harryl@us.ibm.com] > Sent: Monday, February 09, 1998 3:43 PM > To: Paul Moore > Cc: ipp@pwg.org > Subject: RE: IPP> Submission vs. Monitoring and Management > > If either, > > >My primary division ('this thing' and 'the other thing') is - > >- client/app talking to printing subsystem (thing #1) > >- printing subsystem talking to printing device (thing #2). > > Which would you charactize IPP as, today. > > Harry Lewis - IBM Printing Systems > > > > > paulmo@microsoft.com on 02/09/98 03:24:52 PM > Please respond to paulmo@microsoft.com @ internet > To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus > cc: > Subject: RE: IPP> Submission vs. Monitoring and Management > > > My primary division ('this thing' and 'the other thing') is - > - client/app talking to printing subsystem (thing #1) > - printing subsystem talking to printing device (thing #2). > > It is not a submission/end-user vs. admin/managment. Bits of these issues > live in both of the interfaces above. > > Note that I am not necessarily talking about 3 separate boxes, merely > three > separate logical entities. > > I beleive that any printing model that refuses to recognized the existence > of printer servers or other software other than the client app is bound to > ultimately break down. > > Note also that we should not confuse end-user experience with protocols. > There does not need to be a one to one mapping between the user feature > set > and the protocol. > > For example the argument goes - the user does not distinguish between a > printer and a server therefore we should only have one endpoint. Perfectly > true that this is desirable from a user experience viewpoint, but that > does > not mean that what goes on under the hood has to be built that way. > > The current notifcation debate is a perfect example - we all agree that it > should be possible for a user to ask for email telling him that his job > has > printed. This does not mean that the protocol has to support that feature, > just that something has to do it. It is perfectly possible to implemnt > that > without any modification to the existing protocol (the client polls the > printer for the job, when the job has gone the client send email to the > user > - I am not suggesting that this is the right solution, merely that it is a > possibility). Another possibility is that a SNMP trap-like message is sent > to something (we dont have a word for it in the current model) that then > goes 'ahha the job is finished I must send email'. > > We now reach the situation that beacuse we want to send notifications one > way, and because we want the user to get email , then all notifications > should go via email, and this is what the protocol should say. So we > effectively have a proposal to replace SNMP traps by human readable email. > This going from one extreme to another. > > Now if somebody wants to have a separate debate about writing a really > robust protocol for interfacing to printers (and I mean the real hardware > not some logical abstraction) then that will suit me fine. Lets start a > new > track and call it, say, NLS (Not LPD and SNMP). This is what I initially > wanted to do but could not persuade enough people. > > I dont know if thats clear or not - probably just made things more obscure > :-) > > > > -----Original Message----- > > From: Harry Lewis [SMTP:harryl@us.ibm.com] > > Sent: Monday, February 09, 1998 12:03 PM > > To: ipp@pwg.org > > Subject: IPP> Submission vs. Monitoring and Management > > > > I'm confused about part of the thread which was "IPP> Consensus on > sending > > our > > drafts to the IESG". Here, Paul Moore makes a distinction between job > > submission, for which, in the context of IPP, Microsoft proposed SWP... > > > > >I saw two problems with two , potentially different, solutions (hence > my > > >double vote). I rolled with what I saw as the simple solution (HTTP - > > >interesting that you percieve them the opposite way round) and proposed > > >something called SIMPLE web printing based on what we were building - > > that > > >just did job submission. That eventually evolved into what we have > today. > > > > ... and other job related issues that could be addressed (i.e. > Monitoring > > and > > Management). > > > > >Now we move on to address the issues that were lurking in the > background > > - > > >printer discovery, feature dicsovery , configuration discovery, > > managment, > > >notification, flow control, peer queuing,.... (things for s/w to > printer > > >interface) and billing, quotas, access control, server managemnt, job > > >redirection, ... (things for client to print subsystem interface). > > > > In that thread, Paul said: > > > > >The WG is DETERMINED that this will be done by one protocol - I have > > >expressed (with you and others) my opionion that this is not > acheiveable > > >(its desirability is understandable) many times. > > > > I guess it could be perceived, at this juncture, that the PWG is only > > interested in one, "soup to nuts", printing protocol, but I contest that > > there > > has been a sideband approach to job monitoring in co-development for > over > > two > > years. > > > > When the SNMP Job MIB project started, we promptly acknowledged the need > > for > > submission standards. In late 1995, I lobbied for a job submission > > "wrapper" to > > encapsulate submission attributes (i.e. job submission standard) to > > facilitate > > monitoring via the MIB. This was ill received and it wasn't until > > submission > > via the Internet became an issue that we had the opportunity, finally, > to > > correlate the monitoring channel with submission. At first, I was > > concerned > > that the IPP group was going "whole hog", beyond submission, but I was > > reassured that correlation with JMP was paramount (for accounting and > > administration) even if the IETF had rejected the notion of a Job MIB > > internet > > standard. Indeed, Tom (especially), Scott, and others have done a great > > job > > helping see to it. > > > > I know there is distaste, among some, regarding the use of SNMP as it > > relates > > to print jobs. Most of the criticism relates to the unreliable nature of > > UDP > > and the lack of registration and trap direction. SNMPv3 begins to > address > > these > > issues and SENSE goes even farther, with the edition filter. While most > of > > the > > IPP people go home Thursday night, there are a substantial number who > have > > remained for the Friday JMP meeting. Most of the interested parties have > > indicated that their private implementations or prototypes of the > standard > > have > > ALL resorted to some proprietary event mechanism (i.e. Job Traps) to get > > the > > job done. Standardization of job traps is on the Austin agenda. > > > > So, when I hear the statement > > > > >The problem is that nobody wants to do the other thing! > > > > I'm wondering: > > > > A. What is the other thing? > > B. Is this really true? > > > > If the other thing is a side band for job monitoring and management, > > correlated > > with the submission protocol in terms of objects and attributes, then I > > think > > there ARE people in the PWG who have demonstrated their desire to do it. > > AND, I > > think the common point between submission and effective monitoring is > > clearly > > NOTIFICATION! > > > > Harry Lewis > > >