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 XEP I found I reported here: http://mail.jabber.org/pipermail/standards/2013-July/027761.html (mostly cosmetic bugs).
Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)
On 12.06.2013 06:38, XMPP Extensions Editor wrote: Version 0.2 of XEP-0313 (Message Archive Management) has been released. Some feedback if you don't mind. 1) archived/ tag in the example 1, para 3.1 MUST be within 'urn:xmpp:mam:tmp' namespace or otherwise it falls under 'jabber:client' namespace which is wrong. 2) same for message/ tag included in forwarded/ tag: it MUST possess 'jabber:client' namespace. See XEP-0297, 3.2, rule 2 for the explanation. 3) Regarding 5.3 JID matching. I think we should allow bare servers JIDs in always/never lists and process them as *@server.com (i.e. 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] Proposed XMPP Extension: Using Efficient XML Interchange (EXI) Format in XMPP
On 14.03.2013 00:45, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Using Efficient XML Interchange (EXI) Format in XMPP Abstract: This specification describes how EXI compression can be used in XMPP networks. URL: http://xmpp.org/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] Security Question with see-other-host
On 25.01.2012 09:30, Mike Wacker wrote: I saw this in RFC 6120: To reduce the possibility of a denial-of-service attack, (a) the receiving entity SHOULD NOT close the stream with a see-other-host/ stream error until after the confidentiality and integrity of the stream have been protected via TLS or an equivalent security layer (such as the SASL GSSAPI mechanism), and (b) the receiving entity MAY have a policy of following redirects only if it has authenticated the receiving entity. In addition, the initiating entity SHOULD abort the connection attempt after a certain number 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 Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Time to look at anti-spam XEPs? [Fwd: Re: [Operators] Strange users]
On 13.10.2011 00:44, Kim Alvefur wrote: Forwarded Message From: Mathias Ertlm...@fsinf.at Reply-to: XMPP Operators Groupoperat...@xmpp.org To: operat...@xmpp.org Subject: Re: [Operators] Strange users Date: Wed, 12 Oct 2011 15:51:23 +0200 [...] To make a long story short: I 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] request for reviews: XEP-0045 v1.25rc5
On 20.09.2011 08:46, Peter Saint-Andre wrote: On 9/19/11 4:40 PM, Alexander Holler wrote: No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter We have a patch 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] 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, ProcessOne. xmpp:x...@jabber.ru.
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 on the topic in this list and I'd like not to restart that flame :) We already have vcard-temp:x:update for that. In my opinion, vcard-temp:x:update is a hack: * It is documented in XEP-0153 solely for vCard(-temp)-based avatars So? :) * It violates at least one SHOULD in RFC 6121 § 4.2.2 (presence update not related to a user's availability for communication or the communication capabilities of the resource) SHOULD is not a MUST. Violate if you want. * It requires at least one resource for a user to be or become online (inappropriate to impossible for corporate/enterprise deployments) Is it really a big issue? Also, what happens when XEP-0292 supersedes XEP-0054? Indeed, what? I really have no idea :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] NEW: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
30.06.2011 01:37, XMPP Extensions Editor wrote: Version 0.1 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Initial published version. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0300.html I'd like to see http://xmpp.org/extensions/xep-0115.html#security-mti pointing to this XEP instead of IANA Hash Function Textual Names Registry http://www.iana.org/assignments/hash-function-text-names, because the latter 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] Redirects in BOSH
10.05.2011 15:52, Glenn Maynard wrote: On Tue, May 10, 2011 at 1:03 AM, Evgeniy Khramtsovxramt...@gmail.comwrote: 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? Should we add a note about them in the XEP? 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). It won't work in practice: many clients will just ignore them. That's the sort of thing that should be done by XMPP, not by BOSH. BOSH is just a transport layer; it's another way of transporting the higher-level XMPP protocol. How that could be done by XMPP??? We don't even have see-other-host/ supported 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
10.05.2011 16:45, Glenn Maynard wrote: On Tue, May 10, 2011 at 2:08 AM, Evgeniy Khramtsovxramt...@gmail.comwrote: How that could be done by XMPP??? We don't even havesee-other-host/ supported 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. You don't have support for it in BOSH, either, so either way it'd be introducing a new feature that wouldn't be well-supported for a long time. New feature wouldn't be supported at all, as practice shown: there were XEP about sessions handoffs, now, who can recall it's number? Scaling XMPP seems straightforward: load-balance the XMPP/BOSH front ends via DNS or any other mechanism, and handle message routing behind the scenes. Exposing that to the front-ends seems unnecessary, and just introduces ways for things to go wrong.) 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 Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
10.05.2011 17:21, Glenn Maynard wrote: On Tue, May 10, 2011 at 3:10 AM, Evgeniy Khramtsovxramt...@gmail.comwrote: New feature wouldn't be supported at all, as practice shown: there were XEP about sessions handoffs, now, who can recall it's number? Doing it in BOSH would also be a new feature. It is pretty possible to make this feature backward compatible: if you don't see Cookie in a packet, you route that packet internally. 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. I disagree, but I don't have time right now to get into a long discussion about it. If anyone else wants to, feel free... Of course, there are always someone who 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
11.05.2011 06:17, Glenn Maynard wrote: On Tue, May 10, 2011 at 3:33 AM, Evgeniy Khramtsovxramt...@gmail.comwrote: It is pretty possible to make this feature backward compatible: if you don't see Cookie in a packet, you route that packet internally. Nothing stops you from using it if the client supports it; the spec doesn't prohibit other headers from being set. I'm just opposed to BOSH *requiring* cookie support from clients. I don't understand your position: I don't want it, so noone should want it. That's not how standards are written. If we can't require it, then we should RECOMMEND it. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
09.05.2011 15:57, Glenn Maynard wrote: Thinking about this and doing a bit of spec refreshing, a lot of problems with HTTP redirects come to mind: XHR will silently redirect from HTTPS to HTTP if the server tells it to. This is a major problem if the client is configured to refuse to connect to a server insecurely; that's a setting servers should not be able to bypass. This should be handled correctly: if a server redirects from HTTPS to HTTP, then it will have problems. You want to be sure that requests in a session don't keep going to the original server, redirecting every time. This will happen if the HTTP client doesn't support caching (or do so correctly) in order to cache the redirect. What is a problem here? I think it's mostly an optimization issue for a client. As Matthew said, I don't think there's any way to detect that you've been redirected with XHR. The client may want to know this; for example, to attempt to resume a session across browser restarts by caching SIDs in localStorage, you want to know if the server you're talking to has changed. Not sure about XHR, I'm not an AJAX expert. Some clients don't redirect correctly. RFC2616 notes: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. This would be fatal for BOSH. (Even current versions of Wget still do this, so there may be client libraries in the wild that still do, too.) Then this should be fixed in clients and libraries. RFC2616 also says about all redirect types: If the 3xx status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. I don't know how many clients actually implement this requirement (HTML forms in browsers do, but XHR doesn't), but it would break BOSH. I don't know why this requirement exists and whether it is applicable for BOSH since all our requests are POSTs. I have a hard time seeing session hand-offs ever actually working. They'll be rare and require careful handling in clients, so they won't be handled reliably, so servers in turn won't use them. It seems a lot saner to just terminate the session and negotiate 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
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? Should we add a note about them in the XEP? 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? Should we add a note about them in the XEP? 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). Hum, in the XEP-0124 there are some notes about cookies: 1) BOSH can address the needs of constrained clients by employing fully-compliant HTTP 1.0 without the need for cookies or even access to HTTP headers. 2) Clients are not required to have programmatic access to the headers of each HTTP request and response (e.g., cookies or status codes). 3) Requiring cookies is sub-optimal because several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers. Not sure what that means. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
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-other-uri error is easier to control through XMLHTTPRequest, particularly when doing CORS. Be careful that you don't blindly accept redirects, however, or you are trivial to man-in-the-middle attack. If the redirect is via HTTP 3xx+cookie, then CORS already has a solution via Access-Control-* headers. However, the XMLHttpRequest objects in browsers don't always let you know this happened. Maintaining the redirect then becomes the responsibility of the browser, which may not be desirable for BOSH (I don't think it's desirable, anyway (-: ). If done via the see-other-uri BOSH error condition, then this is definitely 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? My thoughts: 1) see-other-host/ is a bit different stuff, it doesn't allow you to redirect without closing the C2S session, just because it's stream:error/ 2) if you don't use SSL, then you are affected by MITM attack no matter what transport you use. 3) security considerations of cookies are covered by the RFC6265. Peter is an Area Director of the corresponding WG, so he could say more if there are huge concerns about the topic which stops us to use 30x+Cookies, but he had no objections :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
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-other-uri error is easier to control through XMLHTTPRequest, particularly when doing CORS. Be careful that you don't blindly accept redirects, however, or you are trivial to man-in-the-middle attack. If the redirect is via HTTP 3xx+cookie, then CORS already has a solution via Access-Control-* headers. However, the XMLHttpRequest objects in browsers don't always let you know this happened. Maintaining the redirect then becomes the responsibility of the browser, which may not be desirable for BOSH (I don't think it's desirable, anyway (-: ). If done via the see-other-uri BOSH error condition, then this is definitely 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, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] RFC vs privacy lists
28.04.2011 23:30, Yann Leboulanger wrote: Le 28/04/2011 15:20, Matthew Wild a écrit : On 28 April 2011 14:16, Yann Leboulangeraste...@lagaule.org wrote: Le 28/04/2011 14:12, Remko Tronçon a écrit : I thought we had established incoming means incoming from the client's POV. Right, i actually meant the whole chain, up to and including the server part (up to the stanza router). It doesn't make sense to filter out stanzas from your own server (not talking about the ones from other users on your server). But the XEP could use some more specification of what incoming really is to avoid this problem of shooting yourself in the foot. if that could be written in XEP-0016 that incoming iq is from a client to another client, or at least not from user's server to user, that would be perfect I think. And probably that clients should not send iq get|set to jid that are blocked Why not just clarify that privacy lists only block incoming iqs of type set/get? Doesn't that solve everything in the least surprising way? that would, yes, but isn't it a problem to be spammed with iq result|error? Such spam is a concern, indeed. I think the server SHOULD NOT block incoming 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
28.04.2011 23:19, Matthew Wild wrote: On 28 April 2011 14:13, Yann Leboulangeraste...@lagaule.org wrote: Unfortunatly the goal of this XEP is not met: latest ejabberd and prosody don't implement that XEP. I've not checked other servers. http://code.google.com/p/prosody-modules/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] Proposed XMPP Extension: JSON Content Type support
26.04.2011 21:28, Dave Cridland wrote: On Wed Apr 20 16:35:55 2011, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: JSON Content Type support Abstract: This specification defines JavaScript Object Notation (JSON) use in XMPP service. URL: http://www.xmpp.org/extensions/inbox/json.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. And XEP-0292 isn't good enough? There's three problems I see with this. 1) It's extremely underspecified. '$' and '$$' are, for instance, never specified. 2) This doesn't really mean that you don't need an XML parser, because you still need to process XMLNS rules, etc. If you *don't* - ie, if the JSON encoding expands all namespaces, then the data sizes will increase vastly. 3) It's not at all clear to me that the mapping is truly reversible or complete. I would expect each DOM node to have representation, and it doesn't seem to be the case. I'm not a massive XML fan, to be honest. If we length-delimited stanzas and used a clean header format, I'd be happier. But the fact is that we *do* use XML, and removing XML entirely just seems like a path without any clear merit. In particular, it's not clear what JSON encoded XMLstreams actually gains us, given the limitations of the JSON encoded XML and the prevelance of XML throughout the deployed network. Dave. Agreed. Probably, if we need an XML replacement, it is better to choose another encoding scheme, not JSON. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] MUC vcards
24.03.2011 03:25, Peter Saint-Andre wrote: I think it would be good to have an example of this in the new vcard spec (XEP-0292). However, in the IETF's VCARDDAV WG I argued for KIND:thing and didn't succeed, so we might want to define a vcard4 extension for that. I'm not an expert 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] SOCKS5 Bytestreams reviews
02.03.2011 02:00, Peter Saint-Andre wrote: As you probably noticed, this morning we published version 1.3 of XEP-0047 (In-Band Bytestreams), incorporating implementation feedback from various client (and server!) developers. What should be changed on the server? I don't remember the exact 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] XEP-0198 status
13.01.2011 05:26, Peter Saint-Andre wrote: That seems mostly reasonable to me. I see a possible edge case if the reconnecion address (ip:port or host:port or whatever) isn't actually there by the time the initiating entity tries to reconnect, i.e., the server tells me the reconnection address and a few days later when my session dies I finally try to reconnect but the address that the server *thought* was going to work a few days ago isn't so much alive anymore. Do we need to worry about that? If so, does the initiating entity just follow the rules from 3920bis regarding the connection process? (See for instance the rules forsee-other-host/ in 3920bis...) I think we need more formal description on this. An *informational* XEP about load-balancing and clustering would be nice. The XEP should describe: 1) possible ways of making clustering and load balancing, describing problems with sharing XMPP-specific data, so server implementors has a variety of options and a complete picture. 2) what technics are preferable (see-other-host/ from the RFC, proposed enabled/ from XEP-0198, redirect technics in BOSH and so on) in order to make sure clients can correctly handle 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.
[Standards] MUC vcards
We've got a feature request to make it possible to set and get vcards of multi-user conference. There is no problem with retrieving vcard, but setting it requires a trick: an owner of a conference can send vcard-temp request to the conference: iq id='v2' type='set' from='owner_of_c...@jabber.org' to='c...@conference.jabber.org' here-goes-vcard/ /iq A conference MUST check if the sender is really owner and set the vcard ;) If the vcard contains PHOTO element, sha1 SHOULD be calculated and SHOULD be provided in every presence sent from bare JID of the conference. Well, something 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] 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 tracker. I'm going to take a break now, but will continue to process issues throughout the week. /psa The only thing I'd like to see in the bis is see-other-host/ error among other SASL errors. So a server is able to redirect a user to another node of a cluster (typically, redirection is based on a hash of a JID). Oops, seems like we can use see-other-host/ from Stream Errors for this purpose. So my suggestion doesn't make much sense, sorry ;) -- 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...@jabber.ru.
Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)
Peter Saint-Andre wrote: Another suggestion: we need to pass 'type' attribute in credentials/ request, because different services may share the same hostname. Another suggestion: we make you the maintainer of this XEP. ;-) Peter I really appreciate this, but I like the idea of Less talk, more code! (c) :) -- 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] NEW: XEP-0279 (Server IP Check)
Matthew Wild wrote: People want this, it's trivial to do, we should standardize a way of doing it. Done. Actually there is already a standard for address discovery - STUN. By the way, you didn't tell why this XEP is useful and why it is better than STUN, or when to use this XEP and when to use STUN. Now this XEP isn't telling people not to use STUN, TURN, UDP or Jingle... it's for the people who don't want or need to use those technologies (perhaps for the moment). This XEP adds incomprehension: a Jabber developer might be confused which approach to choose: this XEP or STUN. I don't feel we should be limiting what people want to do with XMPP, or how they should build their applications Agreed. But I think we need to use a common well-tested solution, and not invent our own without necessity, if possible. BTW, STUN has a protection from poorly written ALGs which 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)
XMPP Extensions Editor wrote: Version 0.1 of XEP-0279 (Server IP Check) has been released. Abstract: This specification defines a simple XMPP extension that enables a client to discover its external IP address. Changelog: Initial published version. (psa) Diff: N/A URL: http://xmpp.org/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 asking -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)
Peter Saint-Andre wrote: Or shall we expect the client to ask about services (e.g., TURN servers) only at the moment it is attempting to prepare candidates for a negotiation? I think yes. Looking through my code I was thinking a little more about shared secret allocation manner. Here are my points: In the case of a shared secret per session, we have troubles with s2s users, since there is no session in s2s and we don't know how to delete stale shared secrets. So I think the easiest solution is to create a new unique username/password pair per credentials requests (and thus per single allocation), but this requires from a server to clean the secret if the allocation was not created in meaningful amount of time (to avoid credentials table overflow from rogue users) as well as clean the secret after the corresponding allocation completes. I prefer this way because 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, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)
XMPP Extensions Editor wrote: Version 0.5 of XEP-0215 (External Service Discovery) has been released. Abstract: This document specifies an XMPP protocol extension for discovering services external to the XMPP network. Changelog: Added ability to request credentials from a particular service; incremented the protocol version number to reflect the new feature. (psa) Diff: http://xmpp.org/extensions/diff/ URL: http://xmpp.org/extensions/xep-0215.html A suggestion: we need to provide a fallback in the case when a server doesn't support shared credentials: in that case a client MUST use long term authentication using its jid/password. This is usefull when there is single TURN server serving both XMPP and SIP domains or when there is no way to exchange shared secrets between XMPP and TURN server. In those cases TURN server may share authentication backend (SQL or whatever) 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, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] UPDATED: XEP-0215 (External Service Discovery)
XMPP Extensions Editor wrote: Version 0.5 of XEP-0215 (External Service Discovery) has been released. Abstract: This document specifies an XMPP protocol extension for discovering services external to the XMPP network. Changelog: Added ability to request credentials from a particular service; incremented the protocol version number to reflect the new feature. (psa) Diff: http://xmpp.org/extensions/diff/ URL: http://xmpp.org/extensions/xep-0215.html Another suggestion: we need to pass 'type' attribute in credentials/ request, because different services may share the same hostname. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)
Pedro Melo wrote: There are a myriad of ways the original IQ or the ack could get lost. My point is that the response does not serve any value to the sender, since I don't believe there is anything useful to be done when the sender does not receive the ack. Resending is almost always going 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)
Justin Karneges wrote: It seems like it would be easier at the server end to have credentials be created at the time of iq get, and that the client should perform the iq just before needing to use the TURN service. The creds would have a lifetime with this in mind. And then just forget about 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
Peter Saint-Andre wrote: 2. Compression makes multicast structures unnecessary. It does? A lot of people are skeptical about the argument oh don't worry about how verbose this is, compression will solve the problem. Indeed. Does anyone have statistics? I think we should rely 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] XEP-0215 and STUN/TURN
Peter Saint-Andre wrote: Yes, I think that SIP and XMPP can share TURN credentials. Why not? From the perspective of the TURN relay there is no difference between the two (as far as I can see). Actually there may be a problem when both SIP and XMPP server have its own embedded TURN server :-/ 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 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 to configure a stun, stuns, turn and turns server in external discovery. In that case he need to create N*3*H*3*H records in the configuration file: a stun and turn takes 3 sections per virtual host (udp, tcp and tls) each and requires to configure it on every node. If N=2 and H=2 (a cluster of 2 nodes and 2 virtual hosts) he needs to create 72 records! Of course a server software may provide a technique to reduce the overhead, but that may cause a configuration file complexity. Personally, I'm interesting in a short-term credentials allocation for a TURN server. I think DNS is the right place to discover stun/turn services since corresponding specifications provide SRV records for that. I think we can move the secret allocation part in a separate request. Example: iq type='get' from='b...@shakespeare.lit/globe' to='shakespeare.lit' id='all1' secret xmlns='urn:xmpp:extdisco:0' type='turn'/ /iq iq type='result' from='shakespeare.lit' to='b...@shakespeare.lit/globe' id='all1' secret xmlns='urn:xmpp:extdisco:0' type='turn' username='jl2er' password='iowerf324'/ Or something like that. What do you think? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
[Standards] XEP-0215 and STUN/TURN
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 to configure a stun, stuns, turn and turns server in external discovery. In that case he need to create N*3*H*3*H records in the configuration file: a stun and turn takes 3 sections per virtual host (udp, tcp and tls) each and requires to configure it on every node. If N=2 and H=2 (a cluster of 2 nodes and 2 virtual hosts) he needs to create 72 records! Of course a server software may provide a technique to reduce the overhead, but that may cause a configuration file complexity. Personally, I'm interesting in a short-term credentials allocation for a TURN server. I think DNS is the right place to discover stun/turn services since corresponding specifications provide SRV records for that. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] reliable messaging
Dave Cridland wrote: It's possible, I suppose, that the remote client went offline before the message/, and came back online after, just in time to get the iq/, but it seems terribly unlikely, especially as you'd also see a presence/ update as it came back online. This may also happens 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...@jabber.ru.
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
Kevin Smith wrote: If your message isn't processed due to an internal client error, how are you able to trust that the client knows that it wasn't processed, and doesn't just send a receipt blindly? Indeed, there is no way to know if received acknowledgement is not false. Therefore all 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
Dave Cridland wrote: I think that includes receipt of a response to a ping sent immediately after the message, if nothing more atomic is available. With the exception that ping introduces addition traffic overhead and complexity in an implementation. My point is to ack everything just like in SIP. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] UPDATED: XEP-0264 (File Transfer Thumbnails)
XMPP Extensions Editor wrote: Version 0.2 of XEP-0264 (File Transfer Thumbnails) has been released. Abstract: This specification defines a way for a client supply a preview image for a file transfer. Changelog: Add paragraph in security section about protecting agains malicious thumbnail dimensions in offer. Fixed a typo. (ml) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0264.xml?%40diffMode=u%40diffWrap=sr1=2962r2=3000u=3ignore=k= URL: http://xmpp.org/extensions/xep-0264.html Useful XEP. I believe it will not be retracted. I really need to implement it. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] [Fwd: Re: Namespace well-formedness and RFC3920bis backwards compatibility]
Sergei Golovan wrote: That's a bug and I thought it was corrected in version 2.x. When I talked to ejabberd author he said that this bug will never be fixed until it will be absolutely clear from reading RFC that it's a bug. Cheers! BTW, that bug would be not very easy to fix. We need to rewrite about 1 kloc in 46 files. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:[EMAIL PROTECTED]
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] 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 servers. Currently STUNbis is a low level protocol which you can use in other protocols such as ICE and TURN. However, as Rémi Denis-Courmont has pointed out [2] on the IETF's BEHAVE list, it is not necessary for the relay to be a TURN server. It's great if the relay is a TURN server, but it could be something else -- and the important point is that for the purposes of media relaying it doesn't really matter to the Jingle client whether the relay does TURN or something simpler. I can't agree :) Why do we need a zoo of relay servers? What is it for?
