IPP> NOT - ISSUE 05

IPP> NOT - ISSUE 05

Michael Sweet mike at easysw.com
Tue Jul 31 14:49:40 EDT 2001


"Hastings, Tom N" wrote:
> 
> Michael asked the following question about the proposed resolution to ISSUE
> 05 about adding 'successful-ok-events-complete' status code:
> 
> This brings up another issue (maybe it has been addressed, I
> don't remember off hand) - if you do a wait-mode Get-Notifications
> with a notify-recipient-uri, and initially there are subscriptions
> for this URI, do we also return a successful-ok-no-more-events
> once all active subscriptions expire (including their events),
> or does the Get-Notifications continue indefinitely (or until
> the server decides to close the connection)???
> 
> TH> I think that it has been addressed in the resolution to ISSUE 05.
> The 'successful-ok-events-complete' status code is only returned once when
> ALL Subscription Objects that match have all gone away, not also on the
> first response to a Wait Mode Get-Notifications that has Events.  Is there
> anything in the proposed text that needs further clarification?  Here is
> the complete text to ISSUE 05 and its proposed resolution:
> 
> ISSUE 05:  OK to add 'successful-ok-events-complete' status code for a
> Get-Notifications response whether Event No Wait or Event Wait mode?
> ...
> 9. 'true'         'events-complete' MUST NOT              'job-completed'
>                                                           or maybe other
> ...
> 9. Printer either (1) returns 'job-completed' event or (2) the Subscription
> Object was canceled by either a Cancel-Job or a Per-Printer Subscription
> expired without being renewed.  For case (1), at least one event MUST be
> returned, while for case (2), it is unlikely that any Events are returned;
> the client should NOT try again.
> ...

MS> However, since the "notify-recipient-uri" matches any subscription
    *at the time events are delivered*, it is not clear that the
    printer can send a "sucessful-ok-events-complete" status when
    a set of subscriptions has not been specified.  That is, if
    we allow a notify-recipient-uri attribute to automatically
    get events for new subscriptions not specifically requested
    (e.g. gimmee all events that are destined for Bob), we need
    to specifically state that the printer object will not wait
    for new subscriptions (for Bob) to be created before closing
    out the current wait-mode Get-Notifications request.

MS> In other words, what will trigger a printer to send a
    successful-ok-events-complete status when the subscription
    doesn't reference specific subscription objects?  Do we
    define this as when all potential subscriptions have expired,
    or only when all known subscriptions have expired.

MS> I bring this up because the only example application I've seen
    for using the recipient URI has been for a client to automatically
    get notifications for new subscriptions, and I can see a client
    wanting to be able to sit in wait mode till the cows come home,
    acting as a central distributor/displayer of notifications for
    a user.  If this is not to be the case (end the Get-Notifications
    once all known subscriptions are expired), then the server may
    in fact want to send the notify-get-interval attribute to the
    client when the client used the notify-recipient-uri attribute,
    since the client will have to retry periodically...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com



More information about the Ipp mailing list