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