-----Original Message-----
From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Wednesday, August 04, 1999 08:13
To: Manros, Carl-Uno B
Cc: IETF-IPP; Moore, Keith;
=?iso-8859-1?Q?F=E4ltstr=F6m at westrelay02.boulder.ibm.com; _Patrik?=
Subject: Re: IPP> ADM - Meeting Minutes from IETF45 - IPP WG Session -
July 14, 199 9 in Oslo
snip...
3. What is the rationale behind duplicate subscriptions? I've missed this
one.
> Duplicate subscriptions will be allowed. A Printer might suppress
>duplicate notifications.
TH> By duplicate subscriptions, we mean suppose a client creates a
"per-printer Subscription object and gets back subscription id 203 with a
lease. Then the application crashes or is restarted and hasn't bothered to
see whether it already has a subscription whose lease hasn't expired. So it
creates another subscription object, and gets back subscription id 220.
Both subscription objects have the same events and the same notification
recipients. Eventually, the first subscription's lease will expire (because
the application won't renew it). But until the first least does expire,
there are duplicate subscriptions.
Its too hard to require the Printer to eliminate the duplicate Subscription
objects.
However, with the sequence number now being associated with the
subscription, rather than with the event type, I don't think that the
Printer can eliminate sending notifications when there are duplicate
Subscription objects. I think the Printer MUST send notifications for all
unexpired Subscriptions. Otherwise, there would be holes in the sequence
numbers that the Notification Recipient would think was a problem. So we
need to eliminate the second sentence from the spec:
A Printer might suppress duplicate notifications.
Robust clients SHOULD keep a separate record of whether they have created a
Subscription object and/or try to renew an existing subscription object that
it theirs, rather than creating duplicate subscriptions.
How does that sound?
Tom