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: Marty Joel (mjoel@netreon.com)
Date: Sat Aug 04 2001 - 05:06:20 EDT

  • Next message: Marty Joel: "IPP> Multipart Chunked Keep-Alive?"

    Hi Tom,

    Great simplification! I wonder if we should require that the sequence
    number list must either be empty or contain exactly as many numbers as the
    number of subscription IDs given. If we don't require that, then the spec
    should probably state that if the list of sequence numbers is smaller than
    the list of subscription IDs, then for any subscriptions for which a
    sequence number isn't given, it means to start with the oldest event for
    that subscription (that has not yet expired).

    Marty

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 08/01/2001
    10:30:17 AM

    Sent by: owner-ipp@pwg.org

    To: "ipp (E-mail)" <ipp@pwg.org>
    cc: "McDonald, Ira" <imcdonald@sharplabs.com>, ipp@webpageassembler.com,
          Michael Sweet <mike@easysw.com>

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

    Michael suggested that we separate Get-Notifications into two separate
    operations:

    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.

    Ira, Carl Kugler, and I just conferenced, and we like the idea and further
    think that there isn't even a need for the searching on URI operation.
    There are two existing ways for a Notification Recipient to get
    notifications for various senders:

    (a) Be an operator and create a Per-Printer Subscription object for the
    Printer
     and subscribe for 'job-complete' and maybe 'job-stopped' events or
    (b) Periodically do a Get-Subscriptions operation to search for existing
    Subscription Objects of interest, i.e., ones that have a particular
    "notify-recipient-uri" value or values. When one or more Subscription
    Objects are found, use the "subscription-id" value(s) in a
    Get-Notifications
    operation.

    So lets simplify Get-Notifications as follows:

    1. drop the "notify-recipient-uri" as an input operation attribute.

    2. drop the "notify-search" (boolean) operation attribute.

    3. Sender MUST supply one or more subscription-ids in the
    "notify-subscription-ids: (1setOf integer(1:MAX)) operation attribute.

    4. Sender MAY supply one or more parallel sequence-numbers in the
    "notify-sequenced-numbers" (1setOf integer(1:MAX)) to eliminate getting
    duplicates for the corresponding Subscription Object.

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Tuesday, July 31, 2001 18:04
    To: Hastings, Tom N
    Cc: McDonald, Ira; ipp (E-mail); ipp@webpageassembler.com
    Subject: Re: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']

    "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),

            or
         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 : Sat Aug 04 2001 - 05:15:29 EDT