Hi Michael,
Comments in your note below.
Cheers,
- Ira McDonald
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Tuesday, July 31, 2001 8:36 AM
To: Hastings, Tom N
Cc: ipp (E-mail); ipp at webpageassembler.com
Subject: Re: IPP> NOT - More about ISSUE 08: Sender MAY include list of
subscription ids and sequence numbers
"Hastings, Tom N" wrote:
> ...
> 5. Add "notify-search" (boolean) operation attribute, 'true' means that
the
> Printer searches Subscription Objects to match the uri when the
> "notify-subscription-ids" is supplied. If "notify-subscription-ids" isn't
> supplied, then the Printer always does search to match URIs.
MS> I'm not sure what benefit this will add - if you have multiple
subscriptions, you probably will either have a common recipient
URI or the subscription IDs themselves, so why would support for
both be needed?
<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.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com