IPP Mail Archive: Re: IPP> notification methods

IPP Mail Archive: Re: IPP> notification methods

Re: IPP> notification methods

From: Michael Sweet (mike@easysw.com)
Date: Fri Jul 21 2000 - 09:44:51 EDT

  • Next message: McDonald, Ira: "RE: IPP> Notifiaction spec [fixed contents]"

    pmoore@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@easysw.com
    Printing Software for UNIX                       http://www.easysw.com

    This archive was generated by hypermail 2b29 : Fri Jul 21 2000 - 09:53:11 EDT