[Standards-JIG] proto-JEP: Smart Presence Distribution
hildjj at gmail.com
Thu May 25 04:36:03 UTC 2006
I assume the intent is for this to be widely implemented.
As such, you might want to take into consideration the architecture
of some of the existing XMPP servers, which have their S2S components
decoupled from the piece that does presence management. The presence
management pieces don't tend to have visibility into the TCP-
connectedness of the S2S links. In fact, you might have multiple,
parallel connections, through multiple different physical paths,
between two domains.
I also agree that disco is the way to find out support for this.
As well, what happens if a user changes a privacy rule in the middle
of a session?
On May 24, 2006, at 10:06 AM, Philipp Hancke wrote:
> Richard Dobson wrote:
>>> 6. Negotiation
>>> This protocol MUST be negotiated between parties willing to
>>> optimize traffic. A
>>> stream feature negotiation is appropriate. During such a
>>> negotiation the
>>> resource name is agreed upon, which in this example was 'route'.
>> Something to note is this would not be negotiated using stream
>> features, this would be negotiated using disco.
> I dont see how this could be useful for anything but a direct
> connection, hence the suggestion to use stream:features, where
> negotiation takes place before the connection is established.
>> Also, with your protocol how does the sending server know if the
>> list is populated yet and how does it know who is already in the
>> list? It seems to me that this can easily get out of sync with
>> neither side having any way of knowing if it is or not, this is
>> something that needs to be resolved,
> The worst case for this is rebuilding this list with EACH tcp
> and it is valid no longer than the lifetime of that (e.g. you send
> a presence broadcast first and after that you only send smarticasts).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1883 bytes
Desc: not available
More information about the Standards