IPP Mail Archive: IPP> NOT - substantive clarification about

IPP Mail Archive: IPP> NOT - substantive clarification about

IPP> NOT - substantive clarification about order Printer sends Event N otifications

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Jul 16 2001 - 13:23:36 EDT

  • Next message: mjoel@netreon.com: "Re: IPP> NOT - substantive clarification about order Printer sends Event N otifications"

    As Marty and others have pointed out, we need to see if specifying the order
    that a Printer sends separate Event Notifications and Event Notifications
    within a Compound Event Notification will affect current implementations of
    ippget, indp, and mailto.

    Bob, Ira, and I have collaborated on defining the order that the Printer
    sends Event Notifications. We suggest that implementations have two choices
    for ordering that should cover the likely implementation approaches. See
    "Printer Event Sending Algorithm" below.

    ***********************************************************************
    Please review these proposals to see if you agree on including them in the
    next version of the Event Notification spec and the three Delivery Method
    documents.
    The deadline for I-Ds is this Friday, so I'd like to hear by Tuesday PM,
    July 17.
    ***********************************************************************

    General comments:

    1. We need to say something about the ordering of Event Notifications as
    sent by the Printer, both for separate Event Notifications and within
    Compound Event Notifications.

    2. We also need to say that depending on the underlying transport, the order
    received of separate Event Notifications by a Notification Recipient MAY be
    different.

    3. ippget and mailto don't even mention Compound Event Notifications, so we
    need to update the text and refer back to [ipp-ntfy] for all three delivery
    methods for the ordering requirements.

    ************** Beginning of proposed new text *****************
    For the Base Event Notifications spec [ipp-ntfy] section 9 after paragraph 2
    add all of the following text:

    Printer Event Sending Algorithm:

    When a Printer processes multiple pending Events, the Printer MUST send
    Event Notifications in one of the following orders, whether as multiple
    separate Event Notifications or together in a single Compound Event
    Notification:

    a) The Event Notifications are grouped by the Subscription Object from which
    the Event Notifications are generated. Within each such grouping, the Event
    Notifications are in time stamp order, i.e., in order of increasing
    "printer-up-time" attribute value in the Event Notification (see Table 5).
    Between such groupings, the order of Event Notifications is IMPLEMENTATION
    DEPENDENT.
      
    OR

    b) The Event Notifications are in time stamp order (order of increasing
    "printer-up-time" attribute value), even when generated from multiple
    Subscription Objects.

    Note that with either variant a) or variant b) of the Printer Event Sending
    Algorithm, the Printer always sends the Event Notifications generated from a
    given Subscription Object in time stamp order, even when the Printer sends
    intervening Event Notifications generated by other Subscription objects. If
    a Subscribing Client wants to ensure that the Printer sends certain Event
    Notifications in time stamp order, the Subscribing Client must ensure that
    the subscription for the Events are in the same Subscription Object. Even
    so, depending on the underlying transport, the actual order that a
    Notification Recipient receives separate Event Notifications MAY differ from
    the order sent by the Printer.

    IPPGET:

    Make the following changes to the first paragraph in the Get-Notifications
    Response, section 5.2 (I put [] around new text, but deleted old text
    without indication):

    Group 3 through N: Event Notification Attributes

    The Printer responds with one Event Notification Attributes Group per
    matched Event Notification. [The entire response is considered a single
    Compound Event Notification (see [ipp-ntfy]).] The initial matched Event
    Notifications are all un-expired Event Notifications associated with the
    matched Subscription Objects [and MUST follow the ordering requirements for
    Event Notifications within a Compound Event Notification specified for the
    "Printer Event Sending Algorithm" in [ipp-ntfy] section 9].

    If the Notification Recipient has selected the option to wait for additional
    Event Notifications [(the "notify-no-wait" attribute was set to 'false' or
    was omitted)], the Printer {sends} subsequent Event Notifications in the
    response [each time it processes additional Events]. [Each time the Printer
    sends such Event Notifications, their ordering MUST be the ordering
    specified for the "Printer Event Sending Algorithm" in [ipp-ntfy] section
    9.]

    [ Note: If a Notification Recipient performs two consecutive
    Get-Notifications operations, the time stamp of the first Event Notification
    in the second Get-Notifications Response may be less than the time stamp of
    the last Event Notification in the first Get-Notification Response. This
    happens because the Printer sends all unexpired Event Notification according
    to the ordering specified in [ipp-ntfy] and some Event Notifications from
    the first Get-Notifications operation may not have expired by the time the
    second Get-Notifications operation occurs. ]

    INDP:

    In INDP section 8.1 Send-Notifications Request, 2nd paragraph (I put []
    around the new text):

    The Printer composes the information defined for an IPP Notification
    [ipp-ntfy] and sends it using the Send-Notifications operation to the
    Notification Recipient supplied in the Subscription object. [The ordering
    of separate Send-Notifications operations that a Printer sends MUST be the
    ordering specified for the "Printer Event Sending Algorithm" in [ipp-ntfy]
    section 9.]

    In INDP section 8.1.1 Send-Notifications Request (I put [] around the new
    text):

    Group 2 to N: Event Notification Attributes

    In each group 2 to N, each attribute is encoded using the IPP rules for
    encoding attributes [RFC2910] and [the attributes within a group] MAY be
    encoded in any order. [The entire request is considered a single Compound
    Event Notification and MUST follow the ordering requirements for Event
    Notifications within a Compound Event Notification specified for the
    "Printer Event Sending Algorithm" in [ipp-ntfy] section 9.] Note: the
    Get-Jobs response in [RFC2911] acts as a model for encoding multiple groups
    of attributes.

    MAILTO:

    In MAILTO section 6, add the following after the existing 2nd paragraph:

    While the "Printer Event Sending Algorithm" in [ipp-ntfy] section 9
    specifies ordering requirements for Printers when sending separate Event
    Notifications, email messages are not guaranteed to arrive in the order sent
    so that the Notification Recipient may not receive them in the same order.

    In MAILTO section 6 Event Notification Content, right before section 6.1 (I
    put [] around the new text):

    The Event Notification content has two parts, the headers and the message
    body. The headers precede the message body and are separated by a blank line
    (see [RFC 822]).

    [A Printer implementation MAY combine several Event Notifications into a
    single email message body. Such an email message is considered a single
    Compound Event Notification and MUST follow the ordering requirements for
    Event Notifications within a Compound Event Notification specified for the
    "Printer Event Sending Algorithm" in [ipp-ntfy] section 9.]

    ************** End of proposed new text *****************

    Tom



    This archive was generated by hypermail 2b29 : Mon Jul 16 2001 - 13:26:11 EDT