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

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

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

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
>IPP operation response is returned. Then the IPP Printer sends
>notifications as additional responses to the client. In this case,
>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
>(1setOf uri)" operation attribute and the Notification Recipient acts
>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
>With either method, we need to define which end can close the connect
>what happens when the connection is closed in order to send more
>notifications. For example, the URL in the "notify-recipients" for
>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

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.