Re: [Standards] Jingle: UDP relays

Peter Saint-Andre wrote: At the recent XMPP devcon, I talked a bit with Thiago Camargo about NAT traversal and media relays. There are really two separate issues here: 1. Finding and using STUN servers for NAT traversal. This is discussed in XEP-0215. New STUNbis doesn't define STUN

Re: [Standards] compare SIMPLE and XMPP

Ralph J.Mayer wrote: I had to learn these days that the presence server that comes with the Cisco Unified Communications Manager uses SIMPLE and not XMPP like I had hoped. In fact, SIP is a child of J. Rosenberg (http://www.jdrosen.net/) et. al. So there is no wonder. Jonathan makes his job

Re: [Standards] [Fwd: Re: Namespace well-formedness and RFC3920bis backwards compatibility]

need to rewrite about 1 kloc in 46 files. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:[EMAIL PROTECTED]

Re: [Standards] UPDATED: XEP-0264 (File Transfer Thumbnails)

it. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] reliable messaging

if the remote client doesn't process the stanza because of an internal error (race condition for example). -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] reliable messaging

Dave Cridland wrote: Well, a broken client is by its nature unreliable There are no 100% unbreakable clients. I don't think you can do anything to prevent that. We can show to the sender that the recipient didn't receive the message. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x

Re: [Standards] reliable messaging

Kevin Smith wrote: How? If the client is broken, you have no way of knowing that it's not sending message receipts in error. Message receipts in error? What do you mean? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] reliable messaging

acknowledge mechanisms (xmpp:ping, message receipts etc.) are useless from that point. Let's don't do anything :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] reliable messaging

in SIP. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

[Standards] XEP-0215 and STUN/TURN

stun/turn services since corresponding specifications provide SRV records for that. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] XEP-0215 and STUN/TURN

Evgeniy Khramtsov wrote: Hello. I'm thinking of XEP-0215 implementation. In fact, the XEP is very simple to implement (at least on server), but that leads to configuration overkill. I imagine a system administrator maintaining a server with N nodes in a cluster and H virtual hosts. He wants

Re: [Standards] XEP-0215 and STUN/TURN

:-/ When in doubt, add another layer of indirection? :) +1. That's why I'm asking about shared secret request separation: we can implement only secret allocation in our server. If one wants to implement a discovery part as well in his own server - no problem ;) -- Regards, Evgeniy

Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)

pushing updates +1. I think a client should ask about credentials at the moment when it wants to create an allocation. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Fwd: Meeting minutes 2010-02-15

on statistics to make a decision, no? A lot of people are skeptical is not an argument :P -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)

to be wrong. Why? I think the exact opposite is true. We have item ID's so we can ignore duplicates. Bye, I guess because if a sender doesn't receive the response, this doesn't mean a receiver doesn't receive the request. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)

it is easier to implement on a server side ;) I have only the question to client implementors: is it possible to keep a credentials per allocation and perform an allocation almost immediately after credentials response, doesn't it introduce implementation problems? -- Regards, Evgeniy Khramtsov

Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)

) with XMPP server. What do you think? PS. I personally prefer short term credentials because it doesn't require implementing additional protection from dictionary attacks on TURN server and protects from using TURN server out of existing XMPP connection. -- Regards, Evgeniy Khramtsov

Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)

hostname. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] NEW: XEP-0279 (Server IP Check)

/extensions/xep-0279.html Why not use STUN? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] NEW: XEP-0279 (Server IP Check)

Peter Saint-Andre wrote: On 3/5/10 9:24 PM, Evgeniy Khramtsov wrote: Why not use STUN? Feel free to add that to your XMPP server and client. There is already STUN support in ejabberd :P For me it is unclear why we need another way to discover client's public ip, that's why I'm

Re: [Standards] NEW: XEP-0279 (Server IP Check)

rewrite IP addresses, that's why MAPPED-ADDRESS is now deprecated in favor of XOR-MAPPED-ADDRESS. This XEP doesn't have such protection. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] NEW: XEP-0279 (Server IP Check)

Tomasz Sterna wrote: If you don't like it, then don't use it. is not a technical argument. Indeed, there was no technical arguments. The only argument I saw was: hey guys, this XEP is simple! -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)

talk, more code! (c) :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] NEW: XEP-0279 (Server IP Check)

Nicolas Vérité wrote: I am not quite also what would happen with BOSH: if there's separate BOSH CMs and/or reverse proxies in the middle... Indeed, I guess this introduces the same problem with backends separation described by Tomasz. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x

Re: [Standards] update on issue processing

15.06.2010 15:09, Evgeniy Khramtsov wrote: 15.06.2010 07:39, Peter Saint-Andre wrote: I've performed initial triage on about 30% of the issues reported on 3920bis during WGLC (through the end of Section 4). Feel free to comment on the issues individually, via this list (preferred) or the issue

[Standards] MUC vcards

like that ;) What do you think of it? Is it possible to describe such behaviour in XEP-0045? Or do you know easier and more correct way to set vcard for a conference? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] XEP-0198 status

this. I can prepare initial raw version of the XEP if someone of you guys wishes to participate in this :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] SOCKS5 Bytestreams reviews

protocol cases (I wrote the implementation 4 years ago), so it is hard for me to compare. According to the history log, nothing should be done. Am I wrong? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] MUC vcards

in vCard details, so I completely rely on your opinion :) What I need is only a interoperable way to implement it :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Proposed XMPP Extension: JSON Content Type support

, it is better to choose another encoding scheme, not JSON. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] RFC vs privacy lists

stanzas sent from the server and from the recipient to himself. So it will be up to the implementation (there could be a configuration option). Will this solve the problem? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] RFC vs privacy lists

/wiki/mod_blocking It's waiting for client support, testing, and feedback before we can include it in a release. Regards, Matthew There is a patch available for ejabberd as well: https://support.process-one.net/browse/EJAB-695 -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Redirects in BOSH

a concern. On the plus side, the BOSH software (whether browser-based or stand-alone) knows a redirect is happening in this case, so you have a better opportunity to protect yourself at the application-level. So what is the decision? What approach should we choose? -- Regards, Evgeniy Khramtsov

Re: [Standards] Redirects in BOSH

03.05.2011 22:26, Evgeniy Khramtsov wrote: 26.02.2011 00:26, Matthew A. Miller wrote: On Feb 25, 2011, at 08:14 , Joe Hildebrand wrote: If the redirect comes from a trusted source (e.g. over HTTPS with a verified certificate) then this can work ok, although we've decided that the BOSH see

Re: [Standards] Redirects in BOSH

a new one. You don't need to hand-off a session all the time, sometimes you just need to redirect a client to a correct node (where the state is kept) to avoid inter-node traffic overhead. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Redirects in BOSH

? It would be great to push some state in the cookies to avoid state sharing across the cluster. Also, a front-end can use them to make route decision without asking the back-end (XMPP server). -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Redirects in BOSH

10.05.2011 15:03, Evgeniy Khramtsov wrote: 10.05.2011 02:29, Glenn Maynard wrote: ... OK, it's not a big deal to use redirects on clients, we can move that part on front-end servers, such as nginx. So I have a question about cookies: is it ok to use them? Are there any problems with them

Re: [Standards] Redirects in BOSH

in the majority of clients even though that's XMPP core stuff. New XEP will not change things: client developers just don't care about scalability. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Redirects in BOSH

.) Such scaling is not a way to go: balancing doesn't help you to much until you have too many *shared* data across a cluster. A good approach is taken by SIP folks: they put some pieces of state in packets using record-routing technics and this works very good. -- Regards, Evgeniy

Re: [Standards] Redirects in BOSH

agrees and disagrees: it's a matter of choice and we need to provide it. If you don't need it you don't use it, that's simple. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Redirects in BOSH

it, then we should RECOMMEND it. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] NEW: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)

registers md2, which has been dropped from new openssl versions and, thus, makes it harder to implement. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

25.08.2011 08:52, Matthew A. Miller wrote: I think in this case, we'll survive (-: I don't like PEP, so I won't :P Having the ability to know when a vCard changes without having to poll is very very very nice. We already have vcard-temp:x:update for that. -- Regards, Evgeniy Khramtsov

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

25.08.2011 13:59, Matthew A. Miller wrote: On Aug 24, 2011, at 20:43, Evgeniy Khramtsov wrote: I don't like PEP, so I won't :P What specifically about PEP do you not like? Or you can discover how to stop worrying and love the PEP (-: As for me, PEP scales poorly. I have already wrote

Re: [Standards] request for reviews: XEP-0045 v1.25rc5

and we are going to include it in the new ejabberd version. Please don't remove the feature from the spec. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Time to look at anti-spam XEPs? [Fwd: Re: [Operators] Strange users]

think we have a significant spamming problem on jabber. So, is it time to bring up the various anti-spam/abuse related XEPs? You're not the first telling this. And all those XEPs are deferred now :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Security Question with see-other-host

of successive redirects (e.g., at least 2 but no more than 5). Does anyone have any clarification to this section and the specific DoS threat if TLS (or authentication) does not happen before see-other-host? Indeed, what problem could occur with unauthenticated redirections? -- Regards, Evgeniy

Re: [Standards] Proposed XMPP Extension: Using Efficient XML Interchange (EXI) Format in XMPP

/extensions/inbox/exi.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. Are there any fast and robust C-implemented libraries for exi recommended? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

. any JID carrying server.com should match). This will allow us to add the whole servers to the matching lists. 4) There is no XML schema. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.

Re: [Standards] Re-escalating update of XEP-0313: MAM

On 11.10.2013 20:28, Valérian Saliou wrote: Also, would be nice if someone could code an ejabberd and an Openfire implementation, this would really push clients forward to implementing it quickly. There is an implementation in commercial version of ejabberd. I wrote it, the issues with the