If you're doing "in-band" HTTP, server-push notifications (with
multi-part responses), it would be useful to detect lost notifications.
In HTTP both client and server are allowed to close the connection at
ANY time. So, if the connection dropped unexpectedly, it would nice if
the client could reconnect and pick up where it left off (using
sequence numbers).
>
> 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
>
>