ISSUE 5 - Can we get rid of most of these notification methods? Having a
large number means that we don't have much interoperability.
The current list of methods are:
Standard uriScheme values are:
'mailto': a 'multipart/report' [RFC1892] message is sent via email
to the specified email address. It MUST consist of both a "text/plain" part
for display to a user and an 'application/ipp' part which is an event report
that a program can process (see Section 5). This delivery method ignores
the supplied values of the "notify-events" attribute and implies the
'job-completed' event (new state is 'completed', 'aborted', or 'canceled').
The notification recipient does not acknowledge receipt of the mail message.
'http': an IPP event report is sent using an HTTP POST to the
indicated URL.
ISSUE 2 - Should we make the 'http' notification method (using POST)
REQUIRED, instead of 'ipp-tcp-notify' and 'ipp-udp-notify'? Then we don't
need to register anything for the two REQUIRED methods.
'ipp-tcp-notify': (REQUIRED) an IPP event report is sent via a
TCP/IP socket that is opened by the Printer object on the IP address
specified in the URI using the specified port using the "host:port" HTTP
convention. For example:
ipp-tcp-notify://foo.com:6000
If the port is omitted, the default port is TBD (see
Registration of ipp-tcp-notify scheme for use with IPP). The
"application/ipp" event report content format is used for this method (see
Section 5).
The event recipient does not respond or acknowledge the
event report.
'snmpv1-notify': an event report is sent as an SNMPv1 trap to the
host specified as the address in the URI. The notification recipient does
not acknowledge receipt of the notification event report (trap).
'snmpv2-notify': an event report is sent as an SNMPv2 inform to the
host specified as the address in the URI. The notification recipient does
acknowledge receipt of the notification event report (inform).
'snmpv3-notify': an event report is sent as an SNMPv3 inform to the
host specified as the address in the URI. The notification recipient does
acknowledge receipt of the notification event report (inform).
ISSUE 3 - Is SNMP support even necessary?
'ipp-udp-notify': (REQUIRED) an IPP event report is sent via a UDP
datagram that is opened by the Printer object on the IP address specified in
the URI using the specified port using the "host:port" HTTP convention. For
example:
ipp-udp-notify://bar.com:6000
If the port is omitted, the default port is TBD (see
Registration of ipp-udp-notify scheme for use with IPP). The UDP datagram
contains the "application/ipp" event report content format (see Section 5).
The notification recipient does not acknowledge receipt of the notification
event report.
'ndps-notify': an IPP event report is sent via NDPS notification
mechanism. See ???.
ISSUE 4 - Need reference to NDPS documentation. Also need
more description here, such as which end opens, does the recipient
acknowledge, and any salient information about the transport.
'sense-notify': an event report is sent as a SENSE UDP datagram
[sense] that is opened by the Printer object or notification service on the
IP address specified in the URI using the specified port using the
"host:port" HTTP convention. The notification recipient does acknowledge
receipt of the notification event report.