Re: [Standards] XMPP example site - www.LiveBaseballChat.com
On Tue, Apr 7, 2009 at 11:00 PM, Dean Collins d...@cognation.net wrote: Basically it is an ajax/xmpp site with 2430 chat rooms set up over the next 6 months for people to talk about specific Baseball games. Interesting... I have been thinking about making a web front end for IO-DATA services, assuming there must be web/JavaScript libraries to talk over the XMPP network... Can you please elaborate on the libraries used behind your website? Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Thu, Apr 09, 2009 at 07:19:11PM -0500, XMPP Extensions Editor wrote: Version 0.8 of XEP-0198 (Stream Management) has been released. Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption. Changelog: [See revision history] (ff/jk/jjh/psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0198.xml?%40diffMode=u%40diffWrap=sr1=2933r2=3028u=3ignore=k= URL: http://xmpp.org/extensions/xep-0198.html Looks fine to me now, just a minor inconsistency (probably from editing): 4. Acks ... An a/ element MUST possess an 'h' attribute. An r/ element SHOULD NOT possess any attributes. But later it says: When an r/ element (request) is received, the recipient MUST acknowledge it by sending an ack element (either a/ or r/) to the sender. ... The response MUST contain a value of 'h' that is equal to the number of stanzas handled by the recipient of the r/ element. Greetings, Robin -- Robin Redeker | Deliantra, the free code+content MORPG el...@ta-sa.org / r.rede...@gmail.com | http://www.deliantra.net http://www.ta-sa.org/ |
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On 4/10/09 1:10 AM, Robin Redeker wrote: On Thu, Apr 09, 2009 at 07:19:11PM -0500, XMPP Extensions Editor wrote: Version 0.8 of XEP-0198 (Stream Management) has been released. Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption. Changelog: [See revision history] (ff/jk/jjh/psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0198.xml?%40diffMode=u%40diffWrap=sr1=2933r2=3028u=3ignore=k= URL: http://xmpp.org/extensions/xep-0198.html Looks fine to me now, just a minor inconsistency (probably from editing): 4. Acks ... An a/ element MUST possess an 'h' attribute. An r/ element SHOULD NOT possess any attributes. But later it says: When an r/ element (request) is received, the recipient MUST acknowledge it by sending an ack element (either a/ or r/) to the sender. ... The response MUST contain a value of 'h' that is equal to the number of stanzas handled by the recipient of the r/ element. Thanks, I'll fix that. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Forwarding Delivery Draft
On 3/17/09 10:17 AM, Peter Saint-Andre wrote: On 3/17/09 10:10 AM, Michael Grigutsch wrote: Hi! Hi MiGri! In 2006 Peter Saint-Andre wrote a Draft for a JEP which would fill an important gap: It is about forwarding stanzas. You can find the document at http://xmpp.org/extensions/inbox/forwarding-delivery.html There was some controversy about forwarding when the XMPP Council last discussed it: http://logs.jabber.org/coun...@conference.jabber.org/2006-02-09.html http://logs.jabber.org/coun...@conference.jabber.org/2006-03-23.html Perhaps you could read those logs and summarize the objections? I can't remember what the issues were at this point. :) I would love to see the XSF publish this as an official XEP and I volunteer to help work on the spec so that we can complete this work. That's great, thanks! It seems that I no longer have the original .xml file for that proposal, so I'll need to reconstruct it from the HTML output. I'll do that soon and send you the file. Done: http://xmpp.org/extensions/inbox/forwarding-delivery.xml Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Proposed XMPP Extension: Instant Gaming
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Instant Gaming Abstract: This document defines an XMPP protocol extension for serverless instant gaming in a one-to-one context. URL: http://www.xmpp.org/extensions/inbox/instant-gaming.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
[Standards] Proposed XMPP Extension: Multi-User Gaming
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Multi-User Gaming Abstract: This document defines an XMPP protocol extension for multi-user gaming. URL: http://www.xmpp.org/extensions/inbox/multi-user_gaming.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
[Standards] Proposed XMPP Extension: Tic-tac-toe
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Tic-tac-toe Abstract: This document defines how to play a Tic-tac-toe game over XMPP URL: http://www.xmpp.org/extensions/inbox/tictactoe.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
[Standards] Proposed XMPP Extension: Server-based Tic-tac-toe
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Server-based Tic-tac-toe Abstract: This document defines how to play a Tic-tac-toe game over XMPP URL: http://www.xmpp.org/extensions/inbox/tictactoe-mug.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
Re: [Standards] XMPP-IM - presence subscription handling
On 2/24/09 8:53 AM, Jiří Zárevúcký wrote: Hello all. I've been thinking about the current subscription management in the XMPP-IM for some time now. I think it's not very well designed. Where were you in 1999?!? We could have used your help back then. For example, there's an obvious redundancy in the roster pushes and subscription stanzas. For (almost) every subscription update / request, there is a presence stanza and a roster push. But that only applies to the contact, who receives the change. Also, the ask attribute looks like a maimed boolean and roster pushes do not contain all the state information - inbound request is missing. Even though the client can track most of the changes by tracking roster pushes and subscription stanzas, there is one change client can never track. When there is an inbound subscription request with no item and user declines it, other resources get no push and no presence stanza - no notification. That is not really a big problem, but all this inconsistency in pushes and presence stanzas makes it all seem very chaotic and untidy. Yep. But what is broken? We don't make protocol changes just for aesthetics. Originally, I wanted to propose modifying roster pushes so they contain all the state information (including eventual inbound subscription request message), essentially leaving subscription-managing presence stanzas only as the mean of requesting the change, not presenting it to the other entity or the other resources. Then one thing occured to me. Do we really need a separate subscription handling for inbound and outbound presences? Users generally don't want it separate. Users want mutual subscription. Is there ever need to have one-side subscription? Sometimes. But I agree that for most end users they don't need that. IMHO this is a client interface issue, not a protocol issue. Providing mechanism for just a mutual subscription, where there would be only both-direction or pending or no subscription at all, would immensely simplify things for both users and implementers. Yes, I agree that immediate effect would be increasing complexity and need of additional effort to maintain backward compatibility. There's the rub. This kind of effort is a non-starter. That would be a tricky task, but I believe that with proper interoperability rules, it would be possible to make transition relatively painless. I believe that in a long run, such change would be a huge improvement. For whom? So, in case you are interested in this idea, I will continue with some semantics I have on my mind. Otherwise, just tell me why do you think it is not possible / feasible / wanted to implement it. I'm pretty sure there is some hidden problem with this I don't realize. I suppose many of you won't take me too seriously, since it would require too massive change to the core protocol, but I'd appreciate if you thought about it a bit. Thanks for any feedback. My feedback is: don't waste time on this kind of project. The problems with backwards-compatibility make it infeasible. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Inconsistent Subscriptions in XMPP
On 4/1/09 12:07 PM, Mridul Muralidharan wrote: If I recall right, probe can be sent to a full jid in case a directed presence was received from it in the past - and the behavior would be different (return last presence stanza sent iirc). Has that behavior changed or is the description below only for bare jid's ? You can probe anything you want. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Inconsistent Subscriptions in XMPP
On 4/7/09 12:45 AM, Philipp Hancke wrote: hijacking the thread... two concrete examples where error handling is needed: subscription state is none initially: SENT: presence to=f...@bar id=jcl_37 type='subscribe'/ RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' type='set'query xmlns='jabber:iq:roster'item ask='subscribe' subscription='none' jid='f...@bar'//query/iq RECV: presence from='f...@bar' to='m...@local/Exodus' type='error' id='jcl_37'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence after relogin and roster fetch: RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_40' type='result'query xmlns='jabber:iq:roster'item ask='subscribe' subscription='none' jid='f...@bar'/ The presence error (which, as can be by looking at the id attribute, is a reply to the initial subscribe) does not affect the subscription state. IMHO the server needs to periodically resend the subscribe to the contact if the state remains ask=subscribe (no reply received from the contact). I'm pretty sure that I added something about this to rfc3921bis. subscription state is both initially: SENT: iq id=jcl_50 type=setquery xmlns=jabber:iq:rosteritem jid=s...@jid subscription=remove//query/iq RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' type='set'query xmlns='jabber:iq:roster'item subscription='remove' jid='s...@jid'//query/iq RECV: iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_50' type='result'/ RECV: presence from='s...@jid' to='m...@local/Exodus' type='error'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence RECV: presence from='s...@jid' to='m...@local/Exodus' type='error'error code='404' type='cancel'remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'//error/presence The subscription state is none afterwards - which is the users intention. The presence errors are replies to unsubscribe/unsubscribed stanzas generated by the server and should imo never have been sent to the client. Agreed -- the server should eat those. The question is: how do error replies to presence subscription stanzas affect the subscription state? That's up to the server. Smart servers will do the right thing. So we need smarter servers (and to provide some advice in rfc3921bis). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] various rfc3920bis feedback
On 2/24/09 11:04 AM, Pavel Simerda wrote: On Tue, 24 Feb 2009 09:14:13 + Dave Cridland d...@cridland.net wrote: What I would like... is to have an easy-to-understand and easy-to-implement piggybacking feature without unnecessary hassle. In fact, by specifying how to do this without actually doing dialbacks, but instead by verifying the identity of the sender based on the X.509 cert, we can actually get rid of SASL EXTERNAL and just use X.509 only, which eliminates the difference between the first authorization and subsequent ones. I don't see any reason to get rid of SASL EXTERNAL. I quite like the concept of using the same authentication flows for all authenticated connections. It would be nice to be able to authenticate each virtual connection separately. It's a multiplex, anyway, if one associations fails, others should remain working. Right, we need a way to say once we have a secure connection, we can add new domains. Joe Hildebrand and I have been talking with some of the TLS and SASL people about this. One of these days we'll at least write up the requirements... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] various rfc3920bis feedback
On 2/25/09 8:55 AM, Pavel Simerda wrote: On Tue, 24 Feb 2009 20:14:27 +0100 Philipp Hancke fi...@goodadvice.pages.de wrote: Pavel Simerda wrote: * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details Piggybacking. Which is subtly broken in RFC 3920 - at least 50% of it. host-unknown/ makes 'target piggybacking' (different to) unusable, as you risk the entire stream. Please provide more specific info about how to fix it in bis I fixed in in my working copy of 220 by completly getting rid of host-unknown for dialback. type='error' seems a good fix. and if/why it is broken now. The relevant passage from 3920 about piggybacking is: After successful dialback negotiation, the Receiving Server SHOULD accept subsequent db:result/ packets (e.g., validation requests sent to a subdomain or other hostname serviced by the Receiving Server) from the Originating Server over the existing validated connection; this enables piggybacking of the original validated connection in one direction. If the receiving server is 'jabber.org', validation requests sent to a subdomain or other hostname serviced by the Receiving Server means that I can piggyback stanzas to 'users.jabber.org' on that connection (target piggybacking, google uses source piggybacking). draft-saintandre-rfc3920bis-08.html added the host-unknown stream error to dialback with the following description: the value of the 'to' attribute provided by the initiating entity in the stream header does not correspond to a hostname that is hosted by the ^ server. Now what happens should I attempt to piggyback the users.jabber.org connection on the jabber.org connection? jabber.org kills my stream. As I said to Peter IMO the whole idea of piggybacking is misguided. Piggybacking means re-using a connection A for data that would otherwise come in B. It would be better to think about it as a generic multiplex. Then all virtual connections would be equal (A and B, specifically). One would immediately see the consequences of closing the physical connection (that should only be closed if all virtual connections are closed). Keeping this as an optional feature (I believe that is a near consensus) will further simplify the most basic implementations. That's the general idea, yes. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] various rfc3920bis feedback
On 2/24/09 12:14 PM, Philipp Hancke wrote: Pavel Simerda wrote: * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details Piggybacking. Which is subtly broken in RFC 3920 - at least 50% of it. host-unknown/ makes 'target piggybacking' (different to) unusable, as you risk the entire stream. Please provide more specific info about how to fix it in bis I fixed in in my working copy of 220 by completly getting rid of host-unknown for dialback. type='error' seems a good fix. and if/why it is broken now. The relevant passage from 3920 about piggybacking is: After successful dialback negotiation, the Receiving Server SHOULD accept subsequent db:result/ packets (e.g., validation requests sent to a subdomain or other hostname serviced by the Receiving Server) from the Originating Server over the existing validated connection; this enables piggybacking of the original validated connection in one direction. If the receiving server is 'jabber.org', validation requests sent to a subdomain or other hostname serviced by the Receiving Server means that I can piggyback stanzas to 'users.jabber.org' on that connection (target piggybacking, google uses source piggybacking). draft-saintandre-rfc3920bis-08.html added the host-unknown stream error to dialback with the following description: the value of the 'to' attribute provided by the initiating entity in the stream header does not correspond to a hostname that is hosted by the ^ server. Now what happens should I attempt to piggyback the users.jabber.org connection on the jabber.org connection? jabber.org kills my stream. Really? Why? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] various rfc3920bis feedback
On 2/24/09 3:10 AM, Philipp Hancke wrote: Dave Cridland wrote: On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: * bidirectional s2s could be announced in stream:features sent right after the opening stream tag from the initiator. Unidirectional S2S has been around for too long, I do not see a real gain in fixing that now. That was an artifact of dialback. If we have mutual authentication via TLS+SASL then why not have a bidirectional s2s connection? * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details Piggybacking. Which is subtly broken in RFC 3920 - at least 50% of it. host-unknown/ makes 'target piggybacking' (different to) unusable, as you risk the entire stream. I'm not so sure about that. host-unknown/ means you're trying to communicate with a domain that I don't host at my server. What I'd like to do here is use the dialback elements as an authorization request mechanism. Dialback is 50% authorization request, 50% key verification. Splitting it up accordingly simplifies the description. As long as it's backwards-compatible. In fact, by specifying how to do this without actually doing dialbacks, but instead by verifying the identity of the sender based on the X.509 cert, we can actually get rid of SASL EXTERNAL and just use X.509 only, which eliminates the difference between the first authorization and subsequent ones. There is no 'subsequent' auth with 0178 yet, is there? There is no subsequent auth anywhere, yet. There are three different options: 1) do 0178 and add subsequent auth (including graceful failure) 2) do 0178 for the first authorization and use piggybacking (with graceful failure again) for subsequent authorization... err... verification 3) ignore any 0178 offers and do piggybacking for everything. Might be a problem if servers require 0178 and really mean it. The dialback flow then becomes: 1) O2R : db:result/ 2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT Assumes that the originating server does not check with the authoritative server that the receiving server has verified the key. 3) R: Connect to A 4) R2A: Establish TLS. 5) R2A: If A's certificate matches O's, goto ACCEPT Nice optimization ;-) 6) R2A: db:verify/ 7) A2R: db:verify/, goto ACCEPT ACCEPT: 8) R2O: Authorize O as requested domain, send db:result/ It's still not clear to me what TLS+dialback really means. If you're going to do TLS, use real certs and then you can do authentication via SASL EXTERNAL. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] various rfc3920bis feedback
On 2/24/09 2:14 AM, Dave Cridland wrote: On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: * bidirectional s2s could be announced in stream:features sent right after the opening stream tag from the initiator. Well... What you need is to: a) Signal the ability of the receiver to handle features sent by the initiator. b) Signal the ability of the initiator to handle bidi streams. c) Turn this on, which presumably involves an authorization phase. I was thinking that the receiver has a stream:feature to handle stream:features, the initiator then sends these, and the receiver can then proceed as the initiator in the other direction. So the initiator would send SASL mechanisms, and the receiver would act as a SASL client to the initator and request authorization. Interesting. I think we need a separate thread about this topic. I'll try to start that soon. * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details Piggybacking. What I'd like to do here is use the dialback elements as an authorization request mechanism. I think that connection re-use is broader than dialback. In fact, by specifying how to do this without actually doing dialbacks, but instead by verifying the identity of the sender based on the X.509 cert, we can actually get rid of SASL EXTERNAL and just use X.509 only, which eliminates the difference between the first authorization and subsequent ones. I'm not convinced of that. Why get rid of SASL EXTERNAL? (It seems preferable to use TLS+SASL for both c2s and s2s.) And what does it mean to just use X.509? The dialback flow then becomes: 1) O2R : db:result/ 2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT 3) R: Connect to A 4) R2A: Establish TLS. 5) R2A: If A's certificate matches O's, goto ACCEPT 6) R2A: db:verify/ 7) A2R: db:verify/, goto ACCEPT ACCEPT: 8) R2O: Authorize O as requested domain, send db:result/ Perhaps. :) * resource conflicts should be handled consistently in servers It's not always possible to handle conflicts in the same way. What do we mean by handled consistently? * an explicit way to kick other resources might be very handy Here be tigers. I'd rather punt on this one. What problem are we solving here, exactly? Can't we use XEP-0146 for this? * multiple resources could have a less confusing named feature (not unbind, but something like multi-bind probably) I'm less than convinced about the validity of multiple resources as a solution to any problem. I think we have consensus to remove this from rfc3920bis. * xml:lang per stanza seems to be pretty rare, I would prefer MAY to SHOULD, or even to discurage per-stanza xml:lang entirerely and encourage use of xml:lang only for elements with localized strings. Many users (and also client developers) just don't care about languages. Unqualified strings are (and will be) very common, I would use MAY even for the elements. In principle, the stanza-level xml:lang can be used especially over S2S sessions to indicate a preferred language for errors. However... various protocols have had features like this for years, and to the best of my knowledge nobody ever uses them. So it seems. So perhaps Pavel's proposal is appropriate. * gone has a very good usecase that could be made explicit... it is JID redirection and could be handled by clients (e.g. the client could offer the user to add the new JID upon error - presence/message would trigger it). Right - a jid redirection would be useful. We'd also need to put together a companion protocol for users to enable it. http://xmpp.org/extensions/inbox/forwarding-delivery.html http://xmpp.org/extensions/inbox/forwarding-request.html * Consider including XEP-198 Stream Management in the RFC We need to actually prove it, first. I don't think anyone's got as far as coding it, yet. Now we have Prosody on the server side and Lampiro on the client side. Time for some testing. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XMPP-IM - presence subscription handling
2009/4/11 Peter Saint-Andre stpe...@stpeter.im: My feedback is: don't waste time on this kind of project. The problems with backwards-compatibility make it infeasible. Peter Yeah. I sometimes get very stupid ideas. Sorry about that. :)
Re: [Standards] Inconsistent Subscriptions in XMPP
--- On Sat, 11/4/09, Peter Saint-Andre stpe...@stpeter.im wrote: From: Peter Saint-Andre stpe...@stpeter.im Subject: Re: [Standards] Inconsistent Subscriptions in XMPP To: XMPP Standards standards@xmpp.org Date: Saturday, 11 April, 2009, 4:04 AM On 4/1/09 12:07 PM, Mridul Muralidharan wrote: If I recall right, probe can be sent to a full jid in case a directed presence was received from it in the past - and the behavior would be different (return last presence stanza sent iirc). Has that behavior changed or is the description below only for bare jid's ? You can probe anything you want. :) I should have clarified better. Assume that there is mutual subscription between userA and userB. Support we have : userA has session us...@domain/resA userB has session us...@domain/resB1 userB has session us...@domain/resB2 After presence has been exchanged, suppose userA blocks userB (or all users) - so an unavailable presence is sent to userB's resources. Subsequent to that, suppose userA sends available to one of the resources, say - us...@domain/resB1 Now, iirc, if resB2 probes, userA's server must return unavailable. But if resB1 probes, userA's server must return the last directed presence sent (subsequent to unavailable). We could replace userB with muc or any other component in the above. IIRC this was a usecase discussed quite a while back - was it removed ? If not, my query was, how does it interact with this list below related to probes, etc. Thanks, Mridul Peter -- Peter Saint-Andre https://stpeter.im/ Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
