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@nls.com@nls.com on 08/17/2000 10:50:44 AM
Sent by: davek@nls.com
To: ipp@pwg.org, Carl Kugler/Boulder/IBM@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@nls.com Portland, Oregon fax 503-228-5662
This archive was generated by hypermail 2b29 : Thu Aug 17 2000 - 14:36:02 EDT