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