Tom, this summary is excellent and very helpful!
I would like to make one observation regarding (2) MIME multi-part
responses.
This method will work the way you've described it but I believe it can also
simplify to allow asynchronous responses to ANY IPP operation and that
"notify-events" and "notify-recipients" can be optional. This would suggest
the upstream IPP entity as default recipient and a pragmatic, fixed set of
event definitions... analogous to the Printer MIB "top-25".
Harry Lewis
IBM Printing Systems
harryl at us.ibm.com
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 10/26/99 11:23:13 PM
To: ipp <ipp at pwg.org>
cc:
Subject: IPP> NOT - List of Notification Delivery Method alternatives
Subj: List of Notification Delivery Method alternatives
From: Tom Hastings
Date: 10/26/99
File: IPP-Notifiication-delivery-methods.doc
This paper is an attempt to capture the list of various proposals for
notification delivery methods (schemes) that have appeared in
contributions and/or were mentioned in the brainstorming telecon on
Wednesday, 10/20/99. The intent is to use this as starting point at the
IPP WG meeting, 10/27/99. One of the principles of brainstorming is
that we list all suggested alternatives. If someone wants to change one
of the proposals, we add the changed proposal as a new proposal. After
we complete the list we go through them all listing the PROs and CONs of
each. Often when such a process is finished, the winner emerges
clearly.
1.Server-directed Client Polling - The client requests notification in
the Job Creation request as in [ipp-not] using "notify-events" and
"notify-recipient". The server returns a new operation attribute to
the client telling the client when next to poll using Get-Job-
Attributes and at which URL. See Harry Lewis's proposal:
Simple_IPP_Notification.pdf.
2.Server push using MIME-multi-part responses - The client requests
notification as an addition to the Job Creation request as in [ipp-
not] using "notify-events" and "notify-recipient". The server
returns multiple responses to the Job Creation request, each as
separate multiple MIME-multi-part responses on the same open channel,
one for each requested event as it occurs. In other words, one Job
Creation request has multiple responses over time. See Harry Lewis's
proposal: Simple_IPP_Notification.pdf.
3.In-band Get-Notifications operation - The client requests
notification in the Job Creation request as in [ipp-not] using
"notify-events" and "notify-recipient". Any time thereafter, the
client requests notifications using a new Get-Notifications operation
which requests delivery of any subsequent events that occur using the
current "notify-events" operation attribute. The server keeps the
channel open and returns multiple MIME-multi-part responses on the
same open channel, one for each requested event as it occurs. In
other words, one Get-Notifications request has multiple responses
over an indefinite period of time.
4.In-band Get-Notifications without Subscription objects - Same as 3,
except that the client supplies the "notify-events" operation
attribute in the Get-Notifications operation, instead of the Job
Creation request. This is the only alternative in which there isn't
a Subscription object.
5.In-band Get-Notifications with queued events - Same as 3, except that
events are queued from the time of the creation of the subscription
in the Job Creation request. Therefore, the Get-Notifications gets
each event whether it happened before or after the Get-Notifications
request.
6.In-band Get-Notification with queued events but only one event per
Get-Notification request - Same as 5, except instead of returning
multiple responses, one for each event, only one event is returned in
a response, and the client must perform another Get-Notification to
get the next request.
7.HTTP-Based IPP Notification Delivery Protocol - Subscriptions are
created as in the [ipp-not]. The "notify-recipients" URL has a new
scheme with a new default port number assigned: ipp-ntfy. The IPP
Printer does a new operation Send-Notifications operation to the
Notification Recipient using a new MIME media type: "application/ipp-
ntfy" with the same encoding as "application/ipp". The Notification
Recipient returns an "application/ipp-ntfy" response. See the Hugo's
proposal: <draft-ietf-ipp-not-http-delivery-00.txt>.
8.HTTP-Based IPP Notification Delivery - Same as 7, except that the
existing "application/ipp" MIME type is used in the request and the
response, since the encoding is the same.
9.SNMP traps over UDP - Subscriptions are created as in the [ipp-not].
The SNMP traps for the Printer MIB and Job Monitoring MIB are used to
deliver the notification using SNMP. See Ira's and my proposal:
<draft-ietf-ipp-server-mib-00.txt> (.pdf).
10. UPD delivery as Send-Notifications - Subscriptions are created as
in the [ipp-not]. Notifications are delivered using a new IPP Send-
Notification request that is encoded as an 'application/ipp' MIME
type and sent as a raw UDP packet. The Notification Recipient
returns an 'application/ipp' MIME type response as a raw UDP packet.
11. TCP delivery as Send-Notifications - Same as 10, except TCP is used
instead of UDP.
12. Email - Subscriptions are created as in the [ipp-not]. The
notifications are delivered by email.
13. Instant messaging - Subscriptions are created as in the [ipp-not].
The "notify-recipient" specifies the Instant Messaging service. This
delivery method is an example where a notification service is used by
the client transparently to the IPP Printer because the IPP Printer
sends the notifications to the Notification Recipient which just
happens to be the Instant Messaging service. The ICQ number
identifying the Ultimate Recipient is passed as a parameter in the
URL specified by the client.
14. Paging - Same as 13, except that the notification service is a
Paging System. The phone number of the Ultimate Recipient is sent as
a parameter in the URL specified by the client.
15. Configured operator paging - There is no subscription object
created. Only a new "operator-paging-number (text)" Printer
Description attribute is added that the System Administrator can
configure. Only Printer events that stop the device are sent by
calling the indicated number.
16. Configured operator delivery - Same as 15, except that the new
Printer Description attribute is "operator-recipients (url)" so that
any delivery method may be used that has text delivery.
17. Configured operator delivery with event filter - Same as 16, with
the addition of an "operator-events (1setOf type2 keyword)" Printer
attribute as well, so that the event can be configured.
18. Configured operator delivery with reasons filter - Same as 17, with
the addition of an "operator-printer-state-reasons (1setOf type2
keyword)" Printer attribute as well, so that specific printer state
reasons can be specified to cause notifications to be sent.
19. Alternatives 1, 2, and 3 with all Subscriptions - Same as 1, 2, and
3 with the addition that the client can use Create-Printer-
Subscription and Create-Job-Subscription operations to request the
notifications, as well as Job Creation requests. I didn't want to
clutter up the presentation with these variants.
20. Your proposal goes here...