Subject: IPP> Submission vs. Monitoring and Management

From: Harry Lewis <[email-masked]>
Date: Mon, 9 Feb 1998 15:02:54 -0500

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

---

From: Paul Moore <[email-masked]>
Date: Mon, 9 Feb 1998 15:41:02 -0800

#1
> -----Original Message-----
> From:	Harry Lewis [SMTP:[email-masked]]
> Sent:	Monday, February 09, 1998 3:43 PM
> To:	Paul Moore
> Cc:	[email-masked]
> 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
> 
> 
> 
> 
> [email-masked] on 02/09/98 03:24:52 PM
> Please respond to [email-masked] @ internet
> To: [email-masked] @ 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:[email-masked]]
> > Sent: Monday, February 09, 1998 12:03 PM
> > To: [email-masked]
> > Subject: IPP> Submission vs. Monitoring and Management
> >
> > I'm confused about part of the thread which was "IPP> Consensus on
> sending
> > our
> > ... 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
> > -
> > has been a sideband approach to job monitoring in co-development for
> over
> > two
> > years.
> >
> > 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
> > indicated that their private implementations or prototypes of the
> standard
> > have

---

From: Harry Lewis <[email-masked]>
Date: Mon, 9 Feb 1998 18:42:57 -0500

If either,

Note that I am not necessarily talking about 3 separate boxes, merely three
separate logical entities.

Note also that we should not confuse end-user experience with protocols