[Standards-JIG] JEP-0030 - Disco to resources

Peter Saint-Andre stpeter at jabber.org
Wed Apr 19 16:34:04 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
>>>> information.
>>> 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
>>> kittens?
>> 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:

1. SASL
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.

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFERmZ8NF1RSzyt3NURAjmoAKChmETQQUbH6cLHX8DZYNqcCczKawCfVHGy
Mg/fVbJYVWFixra9u8zmvK8=
=BVSW
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060419/a1f9b424/attachment.bin>


More information about the Standards mailing list