IPP> NOT - Suggested resolutions to the 27 Issues [HTTP notif ication delivery method(s)]

IPP> NOT - Suggested resolutions to the 27 Issues [HTTP notif ication delivery method(s)]

IPP> NOT - Suggested resolutions to the 27 Issues [HTTP notif ication delivery method(s)]

Hastings, Tom N hastings at cp10.es.xerox.com
Wed Jul 28 15:46:14 EDT 1999


In our IPP telecon today, we did recognize that there are two possible HTTP
notification delivery methods, not just one:

  1. Where the TCP/IP connection opened by the client, stays open after the
IPP operation response is returned.  Then the IPP Printer sends
notifications as additional responses to the client.  In this case, the
Notification Recipient is the requesting client.  

  2. Where the IPP Printer acts as an HTTP client that opens a TCP/IP
channel to the Notification Recipient specified in the "notify-recipients
(1setOf uri)" operation attribute and the Notification Recipient acts as an
HTTP server.  The IPP Printer opens the channel when it has a notification
to deliver.

There was support for making method 1 REQUIRED, because it is so easy to
implement.

With either method, we need to define which end can close the connect and
what happens when the connection is closed in order to send more
notifications.  For example, the URL in the "notify-recipients" for method 1
is not needed, only the scheme.  However, perhaps the URL is still needed
for method 1 in case the connection is closed, so that the IPP Printer could
re-open the connection when it needs to deliver a notification.

Tom 

-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Wednesday, July 28, 1999 09:20
To: ipp at pwg.org
Subject: Re: IPP> NOT - Suggested resolutions to the 27 Issues


 <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,
Notification
> 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
connections.

        -Carl



More information about the Ipp mailing list