IPP Mail Archive: Re: IPP>NOT mailto feature from IETF meeti

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

From: David_Kellerman@nls.com
Date: Thu Aug 17 2000 - 12:50:44 EDT

  • Next message: Wagner,William: "RE: IPP> machine readable etc. - why Harry is right"


    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

    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

    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


    :: 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 - 13:04:24 EDT