Peter Saint-Andre
06-03-2008, 10:45 PM
Sorry for the slow reply.
On 04/23/2008 4:04 AM, Paul Witty wrote:
> Peter Saint-Andre wrote:
>> Paul Witty wrote:
>>
>>> From what I can tell, XEP-0155 helps to get around this. However, it
>>> would be nice to include the ability to not just share presence, but to
>>> also share service discovery information.
>>>
>>
>> As an option in the XEP-0155 negotiation? That seems sensible. Does it
>> need to be a separate option or shall we assume that if you want to
>> share presence you're also willing to share service discovery data?
>> Probably it's best to make it explicit.
>>
>>
> There needs to be a way to indicate that we are doing XEP-0155 in order
> to find presence and service discovery. As it stands, all we can do is
> say that we may want to share presence, but the far end is under no
> obligation to do so. While this makes sense for a text chat, if we want
> to start a Jingle session we can't do anything without presence and
> service information. There should be a way that we say presence and
> service discovery (and perhaps Jingle) are required in this session, so
> that the client can reject/ignore the request immediately.
Well, I think realistically for seamless communication you would
register with a gateway and it would know your capabilities, so that it
could do the right thing in routing inbound calls from people who are
not on your roster.
> To make my life easier, something could be added to XEP-0166 saying that
> clients supporting Jingle should support XEP-0155, or even something
> similar to XEP-0155 but much lighter weight.
I'm all ears. :)
>>> I've not yet tried doing this; it may be that it's entirely the wrong
>>> way to go about it, so if anyone can suggest a better way, please speak
>>> up. For example, I'd like it so that one person could have many
>>> different ways to be contacted e.g. H.323 endpoint, Jingle/XMPP client
>>> on their desktop, Jingle/XMPP client at home. We can't know in advance
>>> what XMPP resource the user will have, so we want to just store the IP
>>> address of their H.323 endpoint (e.g. 1.2.3.4) and their XMPP ID, and
>>> then connect to whichever resource is currently available.
>>>
>>
>> If you don't have any existing relationship with me and my server lets
>> you know what my resources are, I would consider that to be a leak of
>> private information. So I realize this is a pain, but sharing presence
>> and resource information with unknown entities is widely considered to
>> be a leak in the XMPP world. So we need to work around that, which we
>> can do with XEP-0155, presence subscriptions, RAP (XEP-0168), etc.
>>
> I'm all for this, but I think that we should give the client the choice
> to allow incoming sessions from unknown clients, rather than having the
> server reject everything outright.
That makes sense in general, though people need to understand the risks
(and some services might forbid that outright, e.g. as Google Talk does
because it's trying to protect its users).
Peter
--
Peter Saint-Andre
https://stpeter.im/
On 04/23/2008 4:04 AM, Paul Witty wrote:
> Peter Saint-Andre wrote:
>> Paul Witty wrote:
>>
>>> From what I can tell, XEP-0155 helps to get around this. However, it
>>> would be nice to include the ability to not just share presence, but to
>>> also share service discovery information.
>>>
>>
>> As an option in the XEP-0155 negotiation? That seems sensible. Does it
>> need to be a separate option or shall we assume that if you want to
>> share presence you're also willing to share service discovery data?
>> Probably it's best to make it explicit.
>>
>>
> There needs to be a way to indicate that we are doing XEP-0155 in order
> to find presence and service discovery. As it stands, all we can do is
> say that we may want to share presence, but the far end is under no
> obligation to do so. While this makes sense for a text chat, if we want
> to start a Jingle session we can't do anything without presence and
> service information. There should be a way that we say presence and
> service discovery (and perhaps Jingle) are required in this session, so
> that the client can reject/ignore the request immediately.
Well, I think realistically for seamless communication you would
register with a gateway and it would know your capabilities, so that it
could do the right thing in routing inbound calls from people who are
not on your roster.
> To make my life easier, something could be added to XEP-0166 saying that
> clients supporting Jingle should support XEP-0155, or even something
> similar to XEP-0155 but much lighter weight.
I'm all ears. :)
>>> I've not yet tried doing this; it may be that it's entirely the wrong
>>> way to go about it, so if anyone can suggest a better way, please speak
>>> up. For example, I'd like it so that one person could have many
>>> different ways to be contacted e.g. H.323 endpoint, Jingle/XMPP client
>>> on their desktop, Jingle/XMPP client at home. We can't know in advance
>>> what XMPP resource the user will have, so we want to just store the IP
>>> address of their H.323 endpoint (e.g. 1.2.3.4) and their XMPP ID, and
>>> then connect to whichever resource is currently available.
>>>
>>
>> If you don't have any existing relationship with me and my server lets
>> you know what my resources are, I would consider that to be a leak of
>> private information. So I realize this is a pain, but sharing presence
>> and resource information with unknown entities is widely considered to
>> be a leak in the XMPP world. So we need to work around that, which we
>> can do with XEP-0155, presence subscriptions, RAP (XEP-0168), etc.
>>
> I'm all for this, but I think that we should give the client the choice
> to allow incoming sessions from unknown clients, rather than having the
> server reject everything outright.
That makes sense in general, though people need to understand the risks
(and some services might forbid that outright, e.g. as Google Talk does
because it's trying to protect its users).
Peter
--
Peter Saint-Andre
https://stpeter.im/