IPP Mail Archive: Re: IPP> NOT - Issue 1 - Add Subscription object?

Re: IPP> NOT - Issue 1 - Add Subscription object?

kugler@us.ibm.com
Fri, 30 Jul 1999 12:27:31 -0700

<37a19aa5.bdbf6e2-@easysw.com> wrote:
...
> > we clean up subscriptions that are never associated with a job?
>
> First, subscriptions have a "lease" time, which means that after a
> certain amount of time the subscriptions are automatically expired
> (cancelled.) Once a subscription is tied to a job, however, the
> subscription will remain alive until the job is cancelled or
> completed.
>

Can the lease be renewed? That would be a way to adress Tom's concern
below about connection closing in method 1:

>
>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.

If the lease expires and the connection closes, the client could make a
new request to renew the lease and continue to get notifications pushed
from the server.

-Carl