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

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

  • Next message: Marty Joel: "RE: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']"

    Hi,

    I agree with Michael's last suggestion below. Make Get-Notifications only
    take subscription IDs (and corresponding sequence numbers) and never take a
    recipient uri. If the client wants subscriptions for a given uri, they can
    do a Get-Subscriptions.

    Marty

    Michael Sweet <mike@easysw.com>@pwg.org on 07/31/2001 08:17:50 AM

    Sent by: owner-ipp@pwg.org

    To: "McDonald, Ira" <imcdonald@sharplabs.com>
    cc: "Hastings, Tom N" <hastings@cp10.es.xerox.com>, "ipp (E-mail)"
          <ipp@pwg.org>, 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 : Sat Aug 04 2001 - 04:52:45 EDT