IPP Mail Archive: RE: IPP> NOT - 6 Notification ISSUES [Even

RE: IPP> NOT - 6 Notification ISSUES [Event ordering]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Jul 18 2001 - 12:48:39 EDT

  • Next message: Hastings, Tom N: "IPP> NOT - Agreements on the ISSUES in the IPPGET spec and IPP base sp ec"

    See my replies preceded by TH>

    Marty wrote:

       1B. Base Notification Spec: Clarify that the Printer MUST send Event
       Notifications for any given Subscription Object in time stamp order,
       but MAY interleave Event Notifications from other Subscription
       Objects

    MJ> I think that 1B means that all events are ordered, regardless of what
    subscription they came from, at least that's what "interleave" implies.

    TH> But the interleave is a MAY, not a MUST, for the Printer.

    That would differ from the original proposal that they be sorted
    chronologically within subscription groups. On looking below at the
    proposed text for this, it's saying that events can either be sorted
    chronologically regardless of what subscription caused them, or that they
    can be sorted chronologically in groups by subscription. You might as well
    say that they can either be sorted or not, since
    sorted-within-subscription-groups requires as much work at the client as
    sorting unordered events.

    TH> Simple Notification Recipients are only dealing with one Subscription
    object, so that advantage of having the Printer sort by time-stamp for the
    events for a Subscription object, is that the simple Notification Recipients
    would get all events ordered and wouldn't have to sort. Only complex
    Notification Recipients that are getting notifications from multiple
    Subscription objects would have to sort with 1B.

    MJ> 1C. The 3rd option is that events be ordered, which I think makes more
    sense than 1B, although I'd prefer 1A. 1B puts sorting onto the client,
    and if you're going to do that anyway, you might as well go with 1A.

    TH> Requiring strict ordering without allowing interleaving is a strict
    impossibility. In the two Subscription object in the proposed text, the
    Printer would have to wait until the job completes before sending the
    Printer events for another Subscription object, but the Printer jammed so
    the job will never complete, until the Printer is unjammed.



    This archive was generated by hypermail 2b29 : Wed Jul 18 2001 - 12:52:24 EDT