Hi Tom,
Before wording is chosen, we should probably agree on the ordering.
Specifically, I'm concerned how this change will affect any existing
implementations.
Regards,
Marty
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/12/2001 04:33:12 PM
To: ipp@pwg.org
cc: mjoel@netreon.com
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 : Mon Jul 16 2001 - 04:50:57 EDT