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

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

Marty Joel mjoel at netreon.com
Sat Aug 4 04:50:01 EDT 2001


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 at easysw.com>@pwg.org on 07/31/2001 08:17:50 AM

Sent by:  owner-ipp at pwg.org


To:   "McDonald, Ira" <imcdonald at sharplabs.com>
cc:   "Hastings, Tom N" <hastings at cp10.es.xerox.com>, "ipp (E-mail)"
      <ipp at pwg.org>, ipp at 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 at easysw.com
Printing Software for UNIX                       http://www.easysw.com






More information about the Ipp mailing list