IPP Mail Archive: RE: IPP> ippget Spec Changes [substantive

RE: IPP> ippget Spec Changes [substantive clarification about eve nt order]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Jul 12 2001 - 19:33:12 EDT

  • Next message: Herriot, Robert: "RE: IPP> ippget Spec Changes [substantive clarification about eve nt order]"

    Ira, Bob, and I talked further about the absence of anything about event
    order in the Notification spec (and the delivery specs) about the order that
    the Printer sends events. Issue raised by Marty Joel...

    We'd like to add the following clarification to Section 9 of [ipp-ntfy]
    between the second and third paragraphs:

    When several events occur before the Printer can deliver a corresponding
    Event Notification for the same Subscription object, the Printer MUST
    serialize the Event Notifications in time stamp order, i.e., in order of
    increasing "printer-up-time" attribute value in the Event Notification (see
    Table 5) for delivery for that Subscription object. If the Delivery Method
    allows multiple Event Notifications to be delivered in a single Compound
    Event Notification, then the same serialization ordering requirement applies
    within the Compound Event Notification. The Printer NEED NOT order Event
    Notifications for different Subscription objects. Therefore, client are
    warned not to create separate Subscription objects for the same Notification
    Recipient, if the Notification Recipient can't handle events out of time
    stamp order that are generated from separate Subscription objects.

    OK? Please send comments if you object. Silence will be interpreted as
    agreement.

    We should probably add the following clarification to the ippget Delivery
    Method section 5.2, Get-Notifications Response, before the last two
    paragraphs before Table 2:

    As required in [ipp-ntfy], the Printer MUST serialize the order of Event
    Notifications for the same Subscription object in time stamp order, i.e., in
    order of increasing "printer-up-time" attribute value in the Event
    Notification. Since the input parameter is just the URL, not the
    subscription-id, a single Notification Recipient can be getting events for
    multiple Subscription objects. For example, if your secretary keeps an
    outstanding Get-Notifications request with wait, and you always submit your
    jobs using your secretary's URL in each Per-Job Subscription object, he/she
    will be getting events out of order between Subscription objects. This
    shouldn't be a problem, since any events in the Get-Notifications Response
    for job n will occur in order, followed by any events for job m in order
    (but may be out of order with respect to job n), followed by more events for
    job n in order, etc.

    OK? Please send comments if you object. Silence will be interpreted as
    agreement.

    To help in your review of these suggestions, here is the current semantics
    in [ipp-ntfy] that a Printer uses to send Event Notifications:

    9 Event Notification Content

    This section defines the Event Notification content that the Printer sends
    when an Event occurs.

    When an Event occurs, the Printer MUST find each Subscription object whose
    "notify-events" attribute "matches" the Event. See section 5.3.2.2 for
    details on "matching". For each matched Subscription Object, the Printer
    MUST create an Event Notification with the content and format that the
    Delivery Method Document specifies. The content contains the value of
    attributes specified by the Delivery Method Document. The Printer obtains
    the values immediately after the Event occurs. For example, if the
    "printer-state" attribute changes from 'idle' to 'processing', the Event
    'printer-state-changed' occurs and the Printer puts various attributes into
    the Event Notification, including "printer-up-time" and "printer-state" with
    the values that they have immediately after the Event occurs, i.e., the
    value of "printer-state" is 'processing'.

    <insert new paragraph here>

    If two different Events occur simultaneously, or nearly so (e.g.,
    "printer-up-time" has the same value for both), the Printer MUST create a
    separate Event Notification for each Event, even if the associated
    Subscription Object is the same for both Events. However, the Printer MAY
    combine these distinct Event Notifications into a single Compound Event
    Notification if the Delivery Method supports Compound Event Notifications.
    For example, suppose that two nearly-simultaneously Events represent two
    successive 'printer-state-changed' Events, one from 'idle' to 'processing'
    and another from 'processing' to 'stopped'. These two Events have the same
    name but are different instances of the Event. Then the Printer MUST create
    a separate Event Notification for each Event and SHOULD accurately report
    the "printer-state" of the first Event as 'processing' and the second Event
    as 'stopped'.

    If a Subscription Object contains more than one Subscribed Event, and
    several Events occur in quick succession each matching a different
    Subscribed Event in the Subscription Object, the Printer MUST NOT generate a
    single Event Notification from several of these Events, but MAY combine
    distinct Event Notifications into a single Compound Event Notification if
    the Delivery Method supports Compound Event Notifications.

    After the Printer has created the Event Notification, the Printer delivers
    it via either a:

    Push Delivery Method: The Printer sends the Event Notification shortly after
    an Event occurs. For some Push Delivery Methods, the Notification Recipient
    MUST send a response; for others it MUST NOT send a response.

    Pull Delivery Method: The Printer saves Event Notifications for some
    event-lease time and expects the Notification Recipient to request Event
    Notifications. The Printer returns the Event Notifications in a response to
    such a request.

    OK? Please send comments if you object. Silence will be interpreted as
    agreement.

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Thursday, July 12, 2001 15:04
    To: mjoel@netreon.com
    Cc: ipp@pwg.org
    Subject: RE: IPP> ippget Spec Changes

    Marty,

    I'll make these editorial changes, as I'm editing the document to
    incorporate the comments of our Area Director, Ned Freed. However, one of
    your comments is more than editorial. See my comments below, preceded by
    TH>.

    Tom

    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Wednesday, July 11, 2001 18:27
    To: ipp@pwg.org
    Subject: IPP> ippget Spec Changes

    If any changes are going to be made to the ippget spec, perhaps these typos
    can be fixed:

    In 5.2, the Group 3 through N section, last sentence of the first paragraph
    has "the Printer the subsequent".

    TH> So I've changed the sentence from:

    If the Notification Recipient has selected the option to wait for additional
    Event Notifications, the Printer the subsequent Event Notifications in the
    response are Event Notifications associated with the matched Subscription
    Objects as the corresponding Event occurs.

    to:

    If the Notification Recipient has selected the option to wait for additional
    Event Notifications, the Printer sends subsequent Event Notifications in the
    response as Event Notifications associated with the matched Subscription
    Objects as the corresponding Event occurs.

    TH> OK?

    In the same section, the first sentence of the second paragraph has "one
    Event Notification Attributes Groups" which should be singular.

    TH> Ok.

    That section doesn't say the events must be in any order, but it also
    doesn't say they may be in any order, which would match the detail of the
    other specs.

    TH> Here I think you have stumbled into an issue for all the Delivery
    Methods about the order of delivery of events.

    TH> The Send-Notifications Request in the INDP Delivery Method says the
    following for Groups 2 to N:

    In each group 2 to N, each attribute is encoded using the IPP rules for
    encoding attributes [RFC2910] and may be encoded in any order.

    TH> I think that the "any order" refers to the attributes within a group,
    not the order of the groups, though the antecedent to "may be encoded in any
    order" is ambiguous.

    TH> The Get-Notifications Response in the IPPGET Delivery Method says the
    following for Groups 3 to N in the 4th paragraph:

    Each attribute is encoded using the IPP rules for encoding attributes
    [RFC2910] and may be encoded in any order. Note: the Get-Jobs response in
    [RFC2911] acts as a model for encoding multiple groups of attributes.

    TH> Here it is clear that the "any order" is referring to attributes within
    a group, not the order of groups.

    TH> I talked with Bob Herriot and the assumption was that Printer MUST
    deliver the events in time stamp order and "notify-sequence-number" order
    (which are kept per Subscription object), at least within a single Compound
    Event Notification, such as in IPPGET and INDP. So OK to make at least that
    clarification for the Events in group 2 to N in IPPGET Get-Notifications
    Response and INDP Send-Notifications Request?

    TH> It gets trickier to require that the Printer actually delivery events in
    time stamp order for separate Get-Notifications or separate
    Send-Notifications, because some Printers will deliver events by
    Subscription object and others will deliver events by Event.

    TH> Comments?

    TH> Tom

    Regards,

    Marty Joel



    This archive was generated by hypermail 2b29 : Thu Jul 12 2001 - 19:34:51 EDT