Re: [Standards] Unsigned DANE records for TLS assertions
Good morning On Thu, Dec 05, 2013 at 12:58:18PM +, Tony Finch wrote: A related example; OpenSSH uses unsigned SSHFP as a hint to the user, but does not trust them. So there is a precedent, but it is hard to get a human in the loop on s server-to-server connection :-) Last time I checked, OpenSSH was paranoid so much it used even signed SSHFP only as a hint to user. I don't know if it changed since, though. With regards -- All flame and insults will go to /dev/null (if they fit) Michal 'vorner' Vaner signature.asc Description: Digital signature
Re: [Standards] Unsigned DANE records for TLS assertions
Hello On Fri, Nov 22, 2013 at 10:07:51AM +, Dave Cridland wrote: - If an attacker removes the record by fiddling with the DNS, then they can mount an MITM attack. Note that they can also fiddle the DNS into redirecting the connection too. It's not clear if this makes things any harder than before. - If an attacker adds in a TLSA record, this could act as a denial of service. On reflection, I'm not sure if this is actually an overall benefit, but I thought I'd throw the idea out. I didn't read the RFC, but my impression was that it mandated TLSA is always signed by DNSSEC. So, the right thing should probably be to ignore and warn about unsigned TLSA records, not to honor them. With regards -- Look! Behind you! Michal 'vorner' Vaner signature.asc Description: Digital signature
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
Good morning I did not write the XEP, not really read it whole, but from common sense: On Tue, Jun 04, 2013 at 03:41:34PM -0600, Peter Saint-Andre wrote: Section 2.1: If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). Is there any reason why the should is not a MUST? I can imagine a server not wanting to enable it for some domains and enable it for others. In such case, it would send the feature to those it wants it enabled for. With regards -- Anyone who goes to a psychiatrist ought to have his head examined. -- Samuel Goldwyn Michal 'vorner' Vaner signature.asc Description: Digital signature
[Standards] NetConf over XMPP
Hello I'm working with protocol called NetConf (RFC 6241) now. The protocol can be used to configure devices remotely over something more standardized than web interface or ssh command line utilities (which is good for people but not for automated scripts). The protocol uses XML messages and defines several transport layers to work on top of (SSH, TLS socket, …). It seems like a reasonable idea to define a transport over XMPP, which has several advantages (like you don't need 1000 ssh sessions to configure 1000 devices on your client, there's single point where we could define who is allowed to do the configuration, etc). Also, it could be used to configure software as well (XMPP bots, for example), with possibly better UI than the ad-hoc commands. I brought the idea with my boss today that I'd like to do write the XEP and some experimental implementation. I got an answer in the meaning of „That sounds like a cool idea, though we need to finish the current project first“. So, I will probably find the time to write the proposal XEP some time in the future. But if anyone is interested in a way to configure something remotely (either a device or a software), please contact me, we may want to exchange some ideas. Thank you PS.: It seems the email didn't get through when sent from company email, so I'm retrying with a personal one (which is subscribed to the list). Please ignore any possible duplicates. -- BOFH Excuse #452: Somebody ran the operating system through a spelling checker. Michal 'vorner' Vaner signature.asc Description: Digital signature
Re: [Standards] NetConf over XMPP
Hello On Thu, May 30, 2013 at 09:43:43AM +0200, Steffen Larsen wrote: I am not into NetConf, but is it not RPC calls? If so, you can probably use XEP-009: http://xmpp.org/extensions/xep-0009.html Part of NetConf is RPC, but from fast look at this XEP, it's different RPC (the elements used are named differently, the parameters are not wrapped in param, …). This is one example of the NetConf's RPC: rpc message-id=101 xmlns=urn:ietf:params:xml:ns:netconf:base:1.0 get-config source running/ /source filter type=subtree top xmlns=http://example.com/schema/1.2/config; users/ /top /filter /get-config /rpc Also, there's more to NetConf than just the RPCs, like notion of session or discovering what models (sets of configuration options) and features the other side supports. I believe it should be quite easy to map them onto XMPP (put the RPCs into iq, use disco for the models such, a session would be from the first RPC to either explicit close-session/ method or to presence type='unavailable'/). But I think these still need to be described so different implementations have a chance of doing them the same way. With regards -- When a fly lands on the ceiling, does it do a half roll or a half loop? Michal 'vorner' Vaner signature.asc Description: Digital signature
Re: [Standards] Name of IQ query nodes
Hello On Sat, Dec 18, 2010 at 04:44:36PM -0600, David Ammouial wrote: It is not clear from the specification what the name of the query node of an IQ may (or should) be. In RFC 3921, it is implied that it is query. However, there's no mention of whether this is a mandatory tag name or not. Because of that, and because there's no example of any other tag name in the whole RFC, I would tend to believe that it is indeed the only expected tag name. However, several XEPs use another one, for example 'vCard'. It is used and is considered correct to use any name for it. It will have unknown namespace from the point of the RFC, so telling it the name is out of scope. It is considered incorrect to have multiple child elements. Or, the query (set or get) must have exactly one. Result can have up to one and error can have more. It is quite clearly defined in section 9.2.3 of RFC 3920 (XMPP CORE). The fact that 3921 (XMPP IM, that is „on top“ of 3920) uses only query does not change anything. If anything relies on it being called query, then it is broken in two manner. First, the fully qualified name is never query, but includes the namespace, and second, 3920 simply says a child element, not specifying which one. With regards -- Never underestimate the bandwidth of a station wagon full of HDDs. Michal 'vorner' Vaner pgpJYQpNAXqcL.pgp Description: PGP signature
Re: [Standards] RCF3920bis07: Resource generation
Hello On Mon, Oct 06, 2008 at 11:37:34AM +0100, Pedro Melo wrote: The reasons given to use a well-known resource can be solved better using other methods. You omit the reason the resource name carries an information. When I see someone connected with resource 'mobile', I know I should not spam him with large messages. -- I have a theory that it's impossible to prove anything, but I can't prove it. Michal 'vorner' Vaner pgp5xeGv4YiW7.pgp Description: PGP signature
Re: [Standards] RCF3920bis07: Resource generation
Hello On Mon, Oct 06, 2008 at 11:53:51AM +0100, Pedro Melo wrote: Pings assert only one thing: A stanza reached the server, and another was able to get back. You cannot extrapolate any assurances of quality what so ever from this. You can, TCP does not loose bytes in the middle. You are sure all stanzas _before_ the ping got trough. -- You can't have everything... where would you put it? -- Steven Wright Michal 'vorner' Vaner pgpwOsH7Ql2qn.pgp Description: PGP signature
Re: [Standards] RCF3920bis07: Resource generation
Hello
On Mon, Oct 06, 2008 at 12:30:10PM +0100, Pedro Melo wrote:
On Mon, Oct 06, 2008 at 11:37:34AM +0100, Pedro Melo wrote:
The reasons given to use a well-known resource can be solved better using
other methods.
You omit the reason the resource name carries an information. When I see
someone connected with resource 'mobile', I know I should not spam him
with large messages.
IMHO, you should use caps for that.
That's the proper way to solve it. Use an identity client/phone or
client/handheld.
Then you will need caps containing any string to show to user, since
resource can carry any information. I might want to send a message to
specific computer out of the connected ones. I might want to know which
resource I run commands on (let's say with my own account but different
resource, to disconnect it from MUC or so).
--
_(){ __;};_
Michal 'vorner' Vaner
pgpBwg5mhrhux.pgp
Description: PGP signature
Re: [Standards] Reg MUC Roomname
Hello On Wed, Jul 02, 2008 at 12:03:33PM +0530, Thanik wrote: One more query, whether the id attribute in xmpp stanzas is case sensitive or not. You do not need to distinguish, you get it back as is and it depends on you, what IDs you generate. Have a nice day -- This is a terroristic email. It will explode in 10 minutes, if you do not close it in the meantime. Michal 'vorner' Vaner pgpiVX5GjOiu1.pgp Description: PGP signature
Re: [Standards] Any replacement for offline notification from XEP-0022?
Hello On Fri, Jun 27, 2008 at 09:50:59PM +0400, Konstantin Khomoutov wrote: I see that XEP-0085 (Chat State Notifications) which can be thought as being a spiritual successor to the deprecated XEP-0022 (Message Events) lacks support for the message is stored in the server's offline storage notification. Well, if it wasn't stored, you get an error. And if the server told you it did store it, you would know the user is not invisible, does not have you in his ignore list or so. It is not something people should want you to know. So, if you do not get an error, you can count on the message being delivered (now or later). (If it is different in real life, then it is problem of implementation and not of protocol). Did it help? Have a nice day -- ~, sweet ~ Michal 'vorner' Vaner pgpL42NEWvLLK.pgp Description: PGP signature
Re: [Standards] rfc3921bis: multiple items in roster set
Hello On Thu, Jun 05, 2008 at 03:03:16PM -0600, Peter Saint-Andre wrote: I'm reviewing a bunch of old messages about rfc3921bis, so expect a few posts to the list. Here is the first one... Currently, some clients include multiple items in a roster set to complete certain use cases, for example to rename a group: iq type=set' id='rs1' query xmlns='jabber:iq:roster' item jid='[EMAIL PROTECTED]' groupNewGroupName/group /item item jid='[EMAIL PROTECTED]' groupNewGroupName/group /item /query /iq However, Rule 1 in Section 2.1.3 of rfc3921bis states: The query/ element MUST contain one and only one item/ element. Would it break anything to allow multiple items in a roster set? What do you return, if one fails and one succeeds? Or they work as a transaction? (none or all) With regards -- Please enter password: Michal 'vorner' Vaner pgpmegCISxEtO.pgp Description: PGP signature
Re: [Standards] Labeling Roster Items
Hello On Sun, Mar 30, 2008 at 08:53:54PM -0700, anders conbere wrote: On Sun, Mar 30, 2008 at 8:13 PM, Justin Karneges [EMAIL PROTECTED] wrote: On Sunday 30 March 2008 7:34 pm, anders conbere wrote: However in XMPP our roster grouping are still relegated to binning or boxing (an item in a group exists in one and only one group). Actually, in XMPP a contact may be in multiple groups. In fact, the grouping is more like tagging than any sort of binning, since there is no group hierarchy stored in the roster (a group cannot exist without a contact in it, much like a tag can often not exist without at least one thing tagged). Hmm so this problem is by and large in how Groups are implemented in the wild? That in and of itself might seem to be reason at least to create a new semantic grouping. Right now I'm struggling to find an number of clients that let me keep users in multiple groups, or at least give me ui to group in a tagging like behavior. Most clients show them in multiple groups, if they are already in the roster. However, many of them have just switch, in which group a contact is. Gajim (for example) has UI allowing you to put contact in many groups. -- I've already told you more than I know. Michal 'vorner' Vaner pgpzPFoRh2jtG.pgp Description: PGP signature
Re: [Standards] Jingle implementability
Hello
On Fri, Feb 01, 2008 at 04:50:08PM -0800, Robert Quattlebaum wrote:
On Feb 1, 2008, at 1:14 AM, Maciek Niedzielski wrote:
Stanza router could pipeline jingle stanzas through all jingle plugins.
Since a plugin tracks state, etc, it knows if it is interested in this
stanza or not. So if it wants the stanza, stanza gets eaten, else
app-level stanza router tries to pass it to next plugin, etc.
While such a model works well for apps with plug-ins in the same process as
the app, it does not work as well if your plug-ins are in different
processes--because it would be a blocking API.
Why? The router sends the stanza to the first plugin and stops blocking
-- lets it process it. After a while, the first plugin sends the stanza
back with note I do not want this, give it to someone else -- as any
other message from the plugin.
--
do { goto Water; } while( !tryBreakOffTheEar() );
Michal 'vorner' Vaner
Re: [Standards] ProtoXEP: Game Support
Hello On Wed, Jan 16, 2008 at 10:03:12PM +0100, Torsten Grote wrote: It may be an idea to separate the One-to-One and the Multi-User Gaming into distinct XEPs, because Multi-User Gaming is quite complex and controversial. What do you think? Well, I would prefer the Multi User version to be as much as possible similar to the 1-1. I think it could be easier to reuse many parts. Isn't it easier then to have one XEP instead of two, when there would be just different transport and some organization added? -- The problem with graduate students, in general, is that they have to sleep every few days. Michal 'vorner' Vaner pgpQsFkVL3IED.pgp Description: PGP signature
Re: [Standards] ProtoXEP: Game Support
Hello On Sat, Jan 12, 2008 at 12:21:43AM +0100, Torsten Grote wrote: we concentrate on One-to-One gaming, since MUG will need server support. Is it really needed? A gaming support on server? Couldn't this be done trough ordinary MUC? http://www.cs.uni-potsdam.de/~tgrote/xep/game-support.html Just few notes here, may or may not be useful. Discovering: Wouldn't it make sense use service disco to get supported/ongoing games too? (add items supported-games and ongoing-games to item list, and their sub-lists as games, for example) It seems to me defining new protocol for discovering is not needed, if there is a generic one. Invitation: What is the difference between body and reason? I would put the reason to body of the message directly, as is with MUC invitations, and so on. Besides, wouldn't it be better in iq, as it requires response (either positive or negative)? I like the idea of using ordinary thread in messages as the game identifier, allows more concurrent games. Saving: she/he MUST not save the game and send the following she/he MUST NOT save the game and MUST send? Besides, shouldn't game saving/loading be optional in a way some clients can do it and some don't? (Therefore a discoverable feature for that given game). And, it should be noted each game needs a description of it's own, how it is saved, right? Loading: Is it a good idea send the whole state in the invitation? It might be long (depending on the game) and if the other side declines, it is wasted bandwidth. Terminating: It should be specified, what exactly happens, when the other side just changes to unavailable (lost connection, probably). http://www.cs.uni-potsdam.de/~tgrote/xep/tictactoe.html Could it allow playing on any-sized plan (possibly infinite too) and have the length of winning strike starting player negotiated? Besides, it probably should be noted, how the game is saved. Have a nice day -- Please enter password: Michal 'vorner' Vaner pgptQDC5AX8W9.pgp Description: PGP signature
Re: [Standards] ProtoXEP: Game Support
Hello On Sat, Jan 12, 2008 at 01:36:15PM +0100, Olivier Goffart wrote: I agree that the discovering should simply be done by adding gname namespaces to the feature list of the disco : You mean directly in features? But then all the clients who do not know games will get long list of all games the fancy game client supports, I would like to see some cascading. Is disco able to request features of some sub-item? -- ~, sweet ~ Michal 'vorner' Vaner pgpZlPPRh9etU.pgp Description: PGP signature
Re: [Standards] ProtoXEP: Game Support
Hello On Sat, Jan 12, 2008 at 02:31:52PM +0100, Olivier Goffart wrote: Le samedi 12 janvier 2008, Michal 'vorner' Vaner a écrit : But then all the clients who do not know games will get long list of all games the fancy game client supports, Yes, but this is the same with every features, like all the jingle namespace if I don't support jingle, And does it hurt ? The only negative effect I see is the brandwith, and thoses namespace should compress pretty well. There is also the XEP-0115 to help us. You are right, this was just my first sight that told me it will be bigger. But maybe it is not worth it. But, anyway, I think it makes sense use disco in some way to discover the supported games. -- Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. -- Howard Aiken Michal 'vorner' Vaner pgp0T7fnEeiCf.pgp Description: PGP signature
Re: [Standards] ProtoXEP: Game Support
Hello On Sat, Jan 12, 2008 at 05:34:21PM +0100, Torsten Grote wrote: Michal 'vorner' Vaner said the following on 01/12/2008 11:13 AM: And, it should be noted each game needs a description of it's own, how it is saved, right? Could you please elaborate a little bit more on this? I was somehow mistaken by the missing saving in tictactoe. The saved game looked like it is from nowhere. Terminating: It should be specified, what exactly happens, when the other side just changes to unavailable (lost connection, probably). What happens when the other side changes to unavailable is defined, but not in terms of connection losses. They are a problem and I'm not sure how to handle these. If the game was not canceled, the client should be able to reconnect and play. If the client crashes, this is not possible, but the other player could save the game it is of the complete knowledge kind. Hm, did I read it too fast and missed it somewhere, or is there only the think that a client should terminate the game before disconnection? http://www.cs.uni-potsdam.de/~tgrote/xep/tictactoe.html Could it allow playing on any-sized plan (possibly infinite too) and have the length of winning strike starting player negotiated? Well it could, but it doesn't ;) But it there are several variants of Tic Tac Toe which could be added as tictactoe#variant in the future. Well, the variants differ (if I omit the things like 3D, more than 2 players) only in the sizes and I guess a client does not much differ for them. I would rather like to see the numbers negotiated than have variants like: 20x20-5 40x40-5 and so on. (I get this is the first version, but I think a XEP for 3x3-3 variant and another XEP for other variants is somehow a waste, so it would be nice to have it possible in future in the protocol. Not that every client would have to understand all the variants.) Besides, it probably should be noted, how the game is saved. Saving is not yet supported by this XEP. I don't think that saving a game of Tic Tac Toe is really necessary and it could be explicitly stated that it is not supported. Could be a nice example, thought. And you do not need to define much ;-): tictactoe X_O OOX ___ /tictactoe (Again, I know, it's first version.) Have a nice day -- This side up = Michal 'vorner' Vaner pgplq1d2u4l6h.pgp Description: PGP signature
Re: [Standards] ProtoXEP: Game Support
Hello On Sat, Jan 12, 2008 at 04:47:06PM +, Richard Dobson wrote: That will only work if you trust each party to follow the same set of rules governing the game and not to make invalid moves/cheat, it is far better to have a third party (i.e. a gaming server, or maybe one of the participants) receiving all the moves and verifying them before distributing them to all the players, also a lot of games (for example battleships, scrabble, most card based games, i.e. poker, uno) work by neither player knowing the full game state with the full state only known by a neutral third party. You can do all this with a bot moderator and players only visitors and let them PM the gamebot. But then, you can not send normal talking messages. Or, a move would be valid only after approving message by the bot (and all other moves would be considered invalid up to that time). Or a bot could kick for cheating, which is somehow similar what happens with a game without a computer. The only thing that I see as a problem is how to discover the game rooms, unless you have the support. -- I still miss Windows, but my aim is getting better. Michal 'vorner' Vaner pgpE6vXRiILPK.pgp Description: PGP signature
Re: [Standards] ProtoXEP: Game Support
Hello On Sat, Jan 12, 2008 at 05:05:31PM +, Richard Dobson wrote: You can do all this with a bot moderator and players only visitors and let them PM the gamebot. But then, you can not send normal talking messages. Or, a move would be valid only after approving message by the bot (and all other moves would be considered invalid up to that time). Or a bot could kick for cheating, which is somehow similar what happens with a game without a computer. The only thing that I see as a problem is how to discover the game rooms, unless you have the support. Sure exactly, as I said you need some kind of neutral third party for a lot of games, be that a server or a bot it doesnt matter, but you cant do as the previous poster seemed to suggest (as far as I read it) and just use bog standard MUC and RPC between the players for all games. But you do not need to change MUC, it is much easier done with letting MUC be the same and just add something, then redefining the protocol and duplicating the work. You can use standard MUC and RPC, you just need another player who plays the doom of the game. Be it a bot or a real player. Like in any other real game, the only thing you need to add is the figures and moving with them. -- The problem with graduate students, in general, is that they have to sleep every few days. Michal 'vorner' Vaner pgpm9KT10v76M.pgp Description: PGP signature
Re: [Standards] ProtoXEP: Game Support
Hello
On Sat, Jan 12, 2008 at 07:16:19PM +0100, Torsten Grote wrote:
Michal 'vorner' Vaner said the following on 01/12/2008 05:53 PM:
I would rather like to see the numbers negotiated than have
variants like:
20x20-5
40x40-5
and so on.
Feel free to send me your proposal for a section which defines this.
Well, you can put something like
rules xmlns='http://jabber.org/protocol/games/checkers'
width20/width
height20/height
strike5/strike
at-turnX/at-turn
meO/me
/rules
into the invitation. No need for other section, right?
Could be a nice example, thought. And you do not need to define much
;-):
tictactoe
X_O
OOX
___
/tictactoe
(Again, I know, it's first version.)
Well the XEP Game Support has a fictive example for saving Tic Tac Toe
using Data Forms. Your way is much shorter, but is useless for being an
example on how to save game states in general. I'm not an expert on this
and don't know what's the best way. Suggestions by long time XMPP
experts are welcome.
Well, you need some defined mechanism for every separate game anyway.
And what is in your namespace (the game's namespace) is your own thing,
that's what namespaces are for.
You can not get a general way to save a game. And you need to define a
game's moves in it's own namespace anyway, so I see no reason why to
worry about data forms, which are for adding means of transfering data
without defining a separate protocol for every usecase. But you need to
define the fields at last.
--
_(){ __;};_
Michal 'vorner' Vaner
pgpUe8ZbmDVjT.pgp
Description: PGP signature
Re: [Standards] Relaxing XEP-0084 regarding multiple info elements
Hello On Tue, Dec 04, 2007 at 04:44:28PM +0100, Jesus Cea wrote: If I can ask... info 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] Authorization over HTTP
Hello On Fri, Nov 09, 2007 at 11:07:03AM +0100, Tomasz Sterna wrote: Dnia 09-11-2007, Pt o godzinie 10:40 +0100, Michal 'vorner' Vaner pisze: Some kind of single-use password? Could be useful for other things too, like I want to log in from a internet coffee I do not trust at all. And again OpenID is a solution here. You are in an internet cafe, and type http://somesite.com/ in the IE there. SomeSite asks you for login. You enter your OpenID there. Your mobile in your pocket beeps, signalling that your XMPP IM client wants your attention. You take it out, and see a question: Well, I ment something else. I want to connect to my XMPP server from the cafe. So I (at home) generate single-use password on the server and log in by that. Would be nice if there was a XEP for generate me one single-login password. But it could probably be done with AD-HOC commands. Maybe an informational XEP? -- This email was generated by a biological random generator. If you want more random text, just respond to this email. Michal 'vorner' Vaner pgp4YsLLqfRI1.pgp Description: PGP signature
Re: [Standards] Binary data over XMPP
Hello On Fri, Nov 09, 2007 at 10:01:39AM -0700, Joe Hildebrand wrote: On Nov 9, 2007, at 8:47 AM, Tobias Markmann wrote: There are already several binary-to-text encodings which perform a bit better than Base64, two of them are: 1. http://en.wikipedia.org/wiki/ASCII85 invented by Adobe 2. http://base91.sourceforge.net/ Both of those seem to allow and , which make them less than ideal for embedding in XML. Why not replace these 2 with something else? -- If you are over 80 years old and accompanied by your parents, we will cash your check. Michal 'vorner' Vaner pgpTvutzcdXDn.pgp Description: PGP signature
Re: [Standards] Binary data over XMPP
Hello On Tue, Nov 06, 2007 at 10:44:15AM +0100, Tomasz Sterna wrote: Dnia 06-11-2007, Wt o godzinie 09:17 +, Richard Dobson pisze: And repeat the FTP + statefull firewall nightmare? Sorry but what??? Can you explain exactly what you mean by this. Ever tried to get FTP protocol through FW/NAT? It requires protocol level command channel tracking, to find out related data channels and let them in. Special handling, special modules, special setup - ergo: nobody bothers. Because the FTP data channel (not to mention it offers passive transfer, too) is _inbound_. If you opened not one TCP connection to the server, but two, one for XML and one for blobs, how it would be different from single TCP connection? But a different question - is binary XML able to transfer binary data? And is it possible to map normal XML - binary XML one to one? If so, we could have a stream feature use binary XML instead and transfer blob elements not-base64-encoded or something like that. If the server needed to push it to a non-binary stream, it would have to base64 it (or something like that). Does it make sense? (Just an crazy idea, I do not know, if it could be of any use). -- Q: Why was Stonehenge abandoned? A: It wasn't IBM compatible. Michal 'vorner' Vaner pgpocuJEYcEMI.pgp Description: PGP signature
Re: [Standards] Binary data over XMPP
Ahoj On Mon, Nov 05, 2007 at 11:40:18AM +, Dave Cridland wrote: A new top-level stanza of (say) blob/, which much the same attributes as any other routable stanza, but also has an octet count. Upon receipt, the XML processing is suspended, and the following octets are handled verbatim: blob from='[EMAIL PROTECTED]/court' to='[EMAIL PROTECTED]/court' octet-count='4'/1234 You probably can not do that with any reasonably out-of-the-box XML parser. Furthermore, you may need to pass the stream trough charset decoder to get some internal stringish representation. This will make it mad. So, in short, I strongly disagree here. But you may like SCTP or how's the protocol called and push the blobs out-of-the stream. Or another blobby TCP connection to the server. (if you really want to send these things trough the server). -- Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. -- Howard Aiken Michal 'vorner' Vaner pgpN9uBBE4v9P.pgp Description: PGP signature
Re: [Standards] Binary data over XMPP
Hello On Mon, Nov 05, 2007 at 02:45:05PM +, Dave Cridland wrote: Another option would be to setup a distinct connection (and protocol) for routing blobs, and so send them through the server, yet not in-band. I'm not comfortable with this, because it means essentially duplicating all security information, and maintaining synchronization between two distinct streams. Or make the connection blobs by default, and some blobs could contain complete XML documents, like this: lenght of first block message to='bla' length of second block iq ... length of third block some binary data. It is as much drastic approach as the blobs, it changes the protocol from the very basic ground. Furthermore, you can extract the stanza and feed it to any XML parser. -- When eating an elephant take one bite at a time. -- Gen. C. Abrams Michal 'vorner' Vaner pgpoJcX8j7WDU.pgp Description: PGP signature
Re: [Standards] Binary data over XMPP
Hello On Mon, Nov 05, 2007 at 04:21:21PM +0100, Tomasz Sterna wrote: Dnia 05-11-2007, Pn o godzinie 15:59 +0100, Michal 'vorner' Vaner pisze: Dnia 05-11-2007, Pn o godzinie 12:51 +0100, Michal 'vorner' Vaner pisze: You probably can not do that with any reasonably out-of-the-box XML parser. You cannot use out-of-the-box XML parser anyway. You need a one that parses and returns every stream/ subelement separately. Sax. So you can use out-of-the-box parser, or you cannot? Please make up your mind. ;-) Now I can use SAX. If I had to care about the blobs, I couldn't, or I couldn't in an easy way. you stop feeding the data read from socket to parser, and fetch it directly for routing. Unless you work like: Got something on network, read all or full buffer (lets say max 4kB), push it trough utf-8-internal strings and take the whole lot and feed it to the parser. So you read until '' is spotted, as Greg suggested. So you start splitting the data with one more run trough them? That is nasty and slow. -- I left the ssh key under the doormat Michal 'vorner' Vaner pgpNdHkXV7UlP.pgp Description: PGP signature
Re: [Standards] XEP licensing
Hello On Mon, Oct 22, 2007 at 10:23:17AM +0200, Remko Tronçon wrote: IIRC, the problem was that the license doesn't allow one to redistribute modified RFCs. Why would they want to modify RFCs? It would be nice to be able to use some RFC as a base of some other document, but, of course, it could not be called the same RFC. Does the licence allow creating derived works? -- == This email has been checked by an automatic damage possibility check system. It can contain harmful instructions if read backwards. Internal checker ID: lacol.cr/cte/ tlah ohce Michal 'vorner' Vaner pgp45Ag8aKGht.pgp Description: PGP signature
Re: [Standards] Same LAN
Hello On Sat, Oct 13, 2007 at 10:16:26AM +0200, Jonathan Dickinson wrote: Is there currently a way for XMPP to detect if two endpoints are on the same endpoint. We use Live Messenger (blerg... couldn't convert everyone to xmpp) at my new workplace. One thing I found is that when I sent a file to another person on the same LAN it was as fast as our LAN and not the internet: which suggests that Live Messenger automatically figured out that the two clients were on the same LAN and sent the file locally. This is rather interesting functionality that think would really be a good idea for XMPP. Currently, you send your all IP addresses (including the ones of proxies) to the other party. So, if you can connect without the proxy, then you use routing provided by IP, which means you get local transfer for free. (Of course there are clients able to screw it up, for example sending only the public IP, which is useless). -- You can fool some of the people all of the time, and all of the people some of the time, but you can make a fool of yourself anytime. Michal 'vorner' Vaner pgpsYHLentDZg.pgp Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer
Hello On Tue, Sep 18, 2007 at 11:41:43AM -0600, Peter Saint-Andre wrote: - company policy forbids p2p file transfer - server-side virus checking desired/required before download Couldn't it be solved like this: 1) One of them has a public IP - does an HTTP server, the onther one gets/puts 2) HTTP proxy server somewhere in the middle (One puts, one gets, does not get stored). You can get antivirus checks by that, and it is http, so good firewalls should let it trough as they recognize it. However, if admins forbid file transfers, then they will do it anyway somehow. I wouldn't fight them, if it makes the thing less usable in the normal way. -- The cost of living is going up, and the chance of living is going down. Michal 'vorner' Vaner pgpYzBW9asjFU.pgp Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Requirements for IM File Transfer
Hello On Thu, Sep 13, 2007 at 04:39:46PM -0500, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Requirements for IM File Transfer May I add that it is sometime desirable to transfer large files, so they must go trough and not get saved as whole somewhere. -- Fragile. Do not turn umop ap1sdn! Michal 'vorner' Vaner pgpByVnUvruew.pgp Description: PGP signature
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Hello On Wed, Sep 12, 2007 at 08:37:34PM +0200, Jonathan Chayce Dickinson wrote: Anyway, truth be told, if the client can't use Jabber unless they get a certificate, chances are they will, which would not only benefit Jabber, but the internet as a whole. You could even use xmpp.org as the CA, which 'we' would have more control over: so 'we' could crack down on SPIMmers quite easily. Then users go after MSN instead. -- Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. -- Fred Brooks Michal 'vorner' Vaner pgp5VqcgzRFuV.pgp Description: PGP signature
Re: [Standards] IMML
Hello On Mon, Sep 03, 2007 at 04:42:39PM +0200, Michal 'vorner' Vaner wrote: different language and you can not do that without namespace prefixes. Sorry, not language. Namespace… -- Work with computer has 2 phases. First, computer waits for the user to tell it what to do, then the user waits for the computer to do it. Therefore, computer work consists mostly of waiting. Michal 'vorner' Vaner pgp3d6zlanD5X.pgp Description: PGP signature
Re: [Standards] IMML
Hello On Mon, Sep 03, 2007 at 05:32:34PM +0200, Jonathan Chayce Dickinson wrote: What you said is very true Michal, but you haven't taken it one step back. If the truth be told, these clients are processing XML. The sooner they wake up and smell the coffee and use a proper XML processing framework instead of shoddy home-grown ones, the better. There are plenty frameworks out there, just plug-n-play... joke Would you be so kind and plug-n-playd me one in mcabber, please? ;-) /joke XML stands for eXtensible Markup Language, note the 'extensible', you should be able to add to it without worry for backward compatibility. The fact that their client can not support extra attributes is, in reality, a *bug*. Sure, I know. It is. Bugs are everywhere :-(. But, as you noticed, you probably need a home-grown XML syntethyzer, since you are not allowed to put many other things into the XML stream (like processing instructions). And you need at last to modify that one to handle attributes in different namespace than their tag. They need to generate and place XML namespace prefixes there, remember them, atc. As I said, your way is 100% valid and correct. But I just think the way with separate tag will cause in less effort implementing it. Is there any advantage in your way? If there is, I have no objections using it. -- When all else fails, EAT!!! Michal 'vorner' Vaner pgp0CCjJXoUC9.pgp Description: PGP signature
Re: [Standards] NEW: XEP-0225 (Component Connections)
Hello On Fri, Aug 10, 2007 at 11:19:59AM -0700, Justin Karneges wrote: That said, all server implementations need to do this namespace juggling anyway, so I don't see how it is an extra burden to do this for another namespace, too. What doesn't sit well with me is this idea of the standard elements having to live under any random namespace. The namespace is what gives them meaning. If we only ever have exactly two (or potentially with a component namespace, exactly three) possible namespaces for the elements, maybe that is fine. What is not fine is having to worry that someday down the line we may invent yet another namespace that the standard elements must be able to operate under. Is body omnipresent, and existing potentially in all namespaces? :) Well, I take body/ does what it does if it is in the same namespace with stanzas, and it does not much matter which kind of stanza it is (client, server, whatever). Technically, it is the namespace that gives the meaning, but - if you look at the xml document/stream - it is the body that inherited the namespace and does not have the xmlns= attribute (do I sound like XML heretic to you?). -- Security warning: Do not expose this email to direct sunlight. It may lead to undefined behaviour, including possible data or life loses. Michal 'vorner' Vaner pgpf3tKIm9RN6.pgp Description: PGP signature
Re: [Standards] IMML
Hello I'm for the marking of URL or emoticon (not that they would bother me any more, I disabled emoticons completely and have just text, and urls at last don't screw the message up). But I think emphasis is too much for the protocol. Besides, I would do backwards-compatible protocol (no other element besides xhtml and text, why send third version of the text). Just an idea: message textThis is not a joke ;-) http://notajoke.org/text IMML:emoticon start='20' length='3'/ IMML:url start='24' length='19'/ /message -- This is a terroristic email. It will explode in 10 minutes, if you do not close it in the meantime. Michal 'vorner' Vaner pgpTvfEoCIiiT.pgp Description: PGP signature
Re: [Standards] IMML
Hello On Tue, Aug 07, 2007 at 12:57:53PM +0100, Alex Jones wrote: Personally, I sometimes find that plain text alone is not enough to communicate effectively with people, especially when complicated concepts like sarcasm are involved. Newspapers and typeset books generally get away with using emphasis (usually in the form of italicised text) without bringing in background colours and varying typefaces. I remain fairly convinced that some kind of emphasis is part of everyday natural speech. This is my justification for the inclusion. I really _do_ thing text is enough ;-). -- No, you will not fix me Computer Michal 'vorner' Vaner pgpjMw4CW6fwh.pgp Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Stanza Size Limits
Hello Bytes? Not characters? It is easy to count the characters for a client when sending, but - bytes after conversion is harder. And, is it bytes compressed/encrypted or inside the stream? Couldn't this be clarified (actually, I guess there is on other XEP speaking about size of stanza). -- This email was generated by a biological random generator. If you want more random text, just respond to this email. Michal 'vorner' Vaner pgpPu2WNC35uT.pgp Description: PGP signature
Re: [Standards] summary: allowable characters
Hello On Thu, Aug 02, 2007 at 11:40:25AM -0600, Peter Saint-Andre wrote: Clearly we can't allow @ because we use that character as a separator between the node identifier and the domain identifier. Email address can contain @ in the username part - the identifier is the last @ in the address. But Emails don't have resources. We would have to decide which is more valuable to have in the node part allowed - one of them can not be allowed. Just wanted to point out it is theoretically possible to have @ in the node too. -- Anything is possible, unless it's not. Michal 'vorner' Vaner pgpf6KIJ5VK8f.pgp Description: PGP signature
Re: [Standards] XEP-0045: direct invitations
Hello, On Thu, Jul 19, 2007 at 03:34:25PM -0600, Peter Saint-Andre wrote: Michal 'vorner' Vaner wrote: Hello On Thu, Jul 19, 2007 at 02:27:51PM -0600, Peter Saint-Andre wrote: Currently it is not possible to send room invitations directly from one person to another. That is, the invitation must go through the room. See: http://www.xmpp.org/extensions/xep-0045.html#invite This can cause problems with deployments that use privacy lists to block communications from entities that are not in your roster. In order to solve this issue, we need to modify the invite/ element in XEP-0045. Currently the flow is like this: Hm, just a question - how do you handle the tricks like adding the user to member list, adding a password to the invitation (that could have change since the occupant entered, so he does not know the new one, or his client does not) or room that does not allow you to send invites? You don't. Wouldn't it be nice to be able to do something about it? For example send an iq to the MUC server to prepare the stanza for you and you just sent it out? Like ask it for an advice (optional)? iq to='[EMAIL PROTECTED]' type='get' advice xmlns='…' invite … /invite /advice /iq iq from='[EMAIL PROTECTED]' type='result' advice xmlns='…' invite … /invite /advice /iq You do not send client from sending an invitation, but as you said, you can say it to the other person the social way. This allows the other tricks at last. -- This message has optimized support for formating. Please choose green font and black background so it looks like it should. Michal 'vorner' Vaner pgpdz4xFg2NKZ.pgp Description: PGP signature
Re: [Standards] roster schema
Hello On Fri, Jul 06, 2007 at 10:54:01AM +0100, Richard Dobson wrote: It would be handy to also specify an extended additional error along with the not-allowed/ so that the client can know what part of the roster item is wrong which would add to the flexibility, e.g. name-limit-exceeded xmlns=urn:xmpp:roster:errors/ and groupname-limit-exceeded xmlns=urn:xmpp:roster:errors/. Maybe even add the longest allowed item in the error so the client can know how much it must restrict the user? Like name-limit-exceeded xmlns=urn:xmpp:roster:errors max-len=511/ -- A nuclear war can ruin your whole day. Michal 'vorner' Vaner pgp1GdqT4liGm.pgp Description: PGP signature
Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities
Hello On Wed, Jul 04, 2007 at 10:38:26AM +0100, Dave Cridland wrote: (FWIW, Ian's mention of a one hour attack is a collision attack, not a preimage attack, and finds a pair of two-block messages which collide, both of which have specific properties, and the time figures are quoted for an IBM P690, which is somewhat bigger iron than I have about, anyway. Our attacker needs a selected preimage attack, and will almost certainly need one where the legitimate message is several blocks long for MD5, and their primary source of computing power is likely to be a distributed botnet at best - I'm not clear if this attack is distributable or not, but I'm not concerned by it). Not sure what attack he mentioned, but there is collision project. Collisions in time of minutes on PC, and there is something about generating a colliding data with some prefix if I understand it well (there was something it can generate data that has given MD5 and with some initial hash state or so). http://cryptography.hyperlink.cz/MD5_collisions.html Not that I would understand it much, nor read it properly, just that the author is from the same country as me, so I heard about it. So I think if you have few hours or days, you have no much problems in finding something, if you know how. -- The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system Michal 'vorner' Vaner pgpcIx1foAxWO.pgp Description: PGP signature
Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities
Hello On Tue, Jul 03, 2007 at 09:18:59AM -0600, Joe Hildebrand wrote: hash='MD5' and make it mutually-exclusive with ext. Why exclusive? ext for the old clients, hash to check if it makes sense? caps:c node='client' ext='f1 f2 f3' hash='the-hash'/ Or am I missing something? -- chown -R us $BASE Michal 'vorner' Vaner pgpWOroXVyCNJ.pgp Description: PGP signature
Re: [Standards] roster schema
Hello On Sun, Jun 24, 2007 at 11:01:26AM -0400, Andrew Plotkin wrote: On Sun, 24 Jun 2007, Michal 'vorner' Vaner wrote: And it would seem more reasonable to specify (or allow servers to do so) the limit of stanza? Because it is not only the roster then, but private storage, privacy lists... If there must be a limit, then I think the limit should be enforcible by the server, and if server wants to have 2047, then why not? Only if we can guarantee that there will never be cases where one server has to store (or cache) another server's entry. That's a worrisome promise to make. A fixed limit also makes it easier for an admin to migrate server software transparently to his users. With users that store books in their rosters ;-) As I said, such user deserves odd behaviour. I admit that not a lot of people are going to hit this edge case, but in principle... I just do not like setting hard limits in protocol when they do not come out from the logic. I accept there is no need for such long names now and probably will not be at any time, but if I ask why on earth 1023? There were points where there was no choice to put a hard limit (ipv4, for example). But I do not like this limit in the protocol because of someone might be crazy. Is there a limit for size of EMail in the protocol? No, there isn't, if the server considers it to be too big, it tells you. But the too big grows with time, varies by the server and so on. And as I said, if there is a problem with roster items, is there problem with private storage, privacy list and so on? Will all of them be limited? What is the problem with saying the server can have a limit and deny to perform such crazy operation. (BTW, did it happen that someone stored so long string somewhere, or is it just a _possible_ problem?) -- There is one difference between linux and windows. With windows, you pay for the software, but you get all the T-shirts for free. With linux, you get all the software for free, but you buy the T-shirts. Michal 'vorner' Vaner pgpzfpRQZkcLn.pgp Description: PGP signature
