IPP Mail Archive: Re: IPP> NOT - Suggested resolutions to the 27 Issues

Re: IPP> NOT - Suggested resolutions to the 27 Issues

Hugo Parra (HPARRA@novell.com)
Thu, 29 Jul 1999 17:22:57 -0600

We've said that IPP Notification would allow printers to use "general-purpo=
se" Event Notification Services available to them on the network. By not =
supporting straight TCP notification we might be hampering the implementati=
on 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.=20

-Hugo

>>> <kugler@us.ibm.com> 07/28/99 10:19AM >>>
<918c79ab552bd211a2bd00805f15ce850198e57-@x-crt-es-ms1.cp10.es.xerox.c=20
om> wrote:=20
original article:http://www.egroups.com/group/ipp/?start=3D6060=20
> 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,
Notification
> Recipient, Administrator?
>=20
> 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.
>=20

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

-Carl