- latency (how long does it take to get there)
For example, a notification that "the printer is out of paper" is
useful if it is delivered within minutes and not very useful
if it isn't delivered until hours later.
I think that bounds the "requirements" for latency of notification
of some kind of error conditions; probably the same thing holds
for "job complete", too.
- reliability (can notifications get lost)
It's probably hard to be quantitative about the reliability requirement
for IPP notification, but I'd say that while reliable delivery is desirable,
it isn't mandatory, especially since some IPP servers won't support
notification, so clients can't expect to be notified.
- retransmission (if they don't get there, are they sent later)
> TH> We have recently agreed that the subscriber can specify a Quality
> of Service which indicates, among other things, whether to retry or
> not, if not acknowledge is received. Also whether or not the
> Notification Event Recipient is going to acknowledge receipt of Event Reports.
I think that allowing a subscriber to **specify** a Quality of Service
will cause you more pain than gain. You're trying to avoid being
specific about what the actual requirements are, to the point where
you are either forcing all servers to implement more than they need
(all possible levels of Quality of Service) or else the "parameter"
is meaningless: the server implements what it wants and the subscriber
puts up with it.
You can't actually avoid facing this issue by sticking in a parameter.
- duplicate suppression (are they guaranteed only to be sent once)
I believe that for the most part that there is no absolute constraint
not to send duplicate notices, either for error conditions or for
completion notifications. I don't know about the rest. But you should
say what general expectations should be.
- authentication, privacy, traffic (security requirements).
You need to specify the requirements for security, identify
what the security threats might be, and *then* choose
transports that give you the appropriate level of security.
- interoperability (what other notification mechanisms do
they need to work with)
If you need to interoperate with other existing notification
mechanisms, then you need to characterize their model of
operations.
- extensibility (do new devices with new notification requirements
interoperate with old clients that don't need/want new
notifications?)
Eventually, notification capabilities will increase; new kinds of
notifications will occur, with new parameters, values, status
codes, etc. What are the requirements for extensibility? What
notification capabilities aren't there now that you might want
to add later, and how will old clients deal with them? You don't
really want to have to negotiate every last detail of the protocol
every time -- it's too inefficient.
- richness of notification content (are notifications simple
text messages)
What is the range of data that you _expect_ to be _useful_ in
a notification. You might have a protocol that's more flexible
than you need, but what are the general expectations?
- internationalization (if they contain human languages, how is
> the language determined)
What are the general expectations for language negotiation?
What is the expectation for variability?
- breadth (how many individuals, recipients can be established to be
notified of a particular event?)
What are the general expectations here? Again, you can specify
something that's more general, but what do you _need_ to be
practical and successful?
- frequency (how often do notifications occur)
This is part of the context against which you need to evaluate notification
mechanisms. Are you going to allow notification-per-page? Why? How
often are jobs submitted? How frequently are notifications sent?
Hourly? Daily? Every 10 microseconds? What's _expected_?
Larry