A good set of comments. We processed them on our IPP telecon today.
Other members on the DL are welcome to comment as well as usual.
We want to clarify that the "must" in the IPP Notification Requirements is
what the IPP Notification Specification must include. However, such "musts
don't indicate whether an implementation MUST support these features or not.
Deciding what is REQUIRED for conformance and what is OPTIONAL is part of
developing the specification.
See replies listed under WG>
Tom
-----Original Message-----
From: Larry Masinter [mailto:masinter@parc.xerox.com]
Sent: Tuesday, June 29, 1999 01:08
To: ipp@pwg.org
Subject: IPP> comments on "requirements for IPP notifications"
I don't know if it is this document or some other one, but I think
it would be really useful for the group to try to lay out what the
ordinary expectations are for "notification" in the context of IPP,
and to do so independent of the mechanisms you might use to meet
those expectations.
WG> We agree and will add the suggested material to this IPP Notification
Requirements document, independent of the mechanisms we define in the IPP
Notification Specification. Also there may be several mechanisms defined in
the notification specification which meet different levels of the
requirements in the requirements document.
- 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.
WG> We agree that we need some agreement and statement. Something like:
"Immediate Notification means on the order of several minutes subject to
network latency."
"Queued Notification is store and forward and so the time is much less
critical, on the order of email latency."
See our definitions of Immediate Notification and Queued Notification in
sections 2.18 and 2.19. We'll add the "several minutes" to section 2.18.
WG> We guessed that you weren't suggesting that the subscriber indicate
such a latency limit, after which the notification delivery could be
dropped. Correct?
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.
WG> Same.
- 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.
WG> We agree that reliable delivery is both an OPTIONAL feature for an IPP
Printer to support and is something that a notification subscriber can
request or not. We tried to capture the reliability requirement in section
3, item # 14. After discussion we agreed to separate item 14 into a simple
14 and a new item:
14. There must be a mechanism to indicate the quality of service for
delivery of event reports, i.e., the reliability of the delivery.
15. There must be the concept that the Administrator has the policy option
that certain identified notification subscriptions are so important that
printing stops, if the event reports are not acknowledged by the
notification recipient. For example, an accounting application. On the
other hand, the Administrator may have the policy that printing is more
important than accounting, so that printing continues even when such
notification event receipt is not acknowledged. Whether this policy can be
established by the administrator using IPP or is outside IPP is TBD.
- 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.
WG> We think that the delivery method (URL scheme) will indicate whether
acknowledgement is part of delivery or not. Possibly with a parameter to
the URL. In either case, the client can query to see what methods are
supported. Again, we are not trying to say in the requirements document
what will be REQUIRED by an implementation to support. Such decisions seem
ok to defer until we have the spec.
- 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.
WG> We agree to add a requirement something like:
There must be a way for the notification recipient to detect duplicate
notification event reports and missing event reports.
We'll probably do that with a sequence number on a per-subscription basis.
- 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.
WG> We agree. We should attempt to write the Security Considerations
section for the spec now and put it into the Requirements document.
- 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.
WG> We agree. So the interface to the subscriber and to the event report
recipient needs to consider backwards compatibility. We also want to
stream-line the subscription mechanism by not having a lot of parameters.
- 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?
WG> Section 2.22 and 2.23 define Human Consumable Notification and Machine
Consumable Notification. Both will be defined in the spec.
An issue for the spec is which to require when using the email delivery
method or to require the Printer to always send both. Also whether the
subscriber should have any say in which form to send, except the natural
language for the Human Consumable Notification.
- 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?
WG> As in all IPP requests, the client specifies the natural language
desired. The Printer MUST either use that language or fallback to its
configured natural language.
- 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?
WG> An interesting question! The number of recipients associated with a
subscription should have a minimum number required for support.
ISSUE: We did not agree on such a number. This needs more discussion. If
the maximum number required is 1, then clients may not both supporting more
than one recipient.
- 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_?
WG> Job completion events depend on the size of jobs and the throughput of
the Printer.
WG> Page completion events are much more frequent. Events as often as page
completion will be defined. However, a page completion event is unlikely to
be a REQUIRED event for support by an implementation.
Larry