Though the language of IPP notifications is directed towards the printer
application specifically, its relevance to internet document distribution
and confirmation of receipt should be self evident.
##################
>From: "Larry Masinter" <masinter@parc.xerox.com>
>To: <ipp@pwg.org>
>Subject: IPP> comments on "requirements for IPP notifications"
>Date: Tue, 29 Jun 1999 01:07:46 PDT
>X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
>Importance: Normal
>Sender: owner-ipp@pwg.org
>
>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.
>
>- 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
Fax 314.918.9015
INTERNET Mail & IFAX : rshockey@ix.netcom.com
eFAX 815.333.1237
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<