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

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

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

From: Herriot, Robert (Robert.Herriot@pahv.xerox.com)
Date: Thu Jul 12 2001 - 21:38:48 EDT

  • Next message: McDonald, Ira: "RE: IPP> MED - Proposed final ABNF for Media Size Self Describing Names"

    I agree with your ideas, but disagree with some of the wording. In
    particular, I disagree with the statement about the order in which the
    Printer must keep Event Notifications. The internal ordering within the
    Printer is an implementation choice. The real issue is the order on the
    wire, e.g. what is in GetNotitifications. I have some suggested wording
    below. I haven't tried to address the issue of ordering between separation
    operations of sending Event Notifications.

    I also have more neutral language for the client admonition.

    Here is my wording.

    When a Printer sends multiple Event Notifications in a single Compound Event
    Notification, Compound Event Notification MUST contain the Event
    Notifications in one of the following orders.

    a) The Event Notifications are grouped by the Subscription Object that
    generated the Event Notification. The order of these groups in the Compound
    Event Notification is implementation dependent. For Event Notifications
    generated by each Subscription Object group, 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).

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

    If a client wants to ensure that the Printer send certain Event
    Notifications in time stamp order, it must ensure that the subscription for
    the Events are in the same Subscription Object

    -----Original Message-----
    From: Hastings, Tom N
    To: ipp@pwg.org
    Cc: mjoel@netreon.com
    Sent: 07/12/2001 4:33 PM
    Subject: 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 - 21:40:46 EDT