Re: [Standards] roster sequencing

Yep, that would be a good idea. Thanks! Btw... I suggest a clean-up of XEP-59 also for my user-search proposal I sent to the pubsub list. It's not even in INBOX yet but if you want to look: http://data.pavlix.net/xmpp/user-search/user-search.html Pavel On Thu, 4 Sep 2008 20:19:36 +0200 "Fabio

Re: [Standards] roster sequencing

I think it's not so time-critical. On Thu, 04 Sep 2008 11:52:43 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Pavel Simerda wrote: > > +1 for a generic method > > Yeah, that means I need to re-work XEP-0237. :( > > /psa > -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavli

Re: [Standards] roster sequencing

On Thu, Sep 4, 2008 at 7:52 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Pavel Simerda wrote: >> >> +1 for a generic method > > Yeah, that means I need to re-work XEP-0237. :( Since Pavel has reminded XEP-59, what about transforming xep-237 into an extension of it? XEP-59 allows to set the b

Re: [Standards] roster sequencing

Pavel Simerda wrote: +1 for a generic method Yeah, that means I need to re-work XEP-0237. :( /psa smime.p7s Description: S/MIME Cryptographic Signature

Re: [Standards] roster sequencing

+1 for a generic method Pavel On Thu, 04 Sep 2008 09:16:05 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Peter Saint-Andre wrote: > > Pavel Simerda wrote: > >> Just a sidenote to the roster sequencing... > >> > >> There are clients (e.g. Gajim) that ask for > >> vCard right now to show us

Re: [Standards] roster sequencing

Yep, this should be included to... Btw... just reminding XEP-0059: Result Set Management Pavel On Thu, 04 Sep 2008 09:13:22 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Pavel Simerda wrote: > > Just a sidenote to the roster sequencing... > > > > There are clients (e.g. Gajim) that ask

Re: [Standards] xmpp-commits list

Tobias Markmann wrote: On Thu, Sep 4, 2008 at 6:55 PM, Peter Saint-Andre <[EMAIL PROTECTED] > wrote: At the request of Jack Moffitt, I have set up an announce list for commits to the "xmpp" SVN repository, so that folks can track more closely what changes i

Re: [Standards] xmpp-commits list

On Thu, Sep 4, 2008 at 6:55 PM, Peter Saint-Andre <[EMAIL PROTECTED]>wrote: > At the request of Jack Moffitt, I have set up an announce list for commits > to the "xmpp" SVN repository, so that folks can track more closely what > changes in the XEPs, registries, schemas, and the xmpp.org website in

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

Justin Karneges wrote: this enforcement is needed not because we need to protect the poor little client, but because if the client and server don't agree on the same value then it becomes super easy to DoS the client. All a remote user needs to do is send a message that is larger than the clie

[Standards] xmpp-commits list

At the request of Jack Moffitt, I have set up an announce list for commits to the "xmpp" SVN repository, so that folks can track more closely what changes in the XEPs, registries, schemas, and the xmpp.org website in general. You can subscribe here: http://mail.jabber.org/mailman/listinfo/xmpp

Re: [Standards] Stanza Size Limits

On Thursday 04 September 2008 08:11:04 Dave Cridland wrote: > On Thu Sep 4 15:30:53 2008, Peter Saint-Andre wrote: > > Gosh, do we really need all this complexity? Negotiating per-user > > limits seems unnecessary to me. > > Not per-user. Kevin means, I think: > > C1 <--C2S:MTU=1000--> S1 <--S2S:M

Re: [Standards] Stanza Size Limits (was Re: [jde v] Communicate between two client instances of the same ID)

On Wednesday 03 September 2008 15:15:22 Pedro Melo wrote: > On Sep 3, 2008, at 10:03 PM, Justin Karneges wrote: > > If you set a small value for the server policy then you'd be fine, > > but that's > > not very flexible. For example, most desktop clients are surely > > capable of > > handling a 1M

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

On Thu, Sep 4, 2008 at 4:30 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > We need roster sequencing. And especially I do. :) So please provide some > feedback on XEP-0237. > XEP is fine, once supported by the servers. I'd just need to verify whether it is feasible to implement it also with

Re: [Standards] roster sequencing

Peter Saint-Andre wrote: Pavel Simerda wrote: Just a sidenote to the roster sequencing... There are clients (e.g. Gajim) that ask for vCard right now to show user avatars. In future the usual flow might be that the client asks sequentially for various user information via some PubSub/PEP reque

[Standards] roster sequencing

Pavel Simerda wrote: Just a sidenote to the roster sequencing... There are clients (e.g. Gajim) that ask for vCard right now to show user avatars. In future the usual flow might be that the client asks sequentially for various user information via some PubSub/PEP requests. IMO we should not fo

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

On Thu Sep 4 15:30:53 2008, Peter Saint-Andre wrote: Kevin Smith wrote: On Wed, Sep 3, 2008 at 11:15 PM, Pedro Melo <[EMAIL PROTECTED]> wrote: Sure but as a server admin I would not admit a client negotiating a larger stanza than my own C2S or S2S limits. Sorry - I'm jumping in mid-thread

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

Just a sidenote to the roster sequencing... There are clients (e.g. Gajim) that ask for vCard right now to show user avatars. In future the usual flow might be that the client asks sequentially for various user information via some PubSub/PEP requests. IMO we should not forget this when designin

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

Fabio Forno wrote: On Wed, Sep 3, 2008 at 4:13 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: This would signal the client that the max stanza size is 65355 bytes, and the max allowed rate of stanzas per second is 10. I like that. /psa What happens to your roster in that case? ;) We ne

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

Kevin Smith wrote: On Wed, Sep 3, 2008 at 11:15 PM, Pedro Melo <[EMAIL PROTECTED]> wrote: Sure but as a server admin I would not admit a client negotiating a larger stanza than my own C2S or S2S limits. Sorry - I'm jumping in mid-thread again, but I don't remember seeing this discussed. If sta

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

On Wed, Sep 3, 2008 at 4:13 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> This would signal the client that the max stanza size is 65355 bytes, and >> the max allowed rate of stanzas per second is 10. > > I like that. > > /psa > What happens to your roster in that case? ;) Not only a joke

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

Hi, On Sep 4, 2008, at 8:53 AM, Kevin Smith wrote: On Wed, Sep 3, 2008 at 11:15 PM, Pedro Melo <[EMAIL PROTECTED]> wrote: Sure but as a server admin I would not admit a client negotiating a larger stanza than my own C2S or S2S limits. Sorry - I'm jumping in mid-thread again, but I don't re

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

On Wed, Sep 3, 2008 at 11:15 PM, Pedro Melo <[EMAIL PROTECTED]> wrote: > Sure but as a server admin I would not admit a client negotiating a larger > stanza than my own C2S or S2S limits. Sorry - I'm jumping in mid-thread again, but I don't remember seeing this discussed. If stanza sizes are a str

Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)

On Sep 3, 2008, at 10:03 PM, Justin Karneges wrote: On Wednesday 03 September 2008 13:24:00 Pedro Melo wrote: On Sep 3, 2008, at 8:29 PM, Justin Karneges wrote: This is more of a server limit though. The client still needs a way to negotiate its own limit, and have the server protect the cli