[standards-jig] Invisibility Support in Jabber (with pubsub ideas)
theo at theoretic.com
Fri Aug 9 03:45:37 UTC 2002
I like this concept, although have decided to try and make it possible,
even easy, in my pubsub spec I'm working on
[http://www.theoretic.com/?Jabber_2.0/Subscribe] instead of trying to
hack it into the current presence spec.
My idea is to keep the concept and details of "subscription topics"
non-defined in my spec. In other words, everything about the spec
assumes that the topic is already defined or defined elsewhere in the
packet. Then this will allow me or others to go back and create a topic
spec that allows for the grouping together of topics into bigger topics.
So I could have a "presence" topic which everyone on my roster was
subscribed to, but then also divide the subscribers of that topic up
into "family", "friends", "jabber developers", etc, and be able to
address those specialized topics by themselves.
Ben Schumacher wrote:
> I sitting here reading the mailing lists today, and it occurred
> to me that there hasn't been nearly enough controvesy on the
> Jabber-related mailing lists lately, so I've decided to step up and cause
> Here's the deal. I'd like to propose a new type of presence packet for the
> XMPP protocol. I fully expect to hear a lot of backlash from everybody
> with regard to the suggestion, but I think it will add value to the
> protocol. (Please send all flames off-list to ben-devnull at blahr.com.)
> That being said, let me first reference the discussion I had in the JDEV
> conference room earlier today about this issue:
> It starts at about 15:38. (Side note: Boy, it'd sure be nice if there were
> anchors every minute when the room is active in those logs. It'd make it
> much easier to link to. 8^P)
> Basically, consider the following situation.
> 1) I come online as "invisible."
> <presence type='invisible'/>
> 2) I send directed presence of visible to user "a", "c" and "e".
> <presence to='a at server.com' type='visible'/>
> <presence to='c at server.com' type='visible'/>
> <presence to='e at server.com' type='visible'/>
> 3) I change my status to away, the server tracks that I'm only
> visible to "a", "c" and "e" and forwards my presence update
> to only those users.
> 4) I change my status back to available, again the server tracks
> that I'm only visible to "a", "c" and "e" and forwards my
> presence update to only those users.
> 5) I decide I want to be visible to all users on my roster, so I
> send a visible presence out.
> <presence type='visible'/>
> I hope that explains the reason why. I don't think using 'available' is
> appropriate, because it technically isn't part of the protocol (see the
> IETF docs, at http://jabber.org/ietf/), and you're actually changing your
> availablity in this situation anyhow, you are changing your visibility.
> While I understand that people won't like this idea, cause it complicates
> presence even more, it adds value and doesn't do anything with presence
> that shouldn't be done by presence. I, personally, agree with the general
> sentiment that presence is overloaded, but I think this is a result of
> subscription being tied to presence.
> Anyway. That's my suggestion, let the games (flames?) begin!
> Standards-JIG mailing list
> Standards-JIG at jabber.org
/\ Adam Theo, Age 23, Tallahassee FL USA
//\\ Email & Jabber: theo at theoretic.com
// \\ Pager: (850) 709 7738
// || \\ Theoretic Solutions: http://www.theoretic.com
|| "Building Ideas by Bringing them Together"
|| Jabber Protocol: http://www.jabber.org
|| "The Next Generation Communications Protocol"
|| "A Free-Market Socialist Patriotic American Buddhist"
More information about the Standards