[Standards-JIG] JEP-0030 - Disco to resources
stpeter at jabber.org
Wed Apr 19 16:34:04 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Vinod Panicker wrote:
> On 4/19/06, Ralph Meijer <jabber.org at ralphm.ik.nu> wrote:
>> On Wed, Apr 19, 2006 at 06:00:22PM +0530, Vinod Panicker wrote:
>>> On 4/19/06, Ralph Meijer <jabber.org at ralphm.ik.nu> wrote:
>>>> On Wed, Apr 19, 2006 at 10:06:49AM +0530, Vinod Panicker wrote:
>>>>> Can anyone please point me to an instance where "connected" resources
>>>>> are being used for a practical purpose?
>>>> I hope your question does not mean 'what is the point of having
>>>> clients that don't send presence'?
>>> Not at all. Just trying to understand use cases for having connected
>>> and active states.
>> Will, for example I use a non-presence sending bot for conveying my
>> currently playing song using User Tune. This bot is constantly connected
>> but not 'available'.
> I was talking about connected and active, not connected and available.
>>>> That said, having disco#info on a bare (IM account) JID to return
>>>> resources that have not sent presence, will actually leak presence
>>> Right. That means that modifying JEP-0030 to say that disco should be
>>> sent to only available resources would neither cause harm nor any dead
>> Why? I don't see a problem with people sending disco to
>> connected-but-not-available resources. If you already know it exists (by
>> having received a message from it, for example) there is no harm in
>> this. My point was that it shouldn't show up in the list of items that
>> are returned when doing disco#items to the bare JID.
I think this thread started because Vinod read about the idea of sending
a disco#items request before binding a resource, which is a possible way
of discovering what other resources I have. I don't know if we want to
encourage that, but it seems possible. So I would do this:
2. disco#info with no 'to' address
3. get my list of connected(+) resources
4. do resource binding
> Inferred from the various texts in the RFCs, connected and active
> resources cannot receive messages, cannot receive directed iq's and
> nor can they receive presence. I'll quote all of them and the reason
> for inference if you wish. I'm far too tired to compile the list now
Where did you infer this? RFC 3920 talks about delivery to such resources.
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