I wonder who would implement like that????
We solved this 5 years ago when we mandated in IEEE 1284.1 that a printer MUST
keep history on the last 16 jobs.
Those who know not history are destined to re-live it!!
**********************************************
* Don Wright don at lexmark.com *
* Chair, Printer Working Group *
* Chair, IEEE MSC *
* *
* Director, Strategic & Technical Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 859-232-4808 (phone) 859-232-6740 (fax) *
* (Former area code until 10/1 was 606) *
**********************************************
kugler%us.ibm.com at interlock.lexmark.com on 08/17/2000 02:22:10 PM
To: David_Kellerman%nls.com at interlock.lexmark.com
cc: ipp%pwg.org at interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
TheIPPNotification I-Ds will now go the IESG)]
David-
The problem with polling (with Get-Job-Attributes) is that many Printers
forget about a Job as soon as it has reached a final state: completed,
aborted, or canceled. So, on one poll you see the job is in 'processing'
state, and on the next poll you get 'client-error-not-found', and you have
no way of knowing what the final state of the Job was before it
disappeared.
Otherwise, I agree with you, email is too slow, requires too much
configuration, and is subject to abuse. But it might be better than
nothing.
-Carl
David_Kellerman at nls.com@nls.com on 08/17/2000 10:50:44 AM
Sent by: davek at nls.com
To: ipp at pwg.org, Carl Kugler/Boulder/IBM at IBMUS
cc:
Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
TheIPPNotification I-Ds will now go the IESG)]
Carl,
Well, I like your QUALDOCS-Box, but I sure can't imagine one
using e-mail in the way you suggest.
My fundamental problem with adding machine-readable content to
e-mail notification is that, for notification, e-mail is a very
blunt instrument. Pervasiveness is about its only positive
attribute. Gussie it up however you try, and it still doesn't
have the characteristics you need for software-to-softare
notification.
Take a look at your QUALDOCS-Box again:
> However, these return codes are only useful for determining the success
or
> failure of the job submission. To find out the final disposition of the
> job, we have to rely on notifications. Some notifiable events might
> warrant a retry. For example, job-state goes to 'aborted' for
> job-state-reasons 'submission-interrupted'. A QUALDOCS-Box might do an
> automatic retry in this case. If, for whatever reason, the QDB could
only
> get email notifications from a particular IPP Printer, it would need a
> machine-readable notification in order to be able to take this action.
This is a user-friendly "appliance," and you're going to have
your user configure a mail service on this box? I don't think
you want to go there -- POP3, IMAP, SMTP (oops, that's a server,
isn't it?), depending on local infrastructure -- this is not
friendly. And you're going to try to make this appliance appear
reliable to the user, when you have no control over the delivery
of your notifications?
I bet you quickly abandon the idea of e-mail notification and
just poll for job status. (Hey, polling's not so bad -- how do
you think your POP client is getting the e-mail?)
I think, when you look closely at any of the candidate uses for
machine-readable e-mail notifications, you're going to see
similar problems with configuration and/or reliability. And,
yes, it's easy to gloss over the problems if you don't take a
hard look, and you don't consider whether there's a better
solution.
So what I'm looking for is a real problem for which
machine-readable e-mail is the best solution. And what I'm
seeing are "problems" that on closer inspection don't look very
"real" and "solutions" that look more like problems.
Restricting standard e-mail notification to simple
human-readable content was a disciplined decision. Trying to
extend e-mail notification with machine-readable content is a
solution still in search of a problem, and an invitation to
trouble.
David
:: David Kellerman Northlake Software 503-228-3383
::david_kellerman at nls.com Portland, Oregon fax 503-228-5662