IPP Mail Archive: Re: IPP> notification methods

IPP Mail Archive: Re: IPP> notification methods

Re: IPP> notification methods

From: pmoore@peerless.com
Date: Fri Jul 21 2000 - 11:23:46 EDT

  • Next message: pmoore@peerless.com: "RE: IPP> Notifiaction spec [fixed contents]"

    1.mailto and indp are used by clients for totally different purposes - you can
    do things with indp that you absolutely cannot do with mailto and vice versa.
    They are not overlapping they are complimentary. Therefore there is no bloat
    issue as such

    2. I did not suggest that a client implement ALL notification mechansisms - just
    2.

    3. I am surprised that CUPS would want to use mailto from the actual printer
    back to the cups end user. I would have thought that you would want to generate
    mail to your clients and administartors youself. In this way you can ensure that
    they get consistent messages from you. By delegating it to the printers your
    clients will get a mix of differnt messages from different vendors, some smart
    devices will have quite good text, some will have poor text, some might be
    localized if you are lucky. The clean thing to do would be to get indp messages
    from the device into the spooler and then generate the email yourself - you can
    then have consistent configurable text accross the entire set of devices. You
    can also do polling for those device that dont support notifactions at all and
    your users will still get the same great experience.

    [I know I should butt out of the design of your product but I cant help it :-) ]

    4. even if we mandate mailto, not all printers will support it. In order for it
    to work the printer must have its SMTP gateway configured by somebody. In some
    cases this will not have been done so the mailto method wont work - interesting
    question about how a printer should deal with this case. Presumably it must not
    say it can do mailto - or perhaps it will accept the requests and throw them
    away. Clients will always have to be smart.

    5. INDP does go over fire walls - this is true. The main use cases for INDP are
    not Internet casses (ie. spooler talking to actual printer).

    6. For me the mailto method is more useful when the spooler if proxying the
    printers via IPP. Ie. the spooler clients send requests via IPP that it then
    sends to printers (maybe via IPP )

    client-----IPP (mailto)--->spooler------IPP(indp)----->printer. or
    client-----IPP(mailto)---->spooler------(LPR, 9100, parallel)------>printer

    7.Mandating a method does not gurantee interop. THe two methods do totally
    different things. If my client needs machine readable notifications (for example
    I have a rendering pipeline driven by page complete messages) then telling me
    that mailto is available does nothing to help me. Its like saying "we have
    mandated SMTP why the heck do you want to do HTTP" - they do different things.

    8. In real life there will be printers that do notifactions that dont support
    mailto. I am just trying to get the standard to conform to what the actual
    situation will be rather than to some ideal case. Lying to client developers is
    not useful.

    9. Notifiactions is completey optional- all clients will have to behave smartly
    in the situation where thier favorite method is not available.

    Michael Sweet <mike@easysw.com> on 07/21/2000 06:44:51 AM

    To: pmoore@peerless.com
    cc: ipp@pwg.org (bcc: Paul Moore/AUCO/US)

    Subject: Re: IPP> notification methods

    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 - 11:33:54 EDT