IPP Mail Archive: RE: IPP> NOT - ISSUE 05

IPP Mail Archive: RE: IPP> NOT - ISSUE 05

RE: IPP> NOT - ISSUE 05

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Jul 31 2001 - 14:10:17 EDT

  • Next message: Michael Sweet: "Re: IPP> NOT - ISSUE 05"

    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?

    Here is more detail:

    The Printer MUST return the 'successful-ok-events-complete' status code to
    indicate when this return is the last return for all Subscription objects
    that match the request, whether or not there are Event Notifications being
    returned. This condition occurs for Event Wait Mode Notification Recipients
    waiting for responses when the Subscription Object is: (1) canceled with a
    Cancel-Subscription operation, (2) deleted when the Per-Printer Subscription
    lease time expires, or (3) when the 'job-completed' event occurs for a
    Per-Job Subscription. This condition also occurs for a Get-Notifications
    request that a Notification Recipient makes after the job completes, but
    before the Event Lease Time expires.

    Here is a complete table of combinations of "notify-wait", "status-code",
    "notify-interval", and Event Notification Attributes Groups for
    Get-Notification initial (Wait and No Wait) Responses and subsequent Event
    Wait Mode Responses (which may be staying in Wait Mode or may be requesting
    the Notification Recipient to leave Wait Mode):
                                                              Event
      client sends: Printer returns: Notification
      "notify-wait" "status-code" "notify-get-interval" Attribute Groups
      ------------- ------------- --------------------- ----------------
    1.'false'/omitted 'successful-ok' MUST return N maybe
    2.'false'/omitted 'not-found' MUST NOT MUST NOT
    3.'false'/omitted 'busy' MUST return N MUST NOT
    4.'false'/omitted 'events-complete' MUST NOT 'job-completed'

    5. 'true' 'not-found' MUST NOT MUST NOT
    6. 'true' 'busy' MUST return N MUST NOT
    7. 'true' 'successful-ok' MUST NOT MUST
    8. 'true' 'successful-ok' MUST return N maybe
    9. 'true' 'events-complete' MUST NOT 'job-completed'
                                                              or maybe other
    Explanation:
    1-4: client requests Event No Wait
    5-9: client request Event No Wait
    2,5: Subscription object not found, or was canceled earlier; client should
    NOT try again.
    3,6: server busy, tells client to try later; client should try again in N
    seconds.
    4: client polled after job completed, but before Event Lease Time expired,
    and got the 'job-completed' event, so the client shouldn't bother trying
    again; client should NOT try again later.
    7: Printer returns one or more Event Notifications and is ok to stay in
    Event Wait Mode; the client waits for more.
    8: Printer wants to leave Event Wait mode. Can happen on the first
    response (with events) or happen on a subsequent response with or without
    Event Notifications; the client should try again in N seconds.
    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.

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Tuesday, July 31, 2001 08:47
    To: McDonald, Ira
    Cc: Hastings, Tom N; ipp (E-mail); ipp@webpageassembler.com
    Subject: Re: IPP> NOT - More about ISSUE 08: Sender MAY include list of
    subscription ids and sequence numbers

    "McDonald, Ira" wrote:
    >
    > Hi Michael,
    >
    > But when you ask for events by (only) "notify-recipient-uri",
    > you are certain to get duplicates (because your polling interval
    > MUST be shorter than the event persistent, in order for polling
    > to work at all).
    >
    > The explicit list of pairs of subscription-id and sequence-number
    > allows duplicate avoidance. Now you see why the optimization?

    Yes, however you'll still get duplicates with the current proposal
    for any new subscriptions that you haven't added to the subscription
    ID set, and quite frankly that just adds yet another layer of
    complexity to the server's processing of the request:

        Copy subscription ID set to local list
        Copy sequence number set to local list
        for each subscription for recipient URI
            if subscription ID in local list then
                do nothing
            else
                add subscription ID to local list
                add sequence number 0 to local list
            endif
        endfor

    I'm not sure if this level of complexity is needed or not?

    In the case of the wait-mode Get-Notifications, providing the
    recipient URI will give you all events from all matching
    subscriptions, without duplicates (unless you have to re-poll)
    If your client can sort out N subscriptions simultaneously,
    then it can probably track the duplicate events itself and
    not re-process them. Not the most efficient bandwidth-wise,
    but it does reduce the load on the server.

    ....

    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)???

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



    This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 14:12:47 EDT