Re: [Standards] DevCon report
On Wed, Feb 27, 2008 at 5:06 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: 2.1 What people have done or suggested - fast reconnection - pipelining of stream negotiation exchanges (Tony Finch) - don't retrieve roster (but this doesn't really help) Though sending roster diffs helps. There is a new possible approach I've found only after the discussion we had: use just roster push, that must implemented regardlessly any optimization. The client asks for the roster adding a timestamp of the last received push, and the server sends changes as pushes (all timestamped) - compression Under this topic nobody really seems ready to try the binary path - BOSH (for mobile, is it better, the same, or worse than TCP?) I'd say BOSH is the easiest way to make things work now. Almost anything that you get with BOSH for free (implicit transactions, keep the session alive while disconnected, no need to re-negoziate the features) can be obtained also with adequate optimizations in TCP sockets, but these must still be defined and implemented in servers - session pause feature - traffic filtering / profiles for mobile What we will do is experimenting these strategies with our BOSH connection manager : we'll keep you informed about the results bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] [devcon] abuse reporting
Hi, On Feb 25, 2008, at 2:00 AM, Peter Saint-Andre wrote: On day 1 of the DevCon we talked about abuse reporting. Last week I wrote a small spec about it: http://www.xmpp.org/extensions/inbox/error-abuse.html I did a quick read, and I like what I saw so far. I need to read it again though. One thing would like to see in the implementation notes is a recomendation for server authors to allow for forwarding of this reports to a JID or set of JIDs This would allow for ad-hoc aggregation of abuse reports by a third party to cross reference them. We may want to change that so it's similar to XEP-0161, or even merge the two (isn't spim a subset of abuse?): The first time I saw example 1 above, I though hmms.. we might need a reason here So if we add a reason to the abuse stanza, we could merge 161 with this. Feedback is welcome -- it's probably best to post to the standards@xmpp.org list, not here. Changed the destination address. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] [devcon] abuse reporting
Pedro Melo wrote: Hi, On Feb 25, 2008, at 2:00 AM, Peter Saint-Andre wrote: On day 1 of the DevCon we talked about abuse reporting. Last week I wrote a small spec about it: http://www.xmpp.org/extensions/inbox/error-abuse.html I did a quick read, and I like what I saw so far. I need to read it again though. I hope you read version 0.0.2 -- it's much better than 0.0.1. :) One thing would like to see in the implementation notes is a recomendation for server authors to allow for forwarding of this reports to a JID or set of JIDs This would allow for ad-hoc aggregation of abuse reports by a third party to cross reference them. Good point, I'll add that. We may want to change that so it's similar to XEP-0161, or even merge the two (isn't spim a subset of abuse?): The first time I saw example 1 above, I though hmms.. we might need a reason here So if we add a reason to the abuse stanza, we could merge 161 with this. Is that a human-readable reason or a machine-readable reason? Or do we want both, perhaps? /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [devcon] abuse reporting
Hi, On Feb 27, 2008, at 2:59 PM, Peter Saint-Andre wrote: Pedro Melo wrote: On Feb 25, 2008, at 2:00 AM, Peter Saint-Andre wrote: On day 1 of the DevCon we talked about abuse reporting. Last week I wrote a small spec about it: http://www.xmpp.org/extensions/inbox/error-abuse.html I did a quick read, and I like what I saw so far. I need to read it again though. I hope you read version 0.0.2 -- it's much better than 0.0.1. :) I think it was 0.2, but I'll re-read it anyway... :) We may want to change that so it's similar to XEP-0161, or even merge the two (isn't spim a subset of abuse?): The first time I saw example 1 above, I though hmms.. we might need a reason here So if we add a reason to the abuse stanza, we could merge 161 with this. Is that a human-readable reason or a machine-readable reason? Or do we want both, perhaps? I think a machine-readable version is important because most of the time these reports will be generated by automated processes. Human readable might be interesting for one-off reporting by a end- user. But this spec focus on server-to-server reporting. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. If I remember well, disco + data forms were choosen to make this very easy to implement (using basic XEPs), because this information was considered very important. The information is important but not to everyone, nor on every request of disco. Now, if you go with pubsub, we run into where is that node? problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. iq type='set' from='[EMAIL PROTECTED]/barracks' to='pubsub.shakespeare.lit' id='sub1' pubsub xmlns='http://jabber.org/protocol/pubsub' subscribe node='http://jabber.org/network/serverinfo' jid='my_domain'/ /pubsub /iq So there is no issue with the node name. And you don't need PEP, just basic pubsub. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo pisze: On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. Now, if you go with pubsub, we run into where is that node? problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. iq type='set' from='[EMAIL PROTECTED]/barracks' to='pubsub.shakespeare.lit' id='sub1' pubsub xmlns='http://jabber.org/protocol/pubsub' subscribe node='http://jabber.org/network/serverinfo' jid='my_domain'/ /pubsub /iq So there is no issue with the node name. But now you need to know (from where?) that info about jabber.org is stored in pubsub.jabber.org. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Hi, On Feb 26, 2008, at 3:15 PM, Joe Hildebrand wrote: What about section 6.3 of the new version of XEP-115? stream:features c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://jabberd.org' ver='ItBTI0XLDFvVxZ72NQElAzKS9sU=' /stream:features Then you don't even have to do the disco, except the first time. Yes, that would cut down the number of disco's in everything we do, but I still think putting this information in there is wrong. If we do this for 157, why not slap the jabber:id:time in there? The pattern has been: use disco#info to discover support, then use a IQ GET or something similar to retrieve the information. And I don't see any reason to break the pattern. Best regards, On Feb 26, 2008, at 7:24 AM, Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP! -- Joe Hildebrand -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
[Standards] mobile optimizations (was: Re: DevCon report)
Fabio Forno wrote: On Wed, Feb 27, 2008 at 5:06 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: 2.1 What people have done or suggested - fast reconnection - pipelining of stream negotiation exchanges (Tony Finch) - don't retrieve roster (but this doesn't really help) Though sending roster diffs helps. There is a new possible approach I've found only after the discussion we had: use just roster push, that must implemented regardlessly any optimization. The client asks for the roster adding a timestamp of the last received push, and the server sends changes as pushes (all timestamped) Yes, we have roster pushes so it seems like a good idea to use them (in general I think we should make intelligent use of everything we've already defined, such as presence and rosters and roster pushes and so on -- other real-time communication technologies don't have these features at the base level, so it's to our advantage to use them). I think that something like what you suggest might work well. Also, before the devcon Dave Cridland mentioned that he didn't like the XEP-0150 approach but at the devcon we somehow didn't hear from him on this topic, so perhaps he could weigh in with his ideas here. - compression Under this topic nobody really seems ready to try the binary path Yes, so it seemed. Pedro Melo mentioned some further thoughts along these lines at dinner one night, so he and I might work on a spec for that. Right, Pedro? ;-) - BOSH (for mobile, is it better, the same, or worse than TCP?) I'd say BOSH is the easiest way to make things work now. Almost anything that you get with BOSH for free (implicit transactions, keep the session alive while disconnected, no need to re-negoziate the features) can be obtained also with adequate optimizations in TCP sockets, but these must still be defined and implemented in servers True. On the plane yesterday I started working on revisions to XEP-0198 (I'm now calling it Stream Management) that will address many of these points, but as you say BOSH already does a lot of this. We'll work to make sure that the TCP and HTTP bindings implement the same or similar semantics in transport-appropriate ways, so that stream management and BOSH are not wildly different. - session pause feature - traffic filtering / profiles for mobile What we will do is experimenting these strategies with our BOSH connection manager : we'll keep you informed about the results Great, thanks! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] DevCon report
My apologies for the bad line breaks etc. I hadn't slept for 23 hours when I sent that and didn't check the formatting before I hit Send. :( Peter Saint-Andre wrote: Peter Saint-Andre wrote: The XSF held a productive developer conference in Brussels over the last few days. I will write up the minutes tomorrow while flying back to the States and post them as soon as possible. Here's what I wrote on the plane... ** XMPP DevCon #4 When: February 24-25, 2008Where: Brussels, BelgiumLogs: http://logs.jabber.org/[EMAIL PROTECTED]/2008-02-24.html http://logs.jabber.org/[EMAIL PROTECTED]/2008-02-25.htmlScribe: Peter Saint-Andre1.0 Deployment issues, with a focus spam and abuse 1.1 Issues - currently, most spam/abuse happens in Multi-User Chat rooms - JID mimicking common (e.g., add space) - service-wide nick reservation enables denial of service - rate limiting is necessary (handled now by room bots) - nick spam (really long roomnicks) - presence spam seen in the wild (frequent presence changes) - add best practices to XEP-0045- sending a large number of messages to a victim also seen - privacy lists can help (block all not in roster) - even then you can have subscription request spam - do we want centralized blacklists/whitelists (RBL)? - consensus is that RBL would introduce central failure point- better: ask peer server(s) that you trust - things will be worse once botnets gain control of legitimate JIDs - need to be clear on the architecture (client-server) - concentrate on the server side (more trusted, easier to update) - try to avoid netsplits and alternative federations (islands OK) - build a reputation system between servers? (not for end users) 1.2 Possible recommendations - need better monitoring of MUC rooms - Digg-like service for rating XMPP servers? - protocol for reporting abuse and escalating - there is DoS potential here! - better traffic shaping / monitoring in server codebases - share contact information for operators - incremental trust of new servers that come onto the network - ask server buddies about other domains on the network - network status report a la BGP? 2.0 Mobile optimizations 2.1 What people have done or suggested - fast reconnection - pipelining of stream negotiation exchanges (Tony Finch) - don't retrieve roster (but this doesn't really help) - compression - BOSH (for mobile, is it better, the same, or worse than TCP?) - session pause feature - traffic filtering / profiles for mobile 2.2 Issues - bandwidth usage - latency of communication - power consumption == this is the major issue! - some operators block TCP - TCP timeouts are determined by service provider - need ability to pause or quiet a session - what do mobile users want? - presence-enabled contact list - typically a sub-list (not the complete roster) - do not receive presence from everyone - manage via privacy lists? - instant messaging - probably alerts and notifications (pubsub) - possibly Jingle calls (e.g., via wifi) - need way to negotiate how frequently device will wake up? - above all, maximize time in powersave mode! - for what reasons will the device be brought out of powersave? - IM from contact - phone call from contact - selected presence? (buddy pounce) - when brought out of powersave, send other queued stanzas - this is not battery-intensive because now you are awake - can this be done merely with privacy lists? - may need better handling of messages (e.g., Advanced Message Processing = XEP-0079) - define heuristics that say what to send when - TLS compression is good (DEFLATE) -- use it if at all possible - assume that TLS will succeed (it fails only if there is a misconfiguration) - stream feature for this? - buffer / queue stanzas while in pause or quiet mode 2.3 Recommendations / action items - outside expert says: we're on the right track (TCP better than UDP, DEFLATE is good, incremental approach, etc.) - document pipelining of XML sent during stream negotiation (per Tony Finch's email) - do we need an additional filtering protocol? - consensus: no - see how far we can get with privacy lists and best practices - define features for: - pausing a session (no interruptions) - quieting a session (selected interruptions OK) - do these belong in BOSH, in XEP-0198, privacy lists, or somewhere else? 3. XML synchronization / remote eventing 3.1 Motivations - whiteboarding - shared editing - collaborative data objects - more generally: DOM synchronization (for agents / wizards etc.) - even more general: perform operations on non-XML objects - question: is this in scope for XMPP?? 3.2 Issues - two modes (Fabio Forno) - session mode (e.g., whiteboarding) - sessionless (e.g., DOM events) - sharing events is easy - conflict resolution is hard 3.3 Conclusions Two models: 1. event stream
Re: [Standards] [devcon] abuse reporting
Pedro Melo wrote: Hi, On Feb 27, 2008, at 2:59 PM, Peter Saint-Andre wrote: Pedro Melo wrote: The first time I saw example 1 above, I though hmms.. we might need a reason here So if we add a reason to the abuse stanza, we could merge 161 with this. Is that a human-readable reason or a machine-readable reason? Or do we want both, perhaps? I think a machine-readable version is important because most of the time these reports will be generated by automated processes. Human readable might be interesting for one-off reporting by a end-user. But this spec focus on server-to-server reporting. Agreed. I'll define some machine-readable conditions as child elements, so people could always define other conditions in other namespaces if needed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] mobile optimizations (was: Re: DevCon report)
On Wed Feb 27 16:06:23 2008, Peter Saint-Andre wrote: Fabio Forno wrote: Though sending roster diffs helps. There is a new possible approach I've found only after the discussion we had: use just roster push, that must implemented regardlessly any optimization. The client asks for the roster adding a timestamp of the last received push, and the server sends changes as pushes (all timestamped) Yes, we have roster pushes so it seems like a good idea to use them (in general I think we should make intelligent use of everything we've already defined, such as presence and rosters and roster pushes and so on -- other real-time communication technologies don't have these features at the base level, so it's to our advantage to use them). I think that something like what you suggest might work well. Also, before the devcon Dave Cridland mentioned that he didn't like the XEP-0150 approach but at the devcon we somehow didn't hear from him on this topic, so perhaps he could weigh in with his ideas here. At the devcon, the more interesting discussion was concerning quiescing the stream, etc. We decided that, as I recall, we'd not bother discussing startup optimizations, mainly because we basically knew the score there, and with our unnamed external expert talking about other stuff, we concentrated on that. So... There's three options in the roster push optimization space. All involve the client and server maintaining a timestamp for the roster as a whole, and/or each individual item within it. The timestamp might be opaque (like ETags), a strictly increasing sequence number, or a modified, strictly increasing, timestamp. It actually doesn't matter, but the latter two allow for interesting things. Whichever, the server MUST include the timestamp-like thing in each roster push. 1) Client says I got the roster at this point in time. Server says either Then you have it. or Then I'll send you the new roster. This is basically the ETags method. I don't like this, because I add people to my Roster, and reorganize those that are there, relatively often, and this would incur a full dowload each time. 2) Client says I have the roster as of this point in time. Server says Here's all the changes since then.. This is obviously the best option in terms of efficiency, but it, too, has problems. The key issue is that roster entries won't die - instead, they'll be maintained along with a timestamp when deleted, in order that the server can tell a client it's gone. 3) Client says I have the roster as of this point in time. Server either says Here's the changes or Here's the whole roster, depending on whether it can find all deletions. This is basically addressing the shortfall of the above, and allows for a single RTT self-correcting error case. I like this one best, and it's pretty easy to implement. I also have a fondness for modified strictly increasing timestamps, but implementors need to appreciate that computer clocks go backwards, so they need to remember to handle odd cases like that by letting time catch up - just using a few ms later than the last timestamp until the real time is greater than the last timestamp. This would allow clients to show the last changed date/time of the roster entry in a mostly realistic manner. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] mobile optimizations (was: Re: DevCon report)
On Wed, Feb 27, 2008 at 5:06 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Yes, we have roster pushes so it seems like a good idea to use them (in general I think we should make intelligent use of everything we've already defined, such as presence and rosters and roster pushes and so on -- other real-time communication technologies don't have these features at the base level, so it's to our advantage to use them). I think that something like what you suggest might work well. Also, before the devcon Dave Cridland mentioned that he didn't like the XEP-0150 approach but at the devcon we somehow didn't hear from him on this topic, so perhaps he could weigh in with his ideas here. In the next days I'm short in time for helping in authoring the XEP, but at least I can prepare the raw XML samples for handling diffs with roster pushses - compression Under this topic nobody really seems ready to try the binary path Yes, so it seemed. Pedro Melo mentioned some further thoughts along these lines at dinner one night, so he and I might work on a spec for that. Right, Pedro? ;-) Oh yeah, I remember too. That will be a breakthrough in XML technology... ;) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] mobile optimizations (was: Re: DevCon report)
On Wed, 27 Feb 2008, Dave Cridland wrote: I also have a fondness for modified strictly increasing timestamps, but implementors need to appreciate that computer clocks go backwards, so they need to remember to handle odd cases like that by letting time catch up - just using a few ms later than the last timestamp until the real time is greater than the last timestamp. Why not specify a monotonically increasing version counter instead of a real time stamp? Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BAILEY FAIR ISLE FAEROES: WEST OR SOUTHWEST 5 TO 7, OCCASIONALLY GALE 8, PERHAPS SEVERE GALE 9 IN BAILEY AND FAEROES LATER. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.
Re: [Standards] mobile optimizations
Dave Cridland wrote: 2) Client says I have the roster as of this point in time. Server says Here's all the changes since then.. This is obviously the best option in terms of efficiency, but it, too, has problems. The key issue is that roster entries won't die - instead, they'll be maintained along with a timestamp when deleted, in order that the server can tell a client it's gone. yes I think the logic on the server will get very complicated. Util I have a mutual subscription to a contact the server updates the roster item several times(subscription=none,from or to,both +ask). This will be ~5 versions until the subscription is mutual. I also have a fondness for modified strictly increasing timestamps, but implementors need to appreciate that computer clocks go backwards, so they need to remember to handle odd cases like that by letting time catch up - just using a few ms later than the last timestamp until the real time is greater than the last timestamp. for this reason I would prefer a versioning of the roster, so I client can just tell the server I have version 235241 of the roster, let me know if this is the current roster or send me the changes otherwise. Regards, Alex
Re: [Standards] XEP-0175: Contact Addresses
Hi, On Feb 27, 2008, at 3:47 PM, Maciek Niedzielski wrote: Pedro Melo pisze: On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. Now, if you go with pubsub, we run into where is that node? problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. iq type='set' from='[EMAIL PROTECTED]/barracks' to='pubsub.shakespeare.lit' id='sub1' pubsub xmlns='http://jabber.org/protocol/pubsub' subscribe node='http://jabber.org/network/serverinfo' jid='my_domain'/ /pubsub /iq So there is no issue with the node name. But now you need to know (from where?) that info about jabber.org is stored in pubsub.jabber.org. Sorry, my mistake. Replace pubsub.shakespeare.lit with shakespeare.lit. As with PEP, we use the domain as the pubsub server. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] mobile optimizations
Alexander Gnauck wrote: Dave Cridland wrote: I also have a fondness for modified strictly increasing timestamps, but implementors need to appreciate that computer clocks go backwards, so they need to remember to handle odd cases like that by letting time catch up - just using a few ms later than the last timestamp until the real time is greater than the last timestamp. for this reason I would prefer a versioning of the roster, so I client can just tell the server I have version 235241 of the roster, let me know if this is the current roster or send me the changes otherwise. That seems best to me, too. Heck, the server could store the roster in SVN for easier diffs between versions. ;-) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] mobile optimizations
Peter Saint-Andre wrote: Alexander Gnauck wrote: for this reason I would prefer a versioning of the roster, so I client can just tell the server I have version 235241 of the roster, let me know if this is the current roster or send me the changes otherwise. That seems best to me, too. Heck, the server could store the roster in SVN for easier diffs between versions. ;-) Yeah, and send commit notifications via PEP ;D -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] mobile optimizations (was: Re: DevCon report)
On Wed, Feb 27, 2008 at 6:52 PM, Dave Cridland [EMAIL PROTECTED] wrote: 3) Client says I have the roster as of this point in time. Server either says Here's the changes or Here's the whole roster, depending on whether it can find all deletions. This is basically addressing the shortfall of the above, and allows for a single RTT self-correcting error case. I like this one best, and it's pretty easy to implement. I like this one, since it always has a backup when no sinchronization is needed. Moreover the server can store only a window of changes, and send the whole roster if the last known by the client is too old I also have a fondness for modified strictly increasing timestamps, but implementors need to appreciate that computer clocks go backwards, so they need to remember to handle odd cases like that by letting time catch up - just using a few ms later than the last timestamp until the real time is greater than the last timestamp. I wrote timestamps in my other mail, but any strictly growing sequence of number is fine -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] mobile optimizations
Fabio Forno wrote: I like this one, since it always has a backup when no sinchronization is needed. Moreover the server can store only a window of changes, and send the whole roster if the last known by the client is too old +1, I don't think we want to keep all roster revisions from the beginning. If servers will give us such a option this is great, but I don't think it should be required. For normal usage about 100 revisions should be fine. Alex
Re: [Standards] mobile optimizations
On Wed, Feb 27, 2008 at 10:19 PM, Alexander Gnauck [EMAIL PROTECTED] wrote: Fabio Forno wrote: I like this one, since it always has a backup when no sinchronization is needed. s/is needed/succeds/ -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Dnia 2008-02-26, Wt o godzinie 16:05 +0100, Maciek Niedzielski pisze: If I remember well, disco + data forms were choosen to make this very easy to implement (using basic XEPs), because this information was considered very important. This is _the_ point. Pedro, have you read the Standards-JIG archives on the topic? This could answer many of your concerns. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
