IPP Mail Archive: RE: IPP> NOT - More about ISSUE 08: Sender

RE: IPP> NOT - More about ISSUE 08: Sender MAY include list of subscription ids and sequence numbers

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Jul 31 2001 - 11:17:23 EDT

  • Next message: Michael Sweet: "Re: IPP> NOT - More about ISSUE 08: Sender MAY include list of subscription ids and sequence numbers"

    Hi Michael,

    But when you ask for events by (only) "notify-recipient-uri",
    you are certain to get duplicates (because your polling interval
    MUST be shorter than the event persistent, in order for polling
    to work at all).

    The explicit list of pairs of subscription-id and sequence-number
    allows duplicate avoidance. Now you see why the optimization?

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Tuesday, July 31, 2001 11:18 AM
    To: McDonald, Ira
    Cc: Hastings, Tom N; ipp (E-mail); ipp@webpageassembler.com
    Subject: Re: IPP> NOT - More about ISSUE 08: Sender MAY include list of
    subscription ids and sequence numbers

    "McDonald, Ira" wrote:
    > ...
    > <ira> Marty describes the following scenario. A Notification
    > Recipient (NOT the job originator, maybe your secretary)
    > issues Get-Subscriptions with a known "notify-recipient-uri"
    > (e.g., your secretary's 'mailto:' address in 'ippget:' form).
    > Subsequently this Notification Recipient issues periodic
    > (polling) Get-Notifications with the explicit list, but wants
    > to ALSO find any new subscriptions.
    >
    > <ira> I'm not entirely sure I like this optimization. At any
    > point, this Notification Recipient can re-issue Get-Subscriptions
    > and do the search. Adding the optional search (even when the
    > "notify-subscription-ids" operation attribute is supplied) seems
    > like a questionable optimization to me. I think this kind of
    > "third-party" Notification Recipient (not the job originator)
    > should probably do periodic Get-Subscription operations anyway.

    MS> I'd recommend that we just support the notify-subscription-ids
        OR notify-recipient-uri attribute to select subscriptions, and
        REQUIRE the server to reject a request containing both
        attributes with a client-error-bad-request error status.

    MS> If you add the optional search stuff, then having the
        notify-subscription-ids attribute for Marty's scenario
        is of no benefit - the subscription IDs will almost
        certainly be a subset of the subscriptions with the
        specified recipient URI, and you've just forced the
        server to lookup the same subscriptions twice... Better
        to use Get-Subscriptions or always ask for events by
        recipient URI (which should pick up on any new subscriptions
        in wait mode, right? :)

    -- 
    ______________________________________________________________________
    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 - 11:28:58 EDT