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

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

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

Michael Sweet mike at easysw.com
Thu Jul 29 13:39:32 EDT 1999


"Hastings, Tom N" wrote:
> 
> In our IPP telecon today, we did recognize that there are two
> possible HTTP notification delivery methods, not just one:
> ...
> 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
> ...

If we use "Content-Type: multipart/xyz" and then send the individual
updates over the same request we'll probably have better success with
existing HTTP products, and for #1 it is probably the only valid way
to send multiple responses to the client.

For the "active" HTTP POST notification either the normal keep-alive
functionality or a multi-part encoding will work.  Also, the IPP
server SHOULD try to retry a lost connection as needed, but should
also have the option of cancelling the subscription if the server is
unable to detect fault conditions that would degrade the server's
performance.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com
    "Your logic is impeccable, Captain.  We are in grave danger."



More information about the Ipp mailing list