IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - TheIPPNotification I-Ds will now go the IESG)]

IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - TheIPPNotification I-Ds will now go the IESG)]

IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - TheIPPNotification I-Ds will now go the IESG)]

Carl Kugler/Boulder/IBM kugler at us.ibm.com
Thu Aug 17 14:22:10 EDT 2000


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






More information about the Ipp mailing list