[Standards-JIG] proto-JEP: Invisible Command
stpeter at jabber.org
Mon May 15 17:32:24 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Dave Cridland wrote:
> On Fri May 12 18:21:00 2006, Zenon Kuder jr. wrote:
>> I agree. I think this part
>> While the client is in invisible mode, the server:(...) 5. MUST NOT
>> deliver any inbound <message/> stanzas whose 'to' address is bare JID
>> of the user.
>> is not as what people expect...
> You're obviously right, in as much as you're not the only one to raise
> this point.
I don't recognize the term "obvious":
> But I think I see where that MUST is coming from - it's a privacy thing,
> I'd guess, preventing people from probing for you. (Although why it then
> allows <iq> stanzas is a little beyond me).
IQ stanzas to bare JIDs are handled by the server and not delivered to
As to rule 5 ("MUST NOT deliver any inbound <message/> stanzas whose
'to' address is bare JID of the user."):
I am not wedded to that rule. That set of rules was a first attempt at
capturing what people mean by invisibility. I guess I didn't quite
succeed. So by "invisibility" people mean (in part) that the user will
continue to receive all messages sent to the bare JID (i.e., such
messages will not be sent to offline storage but instead will be
delivered to the client)? I suppose that makes sense.
> What I also suspect is that there's multiple reasons for being
> invisible, and this JEP assumes one meaning of invisibility, rather than
> all possible reasons.
Sure. It would be good to define them all.
> For instance, I was thinking of wiring XMPP support into my email
> client. As an instant messaging client, it's far from optimal, but it'd
> be useful for (for instance) remote control, highlighting online users,
> etc. But I don't want to inadvertantly get messages routed to it,
> really, nor subscription requests - I just want presence data, the
> ability to manipulate the roster, and that kind of thing - I'd be using
> it in combination with a "proper" IM client. This is a kind of "90%
> offline", which this JEP describes pretty well, I think.
I think such resources would use negative presence priorities.
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards