[Standards] XEP-0175: Contact Addresses
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!
Re: [Standards] XEP-0175: Contact Addresses
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. 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.. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo pisze: 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. Maybe we could use disco with a well-know node? -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
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. 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
Re: [Standards] XEP-0157: Contact Addresses
Joe Hildebrand pisze: 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. But I may need contact info of your server, not mine. Then this doesn't work. Moreover, XEP-0157 is called Contact Addresses for XMPP Services, so this also includes gateways, transports. Maybe I'd even want to advertise contact information for a bot. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] DevCon report
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 synchronization -- it may be worthwhile to design a simple protocol extension for this 2. object synchronization -- this is hard and probably should be out of scope for the XSF 4.0 File transfer 4.1 Issues - the discussion continues -- why?? - currently no mandatory-to-implement (MTI)
Re: [Standards] Proposed XMPP Extension: Abuse-Related Errors
XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Abuse-Related Errors Abstract: This specification defines an application-specific error condition for reporting abusive communications sent over an XMPP network. URL: http://www.xmpp.org/extensions/inbox/error-abuse.html Version 0.0.2 is now available. I've changed quite a bit in the spec, including the name and the URL: http://www.xmpp.org/extensions/inbox/abuse-reporting.html Enjoy! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
