Re: [jdev] Spoofing of iq ids and misbehaving servers
Hi Thijs, On Thu, Jan 30, 2014 at 4:49 PM, Thijs Alkemade m...@thijsalkema.de wrote: But what baffles me even more is that it almost appears like nobody else ever ran into this problem. Is it really the case that every XMPP client out there does not check for the correct 'from' on result iqs either? Or have they all implemented workarounds to deal with the incorrect behavior of the servers listed above? I faced the same problem in Tkabber a while ago. And a bit more. The other issue with this 'to'-'from' tracking is that you'll have to implement proper JID matching (with stringprep), which wasn't available in Tkabber at the moment. So, I've ended up using random ids (not long though and generated by not a sophisticated PRNG, but still). Cheers! -- Sergei Golovan ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] SOCKS5 Bytestream initiation between chat users in Semi-Anonymous room
On Sat, Jun 14, 2008 at 3:35 AM, Daniel Atallah [EMAIL PROTECTED] wrote: The issue that I'm running into is that because the real JID of the initiator is different than the JID the target is seeing (and vice versa), the DST.ADDR hashes generated by the sender and recipient don't match and consequently the SOCKS5 connection initiation must fai. Tkabber simply uses MUC JIDs ([EMAIL PROTECTED]/nick) when it sends a request to or receives it from a MUC contact. -- Sergei Golovan ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
[jdev] Tkabber 0.11.0 is released
Hi! I'm pleased to announce that Tkabber 0.11.0 is released. Tkabber is an advanced XMPP client written in Tcl/Tk. The release highlights are: * New tabbed user interface. Tab headers now occupy several rows and tab bar can be docked to the left and right sides of chat window * Roster filter * Added support for pixmaps (in particular emoticons) JISP archives (XEP-0038) * Added support for SOCKS4a and SOCKS5 proxy for the main connection * Added user location support (XEP-0080) * Added user mood support (XEP-0107) * Added user activity support (XEP-0108) * Added user tune support (XEP-0118) * Added entity capabilities (XEP-0115 v.1.5, only reporting) support * Added basic robot challenges support (XEP-0158) * Roster is now exported to XML instead of Tcl list * Added support for entity time (XEP-0202) * Tkabber version is now reported in disco#info (XEP-0232) * Moved deprecated Jabber Browser (XEP-0011) to an external plugin * Moved Jidlink file transfer to an external plugin * Added several new plugins: attline, ctcomp, custom-urls, floatinglog, gmail, openurl, presencecmd, receipts * Many fixes and enhancements To download Tkabber visit http://tkabber.jabber.ru/download -- Sergei Golovan ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] Reproducability of XEP-0115: Entity Capabilities - 5.3 Complex Generation Example
On 4/22/08, Stephan Maka [EMAIL PROTECTED] wrote: Yann Leboulanger [EMAIL PROTECTED] wrote: Why do http://jabber.org/protocol/caps and http://jabber.org/protocol/muc include a trailing white-space, opposed to their representation in the Service Discovery result? I don't see any space, but I don't see where in the disco resutl there I guess spaces are added to allow line breaking. Hash is computed for the string without spaces. Look again. I can't even reproduce with the SHA-1 method given in XEP-0115: Remove http://jabber.org/protocol/caps from a hashed string and you'll get the desired hash value. Because it is required. Perhaps this is a bug in the XEP? It looks like a bug in XEP. -- Sergei Golovan
[jdev] Retrieving items list for a pubsub nide
Hi! Looking at section 5.5 of XEP-0060 (http://www.xmpp.org/extensions/xep-0060.html#entity-discoveritems) I see that disco#items query is used for retrieving published items list. However, published items are very different from disco#items. If a naive client attempts to interpret published item as an ordinary disco item it will succeed but the result will be quite strange. Example: iq id='21' to='[EMAIL PROTECTED]' type='get' xml:lang='en' query xmlns='http://jabber.org/protocol/disco#items' node='http://jabber.org/protocol/mood'/ /iq iq from='[EMAIL PROTECTED]' id='21' type='result' to='[EMAIL PROTECTED]/resource' query node='http://jabber.org/protocol/mood' xmlns='http://jabber.org/protocol/disco#items' item name='mood1' jid='[EMAIL PROTECTED]'/ item name='mood2' jid='[EMAIL PROTECTED]'/ /query /iq A client will interpret the answer as if JID [EMAIL PROTECTED] have a natural name (as in XEP-0030) mood1 or mood2. To be able to process items list correctly two conditions must be met: 1) A client must support pubsub. 2) A client must know that a discovered node is a pubsub leaf node (so, it must perform a preliminary disco#info query) and its interpretation of disco#items query must depend on the context (which makes client development more complicated). Is there any valid reason why disco#items query is used for requesting published items (except that both are items)? Maybe it would be better to switch to some more appropriate custom protocol? Cheers! -- Sergei Golovan
Re: [jdev] Authentication Process For Jabber.com
On 3/10/08, Justin Karneges [EMAIL PROTECTED] wrote: On Sunday 09 March 2008 5:49 pm, Peter Saint-Andre wrote: Correct. The spec currently does not say that the server must enforce that rule. But naturally the recipient (or the sender's or recipient's server) could return a stanza error on receiving it. A not-acceptable/ error seems appropriate: message type='error' error type='modify not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/ /error gajim:die/ /message Hmm, you should probably not send the original XML back in this case, since it is invalid. The XML here isn't invalid, but so-called namespace-non-well-formed. And it indeed breaks XML parsers, which take into account XMLNS prefixes (which they MAY do according to clarified RFC-3290-bis). Further, since some XML parsers throw error when an unrecognized prefix is encountered, those clients/servers would most likely respond not with a stanza error, but with an xml-not-well-formed *stream* error and close the connection. I think we have to be very careful about how this stuff is routed. Obviously clients shouldn't be generating invalid XML, but servers shouldn't be routing it either. A good server would disconnect whoever sent gajim:die rather than routing it and DoS'ing other clients. I would like to see (probably in a separate section) rules for closing streams like the following: 1) If an entity sends non-well-formed XML as defined in http://www.w3.org/TR/2006/REC-xml-20060816 then the receiving entity MUST close the stream and return xml-not-well-formed error. 2) If an entity sends namespace-non-well-formed XML as defined in http://www.w3.org/TR/REC-xml-names then the receiving entity MUST close the stream and return xml-not-well-formed error (or may be it's better to introduce a separate error for this case). 3) IF an entity defines XMLNS prefix in a stream header and use it in a stanza (which means that the stanza isn't routable as is) then the receiving entity MAY close the stream and return xml-non-well-formed error, but SHOULD move namespace definition to a stanza level (or convert namespace prefix into xmlns attribute) and process the stanza. (The third rule is arguable though.) These rules ensure namespace-well-formedness of XMPP streams, and no custom XML parsers will be necessary to parse XMPP streams. Currently, general XML parsers either ignore namespace prefixes at all (which means that clients using them will loose some data) or break on unbound prefixes (which means disconnections on gajim:die/). -- Sergei Golovan
Re: [jdev] Authentication Process For Jabber.com
On 3/9/08, Peter Saint-Andre [EMAIL PROTECTED] wrote: Therefore, this is wrong: stream:stream xmlns:stream='http://etherx.jabber.org/streams' messagegajim:die//message /stream It means that it's wrong to send this stanza. But it doesn't mean that it's wrong to accept this stanza. -- Sergei Golovan
Re: [jdev] Authentication Process For Jabber.com
On 2/28/08, Fabio Forno [EMAIL PROTECTED] wrote: On Thu, Feb 28, 2008 at 7:56 AM, Sergei Golovan [EMAIL PROTECTED] wrote: It could be true if XMPP were defined as a XML subset in a consistent way (currently, XMPP doesn't require stream to be namesapce-well-formed, but allows to use XMLNS namespaces). Not true: http://www.xmpp.org/rfcs/rfc3920.html paragraph 4.5 In paragraph 11.3 you could see that the only property which server must validate is XML well-formedness. So, it is perfectly acceptable for XMPP stream not to be namespace-well-formed as defined in http://www.w3.org/TR/1999/REC-xml-names-19990114/ -- Sergei Golovan
Re: [jdev] Authentication Process For Jabber.com
On 2/29/08, Norman Rasmussen [EMAIL PROTECTED] wrote: The point is that: stream:stream xmlns:stream='http://etherx.jabber.org/streams' messagegajim:die//message /stream contains an unbound prefix 'gajim', so MUST be rejected by all XMPP parsers.. If you want to send xml that looks similar to that, you need to transmit one of the following: Just find any rule in RFC 3290 which forbids this stanza with unbound prefix and I'll immediately file a bugreport to ejabberd. -- Sergei Golovan
Re: [jdev] Authentication Process For Jabber.com
On 2/29/08, Norman Rasmussen [EMAIL PROTECTED] wrote: RFC 3920: 11.2, says xml-names is to be used, Does this mean XMPP stream MUST conform [XML‑NAMES]? I don't see that strong statement. So please go and log a bug against ejabberd. If I were an ejabberd developer I'd reject this bugreport as invalid. -- Sergei Golovan
Re: [jdev] Authentication Process For Jabber.com
On 2/28/08, Tomasz Sterna [EMAIL PROTECTED] wrote: Implementing a correct XML parser is very tedious and error prone job. It's always better to use one of the publicly available and well established parsers. Other way you'll end up redoing the hard work the implementers of these parsers did already. ;-) It could be true if XMPP were defined as a XML subset in a consistent way (currently, XMPP doesn't require stream to be namesapce-well-formed, but allows to use XMLNS namespaces). But for now we got two famous examples: 1) Gajim uses XMLNS prefixes and expects them to be defined. So, it disconnects on receiving messagegajim:die//message. 2) Ejabberd doesn't respect XMLNS prefixes, so it doesn't understand query like the following: iq xmlns:v='jabber:iq:version'v:query/iq (but routes them happily). And the interesting problem is that generic XML parsers (expat for example) implement either namespace-well-formed document (with bound XMLNS prefixes, Gajim case) parsers or simpy ignore namespace prefixes (ejabberd case). This means that impementing XMPP software one have to either implement an XML parser or end up with either sometimes dying or somewhat incompatible software. It would be much better and easier to work with, if XMPP required XML streams to be namespace-well-formed. -- Sergei Golovan
Re: [jdev] Connectivity issues with gmail.com and googlemail.com
On 9/28/07, George Hazan [EMAIL PROTECTED] wrote: http://www.ejabberd.im/fix-dns-srv solved my problem. Thanks to badlop :) It's not my case. My server connects to gmail.com and is able to send messages (users at gmail.com receive them). Their messages can't reach me. -- Sergei Golovan
[jdev] Connectivity issues with gmail.com and googlemail.com
Hi!
Last few weeks I'm experiencing a loss of connectivity with gmail.com
and googlemail.com. It's interesting that my messages (from nes.ru to
gmail.com) rich recipients just fine, but messages from gmail.com
can't be delivered (users get error messages).
After switching off STARTTLS over S2S (which hides the problem) I got
the following ejabberd log (it's a typical scenario):
1) Google server connects to nes.ru:
=INFO REPORT 2007-09-19 20:35:31 ===
I(0.241.0:ejabberd_listener:90): (#Port0.6781) Accepted connection
{{72,14,252,129},30195} - {{212,119,199,80},5269}
(Note #Port0.6781. It's an Erlang port, which processes the TCP connection.)
2) ejabberd opens an incoming S2S stream:
=INFO REPORT 2007-09-19 20:35:31 ===
I(0.5062.0:ejabberd_s2s_in:105): started: {gen_tcp,#Port0.6781}
Now the stream is controlled by Erlang process 0.5062.0.
3) gmail.com sends a key
=INFO REPORT 2007-09-19 20:35:32 ===
I(0.5062.0:ejabberd_s2s_in:317): GET KEY: {nes.ru,
gmail.com,
[],
CAESBxC07cjz0SIaEEWGpREmNkivSJRYciOVI70=}
Note port number 0.5062.0.
4) nes.ru opens outgoing S2S stream to verify the key (it's irrelevant here)
5) googlemail.com sends a key over the same TCP connection (!):
=INFO REPORT 2007-09-19 20:35:32 ===
I(0.5062.0:ejabberd_s2s_in:317): GET KEY: {nes.ru,
googlemail.com,
[],
CAESBxC17cjz0SIaEBnkylXoIZMlEI4Y4qYXHDQ=}
The port is the same 0.5062.0. After that the connection is stalled.
ejabberd never receives anything in this stream.
For me it looks like a severe bug in Google Talk server.
Did someone experienced similar problems with gmail.com and
googlemail.com? May be Google Talk admins read this list and can help?
Cheers!
--
Sergei Golovan
Re: [jdev] Connectivity issues with gmail.com and googlemail.com
On 9/19/07, Philipp Hancke [EMAIL PROTECTED] wrote: Hi Sergei, 5) googlemail.com sends a key over the same TCP connection (!): That's called piggybacking. Then things become more complicated, and I don't know where the bug is. Ejabberd verifies both keys, sends dialback answers, and after 10 minutes of silence closes the socket. -- Sergei Golovan
Re: [jdev] Connectivity issues with gmail.com and googlemail.com
On 9/19/07, Sergei Golovan [EMAIL PROTECTED] wrote: On 9/19/07, Philipp Hancke [EMAIL PROTECTED] wrote: Hi Sergei, 5) googlemail.com sends a key over the same TCP connection (!): That's called piggybacking. Then things become more complicated, and I don't know where the bug is. Ejabberd verifies both keys, sends dialback answers, and after 10 minutes of silence closes the socket. Moreover, when I removed the only contact with JID [EMAIL PROTECTED] the situation remains the same. gmail.com opens the stream, and after the dialback is verified no more data comes through the socket. After ten minutes the socket is closed. It's very strange given that other ejabberd deployment don't have problems with Google Talk S2S. Cheers! -- Sergei Golovan
Re: [jdev] File Transfer Interoperability
On 8/8/07, Justin Karneges [EMAIL PROTECTED] wrote: I wouldn't put this at the IBB level. A negotiation timeout will work well enough there. The problem you speak of, which does indeed happen a lot, has more to do with the SI exchange. If someone offers a file, and you take too long to accept, they may cancel the file offer and you'll never know. This will happen regardless of whether you use S5B or IBB or anything. Any other file transfer method requires opening a socket by the receiving party. If the socket can't be opened then the stream is obviously invalid. IBB lacks this part, and I think it would be good to add it. It would make a file transfer working essentially the same regardless of the SI method used. -- Sergei Golovan
Re: [jdev] File Transfer Interoperability
On 8/8/07, Justin Karneges [EMAIL PROTECTED] wrote: In Psi we solved this by adding a timeout to the accept phase. The sender must begin the S5B negotiation within 30 seconds of the receiver Using timeouts is a common way to workaround poorly designed protocols. But isn't it better to fix protocol itself? In case of IBB adding new XEP (almost) doesn't cause any harm. pressing Accept. If the timeout expires, a dialog is presented to the receiver that says something along the lines of the sender probably cancelled. -- Sergei Golovan
Re: [jdev] File Transfer Interoperability
On 8/8/07, Justin Karneges [EMAIL PROTECTED] wrote: If the sender offers a file and then cancels it before the receiver accepts, then S5B hasn't even started yet. In other words, the sender hasn't sent the iq-set for the S5B open. Therefore, there are no sockets to time out, and the receiver will wait forever. Just like with IBB, just like with anything. It's an SI issue. You're right. It's a file transfer request which takes a long time to answer, and not an IBB one. If the sender cancels the file transfer immediately after the receiver accepts, then there is a chance that the sender may have started an IBB or S5B negotiation. This is much less common than the SI problem, and I think a timeout in IBB here would be enough to solve this situation of bad luck. Well, it would be better to clarify at least the most frequent stream breaks. As for now, there's no way to break file transfer gracefully (with error messgae which is shown to the peer). FWIW, S5B also doesn't specify any timeouts. If the receiver goes offline instead of replying with an iq, then the sender will wait forever (and this At least you'll notice that the receiver goes offline (not always though). And in case of sender I think that it's impossible to find a proper timeout. There always will be users complaining that they replied too late. is the case today with Psi). As you can see, endlessly waiting is not a feature of just IBB. We generally don't specify timeouts in XEPs. For Tkabber now uses timeout only when waiting for ping request. But probably it would be better to add some to file transfer part. example, how long should you wait for a vcard request to be answered? Hm. Is it important? You show a notebook (or any other GUI, or nothing if it's a text client) and some progressbar and fill in the fields on answer comes. I don't think that vcard requires timeout at all. -- Sergei Golovan
Re: [jdev] File Transfer Interoperability
On 8/8/07, Peter Saint-Andre [EMAIL PROTECTED] wrote: 3. IBB (XEP-0047) is a great fallback if all else fails. IBB couldn't be a great fallback. It's very inconvenient to use in the fillowing circumstances (which don't so rarely happen): 1) JID A offers file to JID B and waits for the answer (note that to answer, B must return an IQ result, and the time interval might be quite long). 2) JID A decides to abort file transfer and closes the file-transfer-window-or-whatever-GUI-she-has. 3) JID B replies with IQ result, but a) File transfer doesn't start (A aborted it) b) JID B will NEVER know about A aborted file transfer and will stuck with file-receiving-GUI forever since there's no mechanism to recognize this unwilling to transfer. Wouldn't it better to add an extra query from B to A after stream negotiation part? If A doesn't want to send file anymore, she will return error to B. Another possibility is to let JID B to ask any next file chunk (instead of pushing file in IQ set query, B sends IQ get query and receives a chunk in IQ result). Cheers! -- Sergei Golovan
Re: [jdev] XEP-0115: Entity Capabilities
On 6/27/07, Joe Hildebrand [EMAIL PROTECTED] wrote:
On Jun 27, 2007, at 5:53 AM, Sergei Golovan wrote:
I would consider this XEP dangerous and wouldn't like to implement it
in Tkabber. It's too easy for malicious user to flood all contacts
(and not only in his roster) by false information about all clients
and versions he wants.
I think that one never should apply info received from some user to
other users.
Please bring this up on the standards list if you want to talk about
it again, but this point has been beaten to death, I think.
And the only result of these discussions is a really small note in
'Security consideration' section. Which really does cover a small
portion of possible security concerns. I could imagine for example an
attack on future software versions (where the victim can't check the
correctness of capabilities because there's no other sources of
information).
You can always just query each user independently if you like; you
I think that the XEP must not recommend to cache capabilities based
only on reported software name and version. The more acceptable index
is a tuple {jid, client name, client version}.
only need to check it against the cache to look for disagreement, not
cache each one separately.
See the idea of an attack above.
--
Sergei Golovan
[jdev] Escaping JID using XEP-0106
Hi! Could someone clarify how to escape the following JID (and to split it into node, server and resource)? [EMAIL PROTECTED]/[EMAIL PROTECTED]/resource I could do it in two ways: 1) user jabber.org [EMAIL PROTECTED]/resource 2) user\40jabber.org\27user jabber.org resource XEP-0106 doesn't give an exact way of escaping such a JID. And if 1) or 2) is preferrable then there's no way (or it's not easy) to send a message to another JID. Best wishes! -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Tomasz Sterna [EMAIL PROTECTED] wrote: Dnia 27-06-2007, śro o godzinie 12:53 +0400, Sergei Golovan napisał(a): Could someone clarify how to escape the following JID (and to split it into node, server and resource)? [EMAIL PROTECTED]/[EMAIL PROTECTED]/resource This is not a JID. (in other words: this is invalid JID) There is no way of telling which part is a node, domain, resource. You need to escape it FIRST (using XEP-0106) to be a valid JID before trying to parse/split it. You're right. And the question is: How to escape it? Can escaping be done unambiguously? The problem is that if I get alredy escaped JID [EMAIL PROTECTED]/resource then I can unescape it and show to a user as [EMAIL PROTECTED]/[EMAIL PROTECTED]/resource. But what to do if a user enters such a JID into a client entry box and wants to send a message to it? Best wishes! -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Norman Rasmussen [EMAIL PROTECTED] wrote: On 6/27/07, Sergei Golovan [EMAIL PROTECTED] wrote: You're right. And the question is: How to escape it? Can escaping be done unambiguously? Yes, but only if you already know the split. So, a full unsecaped JID (with resource) can't be split unambiguously. Then I'm afraid we should do something with the XEP. The problem is that if I get alredy escaped JID [EMAIL PROTECTED]/resource then I can unescape it and show to a user as [EMAIL PROTECTED]/[EMAIL PROTECTED]/resource. But what to do if a user enters such a JID into a client entry box and wants to send a message to it? You have to provider two entry boxes, or require the the user enter a pre-escaped jid, and reject the ambiguous jid. There is another problem here. If the user receives message from [EMAIL PROTECTED]/resource I can't unescape JID because he will not know if the message came from [EMAIL PROTECTED] Using two entry boxes is not good IMHO. It breaks the idea of JID - the only user identifier in XMPP world. -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Matthias Wimmer [EMAIL PROTECTED] wrote: Matthias Wimmer schrieb: The resource is allowed to contain '@' as well as '/'. Everything behind the first '/' character in a JID is the resource. ... but this has nothing to do with XEP-0106 BTW. XEP-0106 is about mapping non-JID addresses in a JID. e.g. if you have a E-Mail address, that cannot map directly in a JID you will use XEP-0106. As far as I understand, XEP-0106 is also about visual representation of JID. And I think that if two different JIDs have one visual representation then it's bad. -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Tomasz Sterna [EMAIL PROTECTED] wrote: Dnia 27-06-2007, śro o godzinie 15:03 +0400, Sergei Golovan napisał(a): You're right. And the question is: How to escape it? Can escaping be done unambiguously? Yes. You have a node, domain and resource which you need to escape before concatenating them into JID. I didn't see any XMPP client, which requires to enter node and server separately in send message dialogs (I did see clients which asks for chatroom names). The problem is that if I get alredy escaped JID [EMAIL PROTECTED]/resource then I can unescape it and show to a user as [EMAIL PROTECTED]/[EMAIL PROTECTED]/resource. Well... You shouldn't show such a monstrosity to a user. Use the JID parts wisely. Show username, domain eventually resource. In general, I can show unescaped JID. But what's the idea of XEP-0106 then? But what to do if a user enters such a JID into a client entry box and wants to send a message to it? It's an invalid entry and you should return an error to the user. You've asked for a JID and the text entered isn't a valid JID. There is no way of telling which part is what without some external information. Unfortunately, it means that to be able to send message to such a strange JID the user has to khow how to escape it. Should users read XEPs? :) -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Matthias Wimmer [EMAIL PROTECTED] wrote: Hi Sergei! Ah okay ... it seems I start understanding what you are trying to do. You want to map a JID (or something like that) into another JID, e.g. for building the infamous Jabber-Jabber transport. Not exactly. I want to implement XEP-0106 in Tkabber and the idea was to show only unescaped JIDs to a user. But since different escaped (real) JIDs map to one escaped JID then it's impossible (user should definitely know who sent the message). My current yhought is the following: to show unescaped JID if and only if it can be escaped unambiguously. But this approach isn't good too (appending different resources we may break unescaping of any bare JID). So, probably I will not unescape / and @ in nodes. It should solve ambuguity. Or may be hiding real (escaped) JIDs from the user is a bad idea at all? Best wishes! -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Matthias Wimmer [EMAIL PROTECTED] wrote: HI Sergei! Sergei Golovan schrieb: Or may be hiding real (escaped) JIDs from the user is a bad idea at all? In fields where a general JID is expected, I'd say you should display the full (escaped) JID. - As only this one is a JID. The whole fuzz about escaping is just to make something a JID, that wouldn't be one else. So if you need a JID you will always display the result of the escaping. IMO you only do unescaping, if you want to display something that is not a JID but the original address. And you should only do this on places where the user is aware about the fact, that he does not see a JID, but an other address. I see. Table 3 in section 5.1 confused me a bit (especially column User Input). So, if I want to show unescaped JID it's better to show only a node (if it's appropriate). It seems to be too complicated. Thanks anyway. -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Mridul Muralidharan [EMAIL PROTECTED] wrote: It is not about visual representation. xep 106 is about encoding pieces of the jid such that they are compliant with xmpp requirements in a standard way. Then I would like to ask who should escape JIDs and when? I don't think that users will read XEP and escape desired characters. One possible question is: user's client during registration process. And user will be surprised looking at his new brand escaped JID. -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Mridul Muralidharan [EMAIL PROTECTED] wrote: Why would you want to unescape it ? The identifier of the contact is user\40jabber.org\2fuser in xmpp world. The node by itself conveys no meaning other than when associated with the full jid. Citing XEP-0106: Typically, unescaping is performed only by a client that wants to display JIDs containing escaped characters to a human user, or by a gateway to some external system (e.g., email or LDAP) that needs to generate identifiers for foreign systems. The second purpose is clear, but the first (display to a human user) is not so clear for me now. -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Matthias Wimmer [EMAIL PROTECTED] wrote: The same way XEP-0106 is not about allowing nice new characters and displaying them animated in high color and blinking. It is just for the case a character has to be transported and cannot be used directly. Any use of escaping should be avoided when possible, you only do it if you have to. I would say that the introduction of the XEP clearly says that it IS about allowing nice new characters. -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Michal 'vorner' Vaner [EMAIL PROTECTED] wrote: Hello On Wed, Jun 27, 2007 at 01:11:03PM +0200, Norman Rasmussen wrote: On 6/27/07, Sergei Golovan [EMAIL PROTECTED] wrote: You're right. And the question is: How to escape it? Can escaping be done unambiguously? Yes, but only if you already know the split. Is there a way the server part could contain @? I hope a domain name can't contain it. I would take the last @ as the actual separator and leave all the before as just part of the node (same as with email, where you can have address like @@host.com, where the local name on host is really @). The last @ may be in a resource part. Do you think there may be a problem with this approach? Valig JIDs are always split into three parts unambiguously. As far as I thought, XEP-0106 purpose is to allow invalid JIDs to be shown to a user (hiding real complicated escaped JID). But it seems to fail in this. So, let this XEP serve another goal - interoperability between XMPP network and the others. -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Matthias Wimmer [EMAIL PROTECTED] wrote: Sergei Golovan schrieb: I would say that the introduction of the XEP clearly says that it IS about allowing nice new characters. I don't read it that way. I read it: And how should one read: The escaped JID is unescaped only for presentation to a human user (typically by an XMPP client)? Probably the XEP needs some clarification. I think that your interpretation is more reasonable than in the XEP text. -- Sergei Golovan
Re: [jdev] Escaping JID using XEP-0106
On 6/27/07, Matthias Wimmer [EMAIL PROTECTED] wrote: Hi Sergei! Sergei Golovan schrieb: And how should one read: The escaped JID is unescaped only for presentation to a human user (typically by an XMPP client)? As I explained in one of my last e-mails: someone might want to implement a Jabber client that has an interface like Pidgin but that does only XMPP serverside. In this case the client don't want to have unescaped full JID. It only needs unescaped node. The XEP is perfectly suitable for this. But it is full of examples of unescaped full JIDs (in fact bare JIDs). It is confusing. -- Sergei Golovan
Re: [jdev] XEP-0115: Entity Capabilities
On 6/23/07, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Kevin Smith a écrit : On 23 Jun 2007, at 04:14, Andreas Monitzer wrote: Is this XEP not really expected to be implemented by anybody? If so, why do all clients announce c xmlns='http://jabber.org/protocol/caps'/ in their presence stanzas? Caps is implemented by some clients (Psi and probably many others), and I believe Gajim is getting support as part of GSoC this year. Moreover if you are running under Linux then you can try Kopete that supports it already. I wonder if tkabber doesn't as well. I would consider this XEP dangerous and wouldn't like to implement it in Tkabber. It's too easy for malicious user to flood all contacts (and not only in his roster) by false information about all clients and versions he wants. I think that one never should apply info received from some user to other users. Best wishes! -- Sergei Golovan
[jdev] Tkabber 0.10.0 is released
Hi! I'm pleased to announce a new stable release of Tkabber and Tkabber plugins (0.10.0). Some new features with respect to 0.9.9 are: * New artwork by Artem Bannikov * Mediated SOCKS5 connection support for file transfer (XEP-0065) * Blocking communication with users not in roster (using XEP-0016 via simple interface) * Translatable outgoing error messages support (based on recipient's xml:lang) * Remote controlling clients support (XEP-0146) * Extended stanza addressing support (XEP-0033) * New chats history tool with search over the all chatlog files * Roster item icons are chosen based on Disco queries to item server * Search in Disco, Browser, Headlines, RawXML, and Customize windows * New internal plugins: abbrev allows to abbreviate words in chat input windows, postpone stores/restores current input window content * New external plugins (aniemoticons, latex, tkabber-khim, traffic, renju) * Emoticons theme now can be loaded using GUI * Most Tkabber's tabs can now be stored on exit and restored on start * XMPP ping support (XEP-0199). Reconnecting based on XMPP ping replies * Delayed delivery now recognizes XEP-0203 timestamps * Added optional 'My Resources' roster group, which contains other connected resources of the same JID * Many other fixes and enhancements The new release is available at http://files.jabber.ru/tkabber/tkabber-0.10.0.tar.gz and http://files.jabber.ru/tkabber/tkabber-plugins-0.10.0.tar.gz More info and download options are at http://tkabber.jabber.ru/download -- Sergei Golovan
Re: [jdev] XMPP Ping/Keepalive: Recommended method ?
On 6/19/06, Michal vorner Vaner [EMAIL PROTECTED] wrote: On Sun, Jun 18, 2006 at 10:47:19PM -0700, [EMAIL PROTECTED] wrote: Given that the protocol itself does not seem to have a defined keep-alive element, what is the recommended way for a client to keep its connection alive to a XMPP server ? Since XML allows any number of whitespace between elements that is just ignored, you can send a whitespace if you are not in the middle of stanza. It will do, NATs and other beasts will see data flowing, The problem is that this ping is not a ping at all because it only sends data and does not expect reply. So, some NATs and proxies still break connection if they don't see bidirectional flow. Another issue is that with this ping you can't control the connection. If TCP connection breaks (but before TCP timeout reaches - and it is a quite long timeout) both messages and pings goes to black hole and there's no way to work around this (to set some short internal timeout or whatever). -- Sergei Golovan
Re: [jdev] XMPP Ping/Keepalive: Recommended method ?
On 6/19/06, Dave Cridland [EMAIL PROTECTED] wrote: On Mon Jun 19 08:15:40 2006, Sergei Golovan wrote: So, some NATs and proxies still break connection if they don't see bidirectional flow. Could you tell me which NATs do this? I'm unaware of any that handle timeouts differently for unidirectional data flows. I've never seen that but once there was a feature request for Tkabber. Some gateway (probably on MS Windows) dropped connection if there weren't outgoing packets for some time. Another issue is that with this ping you can't control the connection. If TCP connection breaks (but before TCP timeout reaches - and it is a quite long timeout) As far as I'm aware, there *is* no timeout on silent TCP connections. I'm talking about the situation when I keep sending packets, but the other side doesn't receive them. -- Sergei Golovan
[jdev] Jabberd 1.4 bugzilla?
Hi all! Is there a bugzilla or some other place for reporting bugs or requesting new features for jabberd-1.4? -- Sergei Golovan ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] Client-side disco and MUC
On Wed, Jul 06, 2005 at 03:38:43PM +1000, Steve Smith wrote: Hi, If a client implements disco responses is it required that it return a http://jabber.org/protocol/muc feature? Look at http://www.jabber.org/jeps/jep-0045.html#discovery-client -- Sergei Golovan ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] Clients that support JEP-0013
On Wed, Apr 13, 2005 at 04:19:41PM +0200, Matthias Wimmer wrote: Hi Sergei! I don't think I want to implement alternate syntaxes for existing JEPs. If it would add features not present in JEPs okay ... but a client just using other commands because it does not like the syntax of a JEP - I don't think this is a good idea. I've just warned you about current Tkabber implementation in case if you want to use it for debugging jabberd. It's not a good idea because Tkabber doesn't implement JEP-0013 (as someone mentioned earlier in the list). If you have concerns with a JEP - especially with one that is not final yet - you should discuss them on the standards-jig. I don't want to discuss this JEP but I wonder how can any JEP be promoted to draft without any reference implementation? As for me it's nonsense. -- Sergei Golovan ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] Clients that support JEP-0013
On Tue, Apr 12, 2005 at 04:03:14PM +0200, Matthias Wimmer wrote: Hi! Are there any clients that support JEP-0013 (Flexible Offline Message Retrieval)? I have implemented this for jabberd 1.4.5 and would then test it against existing implementations. Tkabber has support, but not exactly of JEP-0013. It uses the following query for requesting offline message headers: iq type='get' offline xmlns='http://jabber.org/protocol/offline'/ /iq instead of disco#items query. The reason is that it's not reasonable to use usual disco query as a state-switching query (server not only replies to the query but also changes its behavior - doesn't send offline messages). Best wishes! -- Sergei Golovan ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] Clients that support JEP-0013
On Tue, Apr 12, 2005 at 06:54:24PM +0400, Sergei Golovan wrote: On Tue, Apr 12, 2005 at 04:03:14PM +0200, Matthias Wimmer wrote: Hi! Are there any clients that support JEP-0013 (Flexible Offline Message Retrieval)? I have implemented this for jabberd 1.4.5 and would then test it against existing implementations. Tkabber has support, but not exactly of JEP-0013. It uses the following query for requesting offline message headers: iq type='get' offline xmlns='http://jabber.org/protocol/offline'/ /iq I forgot to mention that since there is no reason to use only jid, node and name attributes (query isn't a disco#items query) Tkabber expects the following answer: iq type='result' to='[EMAIL PROTECTED]/orchard' offline xmlns='http://jabber.org/protocol/offline' item node='2003-02-27T22:49:17.008Z' from='[EMAIL PROTECTED]/pda' category='presence' type='subscribe'/ item node='2003-02-27T22:52:37.225Z' name='[EMAIL PROTECTED]/balcony' category='message' type='chat'/ item node='2003-02-27T22:52:51.270Z' name='[EMAIL PROTECTED]/balcony' category='message' type='headline'/ item node='2003-02-27T22:53:03.421Z' name='[EMAIL PROTECTED]/balcony' category='message' type='normal'/ item node='2003-02-27T22:53:13.925Z' name='[EMAIL PROTECTED]/balcony' category='message'/ /query /iq Best wishes! -- Sergei Golovan ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] Jabberd2 for Windows?
On Thu, Mar 03, 2005 at 08:15:13AM +1100, Trejkaz wrote: On Wednesday 02 March 2005 11:04, [EMAIL PROTECTED] wrote: better use ejabberd Using ejabberd wouldn't really help the OP test code against jabberd2, would it now? Unless ejabberd is based on jabberd2 now... As far as I understood, the point was to test client against modern (XMPP?) protocol features. In this case testing against ejabberd is as good as against jabberd2. On the other case installing ejabberd in Windows is much easier than jabberd2. -- Sergei Golovan ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
[jdev] Re: [jabber-users] tkabber crashes
On Sun, Oct 24, 2004 at 12:58:24PM +0400, Oleg V. Motienko wrote: Hello! Tkabber crashes on viewing vcard with photo. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 92 (X_LookupColor) Serial number of failed request: 49072 Current serial number in output stream: 49072 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Any ideas ? Tk. ,Img, . http://sourceforge.net/projects/tkimg/ -- Sergei Golovan ___ jdev mailing list [EMAIL PROTECTED] http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] newer version of vcard
On Thu, Oct 21, 2004 at 07:59:48AM +1000, Trejkaz Xaoza wrote: On Thu, 21 Oct 2004 02:11, Sergei Golovan wrote: On Wed, Oct 20, 2004 at 09:25:12AM +0100, Richard Dobson wrote: You should be able to work out the age from the date of birth shouldnt you? Many clients (Psi, Gaim etc.) treat birthday field as a text field. So it's not easy to parse the date, entered by user. Is that not then a bug in the client, for failing to validate that the string which was entered is valid according to the JEP? Hardly a good reason for adding a redundant element to the vCard. (Who stops someone entering anything they want in this new age field, anyway?) Yes, my point is that this is the bug (or probably misfeature) in clients. But the problem is that the bug is present in very popular clients. But anyway adding age field is not a good idea. -- Sergei Golovan ___ jdev mailing list [EMAIL PROTECTED] http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] newer version of vcard
On Wed, Oct 20, 2004 at 09:25:12AM +0100, Richard Dobson wrote: You should be able to work out the age from the date of birth shouldnt you? Many clients (Psi, Gaim etc.) treat birthday field as a text field. So it's not easy to parse the date, entered by user. -- Sergei Golovan ___ jdev mailing list [EMAIL PROTECTED] http://mail.jabber.org/mailman/listinfo/jdev
