IPP> notification methods

IPP> notification methods

IPP> notification methods

Michael Sweet mike at easysw.com
Fri Jul 21 09:44:51 EDT 2000

pmoore at peerless.com wrote:
> Following the SF meeting I would like to formally propose the
> following.
> 1. If a device wants to expose human readable events then it MUST
> support the mailto method
> 2. If a device wants to expose machine readable events then it MUST
> support the INDP method
> But we do not UNCONDITIONALLY require either.

The only problem with this is that there than becomes no standard
notification method for IPP, which means that clients will:

    1. Only work with printer objects that support their particular
       notification method of choice,

    2. Try to implement reception via all notification methods,
       causing bloat, increased complexity, etc. which will
       likely lead to a less stable product,

    3. Not use notification at all, and poll the printer object
       to provide status information to the user.

There is also the issue of whether a notification method is
truly available to the client - e.g. a remote client asks for
indp notifications, but the firewall(s) between the client and
server won't pass them through!

For CUPS, we'll probably implement both mailto and indp to support
existing email notifications and allow better web/GUI clients, so
I'm not so concerned about what happens on systems running CUPS.
However, I do think we need to mandate at least one method to
ensure interoperability.

Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com

More information about the Ipp mailing list