LIST OR PRO REQUIREMENTS 1 IF YOU CAN GET

CENDANT – INTELLIGENT CUSTOMER INTERACTION TECHNICAL REQUIREMENTS
PREFACE NORTH AMERICAN NUMBERING COUNCIL (NANC) FUNCTIONAL REQUIREMENTS SPECIFICATION
DEPARTMENT OF EDUCATION REQUIREMENTS FOR ADMISSION INTO STUDENT

PROJECT CLOSEOUT & FINAL PAYMENT REQUIREMENTS CHECKLIST
THE LISTING RULES’ REQUIREMENTS FOR REVERSE TAKEOVERS OF
1 PROPOSED REQUIREMENTSTRAINING PLAN FOR DM IN CRITICAL CARE

Notification delivery method requirements

List or PRO requirements:

If you can get to the Printer, e.g., through the firewall, then you can get notification.
Don't have to keep open a HTTP connection for every pending job.
Only needs one connection for a print job operation; don't have to open a new channel.
Only keep one HTTP channel open for ALL notifications for one Notification Recipient.
Don't miss events, if the client does the Get-Notifications before submitting jobs.
Works for Per-Job and Per-Printer subscriptions.
Same owner from different workstations can get notifications from different subscriptions.
Subscription object is temporary for the life of the Get-Notification operation and its responses. Clear up when client disconnects
No multiple responses, so can get through any web infrastructure.
HTTP channel not tied up between events.
Can be used with page level notification.
Returns notification. Notification Recipient can cancel when not the subscription owner.
Anyone can be the notification recipient, not just the subscriber.
Events can be batched (also across subscriptions) into one notification message.
No connection overhead.
Builds on Printer and Job MIBs.
SNMP v1 over UDP transport is ubiquitous and can use existing infrastructures (also for management).
Reliable.
Goes through firewalls.
Proven in shipping products.
Can be made without attachments, which is not supported by all email systems.
Several IM services in use today.
Faster than email.
UI pop-up messages available.
Some IM service store messages if they cannot be delivered immediately.
More common than IM.
Notification Recipient does not need Internet connection.
Recipients likely to keep pager with them at all times.
Dead simple to implement.
More flexibility, will allow Per-Job and Per-Printer subscriptions.

List of CONs:

Only works for Job Creation operations.
Printer can't reliably tell when an event will occur, i.e., when job will start or when job will complete.
Won't work for unanticipated events like jams.
More network traffic polling than with other methods.
Need to keep an HTTP connection open for every pending job that wants events.
Only works for Job Creation operations for Per-Job subscriptions. Doesn't work for Per-Printer subscriptions.
Can multiple-responses get through CGI and other web servers?
Get all notifications delivered to one place.
Forces server to relay inband notification.
May miss events between the Job Creation and the Get-Notification request.
Notification Recipient has to keep track of the subscription ids in order.
Uses an operation that is OPTIONAL for notification, instead of one that is REQUIRED.
One channel open for each active job.
Queuing is harder to implement, especially for low end implementations.
Queue can build up if notifications not picked up.
Queue can build up if notifications not picked up.
Can result in many operations to be executed.
Not useful for page level notifications.
Requires that the Notification recipient is an HTTP server.
Firewalls may not let this through.
Needs a new format (MIME-type) and a new default port.
End user workstation may not have SNMP implemented.
End user workstation may not have SNMP implemented.
UDP may be unreliable over a wider area.
Limited content length.
SNMP v3 not widely deployed.
We may need to add congestion control. Discouraged by IETF AD.
Users likely to want other events than page level events, via other delivery methods, so requires multiple subscriptions which may not be supported.
Needs special IPP notification listener code.
Need retry counter which isn't in our current Notification model.
High spam risk.
Store-and-forward may slow down delivery time.
No common standard for IM yet. Need to check how private IMs use URLs today.
May require new URL scheme.
Limited to Human Consumable notifications.
Special port needs to be enabled for traffic. May not be allowed over firewalls.
Have to check which URL scheme to use. Can IFAX scheme be used?
Different model for how to make subscription. Poor man's version. Can conflict with other ways to subscribe.
We can already do this with regular subscriptions.
No common standard on how to introduce messages into the paging service, though some mail services provide an interface.
Would require adding filtering by the Notification Source on state reasons to be usable, because Notification Recipient can't.

10A NCAC 09 1723 TRANSPORTATION REQUIREMENTS TO ASSURE THE
10A NCAC 13D 3031 ADDITIONAL REQUIREMENTS FOR SPINAL CORD
10A NCAC 13F 0311 OTHER REQUIREMENTS (A) THE BUILDING

Tags: requirements