IPP> NOT - Suggested resolutions to the 27 Issues

IPP> NOT - Suggested resolutions to the 27 Issues

IPP> NOT - Suggested resolutions to the 27 Issues

Hugo Parra HPARRA at novell.com
Thu Jul 29 19:22:57 EDT 1999

We've said that IPP Notification would allow printers to use "general-purpose" Event Notification Services available to them on the network.  By not supporting straight TCP notification we might be hampering the implementation of this requirement.  I don't understand why supporting the suggested three application-level protocols should preclude us from allowing straight TCP subscriptions that can be easily routed through network notification services. 


>>> <kugler at us.ibm.com> 07/28/99 10:19AM >>>
 <918c79ab552bd211a2bd00805f15ce850198e57- at x-crt-es-ms1.cp10.es.xerox.c 
om> wrote: 
original article:http://www.egroups.com/group/ipp/?start=6060 
> ISSUE 3:  For TCP/IP delivery, what about leaving the connection open
> versus having to reestablish a connection for each event?  Who
> specifies: client in subscription, Printer implementation,
> Recipient, Administrator?
> XR> We believe that we should use existing application level protocols
> for delivering notifications:  HTTP, SMTP, and SNMP.  These layer on
> TCP/IP, TCP/IP, and UDP, respectively.  We can write a simple MIB as a
> separate RFC that has only the SNMP trap bindings to the IPP
> notification content.

Good.  HTTP/1.1 connections are persistent by default. SMTP can deliver
multiple messages per connection.  SNMP, of course, doesn't use


More information about the Ipp mailing list