IPP Mail Archive: IPP> NOT - More about ISSUE 08: Sender MAY

IPP Mail Archive: IPP> NOT - More about ISSUE 08: Sender MAY

IPP> NOT - More about ISSUE 08: Sender MAY include list of subscriptio n ids and sequence numbers

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

  • Next message: Michael Sweet: "Re: FW: IPP> NOT - 7 issues in the IPPGET spec"

    Here is a refinement to the solution for ISSUE 08: Allow the client to
    supply a list of subscription-ids and notify-sequence-numbers so the Printer
    filters out duplicates?

    Ira, Marty, and I refined Marty and Michael's proposal to allow the client
    to request the Printer to eliminate duplicate events in the
    Get-Notifications responses when using Event No Wait mode.

    Summary of changes from the 7/20/01 IPPGET Delivery Method:

    1. Receiver NEED NOT support the Event Wait Mode, i.e., it can always return
    the "notify-get-interval" meaning that it is not honoring Event Wait Mode.
    Sub-ISSUE: Do we still RECOMMEND supporting Event Wait Mode or just make it
    OPTIONAL?

    2. Receiver MUST support the following operation attributes:

    3. REQUIRE Sender to always send "notify-recipients-uri" (uri) operation
    attribute. If the client supplies only this attribute, the Printer searches
    all Subscription Objects for a match.

    4. Change "notify-subscription-id" (integer(1:MAX)) operation attribute to:
              "notify-subscription-ids" (1setOf integer(1:MAX))
    If the client supplies this attribute and "notify-search" = 'false' or
    omitted, the Printer only access the identifies Subscription Objects; if
    "notify-search" = 'true', the Printer also searches the Subscription Objects
    for additional uri matches.

    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.

    6. Add "notify-sequence-numbers" (1setOf integer(1:MAX)) operation
    attribute.
    If supplied AND "notify-subscription-ids" MUST also be supplied, the Printer
    only returns Events with that sequence number or higher sequence number for
    the ith Subscription object identified by the ith subscription id in
    "notify-subscription-ids", thereby, eliminating duplicates events on a
    Subscription Object basis.

    Note: this is a case of "parallel" attributes which we said we didn't want
    to do again. However, these attributes are NOT on an object so there is not
    problem with setting parallel attributes and these attributes can never get
    into a directory (where the order might get changed). Most cases will be
    just one value for each attribute as well.

    Please send comments to the DL and consider at the IPP FAX WG meeting,
    8/1/01.

    Thanks,
    Tom, Marty, Ira

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, July 30, 2001 17:57
    To: ipp (E-mail)
    Subject: IPP> NOT - 9 issues in the IPPGET spec [2 more than on original
    IPPFAX agenda]

    So there are now two more issues for the IPPGET spec from the mailing list:

    ISSUE 08: Allow the client to supply a list of subscription-ids and
    notify-sequence-numbers so the Printer filters out duplicates? From Marty
    Joel's Fri 07/27/2001 21:15 email:

    Well, if a subscription ID is given with a Get-Notifications request, then
    only one sequence number is (optionally) needed.

    I'm thinking now that instead of Get-Notifications optionally taking a
    single subscription ID, maybe that should be a list, and maybe there should
    be another optional list with corresponding sequence numbers.

    If that is done, then the 3 possibilities are that Get-Notifications takes
    subscription IDs only and no recipient uri, a recipient uri and no
    subscription IDs, or both. I propose that if Get-Notifications is given a
    recipient uri, then a search will be made for matching subscriptions,
    regardless of whether or not any subscription IDs are given. In the event
    that the recipient uri is not given, then Get-Notifications will only
    return events for the given subscription IDs. Whether or not a recipient
    uri is given, if corresponding sequence numbers are given with the
    subscription IDs, then the starting event sequence number will apply only
    to those subscription IDs. For the case where recipient uri is not given,
    the optional list of corresponding sequence numbers will apply to all
    subscriptions being requested.

    For the case where Get-Notifications is being called with a recipient uri,
    then the first call would have no subscription IDs (since if the client
    knows the subscription IDs, the search for those subscriptions having that
    recipient uri can be avoided). The second call would contain that
    recipient uri, and may include , for each subscription of the events
    returned from the first call, the subscription IDs and a list of the
    corresponding next sequence numbers to receive for each. As each
    subsequent call is made, if an event is returned with a subscription ID
    that was previously not returned, then that subscription ID and next
    sequence number will be added to the lists for subsequent calls to
    Get-Notifications. The client is not required to follow this procedure,
    but if followed, it lowers the number of events the printer must process
    and send, and eliminates the possibility of the client receiving duplicate
    events.

    I realize this complicates the spec a bit, but I think it makes ippget more
    versatile, and addresses Michael's excellent point of improving performance
    and bandwidth.

    ISSUE 09: Make Event Wait Mode OPTIONAL for a Sender and a Receiver?
    Currently the spec REQUIRES the Receiver to support both values of the
    "notify-wait" operation attribute ('true' and 'false').

    With the Notification Recipient being able to request the Receiver to filter
    out duplicates, is it ok to allow the Receiver to always force the
    Notification Recipient back to Event No Wait Mode with the
    "notify-get-interval" operation attribute of when to poll next?

    Of should Event Wait Mode be RECOMMENDED for the Receiver?
    What about RECOMMENDED for the Sender?

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, July 27, 2001 17:48
    To: ipp (E-mail)
    Subject: IPP> NOT - 7 issues in the IPPGET spec

    The IPPGET spec that was sent to the IETF last Friday, 7/20, has 7 issues
    that have been raised since then. I've collected them into a single note
    and sent them to the IPP FAX DL (ifx@pwg.org) for their IPPFAX WG meeting in
    Toronto, August 1. IPPFAX REQUIRES support of IPPGET. However, the IPPGET
    spec is an IPP document, so discussion of it should go on the IPP DL. So
    here are the 7 issues.

    If you have a comment think about whether or not to start a new thread. If
    the comment is just about one issue, I suggest a new thread.

    3. IPPGET Delivery Method (<draft-ietf-ipp-notify-get-04.txt>), I posted
    Monday, 7/23, at:
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf

    ISSUE 01 (see section 12): Should we use application/multiplexed
    (draft-herriot-application-multiplexed-03.txt) which can chunk mime types
    using content lengths, instead of multi-part/related, which uses boundary
    strings?

    ISSUE 02: For Event Wait Mode, OK to make each successive response after
    the first a complete IPP response, instead of just the Event Notification
    Attributes Groups?

    Then each response looks like a complete response with its own status code.
    Also complete responses might be necessary on some other transport. Also we
    can move the "notify-interval" attribute back to the Operation Attributes
    Group where it belongs, since it applies to all events being returned in
    that response.

    ISSUE 03: OK to clarify that the Per-Job Subscription Object and the
    associated Job object MUST persist after the job completes (job completed,
    canceled, or aborted) in the Job Retention or Job History phases (see
    [RFC2911] section 4.3.7.2)?

    Otherwise, a Notification Recipient that is polling would not get the Event
    Notification, if it polled after the job completed, but before the Event
    Lease Time expired.

    ISSUE 04: OK to clarify that a client or a Printer MAY disconnect the
    underlying transport connect for any operation, including the Event No Wait
    Get-Notifications operation and the Event Wait Get-Notifications operation
    when the Printer isn't willing to honor the initial request or reneges in a
    later response?

    So a client could keep the connection open for multiple Event No Wait
    Get-Notifications. Before a Printer disconnects it needs to wait enough
    time to make sure that any IPP response has had time to get back to the
    client before disconnecting, otherwise the client might not see the
    response.

    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.

    ISSUE 06: Section 12 says: "The Printer MAY chunk the responses, but this
    has no significance to the IPP semantics." Is this sufficient, or is
    HTTP/1.1 chunking REQUIRED in order to support the multi-part/related MIME
    type?

    ISSUE 07: For Event No Wait mode, should we add a way for the Notification
    Recipient to have the Printer filter out returning Event Notifications that
    the Notification Recipient has already received in order to reduce the
    duplicates (that will usually happen, else events will be lost)? Or should
    we just depend on most usage using Event Wait Mode, so that there aren't
    duplicates? It has been suggested on the mailing list that the Notification
    Recipient could supply pairs of the "notify-sequence-number" and
    "subscription-id" and the Printer would only return events with a higher
    sequence number.

    Tom



    This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 02:43:58 EDT