IPP> NOT - List of Notification Delivery Method alternatives

IPP> NOT - List of Notification Delivery Method alternatives

IPP> NOT - List of Notification Delivery Method alternatives

harryl at us.ibm.com harryl at us.ibm.com
Wed Oct 27 11:11:09 EDT 1999



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







More information about the Ipp mailing list