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)]

David_Kellerman at nls.com David_Kellerman at nls.com
Thu Aug 17 12:50:44 EDT 2000


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