[Standards] multiple roster sources
Hi, RFC3921bis explicitly allows getting roster from many sources: RFC 3921 assumed that the only place where a user stores their roster is the server where the user's account is registered and at which the user authenticates for access to the XMPP network. This specification removes that strict coupling of roster storage to account registration and network authentication, with the result that a user could store their roster at another location, or could have multiple rosters that are stored in multiple locations. This can be exploited by IM gateways for avoiding the well know synchronization problems (here are some details I've written today http://blog.bluendo.com/ff/im-gateways ), making the clients directly retrieve foreign network rosters from the gateways themselves. The idea I discussed today with Jan Kaluza of Spectrum is quite simple: - a user registers with a gateway and they establish a mutual presence subscription, as it happens now - the user's client after the registration (and after each login) asks for the roster directly to the gateway (now in a new namespace, with the new XMPP specs with a direct jabber:iq:roster stanza), and it locally merges the results from different sources - the gateway replies as if it where the server, optionally using any available optimization such as XEP-237 - the XMPP server sends presence packets only to the JID of the gateway, which replies with direct presences from all the virtual contacts in the legacy network Waiting for RFC3921bis to be implemented by servers, we can transitionally use a different namespace, such as iq:jabber:roster:remote, so that servers will allow remote roster stanzas. What we are wondering if there is interest by other client developers (for us with Lampiro this is a priority in order to make things work smoothly), since basically they need to issue multiple roster requests and merge locally the rosters. If there is interest I start writing a xep documenting the protocol -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0184 business rules for message receipts
On Wed, Feb 17, 2010 at 3:35 PM, Jonathan Schleifer js-xmpp-standa...@webkeks.org wrote: 2. A sender SHOULD NOT include a request for message receipts unless it knows (via Service Discovery [4] or Entity Capabilities [5]) that the intended recipient supports the protocol described herein or unless the use of message receipts is negotiated via Stanza Session Negotiation [6]. I agree that those two are not too useful. It might be desirable to send to the bare JID when the user's offline and get a receipt once he gets online again. Just a quick note about the reliability note. These modifications suit better the semantics of message stanzas, but we also accept that we can miss receipts for messages which are actually delivered (just to remember that when we need a prompt ack from an online resource iq pubsub events work better). -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)
On Fri, Feb 19, 2010 at 3:47 AM, Peter Saint-Andre stpehttp://www.goshtube.com/404...@stpeter.im wrote: Tuomas has been quicker than me. I confirm all the points, plus: - even xep-184 does not guarantee reliability in a s2s scenario There are no *guarantees* of reliability even with IQs. The question is: how much reliability do you need, and does the use of iq/ for notifications achieve that? That was my point: in federated scenario there is no such thing like general reliability, but options that can make your solution reliable, accordingly to your definition of reliable and your application constraints. If for you reliable means delivery to the correct resource IQs are reliable. If you can keep items in the node until you receive an ack from all the subscribers IQs are still the best option, otherwise it's better let the offline storage of servers handle the this kind of buffering. Imho seeking for a general solution for reliability is a waste of time, it's better to offer a set of options and then let developers chose which one fits better - I don't see many compatibility issues, since iq/ delivery is a config option which must be turned on I think Kev is concerned about compatibility on the client side. The admin can enable iq/ delivery on the service but a client might not be able to handle the notifications because it is expecting message/ stanzas, not iq/ stanzas. In that case the client will presumably return an IQ error. Yep, but most likely that client won't be able to handle the event payload too, since usually client must have ad hoc handlers for pubsub notifications. Moreover IQs are already used in several solutions (we do, Buddycloud people do) and a documented feature is more likely to be implemented by clients than an undocumented one ;) - yep, it works just with presence subscriptions to the pubsub nodes, but one of the features I usually miss in standard pubsub services for real applications is a decent handling of presence subscriptions I'm not sure how that's connected to iq/ delivery. Just a general consideration: IQs need presence subscriptions with the pubsub service, many application we are developing need them, pubsub components I've tried usually miss this feature (they are server plugins which exploit the internal session table of the server, but this works just for local users); so IQ delivery could be an incentive for supporting presence subscriptions with the pubsub service. bye -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)
On Fri, Feb 19, 2010 at 5:46 AM, Peter Saint-Andre stpe...@stpeter.im wrote: - in case of high throughput iq/ delivery has implicit control flow management, as for IBB TCP has flow control, right? TCP isn't end to end in the way that IBB is, it applies only per-hop. Or at least I think that's what Fabio is getting at. Yep, last year we discussed several options for having some sort of end to end flow control, and at the end the only working and simple solution are IQs -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)
2010/2/19 René Treffer treffer+x...@measite.de:
I think we are talking about the wrong problem. Things may go wrong,
everywhere. The only thing that matters would be a stable way for
Server, my state is X, is that correct? - {yes, no, error}
Decreasing the size of X helps, getting good ways to sync helps, trying to
build endless layers of ack that break randomly won't help much imho.
Sending a single IQ with the client state, at the clients discretion, wait
for the reply, and you are done with detecting any kind of inconsistency. At
least in the cases where the server stores data. Wave had some stuff for
that, iirc. Running a pubsub without storage is a fire forget, by
definition.
Well this is similar to a solution we are adopting for having some
sort of reliability, which is not based on IQs, but needs some more
work and cooperation between the client and the server:
- subscribers have a presence subscription with the pubsub service
- when the client goes online we send the last published item ID
- if the client is not in synch starts pulling items starting from the
last received ID
- while the client is online the server sends events with new item IDs
and the client pulls their payload with IQs
--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0047: IBB
On Wed, Feb 17, 2010 at 11:37 PM, Peter Saint-Andre stpe...@stpeter.im wrote: If I understand your comment correctly, I would change the text as follows: fine, just a doubt about SHOULD or MAY temporarily suspend... I'm not sure it is the general desired behavior, but just for some applications like long living bytestreams. What happens in other cases when a file jingle transfer fails while going on? I think the general case is re-negotiating the jingle session and send the remaining part of the file. I'd suggest to retry in case of timeout in the IQ too (if we have an already established ibb, resending the IQ for a while is the sane thing imho). *** The sender of a data chunk need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize the potential for rate-limiting penalties or throttling. It is possible that delivery of the stanza might fail, in which case the sender's or recipient's server shall return an appropriate error: 1. Because the recipient has gone offline, the recipient's server returns a recipient-unavailable/ error with a type of 'wait'. 2. Because a server-to-server link has gone down, the sender's server returns a remote-server-timeout/ error with a type of 'wait'. Upon receiving an error related to delivery, the sender SHOULD temporarily suspend the stream but retry sending at a later time. It is also possible that there is a problem with the data packet itself, in which case the recipient shall return an appropriate error: 1. Because the session ID is unknown, the recipient returns an item-not-found/ error with a type of 'cancel'. 2. Because the sequence number has already been used, the recipient returns an unexpected-request/ error with a type of 'cancel'. 3. Because the data is not formatted in accordance with Section 4 of RFC 4648, the recipient returns a bad-request/ error with a type of 'cancel'. Upon receiving an error related to the data packet, the sender MUST close the bytestream as described under Closing the Bytestream. *** Because the changes are starting to become more significant, I've posted an interim build here: http://xmpp.org/extensions/tmp/xep-0047-1.3.html Peter -- Peter Saint-Andre https://stpeter.im/ -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com == Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On Thu, Feb 18, 2010 at 11:24 AM, Kevin Smith ke...@kismith.co.uk wrote: 2) Pubsub. Votes outstanding from Dave, Matt, Ralph and Remko. Discussion about iq stanzas for delivery, how they don't give guaranteed delivery, and how XEP-0198 is a solution to the guaranteed delivery problem. Ralph -1 on the changes because of the iq issues. There is no log of the discussion yet, isn't it? If so does anybody has the log saved on the disk? I fear there is some misconception about the use cases where iq/s are needed (basically: it's not about reliability, but about having an immediate ack of delivery and XEP 198 does not solve this). -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)
On Fri, Feb 19, 2010 at 12:10 AM, Tuomas Koski koski.tuo...@gmail.com wrote: I have to admit that I have forgotten these use cases too. How ever here are my reasons why I'm sending events in IQs: * to be 100% sure that the events don't go to offline storage * To have acks without implement XEP-0184 Message Receipts or similar * I'm connected with a JID with multiple resources (/a and /b for example). I want to send events only to resource /a. When the resource /a for some reason disappears some servers starts to route message stanzas sent to resource /a to resource /b. Tuomas has been quicker than me. I confirm all the points, plus: - even xep-184 does not guarantee reliability in a s2s scenario - in case of high throughput iq/ delivery has implicit control flow management, as for IBB - I don't see many compatibility issues, since iq/ delivery is a config option which must be turned on - yep, it works just with presence subscriptions to the pubsub nodes, but one of the features I usually miss in standard pubsub services for real applications is a decent handling of presence subscriptions -- Fabio Forno, Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0047: IBB
On Wed, Feb 17, 2010 at 4:25 AM, Peter Saint-Andre stpe...@stpeter.im wrote: *** I think it needs to be more specific about the error types, as you suggest. So something like this: *** It is also possible that the recipient might detect an error with the data packet, e.g. because the session ID is unknown, because the sequence number has already been used, or because the data is not formatted in accordance with Section 4 of RFC 4648. In this case the recipient shall return an appropriate XMPP stanza error, such as item-not-found/ with a type of 'cancel' or 'modify', unexpected-request/ with a type of 'cancel' or 'modify', or bad-request/ with a type of 'cancel' or 'modify'. If the stanza error is of type 'auth' or 'cancel', the sender MUST close the bytestream as described under Closing the Bytestream; if the stanza error is of type 'continue', 'modify', or 'wait' the sender SHOULD attempt to correct the error and re-send the offending data packet using the same sequence number. The recipient MUST NOT consider a sequence number to have been used until the data packet has been successfully processed; however, the recipient MAY close the bytestream if the sender attempts to send the same data packet too many times (in which case the stanza error condition MUST be policy-violation/ with a type of 'cancel'). *** However, I don't think that text is quite complete, because we might say more about how a client recovers from these errors. For example, how could the recipient handle the situation in which the session ID is unknown? Perhaps there's no good reason to expect that a client could recover from such errors. Feedback from implementers would be appreciated. In fact I'm mumbling over the possible errors: - in real cases the most common error is an iq/ lost for which we receive an error from our server (e.g. the case of a S2S connection taking too much time to reopen), and in this case the recipient is not involved at all in the process and the sender can try to recover by re-sending the stanza - IDs out of sequence o packets with bad data are something which is very uncommon on an xmlstream and when it happens the only sane recovery is restarting the stream - No recovery at all if the SID is missing After this I'm stepping back on the option of always closing the stream when some error is detected by the recipient. bye -- FF
Re: [Standards] XEP-0047: IBB
On Sat, Feb 13, 2010 at 3:26 AM, Peter Saint-Andre stpe...@stpeter.im wrote: A few comments on XEP-0047... First, it might be useful if the error for block size too big provided more detailed information, because right now the recipient can't tell the sender what block size would be acceptable (e.g., if the sender proposes a block size of 4096 and the recipient returns an error, the initiator might then try a block size of 2048 but the receiver might still return an error; that seems to require too many round trips). I propose that we add an application-specific error condition that specifies the preferred block size: iq from='jul...@capulet.com/balcony' id='jn3h8g65' to='ro...@montague.net/orchard' type='error'/ error type='modify' resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/ pref xmlns='http://jabber.org/protocol/ibb' block-size='1024'/ /error /iq Just noticed that the block size is not really negotiated. When possible I'm always keen to handle feature negotiation without using errors, since code remains simpler. So I'd prefer to allow the responder sending back a smaller block size in the answer and not in the error. In that way the initiator can start sending blocks with the received block size, without needing to restart the stream Second, if the recipient detects an error with a data packet, the spec says that it SHOULD (not MUST) return an error and is silent about the number of retries that are appropriate, whether the recipient needs to close the session at some point, etc. One option would be to say that the recipient MUST return an error and close the session if it detects a problem with a data packet. Another would be to more carefully specify the retry logic. Do folks on this list have a preference? What about specifying that the recipient MUST return an error with an appropriate type? In that way it can specify whether to retry or close. Especially with IQs I don't have many use cases for allowing retries, but I think they could be useful for encrypted ibb with a low traffic. When reopening a S2S connection it could happen that some IQs are lost (noticed the problem with some servers) and still being able to retry could be useful. -- Fabio Forno, Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] LAST CALL: XEP-0226 (Message Stanza Profiles)
On Mon, Nov 16, 2009 at 4:41 PM, Dave Cridland d...@cridland.net wrote: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? I'm going to be forced to assume that the answer here is No, given that there's been no response to the Last Call at all. Indeed I sent a first attempt of review to the techreview list. Basically it was positive (yes to 1,2,3, no to 4), I just think it doesn't state well real purpose (or at least what I find useful): the problem is not having overcomplicated stanzas to handle, but having some well defined method to understand which part of the message is the real payload, and which part is just a fallback (usually a body explaining why something has failed) bye -- Fabio Forno, Ooros srl jabber id: f...@jabber.bluendo.com
[Standards] Action rules in XEP-0050
Re-reading XEP-0050 for an implementation issue I've found nothing that forbids sending the actions next/ and complete/ together. Imho it is a nonsense and I think nobody uses it, but for better clarification and better user interfaces (I've seen both buttons together sometimes) I'd write in paragraph 3.4, in the third bullet: next/ and complete/ MUST not be used together. bye -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Action rules in XEP-0050
On Fri, Sep 25, 2009 at 11:38 AM, Dave Cridland d...@cridland.net wrote: On Fri Sep 25 10:29:44 2009, Fabio Forno wrote: Re-reading XEP-0050 for an implementation issue I've found nothing that forbids sending the actions next/ and complete/ together. Imho it is a nonsense and I think nobody uses it, but for better clarification and better user interfaces (I've seen both buttons together sometimes) I'd write in paragraph 3.4, in the third bullet: next/ and complete/ MUST not be used together. Is that kind of structure commonly used for short-cuts in wizards, and suchlike? So you have both a [Next ] and a [Finish] button available? Yep, which are the same actions, confusing users. -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Proposed XMPP Extension: Linked Process Protocol
On Thu, Sep 24, 2009 at 8:42 AM, Joshua Shinavier parc...@gmail.com wrote: - is a dedicated namespace with its verbs the correct approach for these things? why not building it at the top of IO-DATA for example (I'm always in favor to reuse what is existing)? Good question. For one thing, we designed and implemented most of Linked Process before we were aware of IO Data, but it's not too late to consider re-engineering the specification to build upon an existing XMPP extension, if it improves interoperability. That being said, I'm not sure that IO Data is an appropriate basis for Linked Process. Marko may or may not agree (and see Peter Neubauer's response a moment ago), but the commands we use in Linked Process are not particularly Ad-Hoc. There are a fixed set of commands with very specific syntax which does not change from service provider to service provider and which does not need to be discoverable: participating clients should know a priori how to interact with other Linked Process clients. On the other hand, Jabber-RPC might actually be appropriate for Linked Process. As far as I can tell, building upon Jabber-RPC might have relatively little impact on our spec apart from the formatting of our IQ stanzas, as we do not have a need for the passing of complex data types which motivates IO Data. We will look into this possibility more closely and carefully. The big advantage of an RPC-like scenario is extensibility. Future improvements or vendor specific enhancements of the APIs you are reflecting over XMPP could be easily incorporated without changing a specification, which is a thing requiring a formal process and time. And among all different RPCs approaches I'm more keen toward IO-DATA, since it easily allows tracking the API version you are using. - is the XSF the correct place where to standardize these kind of applications? Well, I hope so! If there's a more appropriate place to discuss our spec, please let us know. Well, imho the it's just a problem of critical mass of interested people, now already three different persons showed up, so good luck! ;) bye -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] length of disco attributes
On Wed, Sep 23, 2009 at 5:43 PM, Waqas Hussain waqa...@gmail.com wrote: That hack slightly reduces the attack surface, but does not eliminate it. If any of the identity/ element's attributes have a '/' in them, they are open to attack despite the dummy feature. The thread on the security ML talks about several related attacks, of which this one is probably the most minor. Just realized that I'm many messages behind in that thread, so ignore my previous mail, I'm not adding entropy where there is already plenty ;) -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Proposed XMPP Extension: Linked Process Protocol
On Tue, Sep 22, 2009 at 11:38 PM, Peter Saint-Andre stpe...@stpeter.im wrote: My name is Marko Rodriguez. Joshua Shinavier and I created the Linked Process specification to support Internet-scale distributed computing. Peter Saint-Andre asked me to provide some context pointers to help readers to identify the niche in which Linked Process fits. Here is a list of resources that may be of interest: Thanks, Marko! I will make time to review this before tomorrow's Council meeting, though I must admit that the security considerations of your proposal are pretty scary. ;-) http://xmpp.org/extensions/inbox/lop.html#security It seems an excellent job for starting talking about XMPP Cloud Computing (indeed just peeked inside the use cases too see scope fo the XEP), and I've two considerations to start: - is a dedicated namespace with its verbs the correct approach for these things? why not building it at the top of IO-DATA for example (I'm always in favor to reuse what is existing)? - is the XSF the correct place where to standardize these kind of applications? I try to make myself more clear, since this in feature it will be a gray area with more and more non-chat xmpp applications. In order to standardize non-chat applications the XFS would need members, and a council, having experts in the specific application domain. I don't think that in the present and near future we will have all these skills. However such contributions are very useful since they give precious feedback for the infrastructure and even if the council doesn't decide to accept them as XEPs I think that we could provide some official space for discussion (e.g. more mailing lists? ;) ) -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XSF scope
On Wed, Sep 23, 2009 at 10:36 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I'm curious what you mean by already now it is very difficult to be updated about any aspect of XEPs. Part of the problem is that we've mostly had one spec author, and that introduces bottlenecks. But that situation has changed a bit over the last 12 months and I think it will get better over time because more people are helping with the writing and maintenance of XEPs. Well, reviewing doesn't require as much time as editing XEPs, but the possible topics are so many that I don't think that present and future council can handle more without losing detail ()with all the risks) or delegating decisions. Also, we essentially have one working group, which is this list. I have started other lists as informal special interest groups (for PubSub, Jingle, MUC, etc.). Some of those are more active than others, but overall I think that it has been productive to offload some of the discussions from this list to special-purpose lists. I agree that we have some scalability challenges, but overall I don't think they are too serious. Yet. :) About this I'm more pessimistic, since I'm optimistic (e.g. when people really understand wave - I've still do 100% myself indeed ;) - we'll see floods here) bye -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] to be deferred
On Sat, Sep 19, 2009 at 12:47 PM, Matthew Wild mwi...@gmail.com wrote: * XEP-0225: Component Connections IMHO it would be great to work on this, although Jack Moffitt has questioned how useful any kind of external component protocol really is (given that you serializing and deserializing XML is expensive). +1 to keeping this alive, it's something I'm quite interested in. Regardless of efficiency, components are very popular, they are a great way to implement services, and can be load-balanced, etc. We should definitely keep the ball rolling in this area. Regarding efficiency, by using a more standard XMPP stream, it would allow components to negotiate compression, or other more efficient encodings of the stream such as XEP-0239. Well, jokes aside, imho for components it makes sense to define a more efficient encoding. I like the concept of protocol buffers, but from what I've understood they work well just for messages whose format if fixed so they can't apply to xmpp. In the past we played with different binary encodings, but they usually are oriented to predefined schemas and therefore they are as limited as protocol buffers, but without their simplicity. The only solution we have found working in practice is a naive encoding we experimented, which doesn't cover all xml serialization, but the one which is actually used in XMPP. Here is a basic description of the format: Element: ( (namespace_tag,ns),name_tag,name nattrs,[(namespace_tag,ns),name_tag,name,len,value] nchildren,[Element]| text_tag,text ) tags are 1 or 2 bytes tokens which contain a the next token type (namespace, name or text) and its length in binary format; length values are also defined with 1 or 2 bytes containing a binary value. The great advantage of this format is that the type and the length of each token is known in advance and no escaping is needed, therefore it is possible to make very efficient parsers and serializers (in our experiments 3x than normal xml serialization) -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] to be deferred
On Sat, Sep 19, 2009 at 2:48 PM, Matthew Wild mwi...@gmail.com wrote: Yep, jokes aside this is exactly the kind of thing I had in mind. :) If anybody wants to experiment we have a python and a java implementation, just ask... this is one those things that needs feedback ;) -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Replacement for disco-publish
On Thu, Sep 17, 2009 at 9:14 AM, Pedro Melo m...@simplicidade.org wrote: Hi, No. I would need to check the previous versions but I *almost* certain that XEP-0030 disco-publish feature was created to help clients deal with the initial storm of disco#info requests. Basically, a client would publish his disco#info information to the server, and from then on, any requests for that information from other clients would be replied by the server, and not the client. Like a HTTP proxy cache, with the twist that the HTTP server would push the latest version of the document to the proxy. Others might know the true reason for that part of the spec, I can only speculate. Maybe it was written to solve the initial thundering herd of disco#info requests from everybody on your roster when you log in. Right now, I think the latest XEP-0115 (after we solve the pre-image attacks) is a better solution. Well this is good for di...@info, but what about disco#items? Publishing new items to pubsub nodes seems reasonable to me, since it would allow caching that information in the client (for example we do extensive use of ad hoc commands in our client and it would be nice to be able to cache that information an be notified only when it's changed). Since the distribution of disco#items follows a pattern where there is only one publisher some like PEP could be ideal. (there is just the problem that with many services like muc you don't have presence subscriptions) In anyway, for your use case, these are not the droids you are looking for. I would stick with pubsub: a lot of people are working on it, so you will probably find more good quality code for the server-side components. +1 -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] subdomains
On Wed, Sep 9, 2009 at 11:10 PM, Peter Saint-Andre stpe...@stpeter.im wrote: *** Unfortunately, the notion of a subdomain was never really defined -- it basically meant that you added another domain part to the left-hand side of a server JID, such as foo.example.com if the XMPP server is hosted at example.com or bar.im.example.net if the XMPP server is hosted at im.example.net. Yet we don't really know if what looks like a subdomain really is associated with a given XMPP server. So for instance there might be one XMPP server running at example.net and an entirely different XMPP server running at im.example.net. A long-running example is provided by jabber.com because there is also a server corp.jabber.com for employees (well, they now work for Cisco but you see what I mean!), and corp.jabber.com might look like a subdomain of jabber.com but in practice it is not. This is why we removed the notion of a subdomain from rfc3920bis. Well I think there is a way to define the difference using SRV records: if there is one we should consider it separate domain (even if it should point to the same host of the main domain, since they must be virtual hosts) Similarly, I suggest that we remove it from the JID matching rules in XEP-0016, XEP-0045, etc. Objections? No, since all the cases where we may need the concept of subdomain could be solved at application level with other extensions (e.g. I'm thinking of a case we worked on time ago where we had to consider a subdomain trusted and autoaccept all subscribe from that subdomain) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] subdomains
On Thu, Sep 10, 2009 at 12:18 PM, Dave Cridland d...@cridland.net wrote: No, because conference.jabber.org needs SRV records just the same as any other domain. + No, since all the cases where we may need the concept of subdomain could be solved at application level with other extensions (e.g. I'm thinking of a case we worked on time ago where we had to consider a subdomain trusted and autoaccept all subscribe from that subdomain) I would argue that there is no such thing as a subdomain, from the perspective of XMPP. Yes, I was about to to answer with some long philosophical consideration about what is what we call a subdomain, but the correct approach is indeed that. The protocol shall not have the concept of subdomain, if somebody wants to consider something a subdomain for configuration or application issue is free to do that. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] subdomains
On Thu, Sep 10, 2009 at 4:30 PM, Dave Cridland d...@cridland.net wrote: But seriously, you've made my point - the term subdomain is meaningless in most circumstances. The email address pe...@foo.example.net has no relation to pe...@example.net aside from a (likely) common ancestor in their management. And even that's not certain, given addresses like james...@sausage.demon.co.uk, which was (back when it existed) certainly not under the direct control of Demon Internet. I think that the confusion in XMPP was born with components, which have names like sub.example.org and which are locally routed by most servers even if there is no real address associated to them. Therefore in general we think that they are something that exists only in the server namespace -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] [xmpp] 3920bis: reliability
2009/9/10 Fabio Forno fabio.fo...@gmail.com: Although the core XMPP technology defined in this specification does not contain features to overcome this lack of reliability, XMPP extensions exist to rectify this problem (for example [XEP-0198]). I like this formulation I don't know why but the only reply-to in your message to the ML is not to the ML itself, but to your private address -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] separation of routing and payload
On Tue, Sep 8, 2009 at 10:53 PM, Peter Saint-Andrestpe...@stpeter.im wrote: message xmlns:shim='urn:xmpp:shim:1' from='ro...@montague.net/orchard' to='jul...@capulet.com/balcony' shim:In-Reply-To='123456...@capulet.com' shim:Keywords='shakespeare,lt;xmpp/gt;' bodyNeither, fair saint, if either thee dislike./body /message Now the routing entity (server) doesn't need to grovel around in the child elements of the stanza in order to figure out how to route or deliver the stanza. It works as long as the additional routing information has a flat structure, otherwise packing them inside the headers would be difficult. I'm not aware of such cases, but I think it's worth mentioning Moreover, though I'm well aware of speed gains in this approach, it encourages the bad behavior of some servers that think that the stanza is closed at the first /message found (I wouldn't know how to avoid it without parsing the inner xml) Finally a question for server developers: where is the need of this kind optimizations? Internal routing, c2s, s2s? -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
On Thu, Jul 16, 2009 at 9:49 AM, Pedro Melom...@simplicidade.org wrote: I've been thinking about this problem and I don't see a solution for this that is compatible with different generation of clients (those who support trusted sources for jabber:iq:roster and those that don't). I think this might be one situation where you would have to use a big bang approach: each user decides which protocol he wants to use, and all his clients must use that one. I'm hoping someone smarter will come up with something better though :) Best regards, I've been thinking about it too. Indeed which is the real problem? Just duplicated entries, which will be seen by the new client only, and we can cope with them while merging the rosters and giving precedence to the component's entries. The benefits are so high that we can live with this little issue ;) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Roster changes
On Thu, Jul 16, 2009 at 1:55 AM, Matthew Wildmwi...@gmail.com wrote: [] I think any client which doesn't obey this is inherently insecure already and should be fixed now, regardless of whether this proposed change goes ahead. For the reasons I stated on the XMPP list I don't have any desire for servers to vet stanzas a client receives to its full JID (privacy lists aside). XML well-formedness apart ;) Ok, convincing argument, though I still think that a separate namespace doesn't trouble any existing codebase and it allows experimenting with something new. But perhaps it is just aesthetics (and nobody forbids to use it privately, if you can't upgrade the server) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
Some more thoughts, which are the business rules for accepting roster items? I explain with some cases: - in the main roster on the server we have jids coming from any domain - can rosters coming form separate services (each one with its own domain, e.g. msn.jabber.org) contain jids from other domains or only in the same domain (s...@msn.jabber.org yes, but not s...@jabber.org)? I prefer to restrict to the domain - what happens when the main roster contains jids in the same subdomain of the service? I'd say that all that entries should be ignored by the client - do we allow full jids export their own roster to other clients? I'd say no in the case, roster providers can be just domain jids. bye On Thu, Jul 16, 2009 at 12:11 PM, Fabio Fornofabio.fo...@gmail.com wrote: On Thu, Jul 16, 2009 at 9:49 AM, Pedro Melom...@simplicidade.org wrote: [...[ -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
On Thu, Jul 16, 2009 at 3:27 PM, Kevin Smithke...@kismith.co.uk wrote: - in the main roster on the server we have jids coming from any domain - can rosters coming form separate services (each one with its own domain, e.g. msn.jabber.org) contain jids from other domains or only in the same domain (s...@msn.jabber.org yes, but not s...@jabber.org)? I prefer to restrict to the domain They can come from any domain - think of a shared roster/user groups service. Uhm, I'm trying to think together with presence delivery too. Shared roster is bit tricky in that, since shared.jabber.org could tell you that ham...@danemark.net is you roster, and then what? If your server doesn't know that presence is never routed. This seems a special case where some collaboration with server itself is needed In all the other cases instead the presence to the service jid is sufficient - what happens when the main roster contains jids in the same subdomain of the service? I'd say that all that entries should be ignored by the client You continue as usua (e.g. for a transport you could have the service and the service admin both in your main roster). I was thinking of removal. If it happens that you have s...@msn.jabber.org in the main roster and not more in the gateway it means that you have deleted it, perhaps with a different client, but you server will still think that you have a subscription. Instead if we limit the secondary rosters to a subdomain the client know that missing jids must be deleted from the main roster. (this should happen in the ideal world, but during the transition it will be the rule) - do we allow full jids export their own roster to other clients? I'd say no in the case, roster providers can be just domain jids. I don't follow - are you asking if e.g. I could share my roster with you? I was just wondering if a client entity could be a roster provider for a different client entity. I've no idea of possible applications, and I'd forbid it, but perhaps it's just lack of vision ;) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Roster changes
On Thu, Jul 16, 2009 at 6:15 PM, Dave Cridlandd...@cridland.net wrote: Clients says: iq type='get' query xmlns='jabber:iq:roster' ver='kjashdasfg' foo xmlns='http://example.net/megaprotocol/'/ bar xmlns='http://example.net/otherthing/'/ /query /iq Server responds with items looking like: item jid='ke...@example.org' name='Doctor Smith' groupDoctors/group foo xmlns='http://example.net/megaprotocol/' blargRowr!/blarg /foo /item Yes? Yep, I like the idea of filtering the namespaces we want. It would be super to ask additional data just for a jid, something like: iq type='get' query xmlns='jabber:iq:roster' jid='k...@example.org' foo xmlns='http://example.net/megaprotocol/'/ bar xmlns='http://example.net/otherthing/'/ /query /iq -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Roster changes
On Wed, Jul 15, 2009 at 4:47 PM, Peter Saint-Andrestpe...@stpeter.im wrote: Subjectively, roster (and subscription handling as a whole) was the single most annoying thing I've implemented so far, including MUC, data forms, file-transfer, etc. It's my subjective personal opinion, though, so you can freely ignore it. The only part I feel ugly is redundancy in presence subscriptions (duplicated information in the presence and in the roster protocol), but indeed it works by using just presence and listening for roster pushes from the server, so it is not a big deal. Instead I don't see any practical way for skipping presence floods, they may be annoying, but the only alternative approach is waiting for an undefined time. I never said that the roster+presence functionality is beautiful, simple, or easy to implement -- only that it has worked for 10 years, so I think we need to be very careful about designing something new and backward-incompatible at this stage. I hope not. I see only two intervention areas, which are both backwards compatible: - adding annotations to roster items (the pubsub approach could be fine, but also a separate protocol for address books) - the ability of handling multiple roster sources, as discussed in the other thread in xep 144 The good thing of both is that they just add something that can be ignored by unaware clients and servers. -- Fabio Forno, Ph.D. Bluendo srl jabber id: f...@jabber.bluendo.com
Re: [Standards] Roster changes
On Wed, Jul 15, 2009 at 5:05 PM, Peter Saint-Andrestpe...@stpeter.im wrote: Right. But then clients and servers need to implement two similar but different protocols for almost exactly the same functionality. Is this really worth all the time and effort and confusion involved? If it's for handling multiple sources the two namespaces are just a temporary hack for allowing the messages pass through the server, but the implementation is the same -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Roster changes
On Wed, Jul 15, 2009 at 5:18 PM, Peter Saint-Andrestpe...@stpeter.im wrote: The requirements for such features are quite nebulous, IMHO. If someone cares about them, they can work to define them more clearly. At the moment I don't feel there are any truly compelling use cases here, but I freely admit that I might be wrong because I haven't thought about it in detail yet. The roster activation idea is an optimization for mobile environments that we talked about at XMPP Summit 6 earlier this year. Refer to the list archives for a bit more insight into what that might mean. You are right. In part my fault, in part overwhelmed by too much noise, since each time we start talking about a minor change in the roster, as this time, there is a big thread for re-engineering the whole architecture, with no practical outcome at the end [1]. Therefore we decided to go with privacy lists, which are ugly as well, but at least they are implemented [1] I think that is one of the things where it is better to work in private in small groups and start public discussion only when there is a complete proposal -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Roster changes
On Thu, Jul 16, 2009 at 12:38 AM, Peter Saint-Andrestpe...@stpeter.im wrote: It's not clear how many server codebases follow RFC 3921 about blocking jabber:iq:roster packets, but if we're going to remove that restriction (it seems we have consensus) then start filing bug reports and feature requests with your favorite server codebases and I would bet they will fix this before draft-ietf-xmpp-3921bis becomes an RFC. :) What about clients that don't check the from, which is legit since they trust the server? For them we introduce a temporary security issue -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
2009/7/14 Remko Tronçon re...@el-tramo.be: Right, but I keep wondering if modifying XEP-0093 to include the second use case was wrong... It wasn't really a good flow, no. Psi implements this XEP too, and it helps with the whole auth-storm-on-gateway-registration, but still has quite some drawbacks. I think we should try defining a better protocol for this. Indeed psi still has the problem of storms, since after presenting the addition request it asks to authorize each presence subscription arriving from the gateway as an answer. However this is just an implementation issue easily fixable. I liked the thought we had a few years ago where you could use jabber:iq:roster on something else than a server JID (which was prohibited by the RFC back then, I forgot if we did something about that in bis). Remote rosters such as component rosters wouldn't need to be mirrored in your real roster any more, which would solve quite a bit of problems. Openfire allows this, and the gateways use jabber:iq:roster. It works fine, but in order to use too roster sequencing I'd like to have a centralized repository of the roster, and the best approach, if we don't want to hack into the server, is to directly tell the client what to do. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
On Tue, Jul 14, 2009 at 8:11 PM, Peter Saint-Andrestpe...@stpeter.im wrote: We have long resisted this because we saw jabber:iq:roster as all and only between you and your server (cf. recent discussion about 3921bis on the XMPP WG list). If we remove that restriction, you can have a roster relationship with any other entity, such as shared groups service. With the only caveat that clients must pay attention to the from in roster sets. This puts a bit more complexity in the service and the client, especially if we want to support roster versioning for all the components, but the overall advantages are clear. I like it also for social applications, in that way the service can add/remove special contacts accordingly to the active feeds of the user, without cluttering the main roster So yes, let's use standard rosters for transports and shared groups, and let's keep roster item exchange just for sharing contacts. WFM. Two small issues: - it won't work until servers route the packets (small fix, but upgrades are needed) - transition will be difficult, since if it can't work while using two different clients of which just one supports it (and the case is very common, since nobody uses the same client for teh desktop or mobiles) -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
[Standards] xep - 144
Hi, we are trying to use XEP 144 for synchronizing the roster of our mobile client with remote services, but we encountered a number of issues, mainly: - lack of feedback from the client to the service of which modifications of the roster have been accepted - lack of any mechanism for re-synchronizing the roster if something wen wrong Therefore we are thinking to extend the XEP in order to address these issues, the only problem is that we could propose some breaking changes, therefore we'd like to know if anybody is : - using the XEP (we know that psi does, but the implementation is not very usable, I think for the lack of testing since no transport is using it) - planning to use it, in that case any suggestion? bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
On Mon, Jul 13, 2009 at 11:07 PM, Brian Cullybcu...@gmail.com wrote: I am using it in-house with an ad-hoc command interface, and it works passably. I'm not sure about the points raised here. Regarding lack of feedback, this might be considered a feature. My understanding of roster push is that it merely advises the client to make changes to its roster and is only concerned with the client having accepted the changes (even if it didn't employ them). If a client decides not to take a change a future request for a roster push probably shouldn't push out that change again (the client already reviewed it and said, no). Indeed this is the problem we have in absence of feedback: we don't know if the client reject it or it simply didn't process it, and therefore we can't resend additions. The result we observed is that after a while the roster then to be de-synchronized As for re-synchronizing the roster, as I recall the spec there's no way to synchronize the roster either. Hence the ad-hoc command interface, which can be easily extended to do a full push again, if necessary. This is one option we have, however there is no easy way to detect deletions with the present specs (the client can't keep track of who added the contacts, so missing contacts in the resend can't be dedected That being said, I'm not the biggest fan of XEP-0144, and would be keen to see any proposed changes although I lack any of my own at this time. Briedly waht we have in mind: - for the first issue we plan to add an id to the addition iq type=set x xmlns='http://jabber.org/protocol/rosterx' xid='1234' action type=add/ !-- items -- /x /iq The client therefore sends a result when it receives the stanza, as it happens now. Then after the user has processed the changes it sends back iq/ containing the accepted items iq type=set x xmlns='http://jabber.org/protocol/rosterx' xid='1234' result/ !-- items -- /accepted /x /iq - for the second issue we would like to send an iq/ of type get, specifying a query asking for all the contacts of a given group or domain, so that we can compare the result with the contacts we have in the roster and detect deletions too; as you say this can be done with an ad hoc command too, in that case I'd like to write an example in the xep in order to document the practice. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
On Mon, Jul 13, 2009 at 11:48 PM, Peter Saint-Andrestpe...@stpeter.im wrote: I like the idea of being able to share roster items, introduce one person to another over IM, etc. But I'm not convinced that XEP-0144 solves compelling use cases. XEP-0093 was simpler and therefore better, IMHO. We have two use cases: - exchange of business cards, where xep-0093 was good, since we don't care if the items are processed - roster sync with a component (it may be a transport, but also a component hosting different services), and for that we'd like to see the result of the operation bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
On Tue, Jul 14, 2009 at 12:59 AM, Peter Saint-Andrestpe...@stpeter.im wrote: Right, but I keep wondering if modifying XEP-0093 to include the second use case was wrong... An approach could be resurrecting xep-0093 for the first case and use ad hoc commands for the whole second one. We just send an ad hoc command containing the block of roster commands that the client should apply, ad we wait for the list of accepted commands as result bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep-0136 message archiving
On Mon, Jul 13, 2009 at 10:50 AM, Dave Cridlandd...@cridland.net wrote: The biggest question is really the decision on whether to have the IMAP message be a conversation or a single message. I'd argue that we should make formats for both, but do single messages by default. I bet the discussion already started many times, but what do we define as a conversation? -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] more obsolete specs
On Tue, Jun 2, 2009 at 10:20 PM, Peter Saint-Andre stpe...@stpeter.im wrote: OK. Feel free to work on the spec. I can give you SVN access. :) Aye sir! -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] more obsolete specs
On Sat, May 30, 2009 at 3:17 AM, Peter Saint-Andre stpe...@stpeter.im wrote: Yes, I agree. Is XEP-0144 good enough, or do we need to (1) improve it or (2) define yet another approach to solving the problem? Basically improvements, trying to solve the few situations leading to an undetermined behavior. For example in iq semantics it is written: If the receiving entity successfully processes the suggested action(s) (which may include ignoring certain suggestions), the receiving entity MUST return an empty IQ result to the sending entity. This approach presents some issues: - if the sender of the items is a different entity from the one which will process subscriptions it is impossible to know which modifications have been accepted or rejected - even if the two entities are the same it is not possible to know why some subscriptions haven't been processed. For example if we don't receive a subscribe we can't distinguish an explicit reject from client side issues (network problems, client crash, users forgetting to take actions before ending their session) and this is bad, since we don't know whether to resend them or not Imho an iq/, with the accepted modifications, sent back to the sender after the user has processed the additions would solve the problem (we just need a session-id for linking the this notification to the triggering first request). bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] more obsolete specs
On Fri, May 29, 2009 at 3:42 AM, Peter Saint-Andre stpe...@stpeter.im wrote: for historical purposes, so I'd be fine with keeping that as Deprecated. It seems to me that both XEPs 93 and 144 (which define different flavors of roster item exchange) are not widely implemented, so I'm agnostic about those. XEP 144 is useful but it has two problems: - the result iq is just an ack saying that the receiver has received the roster modification, be we don't know if the user has accepted the new items or not (in some cases it can be done indirectly, but it is not easy) - there should be more sophisticated way to negotiate the level of trust with the roster modifier (e.g. in a Facebook gateway we don't want to accept again the contacts since we already did it) Moreover, if we move from a pure IM scenario to a platform for offering services, I think that XEP-144 is crucial for automating the interaction with different service providers. For example in a geolocal based application I don't want users to continuously search for contacts and approve them while moving, but I'd like to have roster group which is continuously updated with the services available in the current context. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Call for Experience: XEP-0138 (Stream Compression)
2009/4/30 Remko Tronçon re...@el-tramo.be: 1. Who has implemented XEP-0138? Please note that the protocol must be implemented in at least two separate codebases (and preferably more). I implemented it in Psi, and reimplemented it from scratch in Swift. So that's 2 implementations ;-) One more implementation is Lampiro, so it works also with the most sluggish mobile platform, i.e. j2me. 2. Have developers experienced any problems with the protocol as defined in XEP-0138? If so, please describe the problems and, if possible, suggested solutions. The protocol itself is simple enough to not have problems with. I tested the compression part itself with several server implementations, and had no problems. Except for Openfire. It used to work fine up to a certain version, and after that it went wrong. The stream starts out fine, but after a while gets scrambled, typically after a burst of stanzas. Smells like a buffer overrun. [...] I confirm the problem related to Openfire implementation, with all other test servers it is a piece of cake 3. Is the text of XEP-0138 clear and unambiguous? Are more examples necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. I don't recall any confusion over the protocol. I've just a problem with the business rules, specifically these ones # TLS compression and stream compression SHOULD NOT be used simultaneously. # If both TLS (whether including TLS compression or not) and stream compression are used, then TLS MUST be negotiated first, followed by negotiation of stream compression. The above business rules don't forbid but discourage to fall back to stream compression after TLS has been established but no compression has been activated. I see no harm in telling that stream compression MAY be offered after TLS if TLS doesn't succeed in activating compression (so far we haven't been able to to it with any server) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Call for Experience: XEP-0138 (Stream Compression)
On Thu, Apr 30, 2009 at 10:16 PM, Fabio Forno fabio.fo...@gmail.com wrote: I've just a problem with the business rules, specifically these ones # TLS compression and stream compression SHOULD NOT be used simultaneously. # If both TLS (whether including TLS compression or not) and stream compression are used, then TLS MUST be negotiated first, followed by negotiation of stream compression. The above business rules don't forbid but discourage to fall back to stream compression after TLS has been established but no compression has been activated. I see no harm in telling that stream compression MAY be offered after TLS if TLS doesn't succeed in activating compression (so far we haven't been able to to it with any server) Just had an IM coversation with Dave about that. I completely misread the rules skipping the word TLS *compression* in the first rule, so the rules work, sorry. There only one possible improvement in the second rule, which better clarifies when using stream compression: Stream compression MAY be offered after TLS negotiation if TLS compression fails (it sounds more as a recipe for users) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0237: version == sequence number?
On Thu, Apr 23, 2009 at 8:36 PM, Peter Saint-Andre stpe...@stpeter.im wrote: We would need to decide what to do where we currently set ver='0' though. Yeah, I was thinking about that too. I suppose it could still be zero or some non-opaque string (bad), or that we could add another attribute (bootstrap=true?) rather than overload 'ver'. Sorry but I don't get the purpose of this. Isn't sufficient to omit ver for bootstrapping? -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On Fri, Apr 17, 2009 at 4:59 AM, Peter Saint-Andre stpe...@stpeter.im wrote: I think that the things you are describing fall into the category of optimizations that a smart client can implement to improve the user experience. But we don't need to describe all that in the spec (in the unlikely event that you get disconnected after receiving some but not all of the roster pushes, cache what you've received so far but then when you reconnect you can shave a few seconds off the reconnection process by requesting the roster based on the version of the last roster push you cached, not the last full roster update). That kind of thing is great but IMHO it doesn't really belong in an RFC. +1 In fact in our implementation based on the current xep we haven't seen any real issue that can't be dealt with good heuristics -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
[Standards] crazy idea of the day: Oauth'ed sessions
Hi, while I was testing speeqe, the nice BOSH based MUC client of StanzIQ, I've noticed one limitation we have with XMPP which is only partially addressed with XEP-0235, OAuth Over XMPP. XEP-0235 allows to use XMPP resources with an auth token obtained via OAuth. All the use cases in the XEP are based on the assumption that an XMPP entity needs to do some operations on resources on which it has no rights, and therefore it needs a special authorization. That is the purpose of OAuth, however there is one more case which isn't addressed: allow somebody else to behave as if it were me only for a limited scope. Examples are web based chats I don't completely trust: instead of giving them my password I just pass them an OAuth token which allows at most n logins or just exchanging messaging with a given conferencing server. The basic mechanism would be a simple token-based authentication, after which is created a session with the limitations set during the token generation. Right now I'm just asking because it's something that needs big changes in server session management and it will take a long time before seeing it implemented. So it's better to know in advance if there is interest or better way to do the same things. Possible applications: - in general login with untrusted clients or hw (the authentication token can be also generated with an external device such as a smartcard) - web based sessions, with bosh clients embedded in third parties sites (e.g. I'm on facebook and I don't want to use their ugly chat, but my real JID and I don't want to give away my password) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] roster partial activation privacy lists
On Fri, Apr 10, 2009 at 4:07 AM, Peter Saint-Andre stpe...@stpeter.im wrote: [Privacy list management] Another possible hack is to create a temp group and add/subtract people in that group (leaving VIPs alone). Yep, nice thought. This suggests me that perhaps hiding privacy lists from users and doing a bit of group and rule name standardization as for dataforms could solve many of the problems with them. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] unavailable presence from bare JID
On Thu, Apr 9, 2009 at 1:08 AM, Peter Saint-Andre stpe...@stpeter.im wrote: In fact I suppose someday (not anytime soon!) some people might want to get rid of resource entirely, but that'll happen in XMPP 2.0 after I've retired. :) we are already discouraging them with eco xmpp :D -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] unavailable presence from bare JID
On Wed, Apr 8, 2009 at 1:58 PM, Peter Saint-Andre stpe...@stpeter.im wrote: Should the client assume that the resources 'bla' and 'foo' are offline now? I think that presence about a bare JID is meaningless. Many components send presence from [n...@]component.domain without resources. I've always interpreted that as the null resource (while just / should be the resource with length zero) and treated it as if it were a XMPP entity. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Tue, Apr 7, 2009 at 3:05 AM, Peter Saint-Andre stpe...@stpeter.im wrote: S: t xmlns='urn:xmpp:sm:1' max=n/ It isn't perfect but it can work for most of the cases. Agreed. But what is the purpose of max=n here? It could be used to adjust the number of maximun number of outstanding packets (When throttling it makes sense to reduce it) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] roster item exchange
On Mon, Apr 6, 2009 at 12:36 AM, Peter Saint-Andre stpe...@stpeter.im wrote: I haven't looked at XEP-0144 in a long time, but IMHO it would be fairly straightforward to add this kind of optional notification. I'd be happy to work with you on that. Great! we have just implemented in a facebook gateway and in Lampiro a great deal of xep 144 and pep for avatars and we found few quirks and possible optimizations that will improve user experience. I know that we shouldn't encourage too much transports (they must be painful! :D), but the ability of manipulating from another entity the roster is terrific for automatically adding/changing services accordingly to the user context. Tomorrow or in the next days we can catchup via jabber for exchanging ideas. Now it's 2am here, better go to bed ;) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] ACTIVE: XEP-0263 (ECO-XMPP)
On Wed, Apr 1, 2009 at 2:53 PM, Jacek Konieczny jaj...@jajcus.net wrote: On Wed, Apr 01, 2009 at 07:04:12AM -0500, XMPP Extensions Editor wrote: Version 1.0 of XEP-0263 (ECO-XMPP) has been released. Abstract: This specification defines best practices and protocol modifications that will reduce the energy consumption of XMPP systems and thereby help to save the planet. Great document! I am sure European Union will be happy to refund implementations here in Europe. I am sure someone would really be able to get some funds for this. :) We could get some sponsorships for initiatives like the JID give up Day, in which users unregister from servers and uninstall their favorite client ;) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0237: versioning via timestamps?
On Tue, Mar 31, 2009 at 7:40 AM, Curtis King ck...@mumbo.ca wrote: time makes a bad counter as it can go backwards and there are resolution issues ;-) [...] +1 -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Tue, Mar 31, 2009 at 3:23 AM, XMPP Extensions Editor edi...@xmpp.org wrote: Version 0.7 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: Removed pings (use XEP-0199, whitespace pings, or TCP keepalives instead); removed section on throttling, since it is unworkable. (jjh/psa) Imho some throttling notification is feasible only in one way: it's up to the server send unsolicited throttling notifications when it knows it is throttling voluntary the stream (this means that if packets are stuck in a TCP buffer it's likely that even the server doesn't know that the stream is being throttled). Anything triggered by a stanza sent by the client is unworkable since that stanza cannot have higher priority and pass ahead the others. As optional I'd put a stanza for this purpose: S: t xmlns='urn:xmpp:sm:1' max=n/ It isn't perfect but it can work for most of the cases. And what about reqs and acks? In the previous thread (http://mail.jabber.org/pipermail/standards/2009-March/021409.html) we saw that r/ stanzas after the regular ones could lead to some lack of reliability, while it's better to just count stanzas and send back a/ acks bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Tue, Mar 31, 2009 at 4:05 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I would prefer the sequence number to be a stanza count, but Justin talked me out of it while I was making revisions. However, from the post you've pointed to, he seems to agree, so I'll fix that. As to sending r/ after the stanza, I'm not quite sure what you propose. Do you think that the server will just send a/ based on its stanza count (perhaps after every stanza), without forcing the client to request acks? More or less. The r/ stanza should be taken out since it is impossible to know whether just the r/ or both the pair message/ and r/ didn't get to the server, and it is a redundant information if we set the sequence to be stanza count. The only doubt I have is whether to make the stanza count implicit or explicit with a seq attribute in the stanza (eg. message sm:u=n/). The first works if we force to ack each stanza and we don't allow more than one unacked stanza out, the second is more general. In the last message of the thread I was keen to do without the sequence number, but I now realize that that would slow too much the communication from the server to the client (i.e.: all the initial presence burst would take tens of seconds in a mobile connection, having to wait for all the acks) bye -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Tue, Mar 31, 2009 at 5:17 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: Proposed change: Don't send 'u' over the wire anymore. The value shall be derived by the number of stanzas sent, starting from 0 (no stanzas sent yet). C: message/ C: r/ S: a h='1'/ We'd still have r and a ack elements. They'd just only ever contain 'h' now. I fear this increases the problems rather than solving them: it works only if the if we have a 1-1 match between stanzas and r/s, but in this case: - it's redundant - it slows the server to client connection, since burst of packets must be acked one by one -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Tue, Mar 31, 2009 at 5:31 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: C: message/ C: message/ C: message/ C: r/ (when S receives this element, it knows 'u' is 3) S: a h='3'/ Yep but if the client doesn't receive the h='3' the only safe decision is to to resend all the 3 messages, while any number of them could have been already processed and delivered to the correct recipient. If the message itself contained the sequence number the server would be able to discard duplicates. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Tue, Mar 31, 2009 at 5:57 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: justin-keyword-jabber.093...@affinix.com wrote: C: message/ C: message/ C: message/ C: r/ (when S receives this element, it knows 'u' is 3) S: a h='3'/ [...] When the session is resumed, the server will state its last 'h' value. If the server had received all three message stanzas, then the value it will use during the resume is '3'. If it only received one, then it would put '1'. The client will only resend what the server didn't get. Ok, so the r/ just triggers an ack, and everything is bound to an implicit sequence number bound to stanza count. It seems to work, the only thing to decide is whether to count r a stanzas ;) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Tue, Mar 31, 2009 at 6:27 PM, Fabio Forno fabio.fo...@gmail.com wrote: Ok, so the r/ just triggers an ack, and everything is bound to an implicit sequence number bound to stanza count. It seems to work, the only thing to decide is whether to count r a stanzas ;) Just realized: the max number of unacked stanzas could be used in order to prevent throttling and negotiate the rate with server... -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Tue, Mar 31, 2009 at 6:29 PM, Dave Cridland d...@cridland.net wrote: Technically speaking, those aren't stanzas, which might answer the question. And it confirms what I had in mind ;) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
[Standards] pep avatars
Hi, we're implementing user avatars with our mobile client and we're trying to do that with bandwidth issues in mind. According to xep-163 the only reliable way to sync items (avatar version) is sending the latest item to each user session, then if the clients notices a change it can retrieve the avatar. For mobiles this is rather heavy since the average pep notification is 500 bytes, while the vcard-temp:x:update child in the presence is just 100 bytes, and both must be sent each user session. This means that for mobiles it is far better using the old vcard based protocol, approach I don't like since PEP is much more useful. Therefore I'm trying to think of a way to reduce the item notifications and send them only when they are really changed, not to each user session. So far the best way I thought of is extending client presence with an uuid identifying the client instance, so that the PEP service can figure out whether that client has already been updated. Example: presence c capabs/ x xmlns=urn:xmpp:client:uuid:0 uuid=some-uuid /presence The pep service matches the uuid for each node the client is subscribed to and, if it hasn't sent the latest item to that uuid it sends an event notification, otherwise it does nothing, avoiding sending redundant data. -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] pep avatars
On Thu, Mar 26, 2009 at 12:44 PM, Pedro Melo m...@simplicidade.org wrote: I understand your problem, but do you really want to send that with all the presence's or just the initial one? That's one of the things worth discussing ;) I guess it is more conservative to send the uuid for each presence. An additional field in the capabilities could be more efficient since we save a new XML element and a namespace declaration Also, do you have any data on the size of those 500 and 100 bytes after compression? Well... big numbers are more impressive :D I don't want to consider vcard avatars, since I'd like to have a general mechanism for other things too. On the single event we have a gain of the 50 - 60% of the data which is not a lot, but there many random strings in the message. A good guess, with the entropy of the previous messages, could be 150-200 bytes per user, which is still a lot: if you have 100 online contacts it's 15K just for knowing that nothing has changed. Moreover the gain is not just for avatars, but for any PEP node, with very little work at server side and breaking nothing with clients non supporting it (if there is no uuid we just send the notification) -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] pep avatars
On Thu, Mar 26, 2009 at 1:28 PM, Pedro Melo m...@simplicidade.org wrote: I understand, but if the cost of sending those my current item is this with presence if greater than just receiving the item at start (not the image data, just the metadata), then this discussion is moot, right? I haven't explained well. It's not my current item, just my client uuid is[1]. I'd like to be able to do the same with the pair (ext, jid) from the capabilities, but if I use the same client with same resource on a different pc with PEP I've no way to recognize the client hasn't been synchronized. And for this things like sequencing aren't good, since basically you always send the last version for each node. [1] this requires keeping a bit more of context at server side, but I think it is marginal. We are experimenting it with a facebook gw and it is rather easy to maintain On the single event we have a gain of the 50 - 60% of the data which is not a lot, but there many random strings in the message. A good guess, with the entropy of the previous messages, could be 150-200 bytes per user, which is still a lot: if you have 100 online contacts it's 15K just for knowing that nothing has changed. but you would have to send the UUID of each of those contacts to tell each of those PEP nodes which version you have, right? If I have N contacts, and each one of them uses PEP for avatar and user tunes, when I start a new session, I would need to send to each PEP node my current UUID so that they know which version I have before they send me the current version. So I would have 200 stanzas just to communicate my current cached status, via the upload link, usually on the lowest bandwidth side. Or I could receive notifications from all those PEP nodes telling me this is the version I got, from the larger bandwidth side. I admit that I haven't read these XEP's lately and I'm might be missing something... See above, just one uuid, bound to the client, not to subscribed nodes. Some quick figures: - present scenario (just for avatars, with more nodes it gets worse): I go online with 100 online contacts and I receive the latest item version - ~15K - proposed scenario (worst case): all my 100 contacts put client uuid in their capabilities in their presence - 25 byte * 100 - ~ 2.5K and nothing more if avatars haven't changed. In order to waste bandwidth more than the 80% of the contacts must have changes avatar, while in the normal situations (no avatar changed) I save the 80% of the traffic -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Fri, Mar 20, 2009 at 1:22 AM, Fabio Forno fabio.fo...@gmail.com wrote: Of course, I still question the need for 'u' at all if we're doing it like this. Now I remember: for limiting latency it's better to allow a window of unacked stanzas (on slow mobile connections each roundtrip can be 2-3 seconds) Sleep is always beneficial. No need of a sequence number also for multiple unacked stanzas. Example: start session, both client and server reset their counter --- C,u=1: message/ C,u=2: message/ C,u=3: message/ S: a h=3/ --- messages arrived too fast, the server has sent a single ack for all C,u=4: message/ first case broken link, the server has received u=4 and processed it, but it didn't succeed in sending back the ack resume session: client sends u=4, server h=4, no need to resend u=4 new conversation follows second case broken link, the server hasn't received u=4 and processed it resume session: client sends u=4, server h=3, client resends u=4 C,u=4: message/ new conversation follows -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Thu, Mar 19, 2009 at 7:49 PM, XMPP Extensions Editor edi...@xmpp.org wrote: Version 0.6 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, pings, and stream resumption. I see one issue for perfect stream reliability: stanza suplication. An example: [C]message/ [C]r u=1/ [S]a h=1/ [C]message/ [C]r u=2/ server sends back a h=2/ but the connection dies --- client resumes the stream and the last ack is 1 --- [C]message/ -- this packet is duplicated since the server processes it as it arrives, without awaiting for the r/ [C]r u=2/ This is a simple case and it can be avoided with some heuristic, but there are many others also when we force an ack for each packet, since the stanza the following ack aren't atomically processed. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Thu, Mar 19, 2009 at 11:21 PM, Fabio Forno fabio.fo...@gmail.com wrote: I see one issue for perfect stream reliability: stanza suplication. An example: duplication of course ;) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Thu, Mar 19, 2009 at 11:27 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: It's also useful to ping the connection when there's otherwise no traffic. Of course you could just use the ack packets with a sequence number for this, but having a separate ping element seemed cleaner. but compressors like little entropy ;) I'm asking Indeed, which is why the original document said the server SHOULD respond to pings while throttling, not that it MUST. However, maybe it's time to reevaluate how throttling should be done. Yes, but things bound to timeouts are more difficult ti handle In order to ensure presence isn't stale, clients (and servers) are going to want to abandon the connection quickly if it appears dead. I understand that not reading the socket is a very good way to throttle connections, but at the same time how is a client supposed to tell the difference between a throttled connection and a dead connection? Maybe the server could send unsolicited pongs (you're not dead!) while the receive channel is blocked? I was thinking exactly to this, something sent by the server in order to tell please slow down. Pongs are perfect candidates bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Fri, Mar 20, 2009 at 12:49 AM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: I don't see much value in allowing the sequence number to be out of sync with the stanza count, so how about we just make them match? The value of 'u' could always be the number of stanzas transmitted so far, and we wouldn't send 'u' over the wire anymore. I don't know why (it's 1 am here now and part of the brain is already sleeping ;) ) but there is a voice inside me crying because the sequence number is better explicit, and at the same time if it is inserted after the stanza some loss of synchronization can happen. It's likely that tomorrow morning after some sleep I can also produce and example of how it can happen ;) In the meanwhile a second voice is rising: what about putting the u and h attributes inside the message stanzas (an r/ child in the proper namespace can do the work)? bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On Fri, Mar 20, 2009 at 1:12 AM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: 'h' would stay outside of the stanza, since you need to be able to send it without having to send a stanza. And 'u' could always be in the stanza, since you'd never use it without having sent a stanza at the same time. C: message u='1'/ S: a h='1'/ I like it Of course, I still question the need for 'u' at all if we're doing it like this. Now I remember: for limiting latency it's better to allow a window of unacked stanzas (on slow mobile connections each roundtrip can be 2-3 seconds) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
[Standards] roster partial activation privacy lists
A quick recap about all the discussions we had since Brussels and some new thoughts on roster optimizations - Roster sequencing rocks, it should be inserted into rfc3921bis and all the world will implement it - Partial roster retrieval: it's not clear whether it should be just retrieval or something modifying also the behavior of presence broadcast. I'd prefer to stick it just retrieval, without affecting presence and implement it as an optional xep, letting what I call activation to a different mechanism. The main reason is that these are two different things which can be needed in different situations; partial retrieval has sever distinct use cases, which are independent from presence delivery: - just discover the groups - retrieve just a group - retrieve accordingly the subscription state (I feel this is pretty important since I don't want to retrieve 1000 contacts with subscription == none on my mobile, as it can happen if I use the roster as address book for contacts I have very infrequent communications with) - retrieve additional information bound to contacts (certificate, vcard, ...) - About partial roster activation there are different points of view, some say it's not necessary, some is fearing a new monster like privacy lists, others say just use privacy lists! The only thing I'm sure about it is that we need it, since from few tests when I go online with my mobile (compression enabled), I get the following figures: - ~ 1.5 KB for logging in with all the stream features and sasl thing - ~ 4-5 KB for a ~ 150 contact roster - ~ 12-14 KB for the inbound presence storm, most of it completely unwanted. So we did some internal brainstorming and here is what is our implementation plan: - privacy lists have the nice feature of being there and ready, so we will use them - we don't implement them, but just use them, that's to say users will be not aware of the existence of such a baffling thing like privacy lists, we just add a group VIPs (an perhaps some other more in future) and the the user: if you want to save bits just add there all the people you want to see whether they are only or not - If the VIPs group has items we create a privacy list in which all incoming presence is blocked but that of VIPs - Before going online we set the VIPs privacy list as the active one The only problem is that if we want to probe some contacts not in them VIPs group we must either put them temporarily in the VIPs group or unset the privacy list, and I don't know if there ar workarounds for this (but a service with which we can poke the presence of somebody using an iq/ bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] roster versioning redux
On Thu, Mar 12, 2009 at 5:16 PM, Peter Saint-Andre stpe...@stpeter.im wrote: Developers have been poking me about roster versioning: http://xmpp.org/extensions/xep-0237.html In fact developers are already implementing it. :) So we need to make a final decision: 1. Do we limit this to rosters? iq type='get' query xmlns='jabber:iq:roster' ver='foo'/ /iq Implications: (a) it is included in rfc3921bis (b) it can't be used for anything else (e.g. disco) and we'd need to define similar methods for those protocols. for disco it'is better to use result sets and filters, since the usual pattern is browsing new data, not receiving some information that usually has no or few chages. So I go for #1 -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
On Mon, Mar 2, 2009 at 8:23 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I was chatting with Joe Hildebrand about XEP-0255 and he mentioned that [...] It seems that we'd need this because your ethernet address might be different from your wifi address even in the same location (e.g., where I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi address is 00:23:6c:88:d4:1d). Uhm.. is that meaningful? Usually for location queries external references are more useful than your address (e.g. your MAC moves with your notebook, so what is the purpose of doing a query with it?) Besides that there is one more reference we are starting using: RFID addresses, which allow to pinpoint the exact position of the device. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
On Mon, Mar 2, 2009 at 11:15 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I meant your locally-assigned IPv4 or IPv6 address, not your MAC address. My bad. Penitenziagite! :D Yep, now I get the point and it makes sense Besides that there is one more reference we are starting using: RFID addresses, which allow to pinpoint the exact position of the device. The only problem is that there are few different id schemes (e.g EPC, 96bits; iso 15693, 64 bits and other proprietary). Somewhere there urn schemes allowing the mapping between the different standards, but a solution like this should be general enough: typerfid/type ididscheme:id/id (need to do some more research for confirming) -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] Multiple binds in XMPP-CORE
On Sun, Mar 1, 2009 at 10:39 AM, Dave Cridland d...@cridland.net wrote: This sounds like another reason why multiple binds are just overcomplicating the protocol. Additions like this to core cause unforseen issues like this. Who wants this, anyway, and why is it going into core? I was about to ask the same thing. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Multiple binds in XMPP-CORE
On Sun, Mar 1, 2009 at 10:45 AM, Dirk Meyer dme...@tzi.de wrote: I'm thinking of maybe having a proxy in the home network. All local devices connect to the proxy and the proxy relays everything to the server. In that case the proxy registers all resources from its clients to the server. Maybe it is a stupid idea, maybe not. Besides the fact that it seems overcomplicated, I'm not sure that for an home network the approach same jid, multiple resources is the correct one. Multiple resources are sometimes confusing and cause problems in message / packet delivery, so I'd avoid any action for extending their use. The only use of resources I'm a fan of is for allowing simultaneous connections of the same user from different devices. In these cases I prefer at least three possible alternate approaches: - trivial, but effective: give a jid to any device (the TV set is not the same thing that your alarm: they have distinct roles and perhaps also authorized users and contact lists) - in you really want to put all together use different nodes for appending commands - use an home server and talk to the world with s2s connections (sooner or later we will have the challenge of handling hundreds of thousands of s2s connection, so let's face it! ;)) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] roster views
On Sat, Feb 28, 2009 at 10:59 AM, Waqas Hussain waqa...@gmail.com wrote: Partial roster activation is a much much more attractive feature for me than partial roster retrieval. I would probably never consider using partial roster retrieval for my jabber account. Partial retrieval will become useful by using the roster as general purpose address book, as we discussed in Brussels. In that case it becomes essential to be able to query it or do partial retrievals. During the meeting we made also made additional use cases: each roster item could have additional data (vcards, certificates, ...) and that information should be retrieved only upon specific requests, not everytime you get the roster. In other words if we want to extend the roster we need some mechanism for filtering retrieval in two dimensions: - filtering the contacts that are retrieved - filtering the additional information sent with each contact However I tend to agree that partial activation (together with sequencing) is much more urgent than partial retrieval Anyway, some things to consider for roster views: 1. More than one activated group at a time needs to work on/off toggle for each group. If you specify nothing all groups are active by default, otherwise only the groups marked with on are active. I also like the idea of having separate toggles for in/out presence since are very easy to insert the UI: on each group just place two buttons indicating activate/deactivate group and hide/show me to group which are very clear and accessible for all users 2. They may be more useful if they worked based on filters on all data associated with a contact, e.g., groups, subscription, hosts ? 3. IM users would obviously want to change the activated groups more than once during a session, so that needs to be covered The on/off toggle can be sent with an iq at any moment. I don't know (for having a single solution covering also invisibility) if it is useful to activate/deactivate single users. Fabio Forno's email covers 1 and 2. As for the RFC vs XEP argument, my personal opinion is to keep the RFC short, and have these in an XEP, but I don't feel too strongly about that. My point is that sequencing and partial activation should go in the RFC (I think there is global consensus and they could be considered core elements in roster management), while partial retrieval is good for a xep. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] roster views
On Sat, Feb 28, 2009 at 5:57 PM, Jonathan Schleifer js-xmpp-standa...@webkeks.org wrote: I agree that we need an alternative for privacy lists - but this is definitely not partial roster retrival‼ And what about partial activation? With partial activation you still manager the roster as usual, and in a separate iq you set on/off toggles for each group, at any time of the session. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0198 suggestion (Stream management)
On Thu, Feb 26, 2009 at 10:47 PM, Dave Cridland d...@cridland.net wrote: Because the server chooses the sm-id, it can encode the full jid into it if needs be. Yep that was what I meant. BTW: is there in same place (rfcs, xeps) a recommendation saying that relying on a resource set by clients is a bad idea? -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0198 suggestion (Stream management)
On Fri, Feb 27, 2009 at 2:51 PM, Mickael Remond mickael.rem...@process-one.net wrote: Yep that was what I meant. BTW: is there in same place (rfcs, xeps) a recommendation saying that relying on a resource set by clients is a bad idea? I am not sure I understand what you mean. The client is choosing the resource. That's by definition a client provided information. Found! http://xmpp.org/rfcs/rfc3920.html#bind It's already specified: the server may override the resource (some, as google, do): A server SHOULD accept the resource identifier provided by the client, but MAY override it with a resource identifier that the server generates; in this case, the server SHOULD NOT return a stanza error (e.g., forbidden/) to the client but instead SHOULD communicate the generated resource identifier to the client in the IQ result as shown above -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0198 suggestion (Stream management)
On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond mickael.rem...@process-one.net wrote: Hello, As a follow-up of the latest XMPP summit in Brussels, we would like to request a small but useful addition to XEP-0198. The feedback is in session resumption: Is it possible to require the client to pass the full JID of the session being resumed ? With the JID you can simply reconnect to the existing running session without having another shared state. It makes a big difference for large scale deployment with clustering support. In this stanza? resume xmlns='urn:xmpp:sm:0' previd='some-long-sm-id'/ Do you mean using the full jid instead of the previd or in addition? If it's just the jid it can work only if the server sets a resource with some random data, otherwise it becomes extremely easy to hijack a sesssion -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] [Roster|Data] Versioning
On Thu, Feb 19, 2009 at 10:31 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I think this would be a good revision to include in rfc3921bis. See my post on the xmppwg list just now: http://mail.jabber.org/pipermail/xmppwg/2009-February/002507.html For me it's fine, also because other possible large item sets are better handled by xep-59, which is more suitable for browsing (disco#items included, but for pubsub nodes) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] [Roster|Data] Versioning
On Thu, Feb 19, 2009 at 10:45 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I don't think the bandwidth difference is that big here, but I like the idea of putting it in rfc3921bis so that more people implement it. ;-) Evil plan! I wasn't considering this aspect: definitely there! -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
[Standards] oauth signature
Is the Oauth signature in xep 235 actually calculated with the given values (and all escaping correct)? I'm trying to implement it and I get different values, while I can reproduce the sign of main oauth specs Besides fireeagle are there any other services for testing it? -- ff
Re: [Standards] oauth signature
On Sun, Feb 15, 2009 at 7:54 PM, Seth Fitzsimmons s...@mojodna.net wrote: [...] This was calculated using my fork of the OAuth gem (github.com/mojodna/oauth - `sudo gem install mojodna-oauth`): Thanks, I was getting the same signature string with my python code, now I know it's correct ;) I gave a try to the ruby gem too (installed switchboard, fire-hydrant and oauth with sudo gem install mojodna-oauth -s http://gems.github.com;), but while switchboard works fine I can't run the oauth gem, since I get /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- net/https (LoadError) from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' from /var/lib/gems/1.8/gems/mojodna-oauth-0.3.1.6/lib/oauth/consumer.rb:2 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' from /var/lib/gems/1.8/gems/mojodna-oauth-0.3.1.6/lib/oauth/client/helper.rb:2 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' from /var/lib/gems/1.8/gems/mojodna-oauth-0.3.1.6/lib/oauth.rb:2 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' from /var/lib/gems/1.8/gems/mojodna-oauth-0.3.1.6/lib/oauth/cli.rb:2 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' from /var/lib/gems/1.8/gems/mojodna-oauth-0.3.1.6/bin/oauth:3 from /var/lib/gems/1.8/bin/oauth:19:in `load' from /var/lib/gems/1.8/bin/oauth:19 (installed also other gems that were missing, but I can't figure out what is missing now, since I really don't know ruby) Note: You may want to use bare JIDs in your URI. Is fireagle using bare JIDs? Or should the xep be fixed? Signature: 9PQkM4YKgaM067wqrDGshXOwDW0= Escaped signature: 9PQkM4YKgaM067wqrDGshXOwDW0%3D I hope this helps. seth sure, thanks! -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] oauth signature
On Sun, Feb 15, 2009 at 9:57 PM, Seth Fitzsimmons s...@mojodna.net wrote: /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- net/https (LoadError) You need to install ruby-openssl to get Net::HTTPS. You're on Debian / Ubuntu, right? perfect! now everything works with switchboard. Just one minor quirk while installing: fire-hydrant exactly requires switchboard 0.0.11, while from github you get switchboard 0.0.12 (installed by telling gem to ignore dependencies, perhaps that's the reason of the missing gems below) (installed also other gems that were missing, but I can't figure out what is missing now, since I really don't know ruby) What other gems were missing? I.e., are they dependencies that aren't listed properly? When started it failed to load echoe and cucumber, which made to automatically install a bunch of other gems thanks -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
[Standards] roster item exchange
Hi, we are writing a facebook gateway and we'd like to use xep-144 for pushing roster items to the client. Besides the fact that it seems implemented by few clients, I've found another problem. With xep 144 the gateway has no means for knowing whether the user has accepted the presence subscription or not, just that the client has processed it (the result iq is sent as soon as the roster offer has been received). This leads to two unpleasant case: - if the gateway assumes that the items have been accepted and the user does some mistakes (or the client dies), he won't be able to see the contacts any more - if the gateway always sends the roster push we have either unnecessary traffic and the user may be bothered with subscriptions he doesn't want to accept The problem is that I don't see any workaround but extending the xep notifying the gateway which contacts have been accepted and which not -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] connected and available resources
On Fri, Oct 24, 2008 at 6:55 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Also, I think that the rule from rfc3920 is still in force: *** If the JID contained in the 'to' attribute is of the form [EMAIL PROTECTED]/resource and there is a connected resource that exactly matches the full JID, the server SHOULD deliver the stanza to that connected resource. *** Yep, but I see now that there is another possibile conflict between rfc3920 and 3921: In the following rule we say: # If the JID contains a resource identifier and there exists no connected resource that matches the full JID, the recipient's server SHOULD return a service-unavailable/ stanza error to the sender. and in 3921, accordingly to 11.1, rule 3: Else if the JID is of the form [EMAIL PROTECTED]/resource and no available resource matches the full JID, the recipient's server (a) SHOULD silently ignore the stanza (i.e., neither deliver it nor return an error) if it is a presence stanza, (b) MUST return a service-unavailable/ stanza error to the sender if it is an IQ stanza, and (c) SHOULD treat the stanza as if it were addressed to [EMAIL PROTECTED] if it is a message stanza. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] connected and available resources
On Fri, Oct 24, 2008 at 8:01 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Yep, but I see now that there is another possibile conflict between rfc3920 and 3921: In the following rule we say: # If the JID contains a resource identifier and there exists no connected resource that matches the full JID, the recipient's server SHOULD return a service-unavailable/ stanza error to the sender. and in 3921, accordingly to 11.1, rule 3: Else if the JID is of the form [EMAIL PROTECTED]/resource and no available resource matches the full JID, the recipient's server (a) SHOULD silently ignore the stanza (i.e., neither deliver it nor return an error) if it is a presence stanza, (b) MUST return a service-unavailable/ stanza error to the sender if it is an IQ stanza, and (c) SHOULD treat the stanza as if it were addressed to [EMAIL PROTECTED] if it is a message stanza. I don't see a conflict. The rfc3921 rules build on the rfc3920 rules (which are vague enough that the rfc3921rules don't conflict). Or at least that was the idea. In rfc3920 we say hey, each time we have a full JID, if the associated resources is not connected you should send back an error, then in 3921 wait, if the stanza is a message change idea and try to deliver it to the bare JID (without considering the uncertainety related to connected or available resources). As a developer I'd take rfc3920 a transport/routing layer which should work consintently either at the bottom of 3921 or a standalone streaming protocol. In both cases I expect the same behavior for the same packets and this behavior should be defined only in 3920, that's to say: if the resource is not connected, discard the packet, with no change of recovering it at an higher level. However now I see that in 39020bis that sentence has disappeared and we have slightly different rules I'm pretty comfortable with ;) : - If the JID contained in the 'to' attribute is of the form [EMAIL PROTECTED]/resource and there is no connected resource that exactly matches the full JID, the stanza shall be processed as if the JID were of the form [EMAIL PROTECTED]. - If the JID contained in the 'to' attribute is of the form [EMAIL PROTECTED]/resource and there is a connected resource that exactly matches the full JID, the server SHOULD deliver the stanza to that connected resource. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] connected and available resources
On Mon, Oct 20, 2008 at 6:16 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: I think that's a spec bug: s/available/connected/ I think so. For me it makes more sense if in points 1 3 of paragrah 11 we use connected (after that I can start filing tickets across the different server implementations :D). -- Fabio
[Standards] connected and available resources
Hi everybody, accordingly to rfc3921 connected resources are resources that have established a binding, and they become available after sending the first presence stanza. Section 11.1 tells: * Else if the JID is of the form [EMAIL PROTECTED]/resource and no available resource matches the full JID, the recipient's server (a) SHOULD silently ignore the stanza (i.e., neither deliver it nor return an error) if it is a presence stanza, (b) MUST return a service-unavailable/ stanza error to the sender if it is an IQ stanza, and (c) SHOULD treat the stanza as if it were addressed to [EMAIL PROTECTED] if it is a message stanza. This seems that if a resource is connected and not online, that resource can't receive any xmpp stanza from other entities, unless it goes fully online. However server implementations behave slightly different (e.g. ejabberd seems to deliver anything if the resource is correct), and clients ask the roster (or send other iqs to the server) before going online, which should not work if the above rules are strictly enforced. I think that we should better define this point. My position is that we should explicitily allow the delivery of any iq/ packets if the resource belongs to a connected user, even if not online. In this way clients could perform some iq/ queries to well known services before going online, thus eliminating one of the few useful cases for invisibility -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] Full XML
On Fri, Oct 10, 2008 at 12:42 AM, Brett Zamir [EMAIL PROTECTED] wrote: If this could be allowed (at least the processing instructions), I would think that XMPP could be used as the mechanism for accessing (or otherwise transferring) a complete XHTML/SVG/MathML/etc. website (not only in the context of messages, but also, e.g., as a Pubsub delivery; instead of typing a URL, one could type a JID). (This should also make for an interesting means of auto-updating webpage content incrementally as well, I think.) I am aware that XML can be delivered ala the bytestream specs, but I think it could be more convenient to allow it in band and as XML. Full documents tend to be large (often several hundreds of KB) and my fear is that sending them in band would hinder much of the good near real time behavior of XMPP. Therefore it is not a problem of supported expressiveness that could be overcome someway, but of general stream behavior. Although if you find a way to send processing instructions, sooner or later you'll need a way for sending chunks of documents and this is easily done using bytestreams (also in band) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] invisibility
On Wed, Oct 8, 2008 at 12:20 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Fabio Forno wrote: (sorry for the delays, but in the last two days of many standards_ml mails went into the spam folder :( ) Hopefully I just put an end to that! I think the problem comes mainly from the google talk ml, which is full of spam, and it makes the bayesian filter learn that xmpp or jabber may be related to spam :( So this is interesting. In the resource generation thread, we have people trying to fix something that's not broken. In this thread, we have people trying to prevent anyone from fixing something that *is* broken. Human psychology is endlessly fascinating. :) The power of diversity ;) Privacy lists were unnecessary even in the very beginning to solve the problem we thought they needed to solve, which is essentially the following points from RFC 2779: [...] Given that so many developers find privacy lists so confusing (not to mention end users!!!), I would very much like to use XEP-0191 and XEP-0186 for blocking and invisibility because they are much simpler for everyone to grok (block this user, go invisible, what could be easier?). If people then feel they need privacy lists for some more advanced functionality, we have the technology ready to use. But I see no good reason to keep hitting these two particular nails with the big sledgehammer we created back in 2002 (does anyone here remember zebra lists?) when much simpler tools can do the job. I get the point, but what will happen by adopting the simple solutions? A possible scenario: - for invisibility and blocking the simple xeps are used - privacy lists will stay (at list I hope, since they are the only way to do things like temporary going online for only a subset of users, which is critical on mobiles with rosters getting bigger a bigger and consequent flood of presence) - use of privacy lists will remain inconsistent between clients since they will be used only in the border case explained above, with the risk of setting a list in a session and messing up everything when changing client - developers even more confused of what to use and when, also because if the hammer is still there without safety instructions somebody will be tempted to use it instead of the simple solutions (as we where saying we are all different, and somebody may think why use the limited rules when I have a much powerful tool?: the dark side of force is powerful! ;) ) Ok, we can't stop people from doing stupid things, but at least we should warn by updating xep-16 better clarifying when to use it. Imho this Note: The protocol specified herein MAY be used in conjunction with Simple Communications Blocking [1]; see XEP-0191 for details. is not enough strong, but I'd say that they shouldn't be used in the cases covered by the simple xeps (I think MUST can't be used because it is impossible to enforce it) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] invisibility
On Tue, Oct 7, 2008 at 10:43 AM, Andreas Monitzer [EMAIL PROTECTED] wrote: The privacy lists are very potent, but their complexity is just too much for mere mortals. Imho this is not a protocol issue, but a client issue: the interface should be designed better for hiding the complexity of privacy lists to mere mortals. I'd stay with the privacy list approach and discuss better ways for setting them. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] invisibility
On Tue, Oct 7, 2008 at 11:27 AM, Remko Tronçon [EMAIL PROTECTED] wrote: Imho this is not a protocol issue, but a client issue This has been discussed in length before, and the conclusion was that there is no user friendly *and* correct way to do invisibility on top of privacy lists, or any kind of simple operation (such as blocking). Psi has a 'simple' user interface for blocking contacts on top of privacy lists, but if you used *any* other client to do some privacy list operation, then it could break this. We show a warning 'your list may not work', but this is just a horrible user experience. And things get even nastier if you do invisibility, with all kinds of problematic corner cases. Maybe you should look up the original discussion. You cannot fully abstract something that is fundamentally complex. Sooner or later, a user of your abstraction will bump into a problem, and will not understand it unless he understands the concepts underlying your abstraction. (sorry for the delays, but in the last two days of many standards_ml mails went into the spam folder :( ) I agree with the fact there is no general abstraction for privacy lists and there complexity is far beyond the capabilities of the average user (the psi interface for example is of little help if you don't know basic xmpp concepts, and even if you know building them is pretty along task). What I was meaning is just that between adding a new namespace (such as in xep-186) or reusing something already present (xep-126), I prefer the second one. If haven't missed a discussion where xep-126 has been definitely turned down, the main obstacle of a simple privacy list approach is that there is no agreement between client developers in naming the lists associated to basic blocking or invisibility operations, and about when keeping them active (if there are more issues, please point me to the correct discussion, I'm new in this subject, since I've just started studying it for our mobile clients, where we really need fine grained temporary invisibility or unwanted packet blocking). bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] XEP-0047 (IBB streams) and acknowledgment
On Wed, Jun 11, 2008 at 7:54 PM, Justin Karneges [EMAIL PROTECTED] wrote: My plan has always been to use XEP-198 for this. If your server wants you to back off, it'll just not ack back to you over the c2s (or s2s) link. Similarly, a mobile client that is dying would just not ack back to the server. This way you can do flow control per-hop rather than end-to-end. Sorry fo the delay. Yep, agree xep-198 solves the saturation problem of the I/O buffers of clients, which, I think, is most painful for usability. Imho xep-47 should recommend acks with a SHOULD. It just remains open the case when the receiving server has more restrictive policies about IBB than the sending one or the receiving client is too slow, forcing to buffer a large number of packets. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] XEP-0047 (IBB streams) and acknowledgment
On Wed, Jun 11, 2008 at 5:24 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: I don't know if existing clients and servers are that smart, but it They will be if people discover that IBB is so good in passing through firewalls. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] XEP-0047 (IBB streams) and acknowledgment
On Tue, Jun 10, 2008 at 11:40 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Yes, the idea behind XEP-0234 is that IBB will be the file transfer method of last resort, but that it will always work (for some value of always). Some sort of always, correct. The worst case scenario with IBB is ending with an unusable connection if the server starts throttling packets, thing I bet will happen as soon as IBB becomes widespread. In Bruxelles we discussed about the possibility of sending an early warning to the client with a packet from the server asking to limit the rate. This is far better then a fixed bitrate, since it allows severs to dynamically allocate bandwidth accordingly to actual usage. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
