Re: [Standards] XMPP-IM - presence subscription handling

2009-02-24 Thread Jiří Zárevúcký
2009/2/24 Pavel Simerda : > > It has some flaws. See my post about subscriptions, please. > I've seen them. The difference is you are looking at the problems from the server perspective. I'm concentrating on the client perspective and human interface itself. >> Originally, I wanted to propose mod

[Standards] Fwd: Agenda 2009-02-25.

2009-02-24 Thread Kevin Smith
FYI: -- Forwarded message -- From: Kevin Smith Date: Tue, Feb 24, 2009 at 8:01 PM Subject: Agenda 2009-02-25. To: XMPP Council http://xmpp.org/council/agendas/2009-02-25.html /K

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Dave Cridland
On Tue Feb 24 18:04:06 2009, Pavel Simerda wrote: > > * resource conflicts should be handled consistently in servers > > > > > It's not always possible to handle conflicts in the same way. Could you please be more specific? In the case of a split cluster, there's a number of possible resolut

Re: [Standards] XMPP-IM - presence subscription handling

2009-02-24 Thread Pavel Simerda
On Tue, 24 Feb 2009 16:53:30 +0100 Jiří Zárevúcký wrote: > Hello all. > > I've been thinking about the current subscription management in the > XMPP-IM for some time now. I think it's not very well designed. It has some flaws. See my post about subscriptions, please. > For example, there's an

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Philipp Hancke
Pavel Simerda wrote: * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details Piggybacking. Which is subtly broken in RFC 3920 - at least 50% of it. makes 'target piggybacking' (different to) unusable, as you risk the entire stream. Please provide more

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Pavel Simerda
On Tue, 24 Feb 2009 13:07:16 +0100 Philipp Hancke wrote: > Dave Cridland wrote: > [snip] > >> > >> *nod* > >> Might be a problem if a server requires EXTERNAL, but this is rare > >> in uncontrolled environments anyway. > >> > >> That would make 0178 c2s-only and it could be merged with 0257 > >>

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Pavel Simerda
On Tue, 24 Feb 2009 10:20:15 + Dave Cridland wrote: > On Tue Feb 24 10:10:38 2009, Philipp Hancke wrote: > > Dave Cridland wrote: > >> On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: > >>> * bidirectional s2s could be announced in sent > >>> right after the opening tag from the initiato

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Pavel Simerda
On Tue, 24 Feb 2009 11:10:38 +0100 Philipp Hancke wrote: > Dave Cridland wrote: > > On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: > >> * bidirectional s2s could be announced in sent > >> right after the opening tag from the initiator. > > Unidirectional S2S has been around for too long,

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Pavel Simerda
On Tue, 24 Feb 2009 09:14:13 + Dave Cridland wrote: > On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: > > * bidirectional s2s could be announced in sent > > right after the opening tag from the initiator. > > > > > Well... > > What you need is to: > > a) Signal the ability of the re

Re: [Standards] Inconsistent Subscriptions in XMPP

2009-02-24 Thread Pedro Melo
Hi, On Feb 24, 2009, at 12:49 AM, Pavel Simerda wrote: There are several cases when subscription databases in XMPP are inconsistent. You may view subscription information as a global distributed database. Subscription state between two JIDs, for example a...@a and b...@b are stored in two

[Standards] XMPP-IM - presence subscription handling

2009-02-24 Thread Jiří Zárevúcký
Hello all. I've been thinking about the current subscription management in the XMPP-IM for some time now. I think it's not very well designed. For example, there's an obvious redundancy in the roster pushes and subscription stanzas. For (almost) every subscription update / request, there is a pre

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Philipp Hancke
Dave Cridland wrote: [snip] *nod* Might be a problem if a server requires EXTERNAL, but this is rare in uncontrolled environments anyway. That would make 0178 c2s-only and it could be merged with 0257 somehow. That's possible. But then, 0178 should get merged with rfc3920bis. That might be

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Dave Cridland
On Tue Feb 24 11:05:50 2009, Philipp Hancke wrote: 1) do 0178 and add subsequent auth (including graceful failure) 2) do 0178 for the first authorization and use piggybacking (with graceful failure again) for subsequent authorization... err... verification 3) ignore any 0178 offers and do p

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Philipp Hancke
Dave Cridland wrote: * bidirectional s2s could be announced in sent right after the opening tag from the initiator. Unidirectional S2S has been around for too long, I do not see a real gain in fixing that now. This was discussed in Feb 2004 on the XMPPWG list: http://mail.jabber.org/piperm

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Dave Cridland
On Tue Feb 24 10:10:38 2009, Philipp Hancke wrote: Dave Cridland wrote: On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: * bidirectional s2s could be announced in sent right after the opening tag from the initiator. Unidirectional S2S has been around for too long, I do not see a real gai

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Philipp Hancke
Dave Cridland wrote: On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: * bidirectional s2s could be announced in sent right after the opening tag from the initiator. Unidirectional S2S has been around for too long, I do not see a real gain in fixing that now. This was discussed in Feb 200

Re: [Standards] various rfc3920bis feedback

2009-02-24 Thread Dave Cridland
On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: * bidirectional s2s could be announced in sent right after the opening tag from the initiator. Well... What you need is to: a) Signal the ability of the receiver to handle features sent by the initiator. b) Signal the ability of the i