IPP Mail Archive: RE: IPP> NOT - ISSUE 05 [return successful

IPP Mail Archive: RE: IPP> NOT - ISSUE 05 [return successful

RE: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']

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

  • Next message: Michael Sweet: "Re: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']"

    Michael,

    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.

    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?

    With the proposed solution to ISSUE 05 (cut and pasted below), there are two
    ways that a Notification Recipient could get notifications for Bob "until
    the cows come home", i.e., be a perpetual Notification Recipient:

    way a: the Notification Recipient could simply repeatedly do
    Get-Notifications with "notify-recipient-uri" of, say bob@abc.com every
    minute or so, i.e., every "ippget-event-time-to-live" seconds. The response
    comes back, either "client-error-not-found", if there aren't any
    Subscription Objects that match or 'successful-ok' with the first batch of
    events.

    way b: Use the Create-Printer-Subscription operation and create a
    Subscription Object with a "notify-recipient-uri" of, say, bob@abc.com. The
    events could be 'job-completed', and 'job-stopped'. Then that Notification
    Recipient can use Get-Notifications with or without Event Wait Mode and
    specify only the subscription-id of that Per-Printer Subscription object.

    Aren't these two ways sufficient for the Notification Recipient that wants
    to wait for the cows to come home?

    If the policy of the Printer is that a Notification Recipient has to be the
    owner of the Subscription object or the Operator, then both ways will
    require the Notification Recipient to be an operator. But isn't that
    exactly the use case with an IPP FAX Printer? Someone is designated as the
    person to attend the IPPFAX Printer. They are an operator. When jobs
    arrive, they see who the job is intended for (by reading the FAX start sheet
    or the receiver vCard info) and notify the intended job recipient that an
    IPPFAX Job has arrived and been printed.

    In fact, if several groups share the same IPPFAX Printer, they could each
    have a separate URL for the IPPFAX Receiver and each has its own separate
    operator. Each operator only gets notifications for the IPPFAX Jobs that
    are for his/her group.

    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?

    Comments?
    Tom

    Cut and Paste proposed solution to ISSUE 05:

    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 11:50
    To: Hastings, Tom N
    Cc: McDonald, Ira; ipp (E-mail); ipp@webpageassembler.com
    Subject: Re: IPP> NOT - ISSUE 05

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



    This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 20:34:29 EDT