IPP Mail Archive: RE: IPP> ippget Spec Changes

IPP Mail Archive: RE: IPP> ippget Spec Changes

RE: IPP> ippget Spec Changes

From: mjoel@netreon.com
Date: Mon Jul 16 2001 - 04:43:56 EDT

  • Next message: mjoel@netreon.com: "RE: IPP> ippget Spec Changes [substantive clarification about eve nt order]"

    Hi Tom,

    I've marked my comments to your comments below with MJ>.

    Marty

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/12/2001 03:03:41 PM

    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?
    MJ> Looks good.

    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?

    MJ> When I first implemented ippget, I created lists of ippget event
    objects linked to objects that represented Get-Notifications recipients.
    The main benefit to this approach was that when Get-Notifications was
    received, I only had to find the object having the given
    notify-recipient-uri, and there were all its events. If that recipient had
    no events, it would quickly fail to find the given notify-recipient-uri. I
    didn't need to traverse all the subscriptions. In this approach, the end
    result was that events for a recipient were ordered chronologically,
    regardless of which subscription caused them, although I was actually
    storing them in reverse order, since it is fastest to insert a node at the
    head of a linked list, and I didn't think order mattered. Having immediate
    access to the last event added to the list also let me quicly determine if
    all events in the list had expired.

    MJ> On closer inspection of the ippget spec, I came to believe that when a
    subscription is deleted, any events caused by that subscription should
    disappear. Is my interpretation correct?

    MJ> Because of my interpretation that events should expire when their
    subscription expires, I then regretfully decided to change my code and
    attach the linked lists of events to the subscription objects. The down
    side is that the search takes longer, and if I need to return the events
    chronologically, it will be difficult if a recipient has multiple
    subscriptions with events. I'm also currently returning them in reverse
    chronological order, since I'm inserting new events to the head of the list
    for speed, and for the expiration check I mentioned above. I'll definitely
    change the ordering if they must be returned in chronological order.

    MJ> It's been brought to my attention through this mailing list that there
    are already ippget implementations. How will imposing new ordering rules
    affect them?

    TH> Tom

    Regards,

    Marty Joel



    This archive was generated by hypermail 2b29 : Mon Jul 16 2001 - 04:46:05 EDT