1. Duplicate notifications - perhaps the sender thought that the
notification didn't get through, because of some transport error that it got
back, so it send the same notification a second time (with the same sequence
number). If the notification recipient gets two notifications with the same
sequence number then it knows that its a duplication notification and can
disregard one or the other. (not to be confused with a duplicate
subscription).
2. Notifications that don't get delivered. If the sequence number skips a
number and that skipped number never shows up, there was a lost
notification.
Where might detecting such duplicates or lost notifications be useful?
More for 'job-completed' messages in a per-Printer subscription, than most
other events and subscriptions.
Tom
-----Original Message-----
From: harryl@us.ibm.com [mailto:harryl@us.ibm.com]
Sent: Wednesday, August 04, 1999 15:29
To: Hastings, Tom N
Cc: Manros, Carl-Uno B; IETF-IPP; Moore, Keith; paf@swip.net
Subject: RE: IPP> NOT - About duplicate Notification Subscriptions
Very good explanation of the rationale for duplicate subscriptions. I agree,
under these conditions they will definitely exist. Also, the lease will
ultimately clean it up. It should be "fair" for the printer to be
straightforward about it and just issue notifications to the registered
subscriptions (you subscribe to your local newspaper twice, you'll see two
on
your driveway every morning).
Only "trap" I see is app that subscribes (and is granted) infinite lease
then
crashes and re-subscribes. Repeat this several times in succession and
you've
clogged the subscription table.
Not sure I agree with the need for sequence numbers but they are a solution
to a
perceived problem, at least (although you've pointed out some potential
difficulties introduced by seq nums.). Guess I'm just a payload junkie. If I
get
"page 3 completed" way after I've already received and understood "page 5
completed" ... I oughta be able to deal with it! Maybe there are examples
that
don't map well into "redundancy" approaches. Probably comes in more handy
for
device events. I'm on fire... I'm ok (which was first!?)
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 08/04/99 10:56:02 AM
To: Harry Lewis/Boulder/IBM@IBMUS, "Manros, Carl-Uno B"
<cmanros@cp10.es.xerox.com>
cc: IETF-IPP <ipp@pwg.org>, "Moore, Keith" <moore@cs.utk.edu>,
?iso-8859-1?Q?F=E4ltstr=F6m@westrelay02.boulder.ibm.com,
<paf@swip.net>
Subject: RE: IPP> NOT - About duplicate Notification Subscriptions
-----Original Message-----
From: harryl@us.ibm.com [mailto:harryl@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@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