IFX Mail Archive: IFX> Fwd: IPP> comments on "requirements for IPP notifications"

IFX Mail Archive: IFX> Fwd: IPP> comments on "requirements for IPP notifications"

IFX> Fwd: IPP> comments on "requirements for IPP notifications"

Richard Shockey (rshockey@ix.netcom.com)
Tue, 29 Jun 1999 16:49:01 -0500

This message is also forwarded from the main IPP list.

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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<