Mailing lists matching xmpp.org
members xmpp.orgstandards xmpp.org
Re: separate login/password for several services?
On Fri, Sep 27, 2013 at 01:23:54AM -2100, Zeus Panchenko wrote: > > overlay unique > > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) > > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) > > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) > > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) > > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH) > > > > this prevents each uid=X,ou=People,dc=org from having more than one > authorizedService=Y offspring ... while the original idea is to let user > A to have for the service B, several uid-s but to prevent other users to > have the same uids for the corresponding service ... > > what I mean are multiple attributes uid/userpassword "inside" the > offspring not in the `dn' of the offspring: That can be done - it is just a matter of choosing a naming structure that allows it. > dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org > authorizedService: xmpp.org > uid: john > uid: john1 > uid: johnN > userPassword: qwerty > userPassword: qwerty1 > userPassword: qwertyN > cn: john@xmpp.org > sn: xmpp.org > description: John Doe XMPP account at xmpp.org > uidNumber: 12345 > gidNumber: 23456 > homeDirectory: /nonexistent > loginShell: /sbin/nologin > objectClass: person > objectClass: posixAccount > objectClass: shadowAccount > objectClass: authorizedServiceObject That one won't work, as there is no way to link the individual uid and userPassword values. You need one LDAP entry per uid so either add another layer to the tree or use multi-valued RDNs. The tree version would look like this: dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org dn: uid=john,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john userPassword: qwerty dn: uid=john1,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john1 userPassword: qwerty1 dn: uid=johnN,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: johnN userPassword: qwertyN The multi-valued RDNs version like this: dn: uid=john+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john userPassword: qwerty dn: uid=john1+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john1 userPassword: qwerty1 dn: uid=johnN+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: johnN userPassword: qwertyN > and in this case we need to prevent some other user from having > offspring with the same uid ... to prevent for user > uid=johandoe,ou=People,dc=org offspring: > > dn: authorizedService=xmpp.org,uid=johandoe,ou=People,dc=org > authorizedService: xmpp.org > uid: johan > uid: johan1 > userPassword: qwerty > userPassword: qwerty1 > cn: johan@xmpp.org > sn: xmpp.org > description: Johan Doe XMPP account at xmpp.org > uidNumber: 12345 > gidNumber: 23456 > homeDirectory: /nonexistent > loginShell: /sbin/nologin > objectClass: person > objectClass: posixAccount > objectClass: shadowAccount > objectClass: authorizedServiceObject > > possibility to add another `uid: johnN' which is already used by > dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org That should already be covered by the unique overlay setup. Incidentally, you seem to be misusung some fields in the person object: > cn: john@xmpp.org > sn: xmpp.org If you really don't want to put the real name there you should choose a different objectclass that does not force you to fill in those attributes. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
[Standards] XMPP Council Agenda 2018-03-07
Folks, The XMPP Council will be holding it's regular meeting tomorrow (Wednesday) at 1600 UTC. The agenda is collated from (in order of reliability): * Github pull requests marked "Needs Council". * Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda * Random mails from Standards List * Random suggestions directly to me. I (try to) send out the final agenda about 24 hours in advance. Agenda as follows: INTRO: 1) Role Call 2) For fork's sake, can somebody else take the minutes? PART ONE: "Dusty Drafts" These are essentially votes to Call For Experience (CFE - the Last Call equivalent for advancement to Final), or - if we choose not to do that - possibly Deprecate. Or do neither. If the first (CFE) vote passes the second (Deprecate) vote will be struck. 3) CFE for XEP-0020: Feature Negotiation https://xmpp.org/extensions/xep-0020.html 4) Deprecate XEP-0020: Feature Negotiation https://xmpp.org/extensions/xep-0020.html 5) CFE for XEP-0048: Bookmarks https://xmpp.org/extensions/xep-0048.html 6) Deprecate XEP-0048: Bookmarks https://xmpp.org/extensions/xep-0048.html 7) CFE for XEP-0059: Result Set Management https://xmpp.org/extensions/xep-0059.html 8) Deprecate XEP-0059: Result Set Management https://xmpp.org/extensions/xep-0059.html 9) CFE for XEP-0066: Out of Band Data https://xmpp.org/extensions/xep-0066.html 10) Deprecate XEP-0066: Out of Band Data https://xmpp.org/extensions/xep-0066.html 11) CFE for XEP-0072: SOAP Over XMPP https://xmpp.org/extensions/xep-0072.html 12) Deprecate XEP-0072: SOAP Over XMPP https://xmpp.org/extensions/xep-0072.html 13) CFE for XEP-0079: Advanced Message Processing https://xmpp.org/extensions/xep-0079.html 14) Deprecate XEP-0079: Advanced Message Processing https://xmpp.org/extensions/xep-0079.html 15) CFE for XEP-0092: Software Version https://xmpp.org/extensions/xep-0092.html 16) Deprecate XEP-0092: Software Version https://xmpp.org/extensions/xep-0092.html 17) CFE for XEP-0122: Data Forms Validation https://xmpp.org/extensions/xep-0122.html 18) Deprecate XEP-0122: Data Forms Validation https://xmpp.org/extensions/xep-0122.html 19) CFE for XEP-0131: Stanza Headers and Internet Metadata https://xmpp.org/extensions/xep-0131.html 20) Deprecate XEP-0131: Stanza Headers and Internet Metadata https://xmpp.org/extensions/xep-0131.html 21) CFE for XEP-0141: Data Forms Layout https://xmpp.org/extensions/xep-0141.html 22) Deprecate XEP-0141: Data Forms Layout https://xmpp.org/extensions/xep-0141.html 23) CFE for XEP-0229: Stream Compression with LZW https://xmpp.org/extensions/xep-0229.html 24) Deprecate XEP-0229: Stream Compression with LZW https://xmpp.org/extensions/xep-0229.html PART TWO: "Ordinary Stuff" 25) XEP-0045: Implement stable IDs on Reflection #600 https://github.com/xsf/xeps/pull/600 26) XEP-0153: Clarify encoding of update hash #593 https://github.com/xsf/xeps/pull/593 EPILOGUE 27) AOB 28) Next Meeting 29) Close Note that I'm aiming for 30 minutes. Hahahaha. Well, as quick as we can, anyway. Meetings are normally held every Wednesday at 1600 UTC in the xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone (XSF Member or not) may attend, though only XMPP Council members may vote. Relevant comments from the floor are welcomed. Items for the agenda may be placed in Trello and/or submitted to me for next week. We would also welcome a volunteer to take minutes (please - PLEASE - reply to this message if you can take this on). Thanks, Dave. (As Council Chair). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[GitHub] [mina-vysper] Neustradamus opened a new issue #19: XEP-0443: XMPP Compliance Suites 2021
Neustradamus opened a new issue #19: URL: https://github.com/apache/mina-vysper/issues/19 Please add support of XEP-0443: XMPP Compliance Suites 2021: https://xmpp.org/extensions/xep-0443.html Which replaces: - XEP-0423: XMPP Compliance Suites 2020: https://xmpp.org/extensions/xep-0423.html - XEP-0412: XMPP Compliance Suites 2019: https://xmpp.org/extensions/xep-0412.html - XEP-0387: XMPP Compliance Suites 2018: https://xmpp.org/extensions/xep-0387.html - XEP-0375: XMPP Compliance Suites 2016: https://xmpp.org/extensions/xep-0375.html - XEP-0302: XMPP Compliance Suites 2012: https://xmpp.org/extensions/xep-0302.html - XEP-0270: XMPP Compliance Suites 2010: https://xmpp.org/extensions/xep-0270.html - XEP-0243: XMPP Server Compliance 2009: https://xmpp.org/extensions/xep-0243.html - XEP-0242: XMPP Client Compliance 2009: https://xmpp.org/extensions/xep-0242.html - XEP-0216: XMPP Intermediate Server 2008: https://xmpp.org/extensions/xep-0216.html - XEP-0212: XMPP Basic Server 2008: https://xmpp.org/extensions/xep-0212.html - XEP-0211: XMPP Basic Client 2008: https://xmpp.org/extensions/xep-0211.html - XEP-0073: Basic IM Protocol Suite: https://xmpp.org/extensions/xep-0073.html This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [Standards] XEP Advancement Shortlist
Hello all! On Tue, Jun 01, 2021 at 09:21:06PM +0200, Jonas Schäfer wrote: Those can be XEPs which you think deserve some discussion before moving forward and where this would be a good time to discuss them, or those where you think that everything has been said and they should graduate to their next phase in the lifecycle. I looked through Deferred XEPs ordered by last changed. Here's a selection that haven't seen activity in over 10 years: * Metacontacts <https://xmpp.org/extensions/xep-0209.html> I remember at least Gajim using this. Still relevant and useful? * XMPP Nodes <https://xmpp.org/extensions/xep-0271.html> There's been mention of how nodes are underspecified. Would be good to have that corrected. * Statistics Gathering <https://xmpp.org/extensions/xep-0039.html> Something that can encapsulate the Open Metrics data model would be nice. * IQ-Based Avatars <https://xmpp.org/extensions/xep-0008.html> Replaced by vcard-temp, which in turn is being replaced by XEP-0084. * A Framework For Securing Jabber Conversations <https://xmpp.org/extensions/xep-0031.html> * Security Extensions <https://xmpp.org/extensions/xep-0102.html> * Encryption of Archived Messages<https://xmpp.org/extensions/xep-0241.html> Split from XEP-0136, which was Deprecated. * Multi-User Text Editing <https://xmpp.org/extensions/xep-0058.html> * Simple Whiteboarding <https://xmpp.org/extensions/xep-0113.html> These two can probably go in favor of XEP-0284. * Packet Filtering <https://xmpp.org/extensions/xep-0062.html> * XPath Filtering <https://xmpp.org/extensions/xep-0064.html> Based on the Security Considerations section if nothing else. * vCard Filtering <https://xmpp.org/extensions/xep-0164.html> This seems backwards. Would be nice to have a way for the user to limit access per fields in their own vcards, like that OneSocialWeb(?) ProtoXEP that I don't think ever got submitted. * Pubsub Subscription Storage <https://xmpp.org/extensions/xep-0173.html> MIX PAM does this better, right? RIGHT? * Stock Data Transmission <https://xmpp.org/extensions/xep-0067.html> No `xmlns`?! -- Regards, Kim "Zash" Alvefur ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Security
Hi Michael, > So my question is: What is actually the problem with the latest XMPP > end-to-end encryption and signing approaches and why isn’t it safe against > malicious server operators and sniffing of direct client-to-client > transmissions? And is there anything else I should know? The "XMPP Ubiquitous Encryption Manifesto" is only about Transport Layer encryption as far as I know (between c2s and s2s connections). So a malicious server admin could still read these messages, e.g. while they are stored in an offline store or if they are otherwise logged somewhere in a server archive. Concerning XMPP's end-to-end encryption and signing: It has always confused me, because there are so many specifications out there. I haven't read/understood all of them, but each of them seem to deal with encryption in a different way. http://xmpp.org/rfcs/rfc3923.html http://xmpp.org/extensions/xep-0027.html (obsolete) http://xmpp.org/extensions/xep-0116.html http://xmpp.org/extensions/xep-0187.html http://xmpp.org/extensions/xep-0188.html http://xmpp.org/extensions/xep-0200.html http://xmpp.org/extensions/xep-0210.html http://xmpp.org/extensions/xep-0217.html http://xmpp.org/extensions/xep-0241.html http://xmpp.org/extensions/xep-0274.html http://xmpp.org/extensions/xep-0285.html http://xmpp.org/extensions/xep-0290.html and you even found another one... All of them except RFC 3923 are marked as "not recommended to implement", but it's confusing nonetheless. Maybe the authors of these documents could shed some light on the current state of e2e encryption. - Christian
Re: [Standards] XMPP IoT SIG - Call for Participation
On 12/12/16 3:43 PM, Sam Whited wrote: On Mon, Dec 12, 2016 at 2:22 PM, Florian Schmaus wrote: - How fit the existing IoT XEPs into this picture? What are the existing IoT XEPs you're referencing here? http://xmpp.org/extensions/xep-0322.html http://xmpp.org/extensions/xep-0323.html http://xmpp.org/extensions/xep-0324.html http://xmpp.org/extensions/xep-0325.html http://xmpp.org/extensions/xep-0326.html http://xmpp.org/extensions/xep-0347.html Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2022-11-09
Good morning Council members, the next XMPP Council Meeting will take place on Wednesday, November 9st 2022 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join Sorry for the late email. I only saw Jonas’ emails this morning and I think we should start voting on these XEP today to get it over with during this Council year. Otherwise it will get delayed to early December. The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - Proposed XMPP Extension: SCRAM Upgrade Tasks (https://xmpp.org/extensions/inbox/xep-scram-upgrade.html) - Proposed XMPP Extension: Pubsub Signing: OpenPGP Profile (https://xmpp.org/extensions/inbox/pubsub-signing-openpgp.html) - Proposed XMPP Extension: Pubsub Signing (https://xmpp.org/extensions/inbox/pubsub-signing.html) - Proposed XMPP Extension: Pubsub Targeted Encryption (https://xmpp.org/extensions/inbox/pubsub-targeted-encryption.html) - Proposed XMPP Extension: Fast Authentication Streamlining Tokens (https://xmpp.org/extensions/inbox/xep-fast.html) 4) Items for voting a) Proposed XMPP Extension: SCRAM Upgrade Tasks (https://xmpp.org/extensions/inbox/xep-scram-upgrade.html) b) Proposed XMPP Extension: Pubsub Signing: OpenPGP Profile (https://xmpp.org/extensions/inbox/pubsub-signing-openpgp.html) c) Proposed XMPP Extension: Pubsub Signing (https://xmpp.org/extensions/inbox/pubsub-signing.html) d) Proposed XMPP Extension: Pubsub Targeted Encryption (https://xmpp.org/extensions/inbox/pubsub-targeted-encryption.html) e) Proposed XMPP Extension: Fast Authentication Streamlining Tokens (https://xmpp.org/extensions/inbox/xep-fast.html) 5) Pending votes none See Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0452 (MUC Mention Notifications)
Its meant to link to https://xmpp.org/extensions/xep-0297.html instead. Am 27.01.21 um 13:27 schrieb Ivan Vučica: > The mention of “Server IP Check” XEP-0279 seems to be a typo? > > On Tue 26 Jan 2021 at 16:04, Jonas Schäfer <mailto:jo...@wielicki.name>> wrote: > > Version 0.1.0 of XEP-0452 (MUC Mention Notifications) has been > released. > > Abstract: > This specification documents how a user may be informed when they're > mentioned in a MUC which they're not currently joined to. > > Changelog: > Accepted by vote of Council on 2021-01-06. (XEP Editor (jsc)) > > URL: https://xmpp.org/extensions/xep-0452.html > <https://xmpp.org/extensions/xep-0452.html> > > Note: The information in the XEP list at > https://xmpp.org/extensions/ <https://xmpp.org/extensions/> > is updated by a separate automated process and may be stale at the > time this email is sent. The XEP documents linked herein are up-to- > date. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > <https://mail.jabber.org/mailman/listinfo/standards> > Unsubscribe: standards-unsubscr...@xmpp.org > <mailto:standards-unsubscr...@xmpp.org> > ___ > > -- > Sent from Gmail Mobile > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [Fwd: [Council] Agenda 2009-06-03]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI. XMPP Council meetings are open to the public, so feel free to join! /psa - Original Message Subject: [Council] Agenda 2009-06-03 Date: Mon, 1 Jun 2009 21:12:19 +0100 From: Kevin Smith Reply-To: ke...@kismith.co.uk, XMPP Council To: XMPP Council Proposed Agena: 1. Roll Call 2. Agenda bashing. Voting the Jingles to Draft? 3. Jingle - http://xmpp.org/extensions/xep-0166.html 4. Jingle RTP Sessions - http://xmpp.org/extensions/xep-0167.html 5. Jingle ICE-UDP Transport Method - http://xmpp.org/extensions/xep-0176.html 6. Jingle Raw UDP Transport Method - http://xmpp.org/extensions/xep-0177.html 7. XMPP Ping - http://xmpp.org/extensions/xep-0199.html Implementation text ok? http://mail.jabber.org/pipermail/standards/2009-May/022020.html Vote to Final? Obsolete some stuff: 8. Proxy Accept Socket Service (PASS) - http://xmpp.org/extensions/xep-0003.html 9. Jabber Browsing - http://xmpp.org/extensions/xep-0011.html 10. Message Expiration - http://xmpp.org/extensions/xep-0023.html 11. Jabber HTTP Polling - http://xmpp.org/extensions/xep-0025.html 12. AOB 13 Next meeting? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkokQvAACgkQNL8k5A2w/vy7XgCg6nDghyt5bbuPoPVIz2oe+PKR zWoAn1DzVyb9+Afakk5BZ9VxrdnfgXQt =E6q7 -END PGP SIGNATURE-
[Git][gajim/gajim][master] 2 commits: DOAP: Add XEP-0245
Daniel Brötzmann pushed to branch master at gajim / gajim
Commits:
c70dc103 by Daniel Brötzmann at 2021-01-22T17:17:14+01:00
DOAP: Add XEP-0245
- - - - -
304c9af1 by Daniel Brötzmann at 2021-01-22T17:18:19+01:00
DOAP: Use correct RFC strings
- - - - -
1 changed file:
- data/gajim.doap
Changes:
=
data/gajim.doap
=
@@ -42,8 +42,8 @@
https://xmpp.org/rfcs/rfc6120.html"; />
https://xmpp.org/rfcs/rfc6121.html"; />
https://xmpp.org/rfcs/rfc6122.html"; />
-https://tools.ietf.org/html/rfc7395"; />
-https://tools.ietf.org/html/rfc7590"; />
+https://xmpp.org/rfcs/rfc7395.html"; />
+https://xmpp.org/rfcs/rfc7590.html"; />
https://xmpp.org/extensions/xep-0004.html"; />
@@ -456,6 +456,13 @@
1.2
+
+
+https://xmpp.org/extensions/xep-0245.html"; />
+ complete
+1.0
+
+
https://xmpp.org/extensions/xep-0249.html"; />
View it on GitLab:
https://dev.gajim.org/gajim/gajim/-/compare/b42a3ed43c555f8487380a5ebeee161f31687b6b...304c9af12b304bf4661205e3605e3a5e6e267cf3
--
View it on GitLab:
https://dev.gajim.org/gajim/gajim/-/compare/b42a3ed43c555f8487380a5ebeee161f31687b6b...304c9af12b304bf4661205e3605e3a5e6e267cf3
You're receiving this email because of your account on dev.gajim.org.
___
Commits mailing list
Commits@gajim.org
https://lists.gajim.org/cgi-bin/listinfo/commits
Re: [Standards] UPDATED: XEP-0385 (Stateless Inline Media Sharing (SIMS))
We might want to update XEP-0266, too: https://xmpp.org/extensions/xep-0266.html#codecs-opus https://xmpp.org/extensions/xep-0266.html#mti On 11/7/17 2:11 PM, Arc Riley wrote: > https://xmpp.org/extensions/xep-0385.html#sect-idm139941991230272 > > Since the IETF has standardized the patent-clear Opus codec, this should > be recommended. It is already used for WebRTC and broadly supported. > > https://tools.ietf.org/html/rfc6716 > https://caniuse.com/#search=Opus > > > > On Wed, Oct 4, 2017 at 8:54 AM, Jonas Wielicki <mailto:jo...@wielicki.name>> wrote: > > Version 0.2.0 of XEP-0385 (Stateless Inline Media Sharing (SIMS)) has > been released. > > Abstract: > This specification describes a protocol for stateless asynchronous > media sharing with integrity and transport flexibility. It allows > clients to provide a good interoperable user experience in combination > with Carbons and MAM. > > Changelog: > Use 'urn:xmpp:hashes:2' and 'urn:xmpp:jingle:apps:file-transfer:5'. > (fs) > > URL: https://xmpp.org/extensions/xep-0385.html > <https://xmpp.org/extensions/xep-0385.html> > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > <https://mail.jabber.org/mailman/listinfo/standards> > Unsubscribe: standards-unsubscr...@xmpp.org > <mailto:standards-unsubscr...@xmpp.org> > ___ > > > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [Fwd: [Council] Agenda 2009-06-03]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, the meeting will be held on 2009-06-03 (Wednesday) at 19:00 UTC at xmpp:coun...@conference.jabber.org /psa - Original Message Subject: [Council] Agenda 2009-06-03 Date: Mon, 1 Jun 2009 21:12:19 +0100 From: Kevin Smith Reply-To: ke...@kismith.co.uk, XMPP Council To: XMPP Council Proposed Agena: 1. Roll Call 2. Agenda bashing. Voting the Jingles to Draft? 3. Jingle - http://xmpp.org/extensions/xep-0166.html 4. Jingle RTP Sessions - http://xmpp.org/extensions/xep-0167.html 5. Jingle ICE-UDP Transport Method - http://xmpp.org/extensions/xep-0176.html 6. Jingle Raw UDP Transport Method - http://xmpp.org/extensions/xep-0177.html 7. XMPP Ping - http://xmpp.org/extensions/xep-0199.html Implementation text ok? http://mail.jabber.org/pipermail/standards/2009-May/022020.html Vote to Final? Obsolete some stuff: 8. Proxy Accept Socket Service (PASS) - http://xmpp.org/extensions/xep-0003.html 9. Jabber Browsing - http://xmpp.org/extensions/xep-0011.html 10. Message Expiration - http://xmpp.org/extensions/xep-0023.html 11. Jabber HTTP Polling - http://xmpp.org/extensions/xep-0025.html 12. AOB 13 Next meeting? - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkokQ7oACgkQNL8k5A2w/vxLkACdGBWjl564wu/DMEeAKy8Xlxg/ qQwAnAuvDxEI81iOluOGvkp7pspP7pPT =o580 -END PGP SIGNATURE-
[Git][gajim/gajim][master] DOAP: Update RFCs and fix typo
Philipp Hörist pushed to branch master at gajim / gajim Commits: 6764c110 by Daniel Brötzmann at 2020-03-11T18:35:56+01:00 DOAP: Update RFCs and fix typo - - - - - 1 changed file: - data/gajim.doap Changes: = data/gajim.doap = @@ -37,7 +37,8 @@ https://xmpp.org/rfcs/rfc6120.html"; /> https://xmpp.org/rfcs/rfc6121.html"; /> https://xmpp.org/rfcs/rfc6122.html"; /> -https://xmpp.org/rfcs/rfc7590.html"; /> +https://tools.ietf.org/html/rfc7395"; /> +https://tools.ietf.org/html/rfc7590"; /> https://xmpp.org/extensions/xep-0004.html"; /> @@ -511,7 +512,7 @@ -https://xmpp.org/extensions/xep-0368.html"; /> +https://xmpp.org/extensions/xep-0373.html"; /> complete 0.4.0 OpenPGP plugin. View it on GitLab: https://dev.gajim.org/gajim/gajim/-/commit/6764c110d523fe34183e889437b7db2f84d0864f -- View it on GitLab: https://dev.gajim.org/gajim/gajim/-/commit/6764c110d523fe34183e889437b7db2f84d0864f You're receiving this email because of your account on dev.gajim.org. ___ Commits mailing list Commits@gajim.org https://lists.gajim.org/cgi-bin/listinfo/commits
[Standards] Fwd: Re: [Council] Agenda
FYI for those of you who don't follow the coun...@xmpp.org list (yes, anyone can subscribe), there's an XMPP Council meeting later today. Original Message Subject: Re: [Council] Agenda Date: Wed, 09 Nov 2011 06:35:54 -0700 From: Peter Saint-Andre Reply-To: XMPP Council To: ke...@kismith.co.uk, XMPP Council On 11/9/11 6:23 AM, Kevin Smith wrote: Right, I'm probably missing stuff here, please bash as appropriate. 1) Roll call 2) Account manangement protoXEP. Community feedback seems to have finished coming in, and the author has responded. 3) XEP-0258. Last call feedback has been integrated. Accept as Draft? 4) http://xmpp.org/extensions/inbox/correction.html I've made the changes pre-approved a few months ago. Accept as Experimental? 5) ... 5a. XEP-0009 v2.2 http://xmpp.org/extensions/tmp/xep-0009-2.2.html http://xmpp.org/extensions/diff/api/xep/0009/diff/2.1/vs/2.2rc1 5b. XEP-0068 v1.2 http://xmpp.org/extensions/tmp/xep-0068-1.2.html http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2pre1 5c. http://xmpp.org/extensions/inbox/muc-unique.html 5d. http://xmpp.org/extensions/inbox/dmuc3.html /psa
[Standards] XMPP Council Agenda 2022-07-27
Hi Council members, the next XMPP Council Meeting will take place on Wednesday, July 27 2022 at 15:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update a) Proposed XMPP Extension: Bookmark Pinning https://xmpp.org/extensions/inbox/bookmark-pinning.html b) NEW: XEP-0467 (XMPP over QUIC) https://xmpp.org/extensions/xep-0467.html c) Proposed XMPP Extension: Pubsub Attachments https://xmpp.org/extensions/inbox/pubsub-attachments.html d) NEW: XEP-0468 (WebSocket S2S) https://xmpp.org/extensions/xep-0468.html e) LAST CALL: XEP-0215 (External Service Discovery) https://xmpp.org/extensions/xep-0215.html (Will be voted on next week. Please provide feedback) 4) Items for voting a) Proposed XMPP Extension: Bookmark Pinning https://xmpp.org/extensions/inbox/bookmark-pinning.html b) Proposed XMPP Extension: Pubsub Attachments https://xmpp.org/extensions/inbox/pubsub-attachments.html 5) Pending votes - None this week See Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Newsletter] The XMPP Newsletter May 2024
[The XMPP Newsletter May 2024](https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/) Posted on June 6, 2024 | 5 minutes | [Newsletter](https://xmpp.org/categories/newsletter/) | XMPP Communication Team and Contributors [Español](https://xmpp.org/es/2024/06/the-xmpp-newsletter-may-2024/) [XMPP Newsletter Banner] XMPP Newsletter Banner Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of May 2024. XMPP and Google Summer of Code 2024 https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xmpp-and-google-summer-of-code-2024 The XSF has been accepted as a [hosting organisation at GSoC in 2024](https://wiki.xmpp.org/web/Google_Summer_of_Code_2024) again! These XMPP projects have received a slot and will kick-off with coding now: - [Monal](https://monal-im.org/) - [Media Gallery (90 hours, easy)](https://wiki.xmpp.org/web/Gsoc2024/Monal/Media_Gallery) - [Prav.app](https://prav.app/) - [Standards compliant SMS OTP based authentication (350 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Prav.app/Standards_compliant_SMS_OTP_based_authentication) [XSF and Google Summer of Code 2024] XSF and Google Summer of Code 2024 XSF Fiscal Hosting Projects https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xsf-fiscal-hosting-projects The XSF offers [fiscal hosting](https://xmpp.org/community/fiscalhost/) for XMPP projects. Please apply via [Open Collective](https://opencollective.com/xmpp). For more information, see the [announcement blog post](https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/). Current projects you can support: - [Mellium Co-op](https://opencollective.com/mellium) - [Prav iOS](https://opencollective.com/prav-ios) XMPP Events https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xmpp-events - [XMPP Track at FOSSY](https://2024.fossy.us/pages/tracks/): Call for proposals ends June 14th! - [XMPP Sprint in Berlin](https://wiki.xmpp.org/web/Sprints/2024-07_Berlin): On Friday, 12th to Sunday, 14th of July 2024. - [XMPP Italian happy hour](https://video.xmpp-it.net/c/happyhour/videos) [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming). XMPP Videos https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xmpp-videos [Debian and XMPP in Wind and Solar Measurement](https://saimei.ftp.acc.umu.se/pub/debian-meetings/2024/MiniDebConf-Berlin/38-debian-and-xmpp-in-wind-and-solar-measurement.webm) talk at MiniDebConf Berlin 2024. XMPP Articles https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xmpp-articles - In the [JMP Newsletter](http://blog.jmp.chat/b/may-newsletter-2024) they discuss new upcoming SMS routes, a future XMPP to RCS gateway option, and the Cheogram Android 2.15.3-1 release. - Aaron P. MacSween [announced webxdc evolve](https://cryptography.dog/blog/announcing-webxdc-evolve/). Besides other it has also been ported to the XMPP-based [Cheogram service](https://cheogram.com/). XMPP Software News https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xmpp-software-news XMPP Clients and Applications https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xmpp-clients-and-applications - [Psi+ 1.5.1844 through 1.5 1930 portable](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/tehnick/) have been released. - [Psi+ 1.5.1834 through 1.5 1937 installer](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/KukuRuzo/) have been released. XMPP Servers https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xmpp-servers - [Scaling up with MongooseIM 6.2.1](https://xmpp.org/2024/05/scaling-up-with-mongooseim-6.2.1/). - XMPP Web is a third-party webclient that is available as [plugin for Openfire](https://discourse.igniterealtime.org/t/new-openfire-plugin-xmpp-web/93982)! [XMPP Web as Openfire plugin] XMPP Web as Openfire plugin XMPP Libraries & Tools https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#xmpp-libraries--tools - [Initial public announcement of Slixfeed News Bot](https://slixfeed.woodpeckersnest.space/posts/slixfeed-news-bot/). [Slixfeed News Bot] Slixfeed News Bot - QXmpp [1.6.1](https://github.com/qxmpp-project/qxmpp/releases/tag/v1.6.1) (with fixed OMEMO group chat support) and [1.7.0](https://github.com/qxmpp-project/qxmpp/releases/tag/v1.7.0) (with [MIX](https://xmpp.org/extensions/xep-0369.html), [SASL2](https://xmpp.org/extensions/xep-0388.html) and updated [SFS](https://xmpp.org/extensions/xep-0447.html) for compatibility with deployed protocols) have been released. - [go-xmpp 0.2.1](https://github.com/xmppo/go-xmpp/releases/tag/v0.2.1). - [go-sendxmpp 0.11.0](https://salsa.debian.org/mdosch/go-sendxmpp/-/releases/v0.11.0). Extensions and specifications https://xmpp.org/2024/06/the-xmpp-newsletter-may-2024/#extensions-and-specifications The XMPP Standards Foundation develops extensions to XMPP in its [XEP series](https://xmpp
Re: [Standards] UPDATED: XEP-0385 (Stateless Inline Media Sharing (SIMS))
It may be best to have a single XEP cover codec support and reference it as appropriate. On Tue, Nov 7, 2017 at 1:15 PM, Peter Saint-Andre wrote: > We might want to update XEP-0266, too: > > https://xmpp.org/extensions/xep-0266.html#codecs-opus > > https://xmpp.org/extensions/xep-0266.html#mti > > On 11/7/17 2:11 PM, Arc Riley wrote: > > https://xmpp.org/extensions/xep-0385.html#sect-idm139941991230272 > > > > Since the IETF has standardized the patent-clear Opus codec, this should > > be recommended. It is already used for WebRTC and broadly supported. > > > > https://tools.ietf.org/html/rfc6716 > > https://caniuse.com/#search=Opus > > > > > > > > On Wed, Oct 4, 2017 at 8:54 AM, Jonas Wielicki > <mailto:jo...@wielicki.name>> wrote: > > > > Version 0.2.0 of XEP-0385 (Stateless Inline Media Sharing (SIMS)) has > > been released. > > > > Abstract: > > This specification describes a protocol for stateless asynchronous > > media sharing with integrity and transport flexibility. It allows > > clients to provide a good interoperable user experience in > combination > > with Carbons and MAM. > > > > Changelog: > > Use 'urn:xmpp:hashes:2' and 'urn:xmpp:jingle:apps:file-transfer:5'. > > (fs) > > > > URL: https://xmpp.org/extensions/xep-0385.html > > <https://xmpp.org/extensions/xep-0385.html> > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > <https://mail.jabber.org/mailman/listinfo/standards> > > Unsubscribe: standards-unsubscr...@xmpp.org > > <mailto:standards-unsubscr...@xmpp.org> > > ___ > > > > > > > > > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > > > > > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Newsletter] The XMPP Newsletter August 2024
[The XMPP Newsletter August 2024](https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/) Posted on September 5, 2024 | 7 minutes | [Newsletter](https://xmpp.org/categories/newsletter/) | XMPP Communication Team and Contributors [XMPP Newsletter Banner] XMPP Newsletter Banner Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of August 2024. XSF Announcement https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/#xsf-announcement The XSF [has signed an Open Letter to the European Commission](https://xmpp.org/2024/08/the-xsf-signs-open-letter-to-the-european-commission/). As currently many other organizations doing, the [XMPP Standards Foundation](https://xmpp.org/about/xmpp-standards-foundation/) (XSF) has decided to also sign the [Open Letter to the European Commission](https://www.ow2.org/view/Events/The_European_Union_must_keep_funding_free_software_open_letter). The [XMPP Standards Foundation](https://xmpp.org/about/xmpp-standards-foundation/) is also calling for XSF Board 2024 and XSF Council 2024. Be involved in the XMPP Standards Foundation organisation decisions as well as on our specifications we publish. If you are interested in running for Board or Council, please add a wiki page about your candidacy to one or both of the following sections until November 3rd, 2024, 00:00 UTC. Note: XMPP Council members must be elected members of the XSF; however, there is no such restriction for the Board of Directors. XMPP and Google Summer of Code 2024 https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/#xmpp-and-google-summer-of-code-2024 The XSF has been accepted as a [hosting organisation at GSoC in 2024](https://wiki.xmpp.org/web/Google_Summer_of_Code_2024) again! These XMPP projects have received a slot and have kicked-off with coding: - [Monal](https://monal-im.org/) - [Modern Monal onboarding and Media gallery (175 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Monal/Media_Gallery) - [Blog post 1](https://thevaidik.medium.com/google-summer-of-code-gsoc-my-experience-1-xmpp-standards-foundation-da781ac95560) - [Blog post 2](https://thevaidik.medium.com/google-summer-of-code-gsoc-my-experience-2-midterm-evaluations-xmpp-standards-foundation-3be8b27dc653) [XSF and Google Summer of Code 2024] XSF and Google Summer of Code 2024 XSF Fiscal Hosting Projects https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/#xsf-fiscal-hosting-projects The XSF offers [fiscal hosting](https://xmpp.org/community/fiscalhost/) for XMPP projects. Please apply via [Open Collective](https://opencollective.com/xmpp). For more information, see the [announcement blog post](https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/). Current projects you can support: - [Mellium Co-op](https://opencollective.com/mellium) - [Bifrost bridge](https://opencollective.com/bifrost-mam) - [Prav iOS](https://opencollective.com/prav-ios) - [diasp.in](https://opencollective.com/diasp-in) XMPP Events https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/#xmpp-events - [Berlin XMPP Meetup](https://mov.im/?node/pubsub.movim.eu/berlin-xmpp-meetup) (DE / EN): monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month at 6pm local time - [XMPP Sprint in Worcester, UK](https://wiki.xmpp.org/web/Sprints/2024-09_Worcester_UK): From Saturday 21st to Sunday 22nd of September 2024. - [XMPP Italian happy hour](https://video.xmpp-it.net/c/happyhour/videos) [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming). Videos https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/#videos - Blasta: An introduction to the [XMPP-based Annotation System](https://video.xmpp-it.net/w/cfozoUeVLFbBFMCCSCJ1Dn). (06:38) XMPP Articles https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/#xmpp-articles - [XMPP Protocol - Introduction to XMPP](https://machaddr.substack.com/p/xmpp-protocol): An introductory article and concicse overview of the XMPP Protocol and its most prominent features by André Machado. This article is also available for reading in [Portuguese](https://leaf.dragonflybsd.org/~gnemmi/blog/xmpp/xmpp-protocolo-pt.html) and [Spanish](https://leaf.dragonflybsd.org/~gnemmi/blog/xmpp/xmpp-protocolo-es.html), too. XMPP Software News https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/#xmpp-software-news XMPP Clients and Applications https://xmpp.org/2024/09/the-xmpp-newsletter-august-2024/#xmpp-clients-and-applications - [Monal 6.4.2](https://github.com/monal-im/Monal/releases/tag/Build_iOS_964), [6.4.3](https://github.com/monal-im/Monal/releases/tag/Build_iOS_976) and version [6.4.4](https://github.com/monal-im/Monal/releases/tag/Build_iOS_978) have been released. - [Psi+ 1.5.2040 portable](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/tehnick/) has been released. - [Quicksy](https
Re: separate login/password for several services?
Andrew Findlay wrote: > > mmm ... will not it prevent non-uniqueness only for parent DN-s? while > > what I'm trying to ask (I'm sorry for muddled up explanation what I mean) > > about is - uniqueness for the uid *in* the entry ... so, the uniqueness > > of the attribute `uid' among all DN-s containing > > authorizedService=target-service > > You could do that if you are prepared to have one config line for each > service. Something like: > > overlay unique > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH) > this prevents each uid=X,ou=People,dc=org from having more than one authorizedService=Y offspring ... while the original idea is to let user A to have for the service B, several uid-s but to prevent other users to have the same uids for the corresponding service ... what I mean are multiple attributes uid/userpassword "inside" the offspring not in the `dn' of the offspring: dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john uid: john1 uid: johnN userPassword: qwerty userPassword: qwerty1 userPassword: qwertyN cn: john@xmpp.org sn: xmpp.org description: John Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject and in this case we need to prevent some other user from having offspring with the same uid ... to prevent for user uid=johandoe,ou=People,dc=org offspring: dn: authorizedService=xmpp.org,uid=johandoe,ou=People,dc=org authorizedService: xmpp.org uid: johan uid: johan1 userPassword: qwerty userPassword: qwerty1 cn: johan@xmpp.org sn: xmpp.org description: Johan Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject possibility to add another `uid: johnN' which is already used by dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org so, what could be the solution, please? -- Zeus V. Panchenko jid:z...@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
Re: [jdev] DNS outage at xmpp.org/xmpp.net
Once the dust has settled, I presume you will be looking to move at least one of the secondary DNS servers away from the same physical network as the primary ? xmpp.orgnameserver = dns1.mediahost.org xmpp.orgnameserver = dns2.mediahost.org Authoritative answers can be found from: xmpp.orgnameserver = dns2.mediahost.org xmpp.orgnameserver = dns1.mediahost.org dns1.mediahost.org internet address = 62.90.44.166 dns2.mediahost.org internet address = 62.90.44.167 --- Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > The xmpp.org and xmpp.net domains are currently experiencing a DNS > outage because of scheduled downtime at our DNS provider. I do not > yet > have an exact ETA for when service will resume, but I do not expect > it > to be more than a few hours. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > >
Re: [Standards] BOSH patches, hopefully the last before final
Looks good. Two things though: 1. Session Creation Response: My suggestions concerning the 'from' attribute obv hasn't made it :-(.. Well, so be it. But I found this sentence: 'to' -- This attribute communicates the identity of the backend server to which the client is attempting to connect. Isn't it the same than the from attribute then? Shouldn't the 'to' attribute be the client's JID in the server's response? 2. Terminating the BOSH Session Why did you remove the "" from this sentence: "... terminate the session by sending a element with a 'type' attribute..." ? - Christian Gesendet: Dienstag, 11. Februar 2014 um 11:02 Uhr Von: "Winfried Tilanus" An: standards@xmpp.org Betreff: Re: [Standards] BOSH patches, hopefully the last before final On 02/11/2014 03:17 AM, Peter Saint-Andre wrote: > Done: > http://xmpp.org/extensions/tmp/xep-0124-1.11.html > http://xmpp.org/extensions/diff/api/xep/0124/diff/1.10/vs/1.11rc3[http://xmpp.org/extensions/diff/api/xep/0124/diff/1.10/vs/1.11rc3] > http://xmpp.org/extensions/tmp/xep-0206-1.4.html[http://xmpp.org/extensions/tmp/xep-0206-1.4.html] > http://xmpp.org/extensions/diff/api/xep/0206/diff/1.3/vs/1.4rc2[http://xmpp.org/extensions/diff/api/xep/0206/diff/1.3/vs/1.4rc2] > > Peter Thanks a lot, Winfried
Re: [Standards] Call for Experience: XEP-0066: Out of Band Data
Hi, On Thu, Mar 22, 2018 at 11:57:52AM +0300, Kozlov Konstantin wrote: >Hello! > [snip] >I don't see any XEP which describes of full procedure of file transfer >using OOB. >But [1]XEP-0095: Stream Initiation has [2]mention of using OOB as stream >method. >I guess, this method never used before, just because there were no way get >an URL of a file to transfer. But now we have [3]XEP-0363: HTTP File >Upload, which allows to upload a file to a HTTP server and get its URL. >I think we need an Informational (or maybe Standards Track?) XEP, which >describes such way of file transfer, using [4]XEP-0096: SI File Transfer >(deprecated) and [5]XEP-0324: Jingle File Transfer (recommended) as file >transfer application, [6]XEP-0066: Out of Band Data as stream method and >[7]XEP-0363: HTTP File Upload as supplementary XEP for file uploading. Do you mean XEP-0370[1]? > >With my best regards, >Konstantin > > References > >Visible links > 1. https://xmpp.org/extensions/xep-0095.html > 2. https://xmpp.org/extensions/xep-0095.html#usecase-neg >3. https://xmpp.org/extensions/xep-0363.html >4. https://xmpp.org/extensions/xep-0096.html >5. https://xmpp.org/extensions/xep-0234.html >6. https://xmpp.org/extensions/xep-0066.html >7. https://xmpp.org/extensions/xep-0363.html [1] https://xmpp.org/extensions/xep-0370.html -- Emmanuel Gil Peyrot signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Newsletter] The XMPP Newsletter April 2024
Posted on May 5, 2024 | 5 minutes | [Newsletter](https://xmpp.org/categories/newsletter/) | XMPP Communication Team and Contributors [XMPP Newsletter Banner] XMPP Newsletter Banner Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of April 2024. XSF Announcements https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#xsf-announcements If you are interested to join the XMPP Standards Foundation as a member, [please apply until 19th May 2024!](https://wiki.xmpp.org/web/Membership_Applications_Q2_2024). XMPP and Google Summer of Code 2024 https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#xmpp-and-google-summer-of-code-2024 The XSF has been accepted as a [hosting organisation at GSoC in 2024](https://wiki.xmpp.org/web/Google_Summer_of_Code_2024) again! These XMPP projects have received a slot and are in the community bonding phase now: - [Monal](https://monal-im.org/) - [Media Gallery (90 hours, easy)](https://wiki.xmpp.org/web/Gsoc2024/Monal/Media_Gallery) - [Prav.app](https://prav.app/) - [Standards compliant SMS OTP based authentication (350 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Prav.app/Standards_compliant_SMS_OTP_based_authentication) [XSF and Google Summer of Code 2024] XSF and Google Summer of Code 2024 XSF Fiscal Hosting Projects https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#xsf-fiscal-hosting-projects The XSF offers [fiscal hosting](https://xmpp.org/community/fiscalhost/) for XMPP projects. Please apply via [Open Collective](https://opencollective.com/xmpp). For more information, see the [announcement blog post](https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/). Current projects you can support: - [Mellium Co-op](https://opencollective.com/mellium) - [Prav iOS](https://opencollective.com/prav-ios) XMPP Events https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#xmpp-events - [XMPP Sprint in Berlin](https://wiki.xmpp.org/web/Sprints/2024-07_Berlin): On Friday, 12th to Sunday, 14th of July 2024. - [XMPP Italian happy hour](https://video.xmpp-it.net/c/happyhour/videos) [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming). Articles https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#articles - Monal: - [iOS app banned from Chinese Appstore](https://monal-im.org/post/00010-ios-banned/) - [Partial security audit for Monal iOS client](https://monal-im.org/post/00011-security-audit-1/): Radically Open Security (ROS) performed a security audit of some parts of Monal. - Snikket Android app temporarily [unavailable in Google Play store](https://snikket.org/blog/snikket-google-play-removal) (problem already resolved) Software News https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#software-news Clients and Applications https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#clients-and-applications - [Monal 6.3.0](https://github.com/monal-im/Monal/releases/tag/Build_iOS_900) has been released, which brings support for [XEP-0425: Moderated Message Retraction](https://xmpp.org/extensions/xep-0425.html) and [XEP-0490: Message Displayed Synchronization](https://xmpp.org/extensions/xep-0490.html). - [Movim 0.24 “#Mueller”](https://mov.im/node/pubsub.movim.eu/Movim/007843a5-5a44-4710-86a1-70ad7e18bd84) and a [0.24.1 bugfix](https://mov.im/node/pubsub.movim.eu/Movim/d71c1b3a-d36a-4eb4-a6fb-ff245123348f) have been released. - [Psi+ 1.5.1747 through 1.5.1816 installer](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/KukuRuzo/) and [Psi+ 1.5.1768 through 1.5.1819 portable](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/tehnick/) have been released. Now with Qt6 instead of Qt5. Servers https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#servers - [MongooseIM 6.2.1](https://github.com/esl/MongooseIM/releases/tag/6.2.1) has been released. Version 1.1.0 of [XEP-0313 Message Archive Management](https://xmpp.org/extensions/xep-0313.html) is now supported. The improved CETS in-memory storage backend allows you to easily deploy, manage and scale your MongooseIM installation in the cloud without the burden of persistent volumes. - [ejabberd Docs now using MkDocs](https://www.process-one.net/blog/ejabberd-docs-now-using-mkdocs/) Libraries & Tools https://xmpp.org/2024/05/the-xmpp-newsletter-april-2024/#libraries--tools - [Smack 4.4.8](https://discourse.igniterealtime.org/t/smack-4-4-8-released/93807) has been released - [Slidge v0.1.0](https://sr.ht/~nicoco/slidge/) Slidge is an XMPP (puppeteer) gateway library in python. It makes writing gateways to other chat networks (legacy modules) as frictionless as possible. - [go-xmpp 0.2.0](https://github.com/xmppo/go-xmpp/releases/tag/v0.2.0). - [go-sendxmpp 0.10.0](https://salsa.debian.org/mdosch/go-sendxmpp/-/releases/v0.10.0). Extensions and specifications h
[Standards] XMPP Council Agenda 2022-02-08
Good morning Council Members, the next XMPP Council Meeting will take place today, Wednesday, February 08st 2023 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * UPDATED: XEP-0353 (Jingle Message Initiation) (https://xmpp.org/extensions/xep-0353.html) * UPDATED: XEP-0426 (Character counting in message bodies) (https://xmpp.org/extensions/xep-0426.html) * UPDATED: XEP-0444 (Message Reactions) (https://xmpp.org/extensions/xep-0444.html) * UPDATED: XEP-0461 (Message Replies) (https://xmpp.org/extensions/xep-0461.html) * UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection) (https://xmpp.org/extensions/xep-0474.html) * Proposed XMPP Extension: XMPP Compliance Suites 2023 (https://xmpp.org/extensions/inbox/cs-2023.html) 4) Items for voting * Proposed XMPP Extension: XMPP Compliance Suites 2023 * Issue Last Call on XEP-0334: Message Processing Hints 5) Pending votes * none See the all new Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1Zp5FWJI0aubAL29LhrXkhc-MrZauJ1mtkVnm5TrtwLo/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2023-11-08
Good morning Council Members, the next XMPP Council Meeting will take place on, Wednesday, November 8 2023 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - UPDATED: XEP-0377 Spam Reporting (https://xmpp.org/extensions/xep-0377.html) - UPDATED: XEP-0424 Message Retraction (https://xmpp.org/extensions/xep-0424.html) - UPDATED: XEP-0458 Community Code of Conduct (https://xmpp.org/extensions/xep-0458.html) - Proposed XMPP Extension: HTTP Online Meetings (https://xmpp.org/extensions/inbox/xep-http_online_meetings.html) - Proposed XMPP Extension: Communicate & Ask to AI (https://xmpp.org/extensions/inbox/xep-ai.html) 4) Items for voting a) Proposed XMPP Extension: HTTP Online Meetings (https://xmpp.org/extensions/inbox/xep-http_online_meetings.html) b) Proposed XMPP Extension: Communicate & Ask to AI (https://xmpp.org/extensions/inbox/xep-ai.html) c) XEP-0060: Release version 1.25.1 (https://github.com/xsf/xeps/pull/1293) d) XEP-0045: roominfo_changesubject does not exist (https://github.com/xsf/xeps/pull/1292) e) XEP-0402: Replace arbitrary max items with 'max' (https://github.com/xsf/xeps/pull/1278) f) Add Council as approver to all Standards Track XEPs where it was missing (https://github.com/xsf/xeps/pull/1265) 5) Pending votes none See the Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1Zp5FWJI0aubAL29LhrXkhc-MrZauJ1mtkVnm5TrtwLo/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)
On Mon, Jul 16, 2012 at 4:56 PM, Gunnar Hellström < gunnar.hellst...@omnitor.se> wrote: > > 6. The reason Attibute > > To signal the type of communication that is desired, the entity that first > shares session presence MAY include a 'reason' attribute on the > element. Multiple values are allowed. The following values for the 'reason' > attribute are defined: > *video* > Presence is requested for video medium of a call party, e.g. via Jingle > RTP Sessions <http://xmpp.org/extensions/xep-0167.html> > [8<http://xmpp.org/extensions/xep-0276.html#nt-id337164> > ]. *audio* > Presence is requested for audio medium of a call party, e.g. via Jingle > RTP Sessions <http://xmpp.org/extensions/xep-0167.html> > [8<http://xmpp.org/extensions/xep-0276.html#nt-id337164> > ]. ** > *real-time-text* Presence is requested for a real-time text conversation > using a medium of the call party or an extension that requires real-time > text capabilities to be disclosed, such as In-Band Real Time > Text<http://xmpp.org/extensions/xep-0301.html> > [11 <http://xmpp.org/extensions/xep-0276.html#nt-id343682>], or Jingle > RTP Sessions <http://xmpp.org/extensions/xep-0167.html> > [8<http://xmpp.org/extensions/xep-0276.html#nt-id337164>] > or real-time text capabilities beyond a gateway. *message-text* Presence > is requested for a text communication using a message medium of the call > party or an extension that requires text message capabilities to be > disclosed, such asXHTML-IM <http://xmpp.org/extensions/xep-0071.html> > [9<http://xmpp.org/extensions/xep-0276.html#nt-id343644> > ], Chat State Notifications <http://xmpp.org/extensions/xep-0085.html> > [10<http://xmpp.org/extensions/xep-0276.html#nt-id343663> > ], or text message capabilities beyond a gateway. ***file* Presence is > requested for one or more file transfers, e.g. via Jingle File > Transfer<http://xmpp.org/extensions/xep-0234.html> > [12 <http://xmpp.org/extensions/xep-0276.html#nt-id343702>] or Stream > Initiation <http://xmpp.org/extensions/xep-0095.html> > [13<http://xmpp.org/extensions/xep-0276.html#nt-id343721> > ]. > Gunnar's ideas seem good (though the implementation details could be reduced somewhat). I wonder if there's a need for that many granular reasons, because I consider real-time text to be the same category as message-text. However, it is my understanding that this isn't the case for the SIP / RFC4103 side of things, because the SIP RTT / SIP messaging are more independent of each other. On the other hand, the text transmitted over RFC4103/T.140 over SIP (for real time text) and SIP Message/MSRP can be brought into sync by the implementor, much like (XEP-0301) and (XMPP Core) is kept in sync by an implementation. Side note: Right now, as far as I know, I don't see any standardization (as far as I know) for synchronizing the text between RFC4103/T.140, and the text in SIP Mesage, but it is possible, likely by transmitting the SIP Message everytime someone hits Enter, or after a certain number of characters. (which may introduce ambiguity in backspacing to previous message, but there are some solutions to even this too. On the XMPP side of things, it's XEP-0308 last message editing and a very minor extension to XEP-0301 (It's just an "id" parameter for elements containing a event='new'/'reset') can theoretically allow XEP-0301 on last message editing, and permit backspacing to the previous message, for backwards compatibility to "linear RTT" (textphone style).Implementations would have to be responsible for merging the user interface presentation. But this side-note paragraph is not XMPP talk, and probably needs to be brought up on the appropriate IETF mailing list, to synchronize the text of the messaging with the real-time text. Thanks Mark Rejhon
Re: [MUC] IQ Business Rules in XEP-0045
Valentin Chartier - 16 rue Maurice Champeau - 92130 Issy les Moulineaux -
FRANCE - +33 6 47 94 54 25
De : "muc-requ...@xmpp.org"
À : muc@xmpp.org
Envoyé le : Sam 14 Novembre 2009, 19 h 00 min 01 s
Objet : MUC Digest, Vol 10, Issue 2
Remarque : un mail transféré est joint à ce mail.
Send MUC mailing list submissions to
muc@xmpp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.jabber.org/mailman/listinfo/muc
or, via email, send a message with subject or body 'help' to
muc-requ...@xmpp.org
You can reach the person managing the list at
muc-ow...@xmpp.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MUC digest..."
Today's Topics:
1. Re: IQ Business Rules in XEP-0045 (Waqas Hussain)
___
MUC mailing list
MUC@xmpp.org
http://mail.jabber.org/mailman/listinfo/muc
[Newsletter] The XMPP Newsletter June 2024
[The XMPP Newsletter June 2024](https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/) Posted on July 6, 2024 | 6 minutes | [Newsletter](https://xmpp.org/categories/newsletter/) | XMPP Communication Team and Contributors [XMPP Newsletter Banner] XMPP Newsletter Banner Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of June 2024. XMPP and Google Summer of Code 2024 https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/#xmpp-and-google-summer-of-code-2024 The XSF has been accepted as a [hosting organisation at GSoC in 2024](https://wiki.xmpp.org/web/Google_Summer_of_Code_2024) again! These XMPP projects have received a slot and have kicked-off with coding: - [Monal](https://monal-im.org/) - [Modern Monal onboarding and Media gallery (175 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Monal/Media_Gallery) - [Blog post 1](https://thevaidik.medium.com/google-summer-of-code-gsoc-my-experience-1-xmpp-standards-foundation-da781ac95560) - [Prav.app](https://prav.app/) - [Standards compliant SMS OTP based authentication (350 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Prav.app/Standards_compliant_SMS_OTP_based_authentication) - [Blog post 1](https://write.as/assu/gsoc-and-open-source-my-first-steps-into-xmpp) [XSF and Google Summer of Code 2024] XSF and Google Summer of Code 2024 XSF Fiscal Hosting Projects https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/#xsf-fiscal-hosting-projects The XSF offers [fiscal hosting](https://xmpp.org/community/fiscalhost/) for XMPP projects. Please apply via [Open Collective](https://opencollective.com/xmpp). For more information, see the [announcement blog post](https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/). Current projects you can support: - [Mellium Co-op](https://opencollective.com/mellium) - [Prav iOS](https://opencollective.com/prav-ios) XMPP Events https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/#xmpp-events - [XMPP Track at FOSSY](https://2024.fossy.us/): August 1-4th 2024 — Portland State University - [XMPP Sprint in Berlin](https://wiki.xmpp.org/web/Sprints/2024-07_Berlin): On Friday, 12th to Sunday, 14th of July 2024. - [Berlin XMPP Meetup](https://mov.im/?node/pubsub.movim.eu/berlin-xmpp-meetup)[DE / EN]: Monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month - [XMPP Italian happy hour](https://video.xmpp-it.net/c/happyhour/videos) [IT]: Monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming). XMPP Videos https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/#xmpp-videos [Debian and XMPP in Wind and Solar Measurement](https://saimei.ftp.acc.umu.se/pub/debian-meetings/2024/MiniDebConf-Berlin/38-debian-and-xmpp-in-wind-and-solar-measurement.webm) talk at MiniDebConf Berlin 2024. XMPP Articles https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/#xmpp-articles - [Understanding messaging protocols: XMPP and Matrix](https://www.process-one.net/blog/xmpp-matrix/) XMPP Software News https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/#xmpp-software-news XMPP Clients and Applications https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/#xmpp-clients-and-applications - [Psi+ 1.5.1947 through 1.5.2012 installer](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/KukuRuzo/) and [Psi+ 1.5.1979 through 1.5.2000 portable](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/tehnick/) have been released. - [Gajim 1.9.0](https://gajim.org/post/2024-06-10-gajim-1.9.0-released/) and [1.9.1](https://gajim.org/post/2024-06-22-gajim-1.9.1-released/) have been released. Half a year after the last release, Gajim 1.9.0 is finally here. This release brings long awaited support for message replies and message reactions. Message Moderation has been improved as well. Say hello to voice messages! [Gajim message reactions] Gajim message reactions - [Monal 6.4.0](https://github.com/monal-im/Monal/releases/tag/Build_iOS_911) has been released for iOS an macOS, with quite an impressive list of improvements. Monal was also running a [fundraising campaign](https://monal-im.org/post/00012-funding-iphone13/). - [Movim 0.25 “Nagata”](https://mov.im/node/pubsub.movim.eu/Movim/195d732f-a7b7-44ba-b0cc-caa68b6b4426) and [0.25.1 small bugfix](https://mov.im/node/pubsub.movim.eu/Movim/c0f66f93-9c2c-452c-97cc-bd36ebe19858) have been released. XMPP Servers https://xmpp.org/2024/07/the-xmpp-newsletter-june-2024/#xmpp-servers - [Tigase XMPP Server 8.4.0 was released](https://tigase.org/blog/tigase-xmpp-server-8.4.0/) - Most notable features are support for Portable Import/Export Format (XEP-0227), ability to configure users with push devices to show as away, ability to moderate MUCs and support for xmppbl.org. - [ejabberd 24.06: Deep Work Release!](https://www.process-one.net/blog/ejabberd-24-06
Re: [Operators] Public XMPP Services list
On Mon, Feb 22, 2010 at 18:33, Peter Saint-Andre wrote: > On 2/22/10 10:17 AM, Nicolas Vérité wrote: >> On Mon, Feb 22, 2010 at 18:15, Peter Saint-Andre wrote: >>> On 2/22/10 10:14 AM, Tomasz Sterna wrote: >>>> What is the usual update time of http://xmpp.org/services/ ? >>>> iee. How long would I wait for the submitted service to appear on this >>>> list? >>> >>> Forever. >> >> Bad answer... ;-) > > I've been doing this with Florian Thiessen. We might need more > assistance, because we're too slow. > >>> Who wants to help with this? >> >> What's the workload? > > We do this: > > http://xmpp.org/services/verify.shtml > > Given that we have only a few requests a month, the workload is not that > significant. If two other people do this with me, I'd be glad to take over. In order to be listed here: http://xmpp.org/services/ An operator should do the following: http://xmpp.org/services/register.shtml And then we should do this: http://xmpp.org/services/verify.shtml But then who commits back to: http://xmpp.org/services/ ? Btw, jabber.org needs a refresh, admins? -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ http://xmpp.org - http://april.org/ - http://qsos.org/
[Newsletter] The XMPP Newsletter July 2024
[The XMPP Newsletter July 2024](https://xmpp.org/2024/08/the-xmpp-newsletter-july-2024/) Posted on August 5, 2024 | 7 minutes | [Newsletter](https://xmpp.org/categories/newsletter/) | XMPP Communication Team and Contributors [Español](https://xmpp.org/es/2024/08/the-xmpp-newsletter-july-2024/), [Italiano](https://xmpp.org/it/2024/08/the-xmpp-newsletter-july-2024/) [XMPP Newsletter Banner] XMPP Newsletter Banner Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of July 2024. XSF Announcements https://xmpp.org/2024/08/the-xmpp-newsletter-july-2024/#xsf-announcements If you are interested to join the XMPP Standards Foundation as a member, [please apply until August 18th, 2024!](https://wiki.xmpp.org/web/Membership_Applications_Q3_2024). XMPP and Google Summer of Code 2024 https://xmpp.org/2024/08/the-xmpp-newsletter-july-2024/#xmpp-and-google-summer-of-code-2024 The XSF has been accepted as a [hosting organisation at GSoC in 2024](https://wiki.xmpp.org/web/Google_Summer_of_Code_2024) again! These XMPP projects have received a slot and have kicked-off with coding: - [Monal](https://monal-im.org/) - [Modern Monal onboarding and Media gallery (175 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Monal/Media_Gallery) - [Blog post 1](https://thevaidik.medium.com/google-summer-of-code-gsoc-my-experience-1-xmpp-standards-foundation-da781ac95560) - [Blog post 2](https://thevaidik.medium.com/google-summer-of-code-gsoc-my-experience-2-midterm-evaluations-xmpp-standards-foundation-3be8b27dc653) - [Prav.app](https://prav.app/) - INFO: Unfortunately, the mid-term evaluation has not been passed and the project has been stopped - [Standards compliant SMS OTP based authentication (350 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Prav.app/Standards_compliant_SMS_OTP_based_authentication) - [Blog post 1](https://write.as/assu/gsoc-and-open-source-my-first-steps-into-xmpp) [XSF and Google Summer of Code 2024] XSF and Google Summer of Code 2024 XSF Fiscal Hosting Projects https://xmpp.org/2024/08/the-xmpp-newsletter-july-2024/#xsf-fiscal-hosting-projects The XSF offers [fiscal hosting](https://xmpp.org/community/fiscalhost/) for XMPP projects. Please apply via [Open Collective](https://opencollective.com/xmpp). For more information, see the [announcement blog post](https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/). Current projects you can support: - [Mellium Co-op](https://opencollective.com/mellium) - [Bifrost bridge](https://opencollective.com/bifrost-mam) - [Prav iOS](https://opencollective.com/prav-ios) - [diasp.in](https://opencollective.com/diasp-in) XMPP Events https://xmpp.org/2024/08/the-xmpp-newsletter-july-2024/#xmpp-events - [XMPP Sprint in Worcester, UK](https://wiki.xmpp.org/web/Sprints/2024-09_Worcester_UK): September, 21st - 22nd 2024 — The Hive, Worcester - [XMPP Track at FOSSY](https://2024.fossy.us/): August 1-4th 2024 — Portland State University - [Berlin XMPP Meetup](https://mov.im/?node/pubsub.movim.eu/berlin-xmpp-meetup)[DE / EN]: Monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month - [XMPP Italian happy hour](https://video.xmpp-it.net/c/happyhour/videos) [IT]: Monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming). XMPP Articles https://xmpp.org/2024/08/the-xmpp-newsletter-july-2024/#xmpp-articles - [Rivista](https://git.xmpp-it.net/sch/Rivista) is a new publishing system which creates a dynamic journal site from XMPP PubSub nodes; Rivista is compatible with Atom/RSS news readers and HTML browsers as one. - [A blogpost from Haiku-OS on the XMPP Sprint Berlin July 2024](https://www.haiku-os.org/blog/nephele/2024-07-21_xmpp_coding_sprint_berlin). Find also July’s XMPP Sprint in Berlin list of projects](https://wiki.xmpp.org/web/Sprints/2024-07_Berlin#Attendees) that got worked on! - [JMP.chat: Calls from SIP and a potential new SIM plan](https://blog.jmp.chat/b/july-newsletter-2024) - [ProcessOne: Breaking Down the Costs of Large Messaging Services](https://www.process-one.net/blog/breaking-down-the-costs-of-large-messaging-services/) XMPP Software News https://xmpp.org/2024/08/the-xmpp-newsletter-july-2024/#xmpp-software-news XMPP Clients and Applications https://xmpp.org/2024/08/the-xmpp-newsletter-july-2024/#xmpp-clients-and-applications - [Rivista 0.1](https://git.xmpp-it.net/sch/Rivista) has been released. - [Psi+ 1.5.2033 portable](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/tehnick/) has been released. - [Psi+ 1.5.2029 through 1.5 2038 installer](https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/KukuRuzo/) have been released. - [Gajim 1.9.2](https://gajim.org/post/2024-07-19-gajim-1.9.2-released/) has been released and comes with an important OMEMO encryption fix, native notifications on Windows, plus usability
[Standards] XMPP Council Minutes 2018-03-07
A short reminder on Council voting: Council can vote on anything - while a Call For Experience is not a "Status Change" and thus does not require a vote, Council can still vote to ask the Editor to do one. Council members vote either +1 or 0 (the latter is often written signed, and may indicate a leaning), or may veto with -1. A single veto causes the motion to fail; otherwise a majority of the Council must vote +1 for the motion to pass. 1) Roll Call All present, but as Georg arrived Dave had to leave unexpectedly, thus Kev actually chaired. [Speaking personally, many thanks to Kev for taking on this monster meeting at no notice] [ 2) Elided since the lack of a minute-taker was already noted ] 3) CFE for XEP-0020: Feature Negotiation https://xmpp.org/extensions/xep-0020.html Kev noted the ground rules: Each of these votes has two parts - first whether to Call For Experience before moving to Final, the second to instead deprecate it. This one is for CFE with the intention to later move to Final. Georg queried if this were in use anywhere and noted a number of XEPs which reference it; Kev didn't think it was in use anywhere in practise. Daniel, Georg, Kev all -1 for CFE, Sam +0 4) Deprecate XEP-0020: Feature Negotiation https://xmpp.org/extensions/xep-0020.html Daniel, Georg, Kev all +1 for Deprecate, Sam +0 5) CFE for XEP-0048: Bookmarks https://xmpp.org/extensions/xep-0048.html Kev felt this was premature while the ongoing 49/223 mismatch quesiton isn't answered - Georg agreed this was the elephant in the room. Sam felt that a CFE might draw out more feedback. Georg agreed that a CFE, with an additional note about '49, might do the trick. Georg, Daniel, Sam +1 for CFE, Kev 0. 6) Deprecate XEP-0048: Bookmarks https://xmpp.org/extensions/xep-0048.html All present -1. Kev noted at this point that he would assume anyone +1 for a CFE would be -1 on the Deprecate, to which Georg agreed and nobody dissented. 7) CFE for XEP-0059: Result Set Management https://xmpp.org/extensions/xep-0059.html Georg and Kev both raised the current MAM discussion, and felt that we should resolve that prior to a CFE. Georg, Kev -1, Sam Daniel +1 8) Deprecate XEP-0059: Result Set Management https://xmpp.org/extensions/xep-0059.html All present -1 ** Stalemate ** 9) CFE for XEP-0066: Out of Band Data https://xmpp.org/extensions/xep-0066.html Daniel asked what this was actually used for, and Georg replied it was used for inline images in conversations, and suggested it might be harvested for good parts. Kev opined that the CFE might be interesting on this one. All present +1 10) Deprecate XEP-0066: Out of Band Data https://xmpp.org/extensions/xep-0066.html All present -1 11) CFE for XEP-0072: SOAP Over XMPP https://xmpp.org/extensions/xep-0072.html Kev suggested that a CFE might make it obvious whether deprecation was the right option. Sam -1, Georg, Kev, Daniel +1 12) Deprecate XEP-0072: SOAP Over XMPP https://xmpp.org/extensions/xep-0072.html Georg, Daniel, Kev -1, Sam +1 ** Stalemate ** 13) CFE for XEP-0079: Advanced Message Processing https://xmpp.org/extensions/xep-0079.html Kev +1, Daniel, Georg, +0, Sam -0 (Some question, here, over voting practises regarding CFE - note above that the Council may vote on anything). 14) Deprecate XEP-0079: Advanced Message Processing https://xmpp.org/extensions/xep-0079.html Kev felt that '79 needed some discussion in the community first, even if this were not a formal CFE. Daniel, Georg, and Kev -1, Sam +1. 15) CFE for XEP-0092: Software Version https://xmpp.org/extensions/xep-0092.html All present +1 16) Deprecate XEP-0092: Software Version https://xmpp.org/extensions/xep-0092.html All present -1 17) CFE for XEP-0122: Data Forms Validation https://xmpp.org/extensions/xep-0122.html Georg, Daniel, Kev +1, Sam +0 18) Deprecate XEP-0122: Data Forms Validation https://xmpp.org/extensions/xep-0122.html Kev, Daniel, Georg -1, Sam +1 19) CFE for XEP-0131: Stanza Headers and Internet Metadata https://xmpp.org/extensions/xep-0131.html Georg, Daniel, Kev +1, Sam +0 20) Deprecate XEP-0131: Stanza Headers and Internet Metadata https://xmpp.org/extensions/xep-0131.html Kev, Daniel, Georg -1, Sam +0 21) CFE for XEP-0141: Data Forms Layout https://xmpp.org/extensions/xep-0141.html Georg said he was in favour of deprecation, but only after some discussion. Daniel, Georg, Kev +1, Sam -0 22) Deprecate XEP-0141: Data Forms Layout https://xmpp.org/extensions/xep-0141.html Daniel, Georg, Kev -1, Sam +0 23) CFE for XEP-0229: Stream Compression with LZW https://xmpp.org/extensions/xep-0229.html Sam noted he thought he had written an implementation of this for HipChat (but it may have been gzip). Georg noted the insecurities around compression if it is not applied very cautiously. Daniel, Kev, Sam +1 Georg -0 24) Deprecate XEP-0229: Stream Compression with LZW https://xmpp.org/extensions/xep-0229.html Daniel, Kev -1, Sam +0,
[Standards] XMPP Council Agenda 2022-10-19
Good morning Council members, the next XMPP Council Meeting will take place on Wednesday, October 19st 2022 at 15:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - Proposed XMPP Extension: PubSub Social Feed (https://xmpp.org/extensions/inbox/pubsub-social-feed.html) - Proposed XMPP Extension: OpenPGP for XMPP Pubsub (https://xmpp.org/extensions/inbox/pubsub-encryption.html) - Proposed XMPP Extension: SASL SCRAM Downgrade Protection (https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html) 4) Items for voting a) Proposed XMPP Extension: PubSub Social Feed (https://xmpp.org/extensions/inbox/pubsub-social-feed.html) b) Proposed XMPP Extension: OpenPGP for XMPP Pubsub (https://xmpp.org/extensions/inbox/pubsub-encryption.html) c) Proposed XMPP Extension: SASL SCRAM Downgrade Protection (https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html) d) Should this go into XEP-0198? XEP-0198: Add section defining SASL2 and BIND2 interaction https://github.com/xsf/xeps/pull/1215 e) XEP-0045: Remove more of GC1 (https://github.com/xsf/xeps/pull/1213) f) XEP-0167: Release version 1.2.2 (https://github.com/xsf/xeps/pull/1212) 5) Pending votes none See Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Fwd: Minutes 2011-02-16
FYI -- Forwarded message -- From: Kevin Smith Date: Mon, Feb 21, 2011 at 11:54 AM Subject: Minutes 2011-02-16 To: XMPP Council 1) Roll call Kevin, Matt Miller and Ralph present. Matt Wild and Nathan absent. 2) Agenda bashing. 3) http://xmpp.org/extensions/inbox/vcard4.html Accept as a XEP? Matt, Ralph and Kevin in favour. Absent members to reply on-list within a fortnight. 4) http://xmpp.org/extensions/tmp/xep-0198-1.2.html Accept new version? Everyone to vote on-list within a fortnight. 5) Soon-to-expire XEPs: http://xmpp.org/extensions/xep-0215.html http://xmpp.org/extensions/xep-0275.html http://xmpp.org/extensions/xep-0276.html http://xmpp.org/extensions/xep-0277.html (No actions) 6) Date of next meeting 2011-02-23 1600 GMT (although later discussion on Council list) 7) Any other business. Google Summer of Code approaches. Discussion to happen in Board meeting. Peter'd like -47 to be on the next agenda for a new version vote. Fini.
[Standards] Fwd: Minutes 20130418
FYI -- Forwarded message -- From: Kevin Smith Date: Thu, Apr 18, 2013 at 8:21 AM Subject: Minutes 20130418 To: XMPP Council Room logs: http://logs.xmpp.org/council/130417/ 1) Roll call Kev, Matt Miller, Ralph present, Matt Wild late, Tobias sends apologies. 2) http://xmpp.org/extensions/xep-0288.html Move to Draft? MW (later) +1. All others to vote on list. 3) http://xmpp.org/extensions/xep-0152.html Move to Draft? (MW enters here) Agreement not to advance without any positive feedback during last call - LC to be extended and to chase the people likely to give feedback. 4) http://xmpp.org/extensions/inbox/fis.html Accept as Experimental? KS/RM not opposed, others have a fortnight on-list to respond. 5) http://xmpp.org/extensions/inbox/rayo.html Accept as Experimental? 6) http://xmpp.org/extensions/inbox/sensor-network-control.html Accept as Experimental? 7) http://xmpp.org/extensions/inbox/sensor-network-concentrators.html Accept as Experimental? All to respond on-list. 8) Next meeting. 20130424 1500 UTC. KS sends apologies, MM to chair. 9) Any other business? None. Fini.
[Standards] XMPP Council Agenda 2024-06-18
Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, June 18 2024 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * Proposed XMPP Extension: Chat notification settings (https://xmpp.org/extensions/inbox/notification-filter.html) * Proposed XMPP Extension: WebXDC (https://xmpp.org/extensions/inbox/webxdc.html) 4) Items for voting a) Proposed XMPP Extension: Chat notification settings (https://xmpp.org/extensions/inbox/notification-filter.html) b) Proposed XMPP Extension: WebXDC (https://xmpp.org/extensions/inbox/webxdc.html) c) XEP-0045: Add punctuation to improve readability (https://github.com/xsf/xeps/pull/1344) d) XEP-0153: Add missing EMAIL/USERID element in example (https://github.com/xsf/xeps/pull/1348) 5) Pending votes none See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfaRQb5Atdg/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
Re: [Standards] BOSH patches, hopefully the last before final
On 02/11/2014 03:17 AM, Peter Saint-Andre wrote: > Done: > http://xmpp.org/extensions/tmp/xep-0124-1.11.html > http://xmpp.org/extensions/diff/api/xep/0124/diff/1.10/vs/1.11rc3 > http://xmpp.org/extensions/tmp/xep-0206-1.4.html > http://xmpp.org/extensions/diff/api/xep/0206/diff/1.3/vs/1.4rc2 > > Peter Thanks a lot, Winfried
svn commit: r1404539 - /mina/site/trunk/content/vysper/
Author: elecharny Date: Thu Nov 1 10:56:31 2012 New Revision: 1404539 URL: http://svn.apache.org/viewvc?rev=1404539&view=rev Log: Reviewed and fix Vysper pages Modified: mina/site/trunk/content/vysper/extension_roadmap.mdtext mina/site/trunk/content/vysper/mailing_lists.mdtext mina/site/trunk/content/vysper/server_standalone.mdtext mina/site/trunk/content/vysper/server_to_server_comm.mdtext mina/site/trunk/content/vysper/service_discovery.mdtext mina/site/trunk/content/vysper/socks5.mdtext mina/site/trunk/content/vysper/sources.mdtext mina/site/trunk/content/vysper/standards_supported.mdtext mina/site/trunk/content/vysper/test_client.mdtext mina/site/trunk/content/vysper/user_mgmt.mdtext mina/site/trunk/content/vysper/websocket_endpoint.mdtext Modified: mina/site/trunk/content/vysper/extension_roadmap.mdtext URL: http://svn.apache.org/viewvc/mina/site/trunk/content/vysper/extension_roadmap.mdtext?rev=1404539&r1=1404538&r2=1404539&view=diff == --- mina/site/trunk/content/vysper/extension_roadmap.mdtext (original) +++ mina/site/trunk/content/vysper/extension_roadmap.mdtext Thu Nov 1 10:56:31 2012 @@ -28,81 +28,30 @@ This is not set in stone! It's just ther ## Completed - - - - http://xmpp.org/extensions/xep-0004.html"; class="external-link" rel="nofollow">XEP-0004 - Data Forms - - - http://xmpp.org/extensions/xep-0030.html"; class="external-link" rel="nofollow">XEP-0030 - Service Discovery - - - http://xmpp.org/extensions/xep-0048.html"; class="external-link" rel="nofollow">XEP-0048 - Bookmarks - - - http://xmpp.org/extensions/xep-0049.html"; class="external-link" rel="nofollow">XEP-0049 - Private XML Storage - - - http://xmpp.org/extensions/xep-0054.html"; class="external-link" rel="nofollow">XEP-0054 - vcard-temp - - - http://xmpp.org/extensions/xep-0090.html"; class="external-link" rel="nofollow">XEP-0090 - Entity Time (deprecated, see XEP-0202) - - - http://xmpp.org/extensions/xep-0092.html"; class="external-link" rel="nofollow">XEP-0092 - Software Version - - - http://xmpp.org/extensions/xep-0199.html"; class="external-link" rel="nofollow">XEP-0199 - XMPP Ping - - - http://xmpp.org/extensions/xep-0202.html"; class="external-link" rel="nofollow">XEP-0202 - Entity Time - - - +| | | +|---|---| +| [XEP-0004](http://xmpp.org/extensions/xep-0004.html) | Data Forms | +| [XEP-0030](http://xmpp.org/extensions/xep-0030.html) | [Service Discovery](service_discovery.html) | +| [XEP-0048](http://xmpp.org/extensions/xep-0048.html) | Bookmarks | +| [XEP-0049](http://xmpp.org/extensions/xep-0049.html) | Private XML Storage | +| [XEP-0054](http://xmpp.org/extensions/xep-0054.html) | vcard-temp | +| [XEP-0090](http://xmpp.org/extensions/xep-0090.html) | Entity Time (deprecated, see XEP-0202) | +| [XEP-0092](http://xmpp.org/extensions/xep-0092.html) | Software Version | +| [XEP-0199](http://xmpp.org/extensions/xep-0199.html) | XMPP Ping | +| [XEP-0202](http://xmpp.org/extensions/xep-0202.html) | Entity Time | ## In development - - - - http://ietf.org/rfc/rfc3920.txt"; class="external-link" rel="nofollow">RFC3920 - in progress, some features missing - - - http://ietf.org/rfc/rfc3921.txt"; class="external-link" rel="nofollow">RFC3921 - in progress, major features missing - - - http://xmpp.org/extensions/xep-0060.html"; class="external-link" rel="nofollow">XEP-0060 - Publish-Subscribe, fully compliant but not full featured - - - http://xmpp.org/extensions/xep-0045.html"; class="external-link" rel="nofollow">XEP-0045 -Multi-user chat - - - +| | | +|---|---| +| [RFC3920](http://ietf.org/rfc/rfc3920.txt) | in progress, some features missing | +| [RFC3921](http://ietf.org/rfc/rfc3921.txt) | in progress, major features missing | +| [XEP-0060](http://xmpp.org/extensions/xep-0060.html) | Publish-Subscribe, fully compliant but not full featured | +| [XEP-0045](http://xmpp.org/extensions/xep-0045.html) | Multi-user chat | ## Upcoming - - - - http://xmpp.org/extensions/xep-0009.html"; class="external-link" rel="nofollow">XEP-0009 - RPC - - - http://xmpp.org/extensions/xep-0077.html"; class="external-link" rel="nofollow">XEP-0077 - In-band Registration - - - +| | | +|---|---| +| [XEP-0009](http://xmpp.org/extensions/xep-0009.html) | RPC | +| [XEP-0077](http://xmpp.org/extensions/xep-0077.html) | In-band Registration | Modified: mina/site/trunk/content/vysper/mailing_lists.mdtext URL: http://svn.apache.org/viewv
[Standards] XEP announcements delay?
Dear all, Today I have received new announcements about 4 XEPs (0363/0223/0122/0373): - https://xmpp.org/extensions/xep-0363.html -> Version: 0.6.0 / Last Updated: 2018-04-21 - https://xmpp.org/extensions/xep-0223.html -> Version: 1.1 / Last Updated: 2018-03-28 - https://xmpp.org/extensions/xep-0122.html -> Version: 1.0.2 / Last Updated: 2018-03-21 - https://xmpp.org/extensions/xep-0373.html -> Version: 0.3.0 / Last Updated: 2018-04-16 Why there is a delay for announcement ? You can note that the XEP-0223 has been updated following a CVE. Thanks in advance. Regards, BOCQUET Ludovic smime.p7s Description: Signature cryptographique S/MIME ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Newsletter] The XMPP Newsletter February 2024
Posted on March 24, 2024 | 6 minutes | [Newsletter](https://xmpp.org/categories/newsletter/) | XMPP Communication Team and Contributors Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of February 2024. Many thanks to all our readers and all Newsletter contributors! Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more [at the bottom](https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#help-us-to-build-the-newsletter). XSF Announcements https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#xsf-announcements Welcome to our reapplicants and new members in Q1 2024! If you are interested to join the XMPP Standards Foundation, [please apply now](https://wiki.xmpp.org/web/Membership_Applications_Q1_2024). XMPP and Google Summer of Code 2024 https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#xmpp-and-google-summer-of-code-2024 The XSF has been accepted as a hosting organisation at GSoC in 2024 again! [If you are interested, please reach out](https://wiki.xmpp.org/web/Google_Summer_of_Code_2024)! The GSoC project ideas from XMPP-related organisations are: - Monal - [Modern Onboarding (90 hours, easy)](https://wiki.xmpp.org/web/Gsoc2024/Monal/Modern_Onboarding) - [Media Gallery (90 hours, easy)](https://wiki.xmpp.org/web/Gsoc2024/Monal/Media_Gallery) - [MDM support (175 hours, easy)](https://wiki.xmpp.org/web/Gsoc2024/Monal/MDM_support) - [SiriKit support (350 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Monal/SiriKit_support) - Dino - [Inline link preview (175 hours, easy)](https://wiki.xmpp.org/web/Gsoc2024/Dino/Inline_link_preview) - [Rich message support (175 hours, easy)](https://wiki.xmpp.org/web/Gsoc2024/Dino/Rich_message_support) - Prav.app - [Standards compliant SMS OTP based authentication (350 hours, medium)](https://wiki.xmpp.org/web/Gsoc2024/Prav.app/Standards_compliant_SMS_OTP_based_authentication) [XSF and Google Summer of Code 2024] XSF and Google Summer of Code 2024 XSF Fiscal Hosting Projects https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#xsf-fiscal-hosting-projects The XSF offers [fiscal hosting](https://xmpp.org/community/fiscalhost/) for XMPP projects. Please apply via [Open Collective](https://opencollective.com/xmpp). For more information, see the [announcement blog post](https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/). Current projects you can support: - [Mellium Co-op](https://opencollective.com/mellium) - [Prav iOS](https://opencollective.com/prav-ios) XMPP Events https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#xmpp-events - [16th May 2024: XMPP Italian happy hour](https://tube.nicfab.eu/c/xmpp) [IT]: monthly Italian XMPP web meeting, starting May 16th and then every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming). Articles https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#articles We are happy [to announce](https://www.xmpp-it.net/2024/03/03/mario/the-xmpp-it-peertube-instance/) the launch of the [XMPP-IT community’s PeerTube instance](https://video.xmpp-it.net), a dedicated platform for sharing and discovering videos about the XMPP protocol and its applications. Members of the XMPP community are encouraged to contribute by creating and sharing their own videos. Whether it’s tutorials, project showcases, or discussions on XMPP topics, your contributions are welcome. [20 years ago ejabberd was born](https://www.process-one.net/blog/ejabberd-turns-20/)! Happy birthday! [JMP turned 7 years old!](https://blog.jmp.chat/b/february-newsletter-2024) Congratulations! Read also about [mobile-friendly gateway to any SIP provider](https://blog.jmp.chat/b/mobile-friendly-sip-gateway). [SIP via XMPP] SIP via XMPP Software News https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#software-news Clients and Applications https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#clients-and-applications [monocles chat](https://play.google.com/store/apps/details?id=eu.monocles.chat) is available on Google Play. It comes with many updates like a working commands view and better support for [WebXDC](https://webxdc.org/) apps, but also an initial modern integration of stickers. Servers https://xmpp.org/2024/03/the-xmpp-newsletter-february-2024/#servers - [ejabberd 24.02](https://www.process-one.net/blog/ejabberd-24-02/) has been released, and it comes with support for TLS 1.3 and advanced SASL2 protocols. This release brings performance enhancements with Bind 2 for faster connection times, which is especially crucial for mobile network users. Support for [XEP-0424: Message Retraction](https://xmpp.org/extensions/xep-0424.html
Re: [Standards] XMPP Council Minutes 2018-03-07
As an experiment, the actions from this meeting are at https://github.com/xsf/xeps/issues/601 On 7 March 2018 at 17:47, Dave Cridland wrote: > A short reminder on Council voting: > > Council can vote on anything - while a Call For Experience is not a > "Status Change" and thus does not require a vote, Council can still > vote to ask the Editor to do one. Council members vote either +1 or 0 > (the latter is often written signed, and may indicate a leaning), or > may veto with -1. A single veto causes the motion to fail; otherwise a > majority of the Council must vote +1 for the motion to pass. > > 1) Roll Call > > All present, but as Georg arrived Dave had to leave unexpectedly, thus > Kev actually chaired. [Speaking personally, many thanks to Kev for > taking on this monster meeting at no notice] > > [ 2) Elided since the lack of a minute-taker was already noted ] > > 3) CFE for XEP-0020: Feature Negotiation > https://xmpp.org/extensions/xep-0020.html > > Kev noted the ground rules: Each of these votes has two parts - first > whether to Call For Experience before moving to Final, the second to > instead deprecate it. This one is for CFE with the intention to later > move to Final. Georg queried if this were in use anywhere and noted a > number of XEPs which reference it; Kev didn't think it was in use > anywhere in practise. > > Daniel, Georg, Kev all -1 for CFE, Sam +0 > > 4) Deprecate XEP-0020: Feature Negotiation > https://xmpp.org/extensions/xep-0020.html > > Daniel, Georg, Kev all +1 for Deprecate, Sam +0 > > 5) CFE for XEP-0048: Bookmarks > https://xmpp.org/extensions/xep-0048.html > > Kev felt this was premature while the ongoing 49/223 mismatch quesiton > isn't answered - Georg agreed this was the elephant in the room. Sam > felt that a CFE might draw out more feedback. Georg agreed that a CFE, > with an additional note about '49, might do the trick. > > Georg, Daniel, Sam +1 for CFE, Kev 0. > > 6) Deprecate XEP-0048: Bookmarks > https://xmpp.org/extensions/xep-0048.html > > All present -1. > > Kev noted at this point that he would assume anyone +1 for a CFE would > be -1 on the Deprecate, to which Georg agreed and nobody dissented. > > 7) CFE for XEP-0059: Result Set Management > https://xmpp.org/extensions/xep-0059.html > > Georg and Kev both raised the current MAM discussion, and felt that we > should resolve that prior to a CFE. > > Georg, Kev -1, Sam Daniel +1 > > 8) Deprecate XEP-0059: Result Set Management > https://xmpp.org/extensions/xep-0059.html > > All present -1 > > ** Stalemate ** > > 9) CFE for XEP-0066: Out of Band Data > https://xmpp.org/extensions/xep-0066.html > > Daniel asked what this was actually used for, and Georg replied it was > used for inline images in conversations, and suggested it might be > harvested for good parts. Kev opined that the CFE might be interesting > on this one. > > All present +1 > > 10) Deprecate XEP-0066: Out of Band Data > > https://xmpp.org/extensions/xep-0066.html > > All present -1 > > 11) CFE for XEP-0072: SOAP Over XMPP > https://xmpp.org/extensions/xep-0072.html > > Kev suggested that a CFE might make it obvious whether deprecation was > the right option. > > Sam -1, Georg, Kev, Daniel +1 > > 12) Deprecate XEP-0072: SOAP Over XMPP > https://xmpp.org/extensions/xep-0072.html > > Georg, Daniel, Kev -1, Sam +1 > > ** Stalemate ** > > 13) CFE for XEP-0079: Advanced Message Processing > https://xmpp.org/extensions/xep-0079.html > > Kev +1, Daniel, Georg, +0, Sam -0 > > (Some question, here, over voting practises regarding CFE - note above > that the Council may vote on anything). > > 14) Deprecate XEP-0079: Advanced Message Processing > https://xmpp.org/extensions/xep-0079.html > > Kev felt that '79 needed some discussion in the community first, even > if this were not a formal CFE. > > Daniel, Georg, and Kev -1, Sam +1. > > 15) CFE for XEP-0092: Software Version > https://xmpp.org/extensions/xep-0092.html > > All present +1 > > 16) Deprecate XEP-0092: Software Version > https://xmpp.org/extensions/xep-0092.html > > All present -1 > > 17) CFE for XEP-0122: Data Forms Validation > https://xmpp.org/extensions/xep-0122.html > > Georg, Daniel, Kev +1, Sam +0 > > 18) Deprecate XEP-0122: Data Forms Validation > https://xmpp.org/extensions/xep-0122.html > > Kev, Daniel, Georg -1, Sam +1 > > 19) CFE for XEP-0131: Stanza Headers and Internet Metadata > https://xmpp.org/extensions/xep-0131.html > > Georg, Daniel, Kev +1, Sam +0 > > 20) Deprecate XEP-0131: Stanza Headers and Internet Metadata > https://xm
Re: [Standards] finishing the file transfer suite
On 2/14/11 4:22 PM, Peter Saint-Andre wrote: > In Brussels last weekend we had some good discussions about file > transfer. I'd like to see us stabilize this suite of specs in 2011, and > the XMPP Council agreed when it discussed priorities and roadmap a month > or two ago. Here is where I think we stand (I've listed these roughly in > the order I think makes sense for completing the work): Here's a quick update... > 1. XEP-0047: In-Band Bytestreams >http://xmpp.org/extensions/xep-0047.html > > Version 1.3rc2 is at http://xmpp.org/extensions/tmp/xep-0047-1.3.html Done. > 2. XEP-0261: Jingle In-Band Bytestreams Transport Method >http://xmpp.org/extensions/xep-0261.html > > Are there any open issues with this one? Last Call in progress, ending on March 31. > 3. XEP-0065: SOCKS5 Bytestreams >http://xmpp.org/extensions/xep-0065.html > > Version 1.8rc3 is at http://xmpp.org/extensions/tmp/xep-0065-1.8.html I've asked the XMPP Council to approve that version. > 4. XEP-0260: Jingle SOCKS5 Bytestreams Transport Method >http://xmpp.org/extensions/xep-0260.html > > Are there any open issues with this one? I had a change to look at that document a few days ago and I think it's missing some details about the interaction with XEP-0065. However, I won't have time to work on this until early April. > 5. XEP-0234: Jingle File Transfer >http://xmpp.org/extensions/xep-0234.html I haven't looked at that one yet. > 6. XEP-0264: File Transfer Thumbnails >http://xmpp.org/extensions/xep-0264.html Not yet on my radar screen... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] XMPP for graphical collaborative environment
On Jun 05, 2009, at 14:35, Nicolas Vérité wrote: Maybe these (non-yet XSF) specs can help you get some inspiration? XEP-: Multi-User Collaboration http://xmpp.org/extensions/inbox/mucol.html XEP-: Shared XML Document Editing http://xmpp.org/extensions/inbox/sxde.html XEP-: Shared XML Editing http://xmpp.org/extensions/inbox/sxe.html JEP-: An SVG Based Whiteboard Format http://xmpp.org/extensions/inbox/whiteboard.html XEP-: Whiteboard http://xmpp.org/extensions/inbox/whiteboard2.html This might also be relevant: http://code.google.com/apis/wave/guide.html It's more about text sharing, but the basic idea is pretty much the same. andy ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [Standards] [Council] 2016-11-23 Council Meeting Minutes
On Thu, Nov 24, 2016 at 7:22 AM, Tobias Markmann wrote: > ## 5a) https://xmpp.org/extensions/inbox/burner.html Abstain. > ## 5b) https://xmpp.org/extensions/inbox/omemo.html +1 > ## 5c) https://xmpp.org/extensions/inbox/omemo-filetransfer.html Waiting on this one since I think it was being withdrawn? > ## 5d) https://xmpp.org/extensions/inbox/spoiler.html +1 > ## 6a) https://github.com/xsf/xeps/pull/204 +1 > ## 6b) https://github.com/xsf/xeps/pull/263 +1 > ## 6c) https://github.com/xsf/xeps/pull/267 +1 > ## 6d) https://github.com/xsf/xeps/pull/232 +1 (although I think the wording could use some work before this is merged) —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Re: Proposed XMPP Extension: PubSub Server Information
Dear Editor, Council has voted to accept this XEP. cheers Daniel On Mon, Jan 22, 2024 at 3:56 PM wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: PubSub Server Information > Abstract: > This document defines a data format whereby basic information of an > XMPP domain can be expressed and exposed over pub-sub. > > URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
Re: [Standards] NEW: XEP-0449 (Stickers)
This refers to two XEPs in inbox that are 404ing: 2. XEP-: File metadata element < https://xmpp.org/extensions/inbox/file-metadata.html>. (apparently now XEP-0446) 4. XEP-: Stateless file sharing < https://xmpp.org/extensions/inbox/sfs.html>. (apparently now XEP-0447) I suppose the text just needs updating? On Tue, Nov 24, 2020 at 6:16 PM Jonas Schäfer wrote: > Version 0.1.0 of XEP-0449 (Stickers) has been released. > > Abstract: > This specification provides a protocol to send stickers and to create > and share sticker packs. > > Changelog: > Accepted by vote of Council on 2020-11-18. (XEP Editor (jsc)) > > URL: https://xmpp.org/extensions/xep-0449.html > > Note: The information in the XEP list at https://xmpp.org/extensions/ > is updated by a separate automated process and may be stale at the > time this email is sent. The XEP documents linked herein are up-to- > date. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2024-08-27
Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 27 2024 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * UPDATED: XEP-0045 (Multi-User Chat) * UPDATED: XEP-0388 (Extensible SASL Profile) * Proposed XMPP Extension: OAuth Client Login (https://xmpp.org/extensions/inbox/xep-oauth-client-login.html) * Proposed XMPP Extension: Client Access Management (https://xmpp.org/extensions/inbox/xep-client-access-management.html) 4) Items for voting a) Proposed XMPP Extension: OAuth Client Login https://xmpp.org/extensions/inbox/xep-oauth-client-login.html b) Proposed XMPP Extension: Client Access Management https://xmpp.org/extensions/inbox/xep-client-access-management.html c) XEP-0045: Add explicit error definition when non-owners attempt to use owner-specific functionality https://github.com/xsf/xeps/pull/1370 5) Pending votes None See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfaRQb5Atdg/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Newsletter] The XMPP Newsletter November 2023
[The XMPP Newsletter November 2023](https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/) Posted on December 10, 2023 | 8 minutes | [Newsletter](https://xmpp.org/categories/newsletter/) | XMPP Communication Team and Contributors Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of November 2023 and will be the last publication for 2023. Many thanks to all our readers and all contributors! Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more [at the bottom](https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#help-us-to-build-the-newsletter). XSF Announcments https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#xsf-announcments New XSF Board and Council https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#new-xsf-board-and-council The XSF members have [voted for a new XSF Board and XSF Council](https://wiki.xmpp.org/web/Meeting-Minutes-2023-11-23). Congratulations to the new Board members Nicola Fabiano, Edward Maurer, Ralph Meijer, Peter Saint-Andre and Matthew Wild. And congratulations to the new Council members Travis Burtrum, Dan Caseley, Daniel Gultsch, Stephen Paul Weber and Marvin Wissfeld. Please welcome the members to their [new or continuing role](https://xmpp.org/about/xmpp-standards-foundation/)! XMPP Summit 26 & FOSDEM 2024 https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#xmpp-summit-26--fosdem-2024 The XSF is planning the XMPP Summit 26, which is to take place on February 1st & 2nd 2024 in Brussels (Belgium, Europe). Following the Summit, the XSF is also planning to be present at FOSDEM 2024, which takes place on February 3rd & 4th 2024. Find all the details in our [Wiki](https://wiki.xmpp.org/web/Conferences/Summit_26). Please sign-up now if you are planning to attend, since this helps organizing. The event is of course open for everyone interested to participate. [Spread the word](https://fosstodon.org/@xmpp/11131312372184) within your circles! XMPP and Google Summer of Code 2023 https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#xmpp-and-google-summer-of-code-2023 The XSF [has been a hosting organisation at GSoC in 2023 again, and manages two successful slots for XMPP Contributors](https://xmpp.org/2023/02/xmpp-at-google-summer-of-code-2023/). Find the projects for [“Windows Support for Dino”](https://summerofcode.withgoogle.com/programs/2023/projects/ygGSIiHc) and [“Implement group chats in Moxxy”](https://summerofcode.withgoogle.com/programs/2023/projects/UK3oE0f9). We are planning to participate the next year. The time to reach out to the XMPP community is now :-) XSF Fiscal Hosting Projects https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#xsf-fiscal-hosting-projects The XSF offers [fiscal hosting](https://xmpp.org/community/fiscalhost/) for XMPP projects. Please apply via [Open Collective](https://opencollective.com/xmpp). For more information, see the [announcement blog post](https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/). Current projects: - [Mellium Co-op](https://opencollective.com/mellium) XMPP Events https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#xmpp-events - [Berlin XMPP Meetup (remote)](https://mov.im/?node/pubsub.movim.eu/berlin-xmpp-meetup): monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month - [XMPP Italian happy hour](https://tube.nicfab.eu/c/xmpp): monthly Italian XMPP web meeting, starting May 16th and then every third Tuesday of the month at 7:00 PM (online event, with web meeting mode and live streaming). Talks https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#talks - XMPP Italian Happy Hour Podcast: Dive into the world of XMPP with the Italian Happy Hour podcast, a monthly event derived from recorded video sessions. Each episode is dedicated to the XMPP protocol, offering insights and discussions from enthusiasts and professionals within the community. Whether you’re commuting, working out, or simply seeking to listen to interesting conversation, this podcast delivers the essence of Italian XMPP gatherings directly to your ears. Tune in at XMPP Italian Happy Hour Podcast or subscribe to the RSS feed to never miss an episode. Find the [link to podcast](https://open.audio/channels/xmpphappyhour/) and the [link to RSS feed to subscribe the podcast](https://open.audio/api/v1/channels/xmpphappyhour/rss). Plus, join the conversation and keep up with updates by following the podcast page in the Fediverse: @xmpphappyhour@open.audio. The podcast is in Italian but but there may be contributions in English. Articles https://xmpp.org/2023/12/the-xmpp-newsletter-november-2023/#articles - [Au
[Git][gajim/gajim][master] DOAP: Add XEPs 0080, 0082, and 0224
Philipp Hörist pushed to branch master at gajim / gajim Commits: 8265ffb5 by Daniel Brötzmann at 2020-06-27T10:35:06+02:00 DOAP: Add XEPs 0080, 0082, and 0224 - - - - - 1 changed file: - data/gajim.doap Changes: = data/gajim.doap = @@ -179,6 +179,20 @@ 2.4 + + +https://xmpp.org/extensions/xep-0080.html"; /> +complete +1.9 + + + + +https://xmpp.org/extensions/xep-0082.html"; /> +complete +1.1 + + https://xmpp.org/extensions/xep-0084.html"; /> @@ -401,6 +415,13 @@ 1.1 + + +https://xmpp.org/extensions/xep-0224.html"; /> +complete +1.0 + + https://xmpp.org/extensions/xep-0231.html"; /> View it on GitLab: https://dev.gajim.org/gajim/gajim/-/commit/8265ffb5c8532a71221dfc1d17093f1be2b2def4 -- View it on GitLab: https://dev.gajim.org/gajim/gajim/-/commit/8265ffb5c8532a71221dfc1d17093f1be2b2def4 You're receiving this email because of your account on dev.gajim.org. ___ Commits mailing list Commits@gajim.org https://lists.gajim.org/cgi-bin/listinfo/commits
Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)
On 2012-07-16 19:58, Mark Rejhon wrote: I want to comment that XEP-0276 only allows mentioning "media" or "text" as the reason, and not both. XEP-0276 needs to be updated to permit a single mechanism activating all three features simultaneously (audio, video, real-time text). This might be complicated by using separate, concurrent negotiation mechanisms for out-of-band mechanisms (audio, video) and in-band mechanisms (RTT). Even several of you agreed that Jingle is overkill for RTT. It's assumed that clients could detect multiple authentication mechanisms that happens within a short period of time to each other, and an implementation can merge them into a single confirmation message, for potential future XMPP-based "Total Conversation"-compliant software clients. I also see a great potential in XEP-0276 to make ad-hoc calls to parties not known in beforehand, e.g. sip adresses. But on the SIP side there are at least the following media: video, (Through RTP) audio (Through RTP) real-time text ( through RTP RFC 4103) message text ( Through SIP Message or MSRP, or maybe even some XMPP coexistence protocol) on the XMPP side, there are the following media: video ( through Jingle) audio (through Jingle) real-time text ( XEP-0301 in-line, or maybe even RTP based through Jingle ) message text ( plain XMPP, HTML, etc as already specified ) Of these, I think only SIP Message cause real problems , because it does not really have any reliable capability declaration. More thoughts: Are there other features we would like to know of that need representation in the reason element? Location? Multi-user chat? Camera control? Encryption of media? Thus, I agree with Mark that there is a need for a more simultaneous reasons in the element. I do not know if it is sufficient to just extend to allow multiple values, or some more flexible way of coding the and the answer values are needed. seems to be an optional parameter. I guess that that means that the answer may contain presence information outside of what was requested in the element. If that interpretation is right, we can start developing an application behavior responding with all media of possible interest until a version with proper coding of multiple values is published. Modification proposal to section 6: 6.The reason Attibute To signal the type of communication that is desired, the entity that first shares session presence MAY include a 'reason' attribute on the element. Multiple values are allowed. The following values for the 'reason' attribute are defined: *video* Presence is requested for video medium of a call party, e.g. viaJingle RTP Sessions <http://xmpp.org/extensions/xep-0167.html>[8 <http://xmpp.org/extensions/xep-0276.html#nt-id337164>]. *audio* Presence is requested for audio medium of a call party, e.g. viaJingle RTP Sessions <http://xmpp.org/extensions/xep-0167.html>[8 <http://xmpp.org/extensions/xep-0276.html#nt-id337164>]. ** *real-time-text* Presence is requested for a real-time text conversation using a medium of the call party or an extension that requires real-time text capabilities to be disclosed, such asIn-Band Real Time Text <http://xmpp.org/extensions/xep-0301.html>[11 <http://xmpp.org/extensions/xep-0276.html#nt-id343682>], or Jingle RTP Sessions <http://xmpp.org/extensions/xep-0167.html>[8 <http://xmpp.org/extensions/xep-0276.html#nt-id337164>] or real-time text capabilities beyond a gateway. *message-text* Presence is requested for a text communication using a message medium of the call party or an extension that requires text message capabilities to be disclosed, such asXHTML-IM <http://xmpp.org/extensions/xep-0071.html>[9 <http://xmpp.org/extensions/xep-0276.html#nt-id343644>],Chat State Notifications <http://xmpp.org/extensions/xep-0085.html>[10 <http://xmpp.org/extensions/xep-0276.html#nt-id343663>],or text message capabilities beyond a gateway. ***file* Presence is requested for one or more file transfers, e.g. viaJingle File Transfer <http://xmpp.org/extensions/xep-0234.html>[12 <http://xmpp.org/extensions/xep-0276.html#nt-id343702>] orStream Initiation <http://xmpp.org/extensions/xep-0095.html>[13 <http://xmpp.org/extensions/xep-0276.html#nt-id343721>]. Inclusion of the 'reason' attribute can be interpreted by the receiving client as a signal that communication is about to start; for instance, a call accept/reject dialog could double as a UI for accepting or rejecting a session presence request. Answers should include details about the presence, such as supported codecs, and parameters, and encryption capabilities. - I am aware that there are gaps and complexities in this definition, and hope that others can contribute to refining it. . /Gunnar
Re: [Standards] Proposed XMPP Extension: Commenting
Stephan Maka wrote: > [...] if we had a URI scheme for referencing individual items [...] > > xmpp:comments.example.com?pubsub;node=coffeetalk/comments;item=0f72afbe-a9d4-11e0-b0bc-0024bed71c0a Actually, it is specified like that by XEP-0060[1,2] but was just missing in the Querytype registry[3]. Mail to regist...@xmpp.org sent. Stephan [1] http://xmpp.org/extensions/xep-0060.html#impl-uri [2] http://xmpp.org/extensions/xep-0060.html#registrar-querytypes [3] http://xmpp.org/registrar/querytypes.xml
Re: [Operators] Public XMPP Services list
I would be willing to help or write some code to automate the page. Is that an option? Our XMPP testing tool could be adapted to perform those tests: http://xmpp.org/services/verify.shtml On Mon, Feb 22, 2010 at 9:49 AM, Mihael Pranjić wrote: > On 2010-02-22 18:44, Nicolas Vérité wrote: > > On Mon, Feb 22, 2010 at 18:33, Peter Saint-Andre > wrote: > >> On 2/22/10 10:17 AM, Nicolas Vérité wrote: > >>> On Mon, Feb 22, 2010 at 18:15, Peter Saint-Andre > wrote: > >>>> On 2/22/10 10:14 AM, Tomasz Sterna wrote: > >>>>> What is the usual update time of http://xmpp.org/services/ ? > >>>>> iee. How long would I wait for the submitted service to appear on > this > >>>>> list? > >>>> > >>>> Forever. > >>> > >>> Bad answer... ;-) > >> > >> I've been doing this with Florian Thiessen. We might need more > >> assistance, because we're too slow. > >> > >>>> Who wants to help with this? > >>> > >>> What's the workload? > >> > >> We do this: > >> > >> http://xmpp.org/services/verify.shtml > >> > >> Given that we have only a few requests a month, the workload is not that > >> significant. > > > > If two other people do this with me, I'd be glad to take over. > > I could join you :) > > > In order to be listed here: http://xmpp.org/services/ > > An operator should do the following: > http://xmpp.org/services/register.shtml > > And then we should do this: http://xmpp.org/services/verify.shtml > > But then who commits back to: http://xmpp.org/services/ ? > > > > Btw, jabber.org needs a refresh, admins? > > >
Re: separate login/password for several services?
Andrew Findlay wrote: > > lets say I have two users with name John and I need to give each one > > acces to some service, but both of them wish the service uid=john (for > > example, it is common issue for MTA serving different mail domains with > > different user space for each one) > > The first question to ask is how the application is going to tell the > difference between the two users when someone tries to login as 'john'. > > If the users are j...@a.b.com and j...@x.y.org then why not use the > full mail address as the uid? > yes, it is what I was thought about too and I like the idea, though I wanted to check how correct/right is this way > > so what is needed to provide uniqueness of attribute `uid' for each > > dn: authorizedService=target-service,uid=target-user,ou=People,dc=org perhaps I need to define more accurately what I mean: the uniqueness while *creating* the dn ... since for dn-s dn: authorizedService=target-service,uid=target-user1,ou=People,dc=org dn: authorizedService=target-service,uid=target-user2,ou=People,dc=org ... dn: authorizedService=target-service,uid=target-userN,ou=People,dc=org I want to prevent the possibility to create the same uid=john-whatever-format-it-is now I do can ldapadd these ldif-s successfully ---[ ldif ]---- dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org cn: john....@xmpp.org sn: xmpp.org description: John Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org authorizedService: xmpp.org cn: john.sm...@xmpp.org sn: xmpp.org description: John Smith XMPP account at xmpp.org uidNumber: 12356 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john ---[ ldif ]---- and ldapsearch ... "(&(uid=john)(authorizedService=xmpp.org))" outputs both of them, so I need the way I can know that uid: is not unique while creating the dn: so, what I need to prevent the possibility to create the second dn:, since it will contain the same uid value as the first one? > If each 'john' account exists in a distinct identifiable namespace then > you could either put the name of the namespace in the account entry or > you could use it as part of the LDAP hierachy. The application can > then formulate a search that finds the correct entry in one operation. I was thinking to use sn: attribute since it is login dedicated dn: and it is no need in it but all the same, my question remains oppened: how to not to create not unique uid for dn: authorizedService=target-service,uid= ? have I put in into UI for records management or it can be done on the server side (for example like indexes in SQL) -- Zeus V. Panchenko jid:z...@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
Re: [Standards] 2016-11-23 Council Meeting Minutes
On Thu, Nov 24, 2016 at 2:22 PM, Tobias Markmann wrote: > ## 5) There are a couple outstanding XEP submissions that need revoting. > > Votes are taken to the list. > > ## 5a) https://xmpp.org/extensions/inbox/burner.html > +1 > > ## 5b) https://xmpp.org/extensions/inbox/omemo.html > +1 > > ## 5c) https://xmpp.org/extensions/inbox/omemo-filetransfer.html > +1. If Daniel doesn't want it published in this state he can still veto it. > > ## 5d) https://xmpp.org/extensions/inbox/spoiler.html > +1 > > ## 6) There are a couple outstanding pull requests that need revoting too. > > ## 6a) https://github.com/xsf/xeps/pull/204 > +1 > > ## 6b) https://github.com/xsf/xeps/pull/263 > +1 > > ## 6c) https://github.com/xsf/xeps/pull/267 > +1 > > ## 6d) https://github.com/xsf/xeps/pull/232 > +1 Cheers, Tobi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0060: PubSub events with multiple "item" and "retract" elements
Hi,
I am wondering why the XML schema for PubSub events (
https://xmpp.org/extensions/xep-0060.html#schemas-event) specifies that
the "items" element of events may contain multiple "item" and "retract"
elements:
While
https://xmpp.org/extensions/xep-0060.html#publisher-publish-request
and https://xmpp.org/extensions/xep-0060.html#publisher-delete-request
specify that it is not allowed to publish multiple items,
https://xmpp.org/extensions/xep-0060.html#impl-batch allows that
explicitly.
I could imagine an event containing multiple items triggered after such
a batch processing or if the server caches multiple single item
publications before sending an event notification. But if that should
be possible and handled by clients, where is that specified?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Operators] Public XMPP Services list
On 2010-02-22 18:44, Nicolas Vérité wrote: > On Mon, Feb 22, 2010 at 18:33, Peter Saint-Andre wrote: >> On 2/22/10 10:17 AM, Nicolas Vérité wrote: >>> On Mon, Feb 22, 2010 at 18:15, Peter Saint-Andre wrote: >>>> On 2/22/10 10:14 AM, Tomasz Sterna wrote: >>>>> What is the usual update time of http://xmpp.org/services/ ? >>>>> iee. How long would I wait for the submitted service to appear on this >>>>> list? >>>> >>>> Forever. >>> >>> Bad answer... ;-) >> >> I've been doing this with Florian Thiessen. We might need more >> assistance, because we're too slow. >> >>>> Who wants to help with this? >>> >>> What's the workload? >> >> We do this: >> >> http://xmpp.org/services/verify.shtml >> >> Given that we have only a few requests a month, the workload is not that >> significant. > > If two other people do this with me, I'd be glad to take over. I could join you :) > In order to be listed here: http://xmpp.org/services/ > An operator should do the following: http://xmpp.org/services/register.shtml > And then we should do this: http://xmpp.org/services/verify.shtml > But then who commits back to: http://xmpp.org/services/ ? > > Btw, jabber.org needs a refresh, admins?
Re: [Standards] XMPP Council Meeting 2018-09-05
On Fri, Sep 7, 2018, at 09:31, Tedd Sterr wrote: > 2a) MUC Avatars -- https://xmpp.org/extensions/inbox/muc-avatars.html > … > Sam: [on-list] (hesitant to publish this, but it seems fine protocol-wise) -1 I'm torn on this one; it's a great protoxep. Giving rooms their own avatar is important, and having an XEP detail how it's done will help push clients and servers to implement this. I also don't think we need another XEP about avatars. - https://xmpp.org/extensions/xep-0054.html - https://xmpp.org/extensions/xep-0084.html - https://xmpp.org/extensions/xep-0153.html - https://xmpp.org/extensions/inbox/muc-avatars.html That's a lot of avatars with no clear guidance from the community what new client authors should focus their efforts on. Until we get this under control, we should be very careful about publishing any new avatar related specs. In this particular case, I'd very much like to see us discuss the correct solution and add a note to one of the existing XEPs. Since this protoxep doesn't do anything beyond what is already possible using vCard or vcard-temp. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Fwd: [Council] Minutes 2010-06-14
FYI -- Forwarded message -- From: Kevin Smith Date: Wed, Jun 16, 2010 at 9:27 AM Subject: Minutes 2010-06-14 To: XMPP Council 1) Roll call All present 2) Agenda bashing. None 3) XEP-0124: BOSH http://xmpp.org/extensions/tmp/xep-0124-1.10.html Diff: http://xmpp.org/extensions/diff/api/xep/0124/diff/1.9/vs/1.10rc1 Accept new version? Ralph and Matt +1, Kev, Remko and Nathan to vote on-list before 28th June. 4) XEP-0206: XMPP Over BOSH http://xmpp.org/extensions/tmp/xep-0206-1.3.html Diff: http://xmpp.org/extensions/diff/api/xep/0206/diff/1.2/vs/1.3rc1 Accept new version? Ralph and Matt +1, Kev, Remko and Nathan to vote on-list before 28th June. 5) http://xmpp.org/extensions/inbox/sxe.html Accept as Experimental? Ralph strongly in favour, everyone else has until 28th June to object. Matt comments possible ovelap with http://infinote.org/ 6) http://xmpp.org/extensions/inbox/moved.html Accept as Experimental. All in favour. Nathan, Kevin, Matt and Ralph commented that changes were needed. Feedback to come on-list. 7) Date of next meeting June 21st, 1800GMT 8) Any other business None
[Standards] XMPP Council Agenda 2023-12-12
Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, December 12 2023 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - UPDATED: XEP-0198 Stream Management - UPDATED: XEP-0402 PEP Native Bookmarks - UPDATED: XEP-0458 Community Code of Conduct - UPDATED: XEP-0474 SASL SCRAM Downgrade Protection - NEW: XEP-0483 HTTP Online Meetings (https://xmpp.org/extensions/xep-0483.html) - NEW: XEP-0484 Fast Authentication Streamlining Tokens (https://xmpp.org/extensions/xep-0484.html) - Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All (https://xmpp.org/extensions/inbox/host-meta-2.html) 4) Items for voting a) XEP-0077: Specify account creation via HTTP as non-exclusive alternative to XMPP (https://github.com/xsf/xeps/pull/1299) b) Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All (https://xmpp.org/extensions/inbox/host-meta-2.html) 5) Pending votes none See the all new spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfaRQb5Atdg/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] upcoming XEP deferrals
A number of XEPs are due to be deferred in the next 4-5 weeks. Here is my take... 1. XEP-0215: External Service Discovery http://xmpp.org/extensions/xep-0215.html I still find this interesting, but we've never received much feedback on it. Thoughts? 2. XEP-0232: Software Information http://xmpp.org/extensions/xep-0232.html I think this is dead in the water, given how strongly Council members and others resisted it last time. However, be aware that people still want this feature, and will use XEP-0092 instead forever. 3. XEP-0234: Jingle File Transfer http://xmpp.org/extensions/xep-0234.html I've been meaning to review this one again soon. We need to move this to draft along with the rest of the file transfer stack. 4. XEP-0247: Jingle XML Streams http://xmpp.org/extensions/xep-0247.html IMHO we don't need this one any longer, so it can lapse without issue. 5. XEP-0257: Client Certificate Management for SASL EXTERNAL http://xmpp.org/extensions/xep-0257.html I'll ping Dirk Meyer about this one. 6. XEP-0259: Message Mine-ing http://xmpp.org/extensions/xep-0259.html The author has some updates on the way. 7. XEP-0261: Jingle In-Band Bytestreams Transport Method http://xmpp.org/extensions/xep-0261.html This one goes along with XEP-0234. Reviews would be appreciated. 8. XEP-0262: Use of ZRTP in Jingle RTP Sessions http://xmpp.org/extensions/xep-0262.html This one depends on draft-zimmermann-avt-zrtp (a new version was published a few days ago). I'll ping the author of that I-D to find out whether he thinks it will move forward soon. I don't think any changes to XEP-0262 are needed. Feedback is welcome as always. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] 2016-11-23 Council Meeting Minutes
# 2016-11-23 Council Meeting Logs: http://logs.xmpp.org/council/2016-11-23/#16:16:03 ## 0) Role call - Tobias (charining) - Daniel - Dave - Sam - Link Mauve ## 1) Minute taker Tobias recommended a round robin approach, based on that the minutes can be constructed from the chat logs (which I'm doing right now). Daniel thinks its a fair approach. Dave and Sam mention, that ideally it would be a life minute taker outside of the council, so they can directly ask questions if something is unclear. If there are any volunteers in the XMPP community who want to do this, please let us know. ## 2) Voting on accepting https://xmpp.org/extensions/inbox/iot-sig.html This was already accepted. It has been published by now at http://xmpp.org/extensions/xep-0381.html . ## 3) Recommendation for Council representative in IoT SIG Dave volunteered as a backstop. psa can commit to this and states that he has an IoT interest nowadays. Everyone is in favour of recommending psa as Council representative in the IoT SIG. ## 4) Reminder to send updated Bios for the website to the list. Please send a short bio to the Council ML or open a PR against https://github.com/xsf/xmpp.org/blob/master/content/pages/about/xmpp-standards-foundation.md ## 5) There are a couple outstanding XEP submissions that need revoting. Votes are taken to the list. ## 5a) https://xmpp.org/extensions/inbox/burner.html ## 5b) https://xmpp.org/extensions/inbox/omemo.html ## 5c) https://xmpp.org/extensions/inbox/omemo-filetransfer.html ## 5d) https://xmpp.org/extensions/inbox/spoiler.html ## 6) There are a couple outstanding pull requests that need revoting too. ## 6a) https://github.com/xsf/xeps/pull/204 ## 6b) https://github.com/xsf/xeps/pull/263 ## 6c) https://github.com/xsf/xeps/pull/267 ## 6d) https://github.com/xsf/xeps/pull/232 ## 7) AOB psa is going to try try try to finish work on the Jingle specs by the end of the year. EOM ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC: Make projects publish a DOAP file to get listed at xmpp.org
> DOAP is a project to create an XML/RDF vocabulary to describe software > projects This already sounds too complicated to be worth it to me. I would not want to require this of software devs to have their software listed personally. —Sam On Sun, Aug 20, 2017, at 23:08, Emmanuel Gil Peyrot wrote: > Hi, > > For quite a long time I’ve been trying to design a format that would > describe XMPP software, while being useful to most (all?) consumers of > this document, be it simple client listings like at xmpp.org, wikis > about projects wanting to stay up to date, feature matrices comparing > multiple implementations, or even authors who’d like to know who > implemented their specifications. > > Attached are an example of an XMPP software (poezio, a client), and of > a consumer (xmpp.org, a simple website). > > The format itself still has a lot of TODOs, most of which have been > reported to the DOAP project[1], while the XMPP specific parts still > lack a schema entirely. > > The consumer Python script parses the file quite defensively, and then > generates the HTML you could have seen on xmpp.org (for the clients > page[1] and for a XEP page[2]). The XEP page would require some > changes to the way XEPs are processed, since it generates the change > log itself, inserting implementations there. Another way would be to > generate JavaScript code that would insert the DOM nodes at runtime. > > There is also still the issue of having a place where all of these DOAP > URIs would be linked from, I think xmpp.org could act as such even for > projects unlisted from the main pages, but this remains to be decided. > > Please tell me whether you think it is a good idea, whether you would > integrate it with your website/wiki/feature matrix/other, and any > improvement you could think of! > > Thanks, > > [1] https://github.com/ewilderj/doap/issues > [2] https://xmpp.org/software/clients.html > [3] https://xmpp.org/extensions/xep-0380.html > > -- > Emmanuel Gil Peyrot > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > Email had 3 attachments: > + poezio.xml > 14k (application/xml) > + parser.py > 8k (text/x-python) > + signature.asc > 1k (application/pgp-signature) -- Sam Whited s...@samwhited.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0333 (Chat Markers)
Hi Manuel, XEP-0333 Chat Markers are sent by clients, not servers. They are also typically sent to all clients that participate in the conversation (i.e. the recipient, other devices through carbons, participants in a MUC, ...) and for all of them except the sending device such `sent` marker would be useless as the fact that the message was sent is already expressed through them receiving it. If you want servers to ack messages through some means other than stream management, it should be independent from XEP-0333. IIRC there already are proprietary standard extension(s) for this. Marvin On 13.10.20 10:35, Manuel Rubio wrote: > Hi, > > Yes, but I want something more explicit and don't linked to stream > management. > > Kind regards, > Manuel Rubio. > >> El 13 oct 2020, a las 6:33, Philipp Hörist escribió: >> >> >> Hi, >> >> You know that anyway because of stream management acks and if you >> received no error. >> >> Regards >> >> Am Di., 13. Okt. 2020 um 03:41 Uhr schrieb Manuel Rubio >> mailto:man...@altenwald.com>>: >> >> Hi, >> >> sorry to get this message too old from the list but I wanted to >> ask if >> it's possible to add "sent" to the list of markers. >> >> The "sent" will be very useful when a message is sent, the server >> replies directly to the user with a "sent" marker and then we know >> the >> server has the message. >> >> Kind regards, >> Manuel Rubio. >> >> El 2020-04-21 12:43, p...@bouah.net <mailto:p...@bouah.net> escribió: >> > Version 0.4 of XEP-0333 (Chat Markers) has been released. >> > >> > Abstract: >> > This specification describes a solution of marking the last >> received, >> > displayed and acknowledged message in a chat. >> > >> > Changelog: >> > Add notes about usage within MUCs. (mw) >> > >> > URL: https://xmpp.org/extensions/xep-0333.html >> > >> > Note: The information in the XEP list at >> https://xmpp.org/extensions/ >> > is updated by a separate automated process and may be stale at the >> > time this email is sent. The XEP documents linked herein are up-to- >> > date. >> > ___ >> > Standards mailing list >> > Info: https://mail.jabber.org/mailman/listinfo/standards >> > Unsubscribe: standards-unsubscr...@xmpp.org >> <mailto:standards-unsubscr...@xmpp.org> >> > ___ >> ___ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> <mailto:standards-unsubscr...@xmpp.org> >> ___ >> >> ___ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> ___ > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [Fwd: [Council] meeting minutes, 2009-08-05]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI. - Original Message Subject: [Council] meeting minutes, 2009-08-05 Date: Wed, 05 Aug 2009 14:00:11 -0600 From: Peter Saint-Andre Reply-To: XMPP Council To: XMPP Council Results of the XMPP Council meeting held 2009-08-05... Agenda: http://mail.jabber.org/pipermail/council/2009-August/002594.html Log: http://logs.jabber.org/coun...@conference.jabber.org/2009-08-05.html Scribe: Peter Saint-Andre 0. Roll call Present: Ralph Meijer, Jack Moffitt (late but voted on most items), Peter Saint-Andre, Kevin Smith. Absent: Dave Cridland (with regrets). Quorum achieved. 1. Agenda bashing None. 2. PubSub specs XEP-0060 and XEP-0163 are in an interim state to incorporate discussions at XMPP Summit 6 (Brussels) and various list feedback: http://xmpp.org/extensions/tmp/xep-0060-1.13.html http://xmpp.org/extensions/tmp/xep-0163-1.2.html Peter to post to the standards@ list regarding status. 3. XEP-0136: Message Archiving http://xmpp.org/extensions/tmp/xep-0136-1.1.html is seemingly done, but Peter will ping the implementers on the standards@ list to be sure. 4. XEP-0175: Best Practices for Use of SASL ANONYMOUS http://xmpp.org/extensions/tmp/xep-0175-1.2.html incorporates feedback from the standards@ list. Ralph, Peter, and Kev +1. Jack and Dave to post to the council@ list. 5. XEP-0220: Server Dialback No objections to making http://xmpp.org/extensions/tmp/xep-0220-0.4.html the official 0.4 version. Further (but not major) revisions likely before a Last Call. 6. XEP-0256: Last Activity in Presence No clear consensus on http://xmpp.org/extensions/tmp/xep-0256-1.1.html but Peter will post to the standards@ list. 7. http://xmpp.org/extensions/inbox/muji.html No objections to publishing as a XEP. 8. http://xmpp.org/extensions/inbox/dna.html Joe Hildebrand to publish as an Internet-Draft instead. 9. XEP-0227: Portable Import/Export Format for XMPP-IM Servers No objections to issuing a Last Call. 10. Any Other Business? None. Peter to lean on Dave about writing up minutes from the XMPP Summit. Minutes from the XMPP WG session at IETF 75 are forthcoming via the usual IETF processes. 11. Next Meeting August 12, 2009 @ 19:00 UTC. http://xmpp.org/xsf/XSF.ics /psa -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp55SsACgkQNL8k5A2w/vwOTACgtAvYWwjYRP2Fi91hCgu297Xl oZQAniYeaD7bChVlVm53S7cTfCRynlhO =nFCu -END PGP SIGNATURE-
Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft
Am 13.03.19 um 22:16 schrieb Kevin Smith:
On 13 Mar 2019, at 17:37, Peter Saint-Andre wrote:
I can help, but I would not object to adding a more active co-author
(preferably an implementor of the spec).
Do you want to request a last call? Under the new rules Council aren’t allowed
to trigger an LC any more unless either the authors request it or the authors
abandon the XEP.
with my authors hat on: requesting a LC.
/K
Peter
On 3/13/19 10:53 AM, Dave Cridland wrote:
Philipp, Peter,
Do either of you want to remain involved with this one?
Andrew,
If they don't, would you be able to handle processing Last Call feedback?
On Wed, 13 Mar 2019 at 13:14, Ненахов Андрей
mailto:andrew.nenak...@redsolution.ru>>
wrote:
Hello, everyone.
Could we please advance XEP-0353: Jingle Message Initiation
<https://xmpp.org/extensions/xep-0353.html> to draft, please?
We need it because bare XEP-0166 does not work well with push
notifications, and does not support 'ring an all devices' behaviour.
--
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com <http://www.redsolution.com>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
<mailto:standards-unsubscr...@xmpp.org>
___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] Re: Proposed XMPP Extension: Chat notification settings
Hi, It's a great starting point. As additional input, here's a screenshot from the notification settings screen in Slack: https://imgur.com/i6O8GNO It's probably on the upper end of features one could possibly need, but I personally do enjoy having the different option for mobile devices. Marvin On Wed, 2024-06-05 at 13:54 +0200, Timothée Jaussoin wrote: > > Hi, > > I remember that I implemented a few years ago something very similar > in Movim but never standardized it, it's maybe the time to do it. > > Here is my way of doing it. > > > > autojoin="true"> > Miho > > notify="quoted"/> > > > > > > > From what I see in the XEP, it's really close: > > > > > > > > > > > > "never", "always", "on-mention" for the XEP and "never", "always", > "quoted" for my implementation. > > > > > Happy to see that we came up with the same idea and proposal. Once > this XEP will move forward I'll update my code to implement it > accordingly :) > > > > > Regards, > > > > > edhelas > > > > > > Le 05/06/2024 à 12:50, Daniel Gultsch a écrit : > > > > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Chat notification settings > > Abstract: > > This document defines an XMPP protocol extension to synchronise > > per- > > chat notification settings across different clients. > > > > URL: https://xmpp.org/extensions/inbox/notification-filter.html > > > > The Council will decide in the next two weeks whether to accept > > this > > proposal as an official XEP. > > ___ > > Standards mailing list -- standards@xmpp.org > > To unsubscribe send an email to standards-le...@xmpp.org > > > > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[google-appengine] Adding support for various XMPP Extensions
Hi Guys, Just wondering if you plan on adding support for various XMPP extensions, in particular: - Notifications (XEP-0060): http://xmpp.org/extensions/xep-0060.html - Service discovery (XEP-0030): http://xmpp.org/extensions/xep-0030.html - Capabilities advertisement (XEP-0115): http://xmpp.org/extensions/xep-0115.html - Structured data forms (XEP-0004): http://xmpp.org/extensions/xep-0004.html - Workflow management (XEP-0050): http://xmpp.org/extensions/xep-0050.html If there is a plan to provide support for one or more extensions mentioned above, is there currently a concrete timeline? Thanks, Eric --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[jdev] servers page at xmpp.org (was: Re: libraries page at xmpp.org)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/13/12 5:13 AM, gna...@ag-software.de wrote: > Hello, > > I am currently updating the XMPP libraries page at: > http://xmpp.org/xmpp-software/libraries/ Thanks, Alex! I recently also updated the servers page at xmpp.org: http://xmpp.org/xmpp-software/servers/ I think that all the links are up-to-date and correct, but please reply to this message if you see errors or omissions. John Martellaro will be helping us with the clients page, too, so please also report any problems you see there. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+MOsYACgkQNL8k5A2w/vxx1ACgpFDlXFyDdldir5tmFsFjMQdX 75IAoIB8yWOtCzwiSlhJ8/SHxFXThRsi =wtzF -END PGP SIGNATURE- ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
[Members] Fwd: [Standards] ACTIVE: XEP-0458 (Community Code of Conduct)
FYI, the code of conduct is now active. Peter Forwarded Message Subject: [Standards] ACTIVE: XEP-0458 (Community Code of Conduct) Date: Mon, 22 Jan 2024 14:55:21 - From: kevin.sm...@isode.com Reply-To: XMPP Standards To: standa...@xmpp.org Version 1.0.0 of XEP-0458 (Community Code of Conduct) has been released. Abstract: This document describes the XMPP Standard Foundation's Code of Conduct. Changelog: Changed status to Active per Board vote on 2024-01-05. (psa) URL: https://xmpp.org/extensions/xep-0458.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standa...@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
Re: [Standards] One true final way to mark up messages
On Wed, Mar 27, 2019, at 18:52, Ненахов Андрей wrote: > > What is the use case for hyper links and who does it benefit? > > They benefit users. You know, exactly that part of equation that XMPP > currently lacks. > > And the use-case is to make human-readable hyperlinks with titles. For > some reason, links on this page with a list of XMPP extensions > <https://xmpp.org/extensions/> look like XEP-0001 > <https://xmpp.org/extensions/xep-0001.html>, not like > https://xmpp.org/extensions/xep-0001.html This isn't an answer; how do they benefit users? How is this better than: "Hey, here's a link to the XEP we were talking about: https://xmpp.org/extensions/xep-0001.html"; —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] BOSH patches
On 11/27/13 8:23 AM, Winfried Tilanus wrote: > On 08-11-13 23:40, Peter Saint-Andre wrote: > > Hi, > >> Sitting here at IETF 88 with Lance Stout, I'm reminded to finally >> apply the collected patch he sent me to incorporate all the hard >> work that various folks on this list did earlier this year on >> XEP-0124 and XEP-0206. The rendered files and diffs are as >> follows. >> >> http://xmpp.org/extensions/tmp/xep-0124-1.11.html >> >> http://xmpp.org/extensions/diff/api/xep/0124/diff/1.10/vs/1.11rc1 >> >> http://xmpp.org/extensions/tmp/xep-0206-1.4.html >> >> http://xmpp.org/extensions/diff/api/xep/0206/diff/1.3/vs/1.4rc1 Lance has sent me an updated patch, which I have applied. The diff between 124rc1 and 124rc2 is here: http://xmpp.org/extensions/diff/api/xep/0124/diff/1.11rc1/vs/1.11rc2 Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] XMPP Council Agenda 2022-06-15
Hi Council members, the next XMPP Council Meeting will take place on Wednesday, June 15 2022 at 15:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update a) Proposed XMPP Extension: WebSocket S2S (https://xmpp.org/extensions/inbox/websocket-s2s.html) b) Proposed XMPP Extension: XMPP over QUIC (https://xmpp.org/extensions/inbox/xmpp-over-quic.html) 4) Items for voting a) Proposed XMPP Extension: WebSocket S2S (https://xmpp.org/extensions/inbox/websocket-s2s.html) b) Proposed XMPP Extension: XMPP over QUIC (https://xmpp.org/extensions/inbox/xmpp-over-quic.html) 5) Pending votes Daniel is pending on 'Start Last Call on XEP-0215' See Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2022-12-14
Good morning Council Members, the next XMPP Council Meeting will take place today, Wednesday, December 14th 2022 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update a) Published XEP-0471 (Events) https://xmpp.org/extensions/xep-0471.html b) Published XEP-0472 (PubSub Social Feed) https://xmpp.org/extensions/xep-0472.html c) Published XEP-0473 (OpenPGP for XMPP Pubsub) https://xmpp.org/extensions/xep-0473.html d) Published XEP-0474 (SASL SCRAM Downgrade Protection) https://xmpp.org/extensions/xep-0474.html 4) Items for voting Nothing new this week 5) Pending votes none See the all new Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1Zp5FWJI0aubAL29LhrXkhc-MrZauJ1mtkVnm5TrtwLo/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2022-12-21
Good morning Council Members, the next XMPP Council Meeting will take place today, Wednesday, December 21st 2022 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update a) NEW: XEP-0475 (Pubsub Signing) (https://xmpp.org/extensions/xep-0475.html) b) NEW: XEP-0476 (Pubsub Signing: OpenPGP Profile) (https://xmpp.org/extensions/xep-0476.html) c) NEW: XEP-0477 (Pubsub Targeted Encryption) (https://xmpp.org/extensions/xep-0477.html) 4) Items for voting a) Proposed XMPP Extension: Stream Limits Advertisement (https://xmpp.org/extensions/inbox/xep-sla.html) 5) Pending votes none See the all new Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1Zp5FWJI0aubAL29LhrXkhc-MrZauJ1mtkVnm5TrtwLo/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2023-07-05
Good morning Council Members, the next XMPP Council Meeting will take place on Wednesday, July 5 2023 at 15:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * UPDATED: XEP-0317 Hats (https://xmpp.org/extensions/xep-0317.html) * UPDATED: XEP-0453 DOAP usage in XMPP (https://xmpp.org/extensions/xep-0453.html) * Proposed XMPP Extension: Reporting Account Affiliations (https://xmpp.org/extensions/inbox/xep-reporting-account-affiliations.html) 4) Items for voting a) Proposed XMPP Extension: Reporting Account Affiliations (https://xmpp.org/extensions/inbox/xep-reporting-account-affiliations.html) 5) Pending votes none See the Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1Zp5FWJI0aubAL29LhrXkhc-MrZauJ1mtkVnm5TrtwLo/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
[Operators] xmpp.org services XML file
On the http://xmpp.org/services/ page, it says that one of the reasons for the services.xml file is for consumption by clients to populate an IBR server field, but I just noticed that jabber.org is in the file (and definitely has IBR disabled). Shouldn't the submission form [1] ask for and verification list mention checking [2] this? (and the current services checked, which I'm willing to help with) Thanks, ~Paul [1] http://xmpp.org/services/register.shtml [2] http://xmpp.org/services/verify.shtml signature.asc Description: OpenPGP digital signature
Re: [Operators] Annoying spam
On 9/9/15 8:23 AM, Peter Saint-Andre - &yet wrote: It might be time to revisit the old spam-prevention specs we started to define years ago. For the record, those were things like: http://xmpp.org/extensions/xep-0159.html http://xmpp.org/extensions/xep-0267.html http://xmpp.org/extensions/xep-0268.html http://xmpp.org/extensions/xep-0275.html I haven't looked at them in a long time, so I'm not sure if I still think they might work, if they're too complex, etc. Peter -- Peter Saint-Andre https://andyet.com/
[Summit] Re: Interest in attending
Hi, Consider asking in xmpp:x...@muc.xmpp.org?join for a wiki account. It'll probably get better visibility than on this list. Cheers Daniel On Tue, Dec 26, 2023, 03:36 Matthew Ellis wrote: > Hello, > > I would like to attend the summit and request an account to add my name to > the wiki please. > > Thank you, > > Matthew Ellis > > ___ > Summit mailing list -- summit@xmpp.org > To unsubscribe send an email to summit-le...@xmpp.org > ___ Summit mailing list -- summit@xmpp.org To unsubscribe send an email to summit-le...@xmpp.org
Re: [Standards] XEP-0396 (jet-omemo) links to a broken URL
Hi Ivan, I guess you can ignore that. The registry link was inserted by accident. Thanks for reporting this :) Paul 26.08.2020 22:36:55 Ivan Vučica : > Hi, > > https://xmpp.org/extensions/xep-0396.html links to > https://xmpp.org/registrar/jet-omemo.html which doesn't exist. > > Was this meant to link to something else? > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Meeting 2016-11-02
On Wed, Nov 9, 2016 at 12:18 AM, Tobias Markmann wrote: > # 1) Accept as experimental? http://xmpp.org/extensions/inbox/omemo.html > - Lance: +1 > - Tobi: on list > - MattJ: on list > +1 > > ## 2) Accept as experimental? http://xmpp.org/extensions/ > inbox/spoiler.html > - Lance: +1 > - Tobi: on list > - MattJ: on list > +1 > ## 5) Accept as experimental? https://xmpp.org/extensions/ > inbox/burner.html > - Lance: on list > - Tobi: on list > - MattJ: on list > +1 Cheers, Tobi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] NEW: XEP-0486 (MUC Avatars)
Version 0.1.0 of XEP-0486 (MUC Avatars) has been released. Abstract: This specification describes how to publish and retrieve avatars in rooms. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0486.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] UPDATED: XEP-0444 (Message Reactions)
Version 0.2.1 of XEP-0444 (Message Reactions) has been released. Abstract: This specification defines a way for adding reactions to a message. Changelog: fix grammar and spelling (wb) URL: https://xmpp.org/extensions/xep-0444.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] NEW: XEP-0491 (WebXDC)
Version 0.1.0 of XEP-0491 (WebXDC) has been released. Abstract: This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0491.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
Re: separate login/password for several services?
Just crazy idea... several attributes for user passwords (userPassword1, userPassword2, ...) in user account and proxy-mapping overlay (slapo-translucent? slapo-rwm?) with mapping attribute userPassword into userPassword1 or userPassword2 with dependencies from service IP. WBR On 09.08.2013 17:17, Zeus Panchenko wrote: Andrew Findlay wrote: lets say I have two users with name John and I need to give each one acces to some service, but both of them wish the service uid=john (for example, it is common issue for MTA serving different mail domains with different user space for each one) The first question to ask is how the application is going to tell the difference between the two users when someone tries to login as 'john'. If the users are j...@a.b.com and j...@x.y.org then why not use the full mail address as the uid? yes, it is what I was thought about too and I like the idea, though I wanted to check how correct/right is this way so what is needed to provide uniqueness of attribute `uid' for each dn: authorizedService=target-service,uid=target-user,ou=People,dc=org perhaps I need to define more accurately what I mean: the uniqueness while *creating* the dn ... since for dn-s dn: authorizedService=target-service,uid=target-user1,ou=People,dc=org dn: authorizedService=target-service,uid=target-user2,ou=People,dc=org ... dn: authorizedService=target-service,uid=target-userN,ou=People,dc=org I want to prevent the possibility to create the same uid=john-whatever-format-it-is now I do can ldapadd these ldif-s successfully ---[ ldif ] dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org cn: john....@xmpp.org sn: xmpp.org description: John Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org authorizedService: xmpp.org cn: john.sm...@xmpp.org sn: xmpp.org description: John Smith XMPP account at xmpp.org uidNumber: 12356 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john ---[ ldif ] and ldapsearch ... "(&(uid=john)(authorizedService=xmpp.org))" outputs both of them, so I need the way I can know that uid: is not unique while creating the dn: so, what I need to prevent the possibility to create the second dn:, since it will contain the same uid value as the first one? If each 'john' account exists in a distinct identifiable namespace then you could either put the name of the namespace in the account entry or you could use it as part of the LDAP hierachy. The application can then formulate a search that finds the correct entry in one operation. I was thinking to use sn: attribute since it is login dedicated dn: and it is no need in it but all the same, my question remains oppened: how to not to create not unique uid for dn: authorizedService=target-service,uid= ? have I put in into UI for records management or it can be done on the server side (for example like indexes in SQL)
[Standards] XMPP Council Agenda 2024-08-06
Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 6 2024 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - UPDATED: XEP-0054 (vcard-temp) https://xmpp.org/extensions/xep-0054.html - UPDATED: XEP-0386 (Bind 2) https://xmpp.org/extensions/xep-0386.html - UPDATED: XEP-0478 (Stream Limits Advertisement) https://xmpp.org/extensions/xep-0478.html - Proposed XMPP Extension: Jingle Audio/Video Conferences https://xmpp.org/extensions/inbox/av_conferences.html 4) Items for voting a) Proposed XMPP Extension: Jingle Audio/Video Conferences https://xmpp.org/extensions/inbox/av_conferences.html b) XEP-0045: Additional Ban List specifications https://github.com/xsf/xeps/pull/1359 c) XEP-0045: Remove references to using resourceparts when banning users https://github.com/xsf/xeps/pull/1360 d) XEP-0045: Improved wording of status code purpose https://github.com/xsf/xeps/pull/1361 e) XEP-0045: Improve 'Service Removes Non-Member' example https://github.com/xsf/xeps/pull/1362 f) XEP-0045: Clarify usage of presence stanzas when removing a non-member from a members-only room https://github.com/xsf/xeps/pull/1363 g) XEP-0045: Replace inappropriate RFC 2119 key word usage in §9.7 https://github.com/xsf/xeps/pull/1364 h) XEP-0045: Presence sent to occupants of a destroyed room includes a https://github.com/xsf/xeps/pull/1365 5) Pending votes none. I few expired since our last meeting. (see editor updates above) See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfaRQb5Atdg/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] NEW: XEP-0485 (PubSub Server Information)
Version 0.1.0 of XEP-0485 (PubSub Server Information) has been released. Abstract: This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub. Changelog: * Promoted to Experimental. (dg) URL: https://xmpp.org/extensions/xep-0485.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] NEW: XEP-0488 (MUC Token Invite)
Version 0.1.0 of XEP-0488 (MUC Token Invite) has been released. Abstract: This specification provides a way to generate tokens to invite users to a MUC room. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0488.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] NEW: XEP-0490 (Message Displayed Synchronization)
Version 0.1.0 of XEP-0490 (Message Displayed Synchronization) has been released. Abstract: This specification allows multiple clients of the same user to synchronize the displayed state of their chats. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0490.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] UPDATED: XEP-0388 (Extensible SASL Profile)
Version 1.0.1 of XEP-0388 (Extensible SASL Profile) has been released. Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility. Changelog: Fixed typos (md) URL: https://xmpp.org/extensions/xep-0388.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] NEW: XEP-0492 (Chat notification settings)
Version 0.1.0 of XEP-0492 (Chat notification settings) has been released. Abstract: This document defines an XMPP protocol extension to synchronise per- chat notification settings across different clients. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0492.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] UPDATED: XEP-0491 (WebXDC)
Version 0.1.2 of XEP-0491 (WebXDC) has been released. Abstract: This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. Changelog: * Suggest what to use for selfAddr * Add acknowledgements (spw) URL: https://xmpp.org/extensions/xep-0491.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] UPDATED: XEP-0054 (vcard-temp)
Version 1.3.0 of XEP-0054 (vcard-temp) has been released. Abstract: This specification provides canonical documentation of the vCard-XML format currently in use within the Jabber community. Changelog: Updated error cases to be compatible with . (gk) URL: https://xmpp.org/extensions/xep-0054.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] UPDATED: XEP-0386 (Bind 2)
Version 1.0.1 of XEP-0386 (Bind 2) has been released. Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup. Changelog: Add an XML Schema. (egp) URL: https://xmpp.org/extensions/xep-0386.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
Re: [Operators] Public server list - github synchronization
Hi, I mean a pull of the xmpp.net public server list (vcards) -> https://github.com/stpeter/xmppdotnet :-) Anyway, do you plan support of XEP 309 in ejabberd? Regards, -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662 From: Operators [mailto:operators-boun...@xmpp.org] On Behalf Of Mickaël Rémond Sent: Thursday, March 10, 2016 10:52 PM To: XMPP Operators Group Subject: Re: [Operators] Public server list - github synchronization Hello, We are closent monitoring pull requests and talking about them with their developers. We can only integrate them when they are complete (for example support all available back ends) or provide feature that are widely useful. On the specific topic of XEP 309, I am not aware of any pending pull requests. Is there one ? Le Thu, 10 Mar 2016 à 22:28, Marcin Gondek mailto:drix...@e-utp.net>> a écrit : Hi, Hm, anyway I’ve to wait, for ejabberd devs or someone will pull from github. There are 27 pull request, for more than two months :-/ Regards, -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662 From: Operators [mailto:operators-boun...@xmpp.org<mailto:operators-boun...@xmpp.org>] On Behalf Of Ludovic BOCQUET Sent: Wednesday, March 9, 2016 12:46 AM To: operators@xmpp.org<mailto:operators@xmpp.org> Subject: Re: [Operators] Public server list - github synchronization Maybe time to see ejabberd devs, there are tickets : - https://github.com/processone/ejabberd/issues/469 - https://support.process-one.net/browse/EJAB-1528 Prosody module on https://prosody.im/doc/xeplist You can see Metronome IM too: http://mail.jabber.org/pipermail/operators/2013-September/thread.html#1866 :) I think it is possible to update the XEP-0309... Regards, BOCQUET Ludovic Le 08/03/2016 21:14, Marcin Gondek a écrit : Hi, How I can do it, using ejabberd? Regards, -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662 From: Operators [mailto:operators-boun...@xmpp.org] On Behalf Of Ludovic BOCQUET Sent: Tuesday, March 8, 2016 6:36 PM To: operators@xmpp.org<mailto:operators@xmpp.org> Subject: Re: [Operators] Public server list - github synchronization Importance: High Hi, Information: There is a XEP for automatic list: https://xmpp.org/extensions/xep-0309.html. Regards, BOCQUET Ludovic Le 08/03/2016 08:14, Marcin Gondek a écrit : Hi, How often there is a synchronization of vcard between web page and gihub? It's look's like the last was on January :-( Regards, URL: https://xmpp.net/directory.php Public XMPP Server Directory - IM Observatory<https://xmpp.net/directory.php> xmpp.net<http://xmpp.net> Public XMPP Server Directory. This is a list of servers with public registration (i.e., anyone can sign up for free). Follow the links to the website to sign up, or ... -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662
[Git][gajim/gajim][master] DOAP: Update status for some XEPs
Daniel Brötzmann pushed to branch master at gajim / gajim Commits: 70282c6c by wurstsalat at 2021-12-10T21:09:14+01:00 DOAP: Update status for some XEPs - - - - - 1 changed file: - data/gajim.doap Changes: = data/gajim.doap = @@ -86,7 +86,6 @@ https://xmpp.org/extensions/xep-0045.html"/> complete 1.31.2 -All basics stuff is supported. Also, some more advanced features like invitations, creation of rooms, etc. @@ -240,6 +239,22 @@ 1.1.1 + + +https://xmpp.org/extensions/xep-0107.html"/> +removed +1.2 +Removed in 1.4.0 + + + + +https://xmpp.org/extensions/xep-0108.html"/> +removed +1.3 +Removed in 1.4.0 + + https://xmpp.org/extensions/xep-0115.html"/> @@ -556,6 +571,7 @@ partial 0.4 'displayed' markers are supported, but 'acknowledged' markers are not. +1.3.0 @@ -651,6 +667,7 @@ https://xmpp.org/extensions/xep-0425.html"/> complete 0.2.1 +1.4.0 View it on GitLab: https://dev.gajim.org/gajim/gajim/-/commit/70282c6cf6d708590fc1bdc5253f383fd37d68b5 -- View it on GitLab: https://dev.gajim.org/gajim/gajim/-/commit/70282c6cf6d708590fc1bdc5253f383fd37d68b5 You're receiving this email because of your account on dev.gajim.org. ___ Commits mailing list Commits@gajim.org https://lists.gajim.org/cgi-bin/listinfo/commits
[Standards] XEP-0060 1.13rc18
Per Council discussion in March [1] and May [2] and in an effort to get version 1.13 of XEP-0060 published, I have updated the spec as follows: (a) Removed IQ notifications (b) Retained batch publishing (c) Retained SubIDs on subscription approvals The results are here: http://xmpp.org/extensions/tmp/xep-0060-1.13.html A diff from rc13 (before removing IQ notifications) is here: http://xmpp.org/extensions/diff/api/xep/0060/diff/1.13rc13/vs/1.13rc18 A diff from rc17 (before retaining batch publishing and SubIDs on subscription approvals from 1.12) is here: http://xmpp.org/extensions/diff/api/xep/0060/diff/1.13rc17/vs/1.13rc18 These issues will be topics for discussion as we work on 1.14, but the Council decided to push forward with 1.13 before tackling these issues. Ralph, please review these changes to make sure that they address your concerns! /psa [1] http://xmpp.org:5290/muc_log/muc.xmpp.org/council/100329/#13:39:34 [2] http://xmpp.org:5290/muc_log/muc.xmpp.org/council/100503/#13:06:18 smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0288 (Bidirectional Server-to-Server Connections)
The URL is still pointing to version 1.0 from 2013. Is this somehow connected with the error 404 I noticed for the new XEP 380 earlier today? Actually it looks like all the yesterday's updates are not reflected on the xmpp.org pages. Best regards Michal Piotrowski michal.piotrow...@erlang-solutions.com On 26 October 2016 at 22:30, XMPP Extensions Editor wrote: > Version 1.0.1 of XEP-0288 (Bidirectional Server-to-Server Connections) has > been released. > > Abstract: This specification defines a protocol for using server-to-server > connections in a bidirectional way such that stanzas are sent and received > on the same TCP connection. > > Changelog: Fix syntax highlighting and tweak example formatting. (ssw) > > Diff: http://xmpp.org/extensions/diff/api/xep/0288/diff/1.0/vs/1.0.1 > > URL: http://xmpp.org/extensions/xep-0288.html > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Obsoleting vCard-Based Avatars
Hi, I'm just giving a +1 for this one. Regards, Timothée Jaussoin On 08/01/2017 15:59, Sam Whited wrote: Hi all, XEP-0053: vCard-Based Avatars [1] is a historical specification that has been superseded by XEP-0084: User Avatars [2] for quite some time. However, since it's historical it still shows up in the list on xmpp.org and this seems like a possible source of confusion to me. I'd like to propose that we move 0053 to "Obsolete" officially. We could also mention in 0084 that it may be a good idea to implement it in a read-only fashion (as Conversations does) for backwards compatibility, but that new full implementations aren't recommended. Thoughts? —Sam [1]: https://xmpp.org/extensions/xep-0153.html [2]: https://xmpp.org/extensions/xep-0084.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: separate login/password for several services?
On Fri, Aug 09, 2013 at 04:17:02PM +0300, Zeus Panchenko wrote: > the uniqueness while *creating* the dn ... since for dn-s > > dn: authorizedService=target-service,uid=target-user1,ou=People,dc=org > dn: authorizedService=target-service,uid=target-user2,ou=People,dc=org > ... > dn: authorizedService=target-service,uid=target-userN,ou=People,dc=org > > I want to prevent the possibility to create the same > uid=john-whatever-format-it-is If you always put the uid in the DN using the structure shown above then it will not be possible to create duplicates. That assumes that you use the same uid in all the subentries of the main user entry... > now I do can ldapadd these ldif-s successfully > ---[ ldif ] > dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org > authorizedService: xmpp.org > cn: john@xmpp.org > sn: xmpp.org > description: John Doe XMPP account at xmpp.org > uidNumber: 12345 > gidNumber: 23456 > homeDirectory: /nonexistent > loginShell: /sbin/nologin > objectClass: person > objectClass: posixAccount > objectClass: shadowAccount > objectClass: authorizedServiceObject > uid: john > > dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org > authorizedService: xmpp.org > cn: john.sm...@xmpp.org > sn: xmpp.org > description: John Smith XMPP account at xmpp.org > uidNumber: 12356 > gidNumber: 23456 > homeDirectory: /nonexistent > loginShell: /sbin/nologin > objectClass: person > objectClass: posixAccount > objectClass: shadowAccount > objectClass: authorizedServiceObject > uid: john > ---[ ldif ] Both those entries have one uid in the entry and a different one in the DN. The one in the DN refers to the parent entry in each case so it is legal but maybe not what you want. It may be enough for you to simply prevent the non-uniqueness. You can do that using the 'unique' overlay: overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub Unfortunately this creates another problem: *every entry* must have a different uid - probably not what you want... It would be possible to write an access-control list using sets to require that the two uids match. This is not quite as simple as there are various cases to consider. Again it may be too restrictive, as then every sub-entry would have to have the same uid as the main entry (though the passwords could still be different). > > If each 'john' account exists in a distinct identifiable namespace then > > you could either put the name of the namespace in the account entry or > > you could use it as part of the LDAP hierachy. The application can > > then formulate a search that finds the correct entry in one operation. > > I was thinking to use sn: attribute since it is login dedicated dn: and > it is no need in it The data you are putting there is clearly *not* a surname. Don't misuse attributes like this - it will cause trouble later. A more appropriate attribute might be associatedDomain - you will need to add the objectclass 'domainRelatedObject' as well. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
[Summit] Re: XMPP Summit 26: Aftermath & open tasks
Hi all, Thank you very much Eddie. All the best, Nicola FSEN On 3 Mar 2024, at 13:07, E.M. wrote: > Dear XMPP Summit 26 participants and beyond, > > beginning of this month we in Brussels and had another great XMPP Summit! > Thank you all for participation. > > I have been asked to follow-up on the action items and encourage to work on > the ToDos. Here we go. I have collected all Action Items I could find in our > pad: https://pad.nixnet.services/D6jfvHjJTTqyAfHd3Z2_Cg > > If you want me to create issue, I can do so. > > In general, I also invite to sent or add your feedback to the pad: > https://pad.nixnet.services/D6jfvHjJTTqyAfHd3Z2_Cg#Feedback-Summit-26 > > If something has been fulfilled and I missed it, let me know. Sorted in the > same order we spoke about it: > > _ > > # Day 1 > > ## XMPP 2.0 - overlaps with strategy > > * review modernxmpp.org[http://modernxmpp.org] landing page (cal0pteryx) > * make modernxmpp.org[http://modernxmpp.org] and compliance suite more > prominent on xmpp.org[http://xmpp.org] (maybe merge modernxmpp and > xmpp.org[http://xmpp.org]) (cal0pteryx) > * write XEP to prepare 2.0 RFC - MattJ if nobody else volunteers > * everyone write a blog post about implementing stuff and/or contribute to > libraries 😉 - singpolyma > > ## Editor role > > * automatically publish xeps from github on merge > * put shell script that checks author in github actions > * singpolyma volunteers to help automate > * potential risk of abuse (already true) > > > ## Discord like spa > > * Kevin promises to get the spec written out (for real this time) > > ## Strategy (marketing) > > * https://superbloom.design/ (Formerly Simply Secure) have a team of > designers that obtain funding to help open source projects > * have a way to direct devs and users who land on xmpp.org to the appropriate > places; joinjabber.org, modernxmpp > * Don’t deprecate a compliance suite while keeping the newest experimental > > > ## Audio/Video > > * document how we translate jingle to sdp for different webrtc implementations > * volunteers needed please (Larma volunteered :) ) > > ___ > # Day 2 > > ## Read Sync > > * Daniel Gultsch volunteers to write the XEP: > https://gultsch.de/files/xep-mds.html > > > ## Device Management > > * Matt to submit the 2FA/authorization protocol as a XEP > > > ## IM Routing-NG > > * implement it and play with it please: > https://xmpp.org/extensions/xep-0409.html > > ## Stories > > * MattJ to write an xep > > > ## MUC/MIX > > * Daniel Gultsch to writeup what he means by using occupant ids > > > > ## Action items Summit 25 (Written from Matthew’s memory) > > * Write spaces discovery XEP (~Kev?) > * Write spaces admin XEP (~Kev?) > * Try again to implement MIX, provide feedback (~MattJ) > * Update XEP-0317 Hats with Prosody’s implementation, drop the ad-hoc stuff > and focus on display/syntax only (~MattJ) > * WebPush send profile in Push 2.0, incorporate other feedback and submit > (~MattJ) > ___ > Summit mailing list -- summit@xmpp.org > To unsubscribe send an email to summit-le...@xmpp.org signature.asc Description: OpenPGP digital signature ___ Summit mailing list -- summit@xmpp.org To unsubscribe send an email to summit-le...@xmpp.org
Re: [Operators] About the IM Observatory and the old xml files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/2/13 12:43 PM, Cesar Alcalde wrote: > Hello > > The old xmpp.net <http://xmpp.net> website that contained the old > public directory, also linked to the list in xml format ( > http://xmpp.net/services.xml ) That file seems to have been removed > with the transition to the IM Observatory, That was unintentional. We might have lost some redirects in the move. > although outdated versions seem to exist at xmpp.org > <http://xmpp.org>: > > - http://xmpp.org/services/services.xml - > http://xmpp.org/services/services-full.xml > > I guess that those lists are still on xmpp.org <http://xmpp.org> > in order to maintain compatibility with the clients that used them > in their "new account" dialogs. > > I use those files, along with the (less complete) list at > https://list.jabber.at/ , to fetch the servers that will appear at > http://www.jabberes.org/servers/ > > Do you plan to bring back the xml list? Would it be possible to > have it with the "full" format (including description, homepage, > coordinates...)? We're working on that part of it. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdVupAAoJEOoGpJErxa2pyKwQAKmu4pjODuHJGGHRDMmJX0n8 a0/4sBg/sYyOh0FWz8Jum9hehSeKpOgkYhvj+7K6djWKGxtYggYLCiemOL5OFbgy RUFN9jM23C6D26xIPH97eU4neV7C8CrspCKGe03dyYUS0i7rb0KFLx6P51AMUutR 11js094YpvdR4cahzyq7HOlmJGlMrN/zqohuC67FVjLDtRPGpZe9oKpVJdBdP7/n Cd+wSiKkra31GGMvsU7L5C2/aHBKBQZhJK+S4PBoGHH3IuIeoo+yCZ5XhAT13iuS m+bWA7Fn577eTGw7lZ9uI73oHqmvKxHzmXUI3XtTQ9LHKCEmxqbDFt4hTCp6F767 dXDn0A2ZZsndzxdopHNGIbXYxYNVcw+hjSzGjM9Yu4ihxxFzvQWm4usLWa+tkHFz oJtfGPhmJHFZp10NEycAqtbwy0LSTPY2hrml41bEqXb/HMkF4RUnVDf00lTYhglu M8F0rQ3F75uSyRQUk98w0qeHIrNPcNu+th/dBMYrBtwnGsjy1TADfQCrA21uDGwW wWeynJI29kGyEapO0j9o7WG6q6asLTMFEPcXcei7IwOpipyG0Pp4+FHFZbjT7U7m RvcKsYst+TB3OSkR6RHL5vCWLJRQ1Os4vtaBjbLbfOVxwu0I6KOMJWzMS8yanHo7 KZle6j5tysx9H/Mcofcd =HK6I -END PGP SIGNATURE-
