[standards-jig] Re: JEP-0060 PubSub: What are my subscriptions?

jean-louis.seguineau at antepo.com jean-louis.seguineau at antepo.com
Mon Feb 17 23:33:59 UTC 2003


I tend to agree with the need to be able to retrieve the 
state of subscriptions. And I also would like to see it as 
a generic extension in the protocol rather than being tied 
up to the pub-sub area. After all, this could be only an 
application of a more generic state retrieval mechanism.

I also agree that most extension to the XMPP protocol are 
always assuming an illimited life span when defining their 
context. And in the specific case of pub-sub, but also of 
registration and presence subscription, real life 
situations require that expiration could be specified (Do 
we use the x:expire for it ?)

As a side remark, I do not totaly agree with the view that 
presence is just a subset of pub-sub. To be automatically 
informed of a presence (or should I say an availability) is 
certainly such a subset. Additionaly, a "roster" is 
effectively a contact list application of presence. But 
there are more application of presence ouside these, and 
presence is not limited to IM only, although IM is today 
the easiest mind association that people do with 
presence ...

Jean-Louis Seguineau

Quoting standards-jig-request at jabber.org:

> Message: 1
> From: "Bob Wyman" <bob at wyman.us>
> To: <standards-jig at jabber.org>
> Cc: "'Peter Millard'" <me at pgmillard.com>
> Date: Sun, 16 Feb 2003 13:25:25 -0500
> Subject: [standards-jig] JEP-0060 PubSub: What are my 
subscriptions?
> Reply-To: standards-jig at jabber.org
> 
>     There should be a mechanism by which someone can 
determine what
> subscriptions they have outstanding on a particular 
PubSub server. The
> current draft (0.7) seems to provide no such mechanism. 
Hopefully,
> future drafts will.
>     1) It is likely that PubSub clients will present 
lists of current
> subscriptions to users both for informational purposes as 
well as in
> order facilitate the organization of messages that are 
published. From
> time to time, due to crashes on users' machines, software
> reconfiguration, etc. it is inevitable that the client-
maintained
> lists
> will not accurately reflect what the server believes is 
the current
> list
> of subscriptions. Thus, it would be good to provide a 
means by which a
> client can refresh or verify its list of subscriptions to 
ensure that
> it
> is identical to that on the server.
>     2) It is inevitable that people will want to use more 
than one
> device to receive PubSub alerts and notifications. (for 
instance, a
> desktop and a PDA). In such situations it is important 
that both the
> device that creates a subscription and a later, different 
device that
> may receive a notification, agree on what subscriptions 
exist. One
> could
> build protocols to allow the two devices to synchronize, 
however, a
> much
> simpler solution would be to allow clients to query the 
PubSub server
> to
> discover what outstanding subscriptions exist.
>     3) The PubSub protocol, as currently specified, seems 
to assume
> that
> subscriptions are permanent. i.e. subscriptions have 
no "duration"
> attribute or other attribute that can cause them to be 
canceled or
> deleted after some period or upon some condition. Thus, 
it is likely
> that many "dead" subscriptions will accumulate over time 
and consume
> server resources unnecessarily. In such a situation, it 
would be good
> to
> provide users with the information they need to "cleanup" 
unused or
> undesired subscriptions whenever possible. However, in 
the case where
> someone's client "forgets" what subscriptions are active, 
the only way
> for a client to rediscover subscriptions is to learn from 
receiving a
> published message. This "learning" is inadequate, 
however, since some
> nodes will have relatively low traffic and it could be 
hours, weeks,
> or
> months, between messages resulting from particular 
subscriptions.
> Thus,
> it is likely that learning can't be relied on as a method 
for people
> to
> reconstitute lost subscription lists. Thus, a mechanism 
should be
> provided to let them discover their subscriptions.
>     4) The ability to retrieve a list of active 
subscriptions is
> analogous to the ability to retrieve a "roster" in XMPP 
or other
> presence protocols. Given that presence protocols are 
nothing more
> than
> a minimal subset of the PubSub problem, I believe that 
the fact that a
> capability has been found useful in a presence system 
should be a
> strong
> indicator that it should be provided in a more general 
PubSub
> capability. (In fact, I'm constantly wondering why we 
bother having a
> distinct presence protocol anyway...) Whatever, all the 
arguments that
> led to providing the ability to retrieve rosters in 
presence also
> apply
> to PubSub.
> 
>         bob wyman



More information about the Standards mailing list