"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 at easysw.com
Printing Software for UNIX http://www.easysw.com