IPP Mail Archive: Re: IPP> NOT - ISSUE 05 [return successful

IPP Mail Archive: Re: IPP> NOT - ISSUE 05 [return successful

Re: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']

From: Michael Sweet (mike@easysw.com)
Date: Tue Jul 31 2001 - 21:04:04 EDT

  • Next message: Hastings, Tom N: "IPP> NOT - ISSUE 10: OK to change IPPGET "ippget-event-time-to-live" t o "ippget-event-lease-duration"?"

    "Hastings, Tom N" wrote:
    > ...
    > According to the complete proposed solution to ISSUE 05
    > 'successful-ok-events-complete' is returned only once and as soon
    > as there are no more Subscription objects that match what the
    > Notification Recipient has requested in the "notify-recipient-uri"
    > attribute.

    OK, I didn't quite get that from the text, as it did not separate
    the notify-subscription-ids and notify-recipient-uri cases (which
    *can* have the same behavior, but in one case you are asking for
    specific subscriptions objects and the other you are saying "give
    me all of the subscriptions that use the recipient address" - not
    quite the same thing, but maybe I'm just nitpicking...)

    > If there aren't any Subscription Objects on the first
    > Get-Notifications, the Printer returns 'client-error-not-found'
    > right away.
    > I think you are wondering whether returning 'client-error-not-found'
    > on the first probe is the right behavior or whether the Notification
    > Recipient should be able to wait until a Subscription object does
    > get created, correct?

    No, I was wondering about the wait-mode notifications, where the
    Get-Notifications operation finally completes when all subscriptions
    have expired and all events have either expired or been delivered.
    Normally the printer will just return the new
    successful-ok-events-complete status for this case, but for a
    Get-Notifications request that only includes a notify-recipient-uri
    attribute does the printer:

         a) keep the connection going because a new subscription might
            be created for that recipient,

         b) close the connection, returning the
            successful-ok-events-complete status without a
            notify-get-interval attribute to tell the client when
            to retry (because a new subscription might be created
            for that recipient),

         c) close the connection, returning the
            client-error-not-found status with a
            notify-get-interval attribute, just like an
            initial Get-Notifications request.

    I know this is special-casing the hell out of Get-Notifications,
    but a Get-Notifications request with a notify-recipient-uri
    attribute is *not* the same as a request with the
    notify-subscription-ids and possibly notify-sequence-numbers
    sets. In one case you are asking for any matching subscription,
    and the other you are asking for specific subscriptions.

    The more we discuss this the more I find there are two
    (competing) operations: a "Get-Recipient-Notifications" that uses
    the notify-recipient-uri (and maybe the notify-time-stamp
    attribute?) and works one way, and another that is a
    "Get-Subscription-Notifications" request that takes the
    notify-subscription-ids and notify-sequence-numbers attributes
    and works for a specific set of subscriptions.

    If we have separate operations, then we can more easily describe
    the operations and therefore have a better chance that they will
    be implemented correctly. It also gives implementers an easy
    job of writing and optimizing each request.

    > ...
    > Aren't these two ways sufficient for the Notification Recipient
    > that wants to wait for the cows to come home?

    Undoubtedly the retry mechanism is the right way to go, but how
    does the client know when to retry? Isn't that why we added the
    notify-get-interval attribute?

    > ...
    > Maybe the Per-Printer Subscription mechanism that is already part
    > of the base [ipp-ntfy] spec can be used instead of adding more
    > functionality to the IPPGET Delivery Method?

    That's certainly a possibility. Marty probably will have some
    specific ideas about this (IIRC he is the one that brought up
    the recipient URI case), but if the "watch for new job
    subscriptions" stuff can be reimplemented using printer
    subscriptions to provide substantially the same functionality,
    it would simplify the requirements for IPPGET and then maybe
    we can get rid of the recipient URI case altogether.

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

    This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:06:44 EDT