IPP Mail Archive: IPP> What is PUSH?

IPP Mail Archive: IPP> What is PUSH?

IPP> What is PUSH?

From: mjoel@netreon.com
Date: Wed Jul 18 2001 - 11:03:23 EDT

  • Next message: mall.com: "IPP> FREE Advertising at Mall.com"

    Hello,

    According to the notification spec, a PUSH is where IPP:

         delivers the Event Notification using the Delivery Method and target
    address identified
         in the Subscription Object's "notify-recipient-uri" attribute if the
    Delivery Method

    Since that's the definition of push, then I don't think ippget meets the
    requirements. Ippget seems more like a long, drawn out pull to me. As I
    mentioned in my last email, the so-called push part of ippget is very
    difficult to implement.

    If I were to redesign ippget to follow the notification spec's definition
    of push, it would look like this:

    1) When creating an ippget subscription, a new attribute would indicate if
    using ippget for push or pull, and that would be stored in the subscription
    object.

    2) Get-Notifications would be for ippget's pull mode. There would be no
    "notify-no-wait". After Get-Notifications returns the events that have
    already occurred, it would simply disconnect as IPP does after every other
    request.

    3) Events objects would only be stored for pull mode. Also, it's my
    opinion that event objects should be discarded as soon as they are
    delivered, or at least when using reliable delivery methods. Why should a
    client see the same event multiple times?

    4) When an event for a push-mode ippget subscription occurs, then as the
    notification spec says, it would send that event to the client using its
    notify-recipient-uri. But how? Push-mode ippget could imply a port the
    client will listen to, which of course can be overridden in
    notify-recipient-uri. Listening on a port could require network
    administrators to have to pierce a hole in their firewalls. If it used
    HTTP, which defaults to port 80, the server could send a GET or POST, and
    the client would return OK. That will require a port redirector if the
    client computer is also a web server.

    Sorry to propose changes so late in the specification cycle, but I'm new to
    this group, and have discovered ippget's problems only recently.

    Regards,

    Marty Joel



    This archive was generated by hypermail 2b29 : Wed Jul 18 2001 - 11:07:04 EDT