IPP Mail Archive: IPP> Updated IPPGET Delivery Method docume

IPP Mail Archive: IPP> Updated IPPGET Delivery Method docume

IPP> Updated IPPGET Delivery Method document posted.

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jul 20 2001 - 18:45:33 EDT

  • Next message: McDonald, Ira: "IPP> FW: Revised SLPv2 Search Filters (for SLPv2 updates)"

    I've incorporated most of the comments and agreements on the mailing list
    for the ippget Delivery Method. The updated documents are available at:


    The .pdf version have line numbers. The -rev shown the revisions from the
    previous version. Here is the Abstract:

            This document describes an extension to the Internet Printing
    Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. This
    document specifies the 'ippget' Delivery Method for use with the "IPP Event
    Notifications and Subscriptions" specification [ipp-ntfy]. When IPP
    Notification [ipp-ntfy] is supported, the Delivery Method defined in this
    document is one of the RECOMMENDED Delivery Methods for Printers to support.

            The 'ippget' Delivery Method is a 'pull' Delivery Method with
    aspects of a 'push' method as well. That is, when an Event occurs, the
    Printer saves the Event Notification for a period of time called the Event
    Notification Lease Time. The Notification Recipient fetches (pulls) Event
    Notifications using the Get-Notifications operation. If the Notification
    Recipient has selected the option to wait for additional Event
    Notifications, the Printer continues to return (similar to push) Event
    Notifications to the Notification Recipient as Get-Notification responses as
    Events occur. This push aspect is not a true 'push', since the Printer does
    not open the connect, but rather continues to return responses as Events
    occur using the connection originated by the Notification Recipient.
    Please send comments on the document to the mailing list. Although the
    ippget spec did pass IPP WG Last Call last Fall, we are re-opening it, due
    to implementation experience, especially with IPPFAX.

    The IPPFAX WG is meeting, August 1, in Toronto. Since they have agreed that
    ippget is the one REQUIRED Delivery Method, perhaps they can also discuss
    ippget at the face to face meeting. However, please continue the good
    discussion on the mailing list to see if we can get closure on the mailing

    I just made the IETF cutoff for Internet-Drafts for the upcoming IETF
    meeting in London, August 6-10. So we may be able to get some feedback from
    IETF folks too.

    There are still some issues about exactly how multi-part/related is used
    with Event Wait Mode in multiple Get-Notifications responses to a single
    Get-Notifications request. We need to write out a complete example, after
    we agree on how to do it, and include that as an appendix to the document.

    ISSUE 1: Do we add an in-band end-of-segment tag to indicate the end of a
    batch of Event Notifications that occur together (that would correspond to
    one application/ipp part under the multi-part/related type).

    ISSUE 2: Do we want to consider using Bob Herriot's new
    application/multiplexed which uses lengths for chunking in the data, instead
    of using multi-part/related which uses boundary strings?

    Here are the changes from the previous draft:

    1. Change the terminology in IPPGET not to use "push", since the term
    "push" outside of IPP Notification means create the connection as well as
    send. In IPPGET use the term "wait mode" instead.

    2. Clarify that a Printer that supports the IPPGET Delivery Method,
    MUST use HTTP chunking (HTTP/1.1 required feature) in the Get-Notifications
    response if it keeps the connection open, i.e., honors the client's request
    for "wait mode".

    3. Clarify that "using the Get-Jobs model for returning multiple groups
    of attributes" means that the Printer returns the 'end-of-attributes' (0x03)
    tag exactly once at the end of the last Get-Notifications Response to
    indicate that there are no more events that will come because the
    Subscription Object(s) have all been cancelled/deleted.

    4. Use multi-part/related for a Get-Notifications Response for Event
    Wait Mode. Each batch of Event Notifications will be separate
    application/ipp MIME type under the multi-part/related, but only the last
    one ends with the 'end-of-attributes' (0x03) tag.

    5. REQUIRE URI matching rules for ippget scheme (for example, the
    scheme name and host name are case insensitive).

    6. REQUIRE that a Printer MUST return the "notify-recipient-uri" value
    exactly as submitted by the Subscribing Client (no case conversion or other

    7. Reduce the length of the "notify-recipient-uri" attribute for ippget
    to 255 octets (since this doesn't really specify a resource and an
    implementation may want to keep a canonical form copy as well).

    8. In order to improve the searching efficiency of all the Subscription
    Objects on a Get-Notifications and to allow the client to be certain of
    getting events from only one Subscription object, allow the client to supply
    the "notify-subscription-id", the "notify-recipient-uri" or both operation
    attributes. When the client supplies the "notify-subscription-id", the
    Printer only returns events associated with that Subscription Object. The
    Printer MUST support both operation attributes and MUST reject a request
    which has neither and return the 'client-error-bad-request' status code. If
    only the "notify-subscription-id" is supplied, the Printer MUST check that
    the identified Subscription object's "notify-recipient-uri" attribute
    matches the 'ippget' scheme (case insensitive).

    9. Change the "notify-get-interval" (integer(0:MAX)) attribute so that
    the Printer always returns it by itself in a separate Event Notifications
    Attribute Group, instead of being returned in the Operation Attributes
    Group. The Printer MUST return it if and only if (1) it is too busy and is
    rejecting the request, (2) the client didn't ask for Event Wait Mode, or (3)
    the Printer wants to leave Event Wait Mode on the first or any subsequent

    10. Do not generalize Get-Notifications for use with indp or mailto
    Delivery Methods. REQUIRE the Printer to reject the Get-Notifications
    Request if the scheme is not 'ippget'. But allow a future Delivery Method
    Document to use the Get-Notifications operation if polling makes sense for
    that Delivery Method

    11. Don't change the Get-Notifications operation name and keep it in the
    ippget spec.

    12. Change the sense of the Get-Notifications "notify-no-wait" (boolean)
    operation attribute to a positive "notify-wait" (boolean), so that omitted
    and 'false' mean the easier non-wait operation.

    13. Rename "notify-ippget-redirect" (uri) to "redirect-uri" (uri), so
    that it could in principle be used for other operations.

    14. Rename "suggested-ask-again-time-interval" (integer(0:MAX)) to
    "notify-get-interval", to shorten it, and indicate that it is for
    notification, but only events returned by the Get-Notifications operation.

    15. Rename "begin-to-expire-time-interval" (integer(0:MAX)) to
    "ippget-event-time-to-live", to shorten it somewhat, use recognized terms
    for this concept, and indicate that it is for events, but only ippget

    16. Clarify that for Subscriptions that contain Job events, that the
    Subscription Object that has the ippget scheme MUST stay around for the
    "ippget-event-time-to-live" value and so MUST the corresponding Job object,
    so that the Notification Recipient can query the Job after receiving the
    'job-completed' Event Notification. (For the other Delivery Methods, the
    usual Job History mechanism can be used to retain the Job objects after the
    job completion, so that the Notification Recipient can query the Job object
    after receiving the 'job-completed' Event Notification.)

    17. Clarify that the Cancel-Subscriptions operation does not need to
    keep the Subscription object after the request, no matter what kind of
    Delivery Method it contains. Therefore, any events associated with the
    Subscription object MUST NOT be returned by the Get-Notifications operation
    after the Cancel-Subscription operation for that Subscription Object.

    This archive was generated by hypermail 2b29 : Fri Jul 20 2001 - 18:47:55 EDT