[Standards-JIG] Reason for subscription/unsubscription
tomek at xiaoka.com
Thu Jun 24 13:09:33 UTC 2004
Rachel Blackman wrote:
> 1) It's nice to get a reason in the same UI element as the '<x> would
> like to add you to their roster, allow them?' question. For instance,
> '<x> would like to add you...' having a 'Notes: Hey, we talked at
> OSCON, I'd be interested in continuing our design discussions' might
> spur a memory as to who it was if the JID alone didn't.
So <x> can sand me a <message type="chat"><body>Hey, we talked at OSCON,
I'd be interested in continuing our design discussions.</body></message>
I will reply him and we can talk.
Presence has nothing to do wit it.
> 2) A message may not go to the specific Jabber resource you are on as;
> presence goes to all connected resources and thus allows you to answer
> from any. Having the subscription request reason split into a message
> stanza means that they are not guaranteed to arrive at the same
> client, thus may not be able to be properly associated.
Normally one sends a message to a Bare-JID and it lands in a client with
the highest priority.
And this behavior is desireable.
The highest priority resource is the one I want messages to appear (the
one I'm currently sitting at).
> 3) Some clients allow the functionality of blocking messages from
> client JIDs not on your roster, for privacy purposes. If that's the
> case, you might have the message explaining the reason for a
> subscription not come up, unless it were in the presence element
> containing the subscription request.
If one does not want to get messages from the people one doesn't know,
do You think he/she wants to get messages disguised as presence?
> 4) ICQ UINs, for instance, do not give any real information. Allowing
> subscription reasons in presence information would allow the ICQ
> gateway to provide the ICQ subscription request reasons in the Jabber
> subscription requests, and vice versa. :)
We have VCards for getting user information.
JIT emulates them correctly. :-)
If You have no idea of who is writing to you - press the VCard button in
the window and see his VCard.
> So you cannot ever see a situation where you might meet someone at
> OSCON or something similar, want to continue discussions, but not
> necessarily recognize their JID?
I can shurely see the situation.
But if one wants to talk with me - one sends me a message.
Subscription request in this situation is something like:
"Hey, we've meet at OSCON - I want to observe if you're online."
What for I ask? ;-)
This information is usefull to my friends, not someone I talked once.
> I sometimes meet people offline, in the real world, and then end up
> with them on my IM roster based on that. I don't necessarily remember
> who a particular screen name, UIN, or JID belongs to at the time they
> try to add me.
You may add someone to the roster not requesting presence information.
You can then double-click and talk. No problem. :-)
I am continuing this discussion, becouse I really believe that "nice,
but not very usefull" features just bloats applications and protocols.
And gives ways to abuse the feature.
More information about the Standards