Hi Tom, et al,
The whole purpose of defining an event order seems to be to make coding
easy for the client implementors, at the expense of the server
implementors. I'm wearing both hats, so it's all the same to me. I
suppose that theoretically there could be more client than server
implementations, which might be the only rational for all this. As I see
it, for implementing a client, it's as difficult to handle the events
grouped by subscription as it would be if the event order was random. For
that reason, I propose that algorithm option (a) below be discarded.
If I was to decide between forcing the events to be in chronological order
(option (b) below) or that they be random (implementation-specific), I
would choose random. I think it is more important that the server be able
to process requests as quickly as possible, than to make it easy for the
client impementors to code. If sorting is to be done, for performance
reasons it makes more sense to me that it be done at the client.
For these reasons, and for the fact that existing implementations may be
ordering events differently than the proposals below, I propose that the
specifications be changed to state that the event order is determined by
the implementation, and that if the client needs them chronological it
should sort them.
Regards,
Marty Joel
"Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 07/16/2001
10:23:36 AM
Sent by: owner-ipp@pwg.org
To: ipp@pwg.org
cc: mjoel@netreon.com
Subject: IPP> NOT - substantive clarification about order Printer sends
Event N otifications
As Marty and others have pointed out, we need to see if specifying the
order
that a Printer sends separate Event Notifications and Event Notifications
within a Compound Event Notification will affect current implementations of
ippget, indp, and mailto.
Bob, Ira, and I have collaborated on defining the order that the Printer
sends Event Notifications. We suggest that implementations have two
choices
for ordering that should cover the likely implementation approaches. See
"Printer Event Sending Algorithm" below.
***********************************************************************
Please review these proposals to see if you agree on including them in the
next version of the Event Notification spec and the three Delivery Method
documents.
The deadline for I-Ds is this Friday, so I'd like to hear by Tuesday PM,
July 17.
***********************************************************************
General comments:
1. We need to say something about the ordering of Event Notifications as
sent by the Printer, both for separate Event Notifications and within
Compound Event Notifications.
2. We also need to say that depending on the underlying transport, the
order
received of separate Event Notifications by a Notification Recipient MAY be
different.
3. ippget and mailto don't even mention Compound Event Notifications, so we
need to update the text and refer back to [ipp-ntfy] for all three delivery
methods for the ordering requirements.
************** Beginning of proposed new text *****************
For the Base Event Notifications spec [ipp-ntfy] section 9 after paragraph
2
add all of the following text:
Printer Event Sending Algorithm:
When a Printer processes multiple pending Events, the Printer MUST send
Event Notifications in one of the following orders, whether as multiple
separate Event Notifications or together in a single Compound Event
Notification:
a) The Event Notifications are grouped by the Subscription Object from
which
the Event Notifications are generated. Within each such grouping, 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).
Between such groupings, the order of Event Notifications is IMPLEMENTATION
DEPENDENT.
OR
b) The Event Notifications are in time stamp order (order of increasing
"printer-up-time" attribute value), even when generated from multiple
Subscription Objects.
Note that with either variant a) or variant b) of the Printer Event Sending
Algorithm, the Printer always sends the Event Notifications generated from
a
given Subscription Object in time stamp order, even when the Printer sends
intervening Event Notifications generated by other Subscription objects.
If
a Subscribing Client wants to ensure that the Printer sends certain Event
Notifications in time stamp order, the Subscribing Client must ensure that
the subscription for the Events are in the same Subscription Object. Even
so, depending on the underlying transport, the actual order that a
Notification Recipient receives separate Event Notifications MAY differ
from
the order sent by the Printer.
IPPGET:
Make the following changes to the first paragraph in the Get-Notifications
Response, section 5.2 (I put [] around new text, but deleted old text
without indication):
Group 3 through N: Event Notification Attributes
The Printer responds with one Event Notification Attributes Group per
matched Event Notification. [The entire response is considered a single
Compound Event Notification (see [ipp-ntfy]).] The initial matched Event
Notifications are all un-expired Event Notifications associated with the
matched Subscription Objects [and MUST follow the ordering requirements for
Event Notifications within a Compound Event Notification specified for the
"Printer Event Sending Algorithm" in [ipp-ntfy] section 9].
If the Notification Recipient has selected the option to wait for
additional
Event Notifications [(the "notify-no-wait" attribute was set to 'false' or
was omitted)], the Printer {sends} subsequent Event Notifications in the
response [each time it processes additional Events]. [Each time the
Printer
sends such Event Notifications, their ordering MUST be the ordering
specified for the "Printer Event Sending Algorithm" in [ipp-ntfy] section
9.]
[ Note: If a Notification Recipient performs two consecutive
Get-Notifications operations, the time stamp of the first Event
Notification
in the second Get-Notifications Response may be less than the time stamp of
the last Event Notification in the first Get-Notification Response. This
happens because the Printer sends all unexpired Event Notification
according
to the ordering specified in [ipp-ntfy] and some Event Notifications from
the first Get-Notifications operation may not have expired by the time the
second Get-Notifications operation occurs. ]
INDP:
In INDP section 8.1 Send-Notifications Request, 2nd paragraph (I put []
around the new text):
The Printer composes the information defined for an IPP Notification
[ipp-ntfy] and sends it using the Send-Notifications operation to the
Notification Recipient supplied in the Subscription object. [The ordering
of separate Send-Notifications operations that a Printer sends MUST be the
ordering specified for the "Printer Event Sending Algorithm" in [ipp-ntfy]
section 9.]
In INDP section 8.1.1 Send-Notifications Request (I put [] around the new
text):
Group 2 to N: Event Notification Attributes
In each group 2 to N, each attribute is encoded using the IPP rules for
encoding attributes [RFC2910] and [the attributes within a group] MAY be
encoded in any order. [The entire request is considered a single Compound
Event Notification and MUST follow the ordering requirements for Event
Notifications within a Compound Event Notification specified for the
"Printer Event Sending Algorithm" in [ipp-ntfy] section 9.] Note: the
Get-Jobs response in [RFC2911] acts as a model for encoding multiple groups
of attributes.
MAILTO:
In MAILTO section 6, add the following after the existing 2nd paragraph:
While the "Printer Event Sending Algorithm" in [ipp-ntfy] section 9
specifies ordering requirements for Printers when sending separate Event
Notifications, email messages are not guaranteed to arrive in the order
sent
so that the Notification Recipient may not receive them in the same order.
In MAILTO section 6 Event Notification Content, right before section 6.1 (I
put [] around the new text):
The Event Notification content has two parts, the headers and the message
body. The headers precede the message body and are separated by a blank
line
(see [RFC 822]).
[A Printer implementation MAY combine several Event Notifications into a
single email message body. Such an email message is considered a single
Compound Event Notification and MUST follow the ordering requirements for
Event Notifications within a Compound Event Notification specified for the
"Printer Event Sending Algorithm" in [ipp-ntfy] section 9.]
************** End of proposed new text *****************
Tom
This archive was generated by hypermail 2b29 : Mon Jul 16 2001 - 14:27:35 EDT