Re: [Standards] Nodeprep question
Mickaël Rémond wrote: > Hello, > > Le 19 nov. 07 à 23:20, Tomasz Sterna a écrit : > >> Dnia 19-11-2007, Pn o godzinie 22:27 +0100, Mickaël Rémond pisze: >>> Nodeprep adds forbidden characters to usual stringprep tables. Among >>> those characters we find "/" (47). >> >> IIUC the only reason that slash '/' character is forbidden in a node >> part is, that it is a resource delimiter. >> So encountering '/' in the JID means that the resource has just started. > > Yes, sure I understand the purpose of the limitation. > >>> Some libraries extend it to caracters such as c/o (8453). The rational >>> behind that is that it contains a fraction. >> >> I think they do wrong. > > I finally found the document that can be really usefull to know which > characters should be forbidden after normalization. > For the record, you can check: > http://www.unicode.org/Public/UNIDATA/NormalizationTest.txt > > It shows that KC normalization turns c/o character (8453 in decimal, > 2105 in hexa) in 0063 002F 006F > It shows that it contains 002F (47 in decimal) which is a forbidden > character. > > This is the resource I was looking for on Unicode normalization for as > it explains precisely implied forbidden characters due to normalization. Would it be helpful to post a little XEP about this or something? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0166: references to XEP-0155 and XEP-0168
Lauri Kaila wrote: > 2007/12/1, Peter Saint-Andre <[EMAIL PROTECTED]>: >> (1) XEP-0155 and XEP-0168 are not normative dependencies in XEP-0166, >> and we mention them only to help implementors. However, I think it would >> be best to move those references to XEP-0208. I am also open to delaying >> the advancement of XEP-0208 until we have more experience with Jingle >> technologies. >> >> (2) XEP-0168 probably is still immature and I think it would be best for >> the Council to delay advancement of this spec. >> >> In a way, the whole resource determination problem is orthogonal to >> XEP-0166. Once you figure out the resource, use XEP-0166. How you figure >> out the resource is up to you. > > I totally agree. Good. :) I will modify XEP-0166 accordingly. I hope to push out a revised version in the next few days. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] XEP-0166 v. 0.22pre1
OK, I think that I have incorporated the Last Call feedback received so far. Please let me know if I have missed anything. Rendered document: http://www.xmpp.org/extensions/tmp/xep-0166-0.22.html SVN diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0166.xml?r1=1420&r2=1440 Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Relaxing XEP-0084 regarding multiple elements
Jesus Cea wrote: > If I can ask... > > "" demands height/width... What if the avatar is a SVG file?. Incorrect. It is RECOMMENDED, not REQUIRED: http://www.xmpp.org/extensions/xep-0084.html#table-1 See also the schema: ==>type='xs:unsignedByte' ==> use='optional'/> ==>type='xs:unsignedByte' ==> use='optional'/> smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] s2s blocking of abusive users
On Wt, 2007-12-04 at 16:27 +0100, Jesus Cea wrote: > All traffic between two xmpp servers is transmitted using a single TCP > connection. You can't "delay" a single remote user. You "delay" all of them. I am very aware of that. > In fact, if I would program a xmpp server, I would enqueue in RAM and > cut the connection when buffer >X MB or I'm unable to flush the buffer > after Y seconds. I'm aware that the connection oriented TCP layer is very good at it and I do not need to reinvent it at the application layer. > In some circunstances the server simply can't choose to not generate new > traffic. Let's say, I'm a user sending "normal" traffic to two other > users. One of them is receiving just fine. The other one annnounces a > closed TCP window (closed flow control) to the server, so traffic in > being enqueued in tcp layer and, later, in the application. Server > shouldn't block me, because that would impact my "normal" traffic with > the responsive user. Why would dropped packets affect the flowing ones? > So flow control at TCP layer is of no help to the server. And less so > when the stream coming is multiplexing traffic by several different > (innocent) users. That is the case for S2S connections. I am very aware of that. > I think stpeter is talking more in the line of "I'm receiving abusing > traffic from [EMAIL PROTECTED] I don't want to punish ALL @ users. And if you would reread my statements I'm against it. It's the abuser server role to take care of the abuser, not the abused one. And if it does not taking care, all of it's users will hurt. Experience shows that collective responsibility is good at enforcing policies. > So, no TCP queues or delays to care of. You don't ever need to take care of the TCP queues manually. They "just work". :-) -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Relaxing XEP-0084 regarding multiple elements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal 'vorner' Vaner wrote: >> "" demands height/width... What if the avatar is a SVG file?. > > Then it says how large it should be rendered? Ah. That is a point :-). Then I don't understand why each "" includes a height/width if all "" are "equivalent". Why is not that info in the enclosing metadata?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR1WP6Jlgi5GaxT1NAQLgwgQApF5t/BwJENCHWHRSTm3afTXQ+FWfSC8H vi/YbMm3Uv+ffXQ7+y7lOB3uHocDB+OUTfVODrbZ9IrcXJIe05AICt+1MqWpMlkB dz6DwoXXCEPRPG4SLbWXRI9W7WZil+FaCnQZ3VkS8iIedNSzeJ02+oOHWRSMbLYq g6wuGag0+TM= =vszT -END PGP SIGNATURE-
Re: [Standards] s2s blocking of abusive users
Jesus Cea wrote: > I think stpeter is talking more in the line of "I'm receiving abusing > traffic from [EMAIL PROTECTED] I don't want to punish ALL @ users. I > rather > prefer to send a control stanza to @ server asking for banning > [EMAIL PROTECTED] traffic to me, giving a reason". The @ server could > sent to > [EMAIL PROTECTED] user an inmediate notification message for each sending try, > like currently we do with the offline message storing (but these > notifications would be sended by the @ server, not the remote one), > dropping the messages locally. I think I'm talking about something like "Hey , I am receiving abusing traffic from [EMAIL PROTECTED] I don't want to punish ALL @ users. I am going to bounce stanzas from [EMAIL PROTECTED] with a stanza error with a special application-specific condition. Take that as you please. However if I continue to receive these abusive stanzas, I may send you a *stream* error and close the s2s connection." Naturally, if I return a number of error stanzas then I have increased the number of stanzas being exchanged, which (you could argue) induces a multiplication attack. But the origin server now feels the pain as well, and it can take local action based on my abuse reports. That may be some kind of traffic filtering, it may be warning the local user or ending their local session, etc. Right now I'm not as interested in that problem and more interested in the simple matter of abuse reporting. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Relaxing XEP-0084 regarding multiple elements
Hello On Tue, Dec 04, 2007 at 04:44:28PM +0100, Jesus Cea wrote: > If I can ask... > > "" demands height/width... What if the avatar is a SVG file?. Then it says how large it should be rendered? -- Never underestimate the bandwidth of a station wagon full of HDDs. Michal 'vorner' Vaner pgpNBUXJCtfen.pgp Description: PGP signature
Re: [Standards] Relaxing XEP-0084 regarding multiple elements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If I can ask... "" demands height/width... What if the avatar is a SVG file?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR1V13Jlgi5GaxT1NAQJZxgP+PlUctUNZVFCEbY+8ri94Z6v24EmXHRJl mc61CVit8ZwpihAgWn+6QGet7IdtrHPNV5dQmNL48E0hiOUBswXOWy0hrrAOBATf 7wfZrVc4qDe8e9ZQaUR6ZBSTe/UPBc7hXX6jfVXGcMa5nsr2HVCUD70fGp42tVJB ol5exyV32Nw= =qG1a -END PGP SIGNATURE-
Re: [Standards] s2s blocking of abusive users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomasz Sterna wrote: > Dnia 28-11-2007, Śr o godzinie 01:05 +0100, Jesus Cea pisze: >>> The TCP buffering, timeouts and retransmission will handle the rest, >>> thus you will effectively enforce the peer to transmit no faster >> than >>> 10kbps. >> Then you add "lag" to the connection, but you will "eat" the bytes >> sonner or later :-/ > > TCP buffers are not infinite and congestion control kicks very soon and > takes care of excessive bytes. > > Wikipedia has some good articles of it. Please read > http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm All traffic between two xmpp servers is transmitted using a single TCP connection. You can't "delay" a single remote user. You "delay" all of them. About your objection, I don't know what xmpp implementations are doing when network buffering fills. They could cut the connection by timeout or could enqueue (in application space) until exhausting RAM and hitting the swap :-), finally crashing. We have no idea. In fact, if I would program a xmpp server, I would enqueue in RAM and cut the connection when buffer >X MB or I'm unable to flush the buffer after Y seconds. In some circunstances the server simply can't choose to not generate new traffic. Let's say, I'm a user sending "normal" traffic to two other users. One of them is receiving just fine. The other one annnounces a closed TCP window (closed flow control) to the server, so traffic in being enqueued in tcp layer and, later, in the application. Server shouldn't block me, because that would impact my "normal" traffic with the responsive user. So flow control at TCP layer is of no help to the server. And less so when the stream coming is multiplexing traffic by several different (innocent) users. That is the case for S2S connections. I think stpeter is talking more in the line of "I'm receiving abusing traffic from [EMAIL PROTECTED] I don't want to punish ALL @ users. I rather prefer to send a control stanza to @ server asking for banning [EMAIL PROTECTED] traffic to me, giving a reason". The @ server could sent to [EMAIL PROTECTED] user an inmediate notification message for each sending try, like currently we do with the offline message storing (but these notifications would be sended by the @ server, not the remote one), dropping the messages locally. So, no TCP queues or delays to care of. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR1Vxxplgi5GaxT1NAQKk0QP+PdUHez0hzjhu/0Es6GcSeLFN4HW3anwy yoW3Ax2CXkifdED1pc/2LeBcoKcm1VzP/+tEWuCeLQE/e9+o7wTlpPd6TMuaKzCd OfU1W6LzDl3oqJ7gKCZuJz4JS3ViujAymUyUvy651I1WltZIV9uqADucaPtkM1in zLLU0eVSR8U= =V4+y -END PGP SIGNATURE-
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Karneges wrote: > Most TLS libraries operate as a "black box", passing an opaque stream of > bytes > to the application. I'd suggest making the XEP have a more transparent use > of TLS to match this fact. In other words, rather than saying the first iq > stanza must contain certain explicit TLS constructs (e.g. ClientHello), just > say it can contain any arbitrary TLS data, just like how a real TLS stream > over TCP works. This would allow most off-the-shelf TLS libraries, such as > OpenSSL, to be used with XTLS. Since a stanza stream has TCP-like behavior, > I think we can get away with this. > > Of course, this would mean we'd lose the direct mapping between each > transported stanza and the content within. For example, a single IM may span > multiple transported stanzas, or a single transported stanza may contain > multiple IMs. However, I don't think having a direct mapping buys us much at > all, while having an opaque/transparent transport buys us a *lot*. I agree. Most of the time, you can't control what is going in each TLS packet. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR1VrXZlgi5GaxT1NAQJ0GwP/RDWzqP/gh4/prc7nVkXsWegDtLyadzgy X1u7ZKcVM8nZcX6ja6PCr2BjbsyJWLxI7otoC226dncFqnj8DxfW8d1EBNAIR6SI wcfT32dC9PsMJWkjIJNqGs42nmKK64rGd0SOhMBvZPaFUrXTXbHrj03gMxVJ5M69 gqhw7BF58aM= =Uqz+ -END PGP SIGNATURE-
