[Standards] Inconsistent Subscriptions in XMPP
There are several cases when subscription databases in XMPP are inconsistent. You may view subscription information as a global distributed database. Subscription state between two JIDs, for example a...@a and b...@b are stored in two places at the same time. Servers A and B maintain their own copies of subscription state. For a...@a's subscripton to b...@b, server B holds the authoritative record, while server A has a non-authoritative copy. I believe we need a mechanism to automatically check consistency of these records and fix any inconsistency to ensure that: * If the authoritative information changed without notification to an interested party, the interested party should discover it as soon as possible. * The same for nonexistant users. Inconsistencies occur when: * The interested server is down while the changes occur. * A notification was lost. * A domain is moved to another server without copying the database (the subscriptions must be re-created manually) * Database is restored from a backup due to data corruption. Possible approaches: * Server would monitor suspicious stanzas (e.g. messages and presence from an offline resource) and check the subscription state. What with the roster items that are inconsistent? * Mark as inconsistent, let the client present it to the user to take action. * Auto-repair and thus maintain consistency Looking forward to all feedback. Pavel -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
[Standards] various rfc3920bis feedback
Feedback mostly discussed in the jdev conference: * bidirectional s2s could be announced in sent right after the opening tag from the initiator. * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details * resource conflicts should be handled consistently in servers * an explicit way to kick other resources might be very handy * multiple resources could have a less confusing named feature (not unbind, but something like multi-bind probably) * xml:lang per stanza seems to be pretty rare, I would prefer MAY to SHOULD, or even to discurage per-stanza xml:lang entirerely and encourage use of xml:lang only for elements with localized strings. Many users (and also client developers) just don't care about languages. Unqualified strings are (and will be) very common, I would use MAY even for the elements. * "gone" has a very good usecase that could be made explicit... it is JID redirection and could be handled by clients (e.g. the client could offer the user to add the new JID upon error - presence/message would trigger it). * Consider including XEP-198 Stream Management in the RFC Pavel -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] IBB revisions
Peter Saint-Andre wrote: > As promised at the XMPP Summit, I've been working on some revisions to > XEP-0047 (In-Band Bytestreams). The changes consist of clarifying packet > processing and error handling, adding more examples, recommending IQs > over messages, correcting the schemas, etc. You can review the changes > in process here: > > http://xmpp.org/extensions/tmp/xep-0047-1.2.html > > The modifications are not necessarily substantive but they are widespread: > > http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0047.xml?%40diffMode=u&%40diffWrap=s&r1=1555&r2=2759&u=3&ignore=&k= > > Feedback is welcome, especially from Justin. :) I've incorporated the feedback received so far. The latest version is 1.2rc3 (reload as necessary). The diff from 1.2rc2 is here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0047.xml?%40diffMode=u&%40diffWrap=s&r1=2759&r2=2771&u=3&ignore=&k= The diff from 1.1 is here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0047.xml?%40diffMode=u&%40diffWrap=s&r1=1555&r2=2771&u=3&ignore=&k= Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] IBB revisions
Alexander Gnauck wrote: > Peter Saint-Andre schrieb: >> Feedback is welcome, especially from Justin. :) > > I will use IBB in a project for sending big data objects. So not files > directly. Because it well designed for splitting any data in chunks. > > So we could add other examples and use cases than only file transfer to it. How does that change the processing model? I'm happy to add more examples if that would be helpful? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] [Fwd: Re: [Council] XMPP BOF @ IETF 74]
At its next meeting (Wednesday), the XMPP Council will have a chat about the XMPP BOF @ the IETF. Read on for more information. As always, anyone can join the Council meeting. Original Message Subject: Re: [Council] XMPP BOF @ IETF 74 Date: Mon, 23 Feb 2009 15:58:34 -0700 From: Peter Saint-Andre Reply-To: XMPP Council To: XMPP Council References: <49a19cd8.9010...@stpeter.im> Peter Saint-Andre wrote: > Plans are coming together for an XMPP BOF @ IETF 74 in San Francisco, > probably to be held on Monday, March 23. Let's discuss in the next > Council meeting. I'll post further before then. See the archives for the xmp...@xmpp.org list for details. Posting here so we can talk in the Council meeting. 0. Does it make sense to revive the XMPP WG in order to complete work at the IETF on some topics of interest? I see the primary topics as: 1. RFC revisions (rfc3920bis/rfc3921bis). 2. Do we need to complete interop reports? (Those might not needed until we try to advance the core specs from Proposed to Draft, whereas right now I think we will cycle at Proposed.) 3. Finish mappings between XMPP and SIP/SIMPLE (cf. the series of I-Ds with names draft-saintandre-sip-xmpp-* -- currently 6 of them). 4. Mobile optimizations. So far these are mainly roster versioning and stream management (XEP-0198). The "roster filtering" stuff discussed at the XMPP Summit might also be worth considering. I think that "session hush" (also discussed in Brussels) is too preliminary. 5. Replace stringprep / IDNA with something more reasonable. 6. End-to-end encryption. 7. BOSH. However, I think this is more properly part of the AppArea meeting, see here: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00313.html So, I think we might need the following participation from the XMPP community before the BOF: a. Internet-Draft submissions for stream management (XEP-0198) and e2e (Jingle-XTLS proposal). In the Council meeting let's discuss whether we think it's OK to send this work off to the IETF. The same goes for some of the roster work (versioning and filtering). b. Commitments from presenters. That would include core (me), SIP-XMPP (perhaps Salvatore Loreto from Ericsson), mobile (me, or perhaps Justin Karneges could come up to SF to talk about XEP-0198), stringprep and IDNA (Kurt Zeilenga or Joe Hildebrand?), e2e (probably me, I don't think Dirk could be there), and BOSH (Jack?). We'll talk about this more in the meeting, I just wanted to set the stage. Peter -- Peter Saint-Andre https://stpeter.im/ -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] XEP-0045 Muc invite
Example 208 shows the as child of cauldronburn Example 124 has the as child of cauldronburn which one is correct. I think the second one. is missing in the schema of Also if 208 is correct ;-) Regards, Alex -- Alexander Gnauck http://www.ag-software.de xmpp:gna...@jabber.org
Re: [Standards] IBB revisions
Peter Saint-Andre schrieb: Feedback is welcome, especially from Justin. :) I will use IBB in a project for sending big data objects. So not files directly. Because it well designed for splitting any data in chunks. So we could add other examples and use cases than only file transfer to it. Alex
