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