Subject: RE: [Simple] Partial Notifies?

From: "Avshalom Houri" <[email-masked]>
Date: Wed, 5 Sep 2001 13:33:36 +0200

> I was actually debating this issue when doing the update of the presence

> spec. Its not specified right now, all through the events framework allows

> each package to define how its done.

I think that it should be included since NOTIFY can become big especially
given

detail/schema/human readable comment.

> One model to do this is something I have proposed for other packages:

> 1. the notify triggered by a subscribe contains the full state

> 2. subsequent notifies contain only the piece thats changed (i.e., the

> contact address that is different)

> 3. the subscriber keeps track of the cseq to see if it may have missed a

> notify. If there are no gaps in Cseq, nothing was missed. If there is a
gap,

> something may have been missed, or else there was an intermediate
challenge

> or something like that. So, the subscriber re-subscribes to get a
triggered

> notify with full state.

I assume that the granularity will be a single tuple of the presence, and
that

there will be an operator preceding the tuple for add/delete/update.

> A better way to handle the ordering is for the presence document itself to

> contain version numbers, but that would require changes in the pidf spec.

> Since the initial SUBSCRIBE has to trigger full state anyway, idempotency
of

> SUBSCRIBE would argue for having full state triggered notify for refreshes

> too.

It seems that Dror's suggestion ([email-masked]) can be helpful here.

avshalom

Sametime/Lotus/IBM

        Jonathan Rosenberg <[email-masked]>

      05/09/2001 09:53

      To: "'Avshalom Houri'" <[email-masked]>,
[email-masked]

      cc:

      Subject: RE: [Simple] Partial Notifies?

> -----Original Message-----

> From: Avshalom Houri [mailto:[email-masked]]

> Sent: Friday, August 31, 2001 7:38 AM

> To: [email-masked]

> Subject: [Simple] Partial Notifies?

> [Sending from a different email due to mailing list DNS problems]

> Will it be possible to get partial updates to presence info?

> It is of course

> an optimization

I was actually debating this issue when doing the update of the presence

spec. Its not specified right now, all through the events framework allows

each package to define how its done.

One model to do this is something I have proposed for other packages:

1. the notify triggered by a subscribe contains the full state

2. subsequent notifies contain only the piece thats changed (i.e., the

contact address that is different)

3. the subscriber keeps track of the cseq to see if it may have missed a

notify. If there are no gaps in Cseq, nothing was missed. If there is a gap,

something may have been missed, or else there was an intermediate challenge

or something like that. So, the subscriber re-subscribes to get a triggered

notify with full state.

A better way to handle the ordering is for the presence document itself to

contain version numbers, but that would require changes in the pidf spec.

Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of

SUBSCRIBE would argue for having full state triggered notify for refreshes

too.

-Jonathan R.

---

Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.

Chief Scientist First Floor

dynamicsoft East Hanover, NJ 07936

[email-masked] FAX: (973) 952-5050

http://www.jdrosen.net PHONE: (973) 952-5000

http://www.dynamicsoft.com

---

From: "Robert Brown" <[email-masked]>
Date: Wed, 5 Sep 2001 13:41:20 -0700

Watcher info can become pretty big too.  It would be nice to receive
partials that only contained new pending watchers.

----- Original Message -----
From: "Avshalom Houri" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 05, 2001 4:33 AM
Subject: RE: [Simple] Partial Notifies?

gap,
challenge
triggered
of
> _______________________________________________
> simple mailing list
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>