├── .gitattributes ├── .github ├── ISSUE_TEMPLATE.md └── workflows │ ├── auto-triage.yml │ └── xep-validation.yml ├── .gitignore ├── .gitlab-ci.yml ├── .travis.yml ├── Dockerfile ├── LICENSE.txt ├── Makefile ├── README.md ├── archive.sh ├── checkdeadlinks.py ├── dbupdate.py ├── deferred.py ├── deps ├── adjcalc.sty ├── adjustbox.sty ├── collectbox.sty ├── tabu.sty ├── tc-dvips.def ├── tc-pdftex.def ├── tc-pgf.def ├── tc-xetex.def └── trimclip.sty ├── docs ├── MODERATION.md ├── PROCESSING.md ├── README.md ├── REPOSITORY.md └── TRIAGING.md ├── examples.xsl ├── fo.xsl ├── inbox ├── account-management.xml ├── auth-tokens.xml ├── automatic-trust-management.xml ├── automatic-trust-transfer.xml ├── av_conferences.xml ├── baseline-security.xml ├── bidi.xml ├── bmh.xml ├── bookmark-pinning.xml ├── bookmarks-conversion.xml ├── buddycloud-channels.xml ├── buttons.xml ├── calendaring.xml ├── call-invites.xml ├── cap.xml ├── carbons.xml ├── cb-pseudomechanisms.xml ├── client-key.xml ├── client-state-notification.xml ├── cmr.xml ├── compatibility-fallback.xml ├── content-ratings.xml ├── content-types.xml ├── cs-2019.xml ├── cs-2020.xml ├── cs-2021.xml ├── cs-2022.xml ├── cs-2023.xml ├── decloak.xml ├── disco-feature-attachment.xml ├── distributedmuc.xml ├── dmuc3.xml ├── dna.xml ├── doap-usage-in-xmpp.xml ├── dox.xml ├── dsig-design.xml ├── dsig.xml ├── eax-car.xml ├── eax-cir.xml ├── eax.xml ├── ephemeral-messages-v2.xml ├── esfs.xml ├── events.xml ├── extended-channel-search.xml ├── fallback.xml ├── fasten.xml ├── file-metadata.xml ├── fmuc.xml ├── forwarding-delivery.xml ├── fsn.xml ├── ft-metadata.xml ├── fulltext.xml ├── gateway-relayed-encryption.xml ├── gdpr.xml ├── gre-encrypter-openpgp.xml ├── gre-formatter-mime.xml ├── hacx.xml ├── hash-recommendations.xml ├── host-meta-2.xml ├── ibr-token.xml ├── im-ng.xml ├── inbox.xml ├── incident-reporting.xml ├── instant-gaming.xml ├── iot-events.xml ├── isr-sasl2.xml ├── isr.xml ├── jid-mention.xml ├── jingle-ibb.xml ├── jingle-nodes.xml ├── jingle-rtp-codecs.xml ├── jingle-rtp-mti.xml ├── jingle-s5b.xml ├── jingle-sdp.xml ├── jingle-xtls.xml ├── jingle-zrtp.xml ├── json.xml ├── lop.xml ├── mamfc.xml ├── mix.xml ├── mobile.xml ├── moved.xml ├── moved2.xml ├── muc-activity.xml ├── muc-admin.xml ├── muc-affiliations-versioning.xml ├── muc-avatars.xml ├── muc-light.xml ├── muc-mention-notifications.xml ├── muc-presence-versioning.xml ├── muc-selfping.xml ├── muc-token-invite.xml ├── muji.xml ├── multi-user_gaming.xml ├── multistage-ibr.xml ├── mux.xml ├── notification-filter.xml ├── notification-inbox.xml ├── nsver.xml ├── occupant-id.xml ├── omemo-filetransfer.xml ├── omemo-media-sharing.xml ├── order-by.xml ├── outofband.xml ├── password-storage.xml ├── pep-vcard-conversion.xml ├── peptzo.xml ├── preauth-ibr.xml ├── problem-reporting.xml ├── pubsub-attachments.xml ├── pubsub-caching-hints.xml ├── pubsub-encryption.xml ├── pubsub-extended-discovery.xml ├── pubsub-extended-subscription.xml ├── pubsub-file-sharing.xml ├── pubsub-filter.xml ├── pubsub-node-relationships.xml ├── pubsub-ns.xml ├── pubsub-public-subscriptions.xml ├── pubsub-server-info.xml ├── pubsub-signing-openpgp.xml ├── pubsub-signing.xml ├── pubsub-since.xml ├── pubsub-social-feed.xml ├── pubsub-targeted-encryption.xml ├── pubsub-uri.xml ├── qos.xml ├── quick-response.xml ├── reactions.xml ├── reminders.xml ├── remote-control.xml ├── replies.xml ├── reputation.xml ├── rest.xml ├── room-activity-indicators.xml ├── rsf.xml ├── s2s-components.xml ├── sasl2.xml ├── sensors.xml ├── server-rosters.xml ├── service-outage-status.xml ├── sfs.xml ├── shared-bosh.xml ├── sic.xml ├── sift.xml ├── sige2ee.xml ├── sox.xml ├── spaces.xml ├── spim.xml ├── stickers.xml ├── stories.xml ├── sxe.xml ├── thumbs.xml ├── tictactoe-mug.xml ├── tictactoe.xml ├── token-reconnection.xml ├── tos.xml ├── totp-2fa.xml ├── trust-messages.xml ├── udt.xml ├── user-auth.xml ├── userrating.xml ├── websocket-s2s.xml ├── webxdc.xml ├── xep-ai.xml ├── xep-client-access-management.xml ├── xep-downgrade-prevention.xml ├── xep-fast.xml ├── xep-happy-eyeballs.xml ├── xep-http_online_meetings.xml ├── xep-iwe.xml ├── xep-mds.xml ├── xep-oauth-client-login.xml ├── xep-reporting-account-affiliations.xml ├── xep-sasl-cb-types.xml ├── xep-sce.xml ├── xep-scram-upgrade.xml ├── xep-sla.xml ├── xep-slow-mode.xml ├── xep.dtd ├── xep.ent ├── xep.xsl ├── xmpp-over-quic.xml ├── xor.xml └── xtls.xml ├── pack-only.Dockerfile ├── prettify.css ├── prettify.js ├── protopage.xsl ├── protopagegen.sh ├── ref.xsl ├── resources ├── xmpp-text.pdf └── xmpp.pdf ├── texml-xsl ├── cmp.xsl ├── date-time.xsl ├── example.xsl ├── markup.xsl ├── math.xsl ├── node.xsl ├── stdlib.xsl ├── string.xsl ├── svg.xsl └── uri.xsl ├── tools ├── 2xep.lua ├── accept.py ├── archive.py ├── ci-announce.sh ├── ci-archive.sh ├── ci-changed-builds.sh ├── ci-prune-build.sh ├── ci-restore-timestamps.py ├── deferrals.py ├── extract-metadata.py ├── find-lcs.sh ├── github_auto_triage_pr.sh ├── issue-cfe.py ├── local-triage.py ├── makeent.py ├── md-diff.sh ├── merge-helper.sh ├── send-updates.py ├── triage.sh ├── validate-xep0001-conformance.sh ├── xep2md.lua ├── xep2md.sh ├── xeplib.py └── xeplist-to-csv.py ├── xep-0001.xml ├── xep-0002.xml ├── xep-0003.xml ├── xep-0004.xml ├── xep-0005.xml ├── xep-0006.xml ├── xep-0007.xml ├── xep-0008.xml ├── xep-0009.xml ├── xep-0010.xml ├── xep-0011.xml ├── xep-0012.xml ├── xep-0013.xml ├── xep-0014.xml ├── xep-0015.xml ├── xep-0016.xml ├── xep-0017.xml ├── xep-0018.xml ├── xep-0019.xml ├── xep-0020.xml ├── xep-0021.xml ├── xep-0022.xml ├── xep-0023.xml ├── xep-0024.xml ├── xep-0025.xml ├── xep-0026.xml ├── xep-0027.xml ├── xep-0028.xml ├── xep-0029.xml ├── xep-0030.xml ├── xep-0031.xml ├── xep-0032.xml ├── xep-0033.xml ├── xep-0034.xml ├── xep-0035.xml ├── xep-0036.xml ├── xep-0037.xml ├── xep-0038.xml ├── xep-0039.xml ├── xep-0040.xml ├── xep-0041.xml ├── xep-0042.xml ├── xep-0043.xml ├── xep-0044.xml ├── xep-0045.xml ├── xep-0046.xml ├── xep-0047.xml ├── xep-0048.xml ├── xep-0049.xml ├── xep-0050.xml ├── xep-0051.xml ├── xep-0052.xml ├── xep-0053.xml ├── xep-0054.xml ├── xep-0055.xml ├── xep-0056.xml ├── xep-0057.xml ├── xep-0058.xml ├── xep-0059.xml ├── xep-0060.xml ├── xep-0061.xml ├── xep-0062.xml ├── xep-0063.xml ├── xep-0064.xml ├── xep-0065.xml ├── xep-0066.xml ├── xep-0067.xml ├── xep-0068.xml ├── xep-0069.xml ├── xep-0070.xml ├── xep-0071.xml ├── xep-0072.xml ├── xep-0073.xml ├── xep-0074.xml ├── xep-0075.xml ├── xep-0076.xml ├── xep-0077.xml ├── xep-0078.xml ├── xep-0079.xml ├── xep-0080.xml ├── xep-0081.xml ├── xep-0082.xml ├── xep-0083.xml ├── xep-0084.xml ├── xep-0085.xml ├── xep-0086.xml ├── xep-0087.xml ├── xep-0088.xml ├── xep-0089.xml ├── xep-0090.xml ├── xep-0091.xml ├── xep-0092.xml ├── xep-0093.xml ├── xep-0094.xml ├── xep-0095.xml ├── xep-0096.xml ├── xep-0097.xml ├── xep-0098.xml ├── xep-0099.xml ├── xep-0100.xml ├── xep-0101.xml ├── xep-0102.xml ├── xep-0103.xml ├── xep-0104.xml ├── xep-0105.xml ├── xep-0106.xml ├── xep-0107.xml ├── xep-0108.xml ├── xep-0109.xml ├── xep-0110.xml ├── xep-0111.xml ├── xep-0112.xml ├── xep-0113.xml ├── xep-0114.xml ├── xep-0115.xml ├── xep-0116.xml ├── xep-0117.xml ├── xep-0118.xml ├── xep-0119.xml ├── xep-0120.xml ├── xep-0121.xml ├── xep-0122.xml ├── xep-0123.xml ├── xep-0124.xml ├── xep-0125.xml ├── xep-0126.xml ├── xep-0127.xml ├── xep-0128.xml ├── xep-0129.xml ├── xep-0130.xml ├── xep-0131.xml ├── xep-0132.xml ├── xep-0133.xml ├── xep-0134.xml ├── xep-0135.xml ├── xep-0136.xml ├── xep-0137.xml ├── xep-0138.xml ├── xep-0139.xml ├── xep-0140.xml ├── xep-0141.xml ├── xep-0142.xml ├── xep-0143.xml ├── xep-0144.xml ├── xep-0145.xml ├── xep-0146.xml ├── xep-0147.xml ├── xep-0148.xml ├── xep-0149.xml ├── xep-0150.xml ├── xep-0151.xml ├── xep-0152.xml ├── xep-0153.xml ├── xep-0154.xml ├── xep-0155.xml ├── xep-0156.xml ├── xep-0157.xml ├── xep-0158.xml ├── xep-0159.xml ├── xep-0160.xml ├── xep-0161.xml ├── xep-0162.xml ├── xep-0163.xml ├── xep-0164.xml ├── xep-0165.xml ├── xep-0166.xml ├── xep-0167.xml ├── xep-0168.xml ├── xep-0169.xml ├── xep-0170.xml ├── xep-0171.xml ├── xep-0172.xml ├── xep-0173.xml ├── xep-0174.xml ├── xep-0175.xml ├── xep-0176.xml ├── xep-0177.xml ├── xep-0178.xml ├── xep-0179.xml ├── xep-0180.xml ├── xep-0181.xml ├── xep-0182.xml ├── xep-0183.xml ├── xep-0184.xml ├── xep-0185.xml ├── xep-0186.xml ├── xep-0187.xml ├── xep-0188.xml ├── xep-0189.xml ├── xep-0190.xml ├── xep-0191.xml ├── xep-0192.xml ├── xep-0193.xml ├── xep-0194.xml ├── xep-0195.xml ├── xep-0196.xml ├── xep-0197.xml ├── xep-0198.xml ├── xep-0199.xml ├── xep-0200.xml ├── xep-0201.xml ├── xep-0202.xml ├── xep-0203.xml ├── xep-0204.xml ├── xep-0205.xml ├── xep-0206.xml ├── xep-0207.xml ├── xep-0208.xml ├── xep-0209.xml ├── xep-0210.xml ├── xep-0211.xml ├── xep-0212.xml ├── xep-0213.xml ├── xep-0214.xml ├── xep-0215.xml ├── xep-0216.xml ├── xep-0217.xml ├── xep-0218.xml ├── xep-0219.xml ├── xep-0220.xml ├── xep-0221.xml ├── xep-0222.xml ├── xep-0223.xml ├── xep-0224.xml ├── xep-0225.xml ├── xep-0226.xml ├── xep-0227.xml ├── xep-0228.xml ├── xep-0229.xml ├── xep-0230.xml ├── xep-0231.xml ├── xep-0232.xml ├── xep-0233.xml ├── xep-0234.xml ├── xep-0235.xml ├── xep-0236.xml ├── xep-0237.xml ├── xep-0238.xml ├── xep-0239.xml ├── xep-0240.xml ├── xep-0241.xml ├── xep-0242.xml ├── xep-0243.xml ├── xep-0244.xml ├── xep-0245.xml ├── xep-0246.xml ├── xep-0247.xml ├── xep-0248.xml ├── xep-0249.xml ├── xep-0250.xml ├── xep-0251.xml ├── xep-0252.xml ├── xep-0253.xml ├── xep-0254.xml ├── xep-0255.xml ├── xep-0256.xml ├── xep-0257.xml ├── xep-0258.xml ├── xep-0259.xml ├── xep-0260.xml ├── xep-0261.xml ├── xep-0262.xml ├── xep-0263.xml ├── xep-0264.xml ├── xep-0265.xml ├── xep-0266.xml ├── xep-0267.xml ├── xep-0268.xml ├── xep-0269.xml ├── xep-0270.xml ├── xep-0271.xml ├── xep-0272.xml ├── xep-0273.xml ├── xep-0274.xml ├── xep-0275.xml ├── xep-0276.xml ├── xep-0277.xml ├── xep-0278.xml ├── xep-0279.xml ├── xep-0280.xml ├── xep-0281.xml ├── xep-0282.xml ├── xep-0283.xml ├── xep-0284.xml ├── xep-0285.xml ├── xep-0286.xml ├── xep-0287.xml ├── xep-0288.xml ├── xep-0289.xml ├── xep-0290.xml ├── xep-0291.xml ├── xep-0292.xml ├── xep-0293.xml ├── xep-0294.xml ├── xep-0295.xml ├── xep-0296.xml ├── xep-0297.xml ├── xep-0298.xml ├── xep-0299.xml ├── xep-0300.xml ├── xep-0301.xml ├── xep-0302.xml ├── xep-0303.xml ├── xep-0304.xml ├── xep-0305.xml ├── xep-0306.xml ├── xep-0307.xml ├── xep-0308.xml ├── xep-0309.xml ├── xep-0310.xml ├── xep-0311.xml ├── xep-0312.xml ├── xep-0313.xml ├── xep-0314.xml ├── xep-0315.xml ├── xep-0316.xml ├── xep-0317.xml ├── xep-0318.xml ├── xep-0319.xml ├── xep-0320.xml ├── xep-0321.xml ├── xep-0322.xml ├── xep-0323.xml ├── xep-0324.xml ├── xep-0325.xml ├── xep-0326.xml ├── xep-0327.xml ├── xep-0328.xml ├── xep-0329.xml ├── xep-0330.xml ├── xep-0331.xml ├── xep-0332.xml ├── xep-0333.xml ├── xep-0334.xml ├── xep-0335.xml ├── xep-0336.xml ├── xep-0337.xml ├── xep-0338.xml ├── xep-0339.xml ├── xep-0340.xml ├── xep-0341.xml ├── xep-0342.xml ├── xep-0343.xml ├── xep-0344.xml ├── xep-0345.xml ├── xep-0346.xml ├── xep-0347.xml ├── xep-0348.xml ├── xep-0349.xml ├── xep-0350.xml ├── xep-0351.xml ├── xep-0352.xml ├── xep-0353.xml ├── xep-0354.xml ├── xep-0355.xml ├── xep-0356.xml ├── xep-0357.xml ├── xep-0358.xml ├── xep-0359.xml ├── xep-0360.xml ├── xep-0361.xml ├── xep-0362.xml ├── xep-0363.xml ├── xep-0364.xml ├── xep-0365.xml ├── xep-0366.xml ├── xep-0367.xml ├── xep-0368.xml ├── xep-0369.xml ├── xep-0370.xml ├── xep-0371.xml ├── xep-0372.xml ├── xep-0373.xml ├── xep-0374.xml ├── xep-0375.xml ├── xep-0376.xml ├── xep-0377.xml ├── xep-0378.xml ├── xep-0379.xml ├── xep-0380.xml ├── xep-0381.xml ├── xep-0382.xml ├── xep-0383.xml ├── xep-0384.xml ├── xep-0385.xml ├── xep-0386.xml ├── xep-0387.xml ├── xep-0388.xml ├── xep-0389.xml ├── xep-0390.xml ├── xep-0391.xml ├── xep-0392.xml ├── xep-0393.xml ├── xep-0394.xml ├── xep-0395.xml ├── xep-0396.xml ├── xep-0397.xml ├── xep-0398.xml ├── xep-0399.xml ├── xep-0400.xml ├── xep-0401.xml ├── xep-0402.xml ├── xep-0403.xml ├── xep-0404.xml ├── xep-0405.xml ├── xep-0406.xml ├── xep-0407.xml ├── xep-0408.xml ├── xep-0409.xml ├── xep-0410.xml ├── xep-0411.xml ├── xep-0412.xml ├── xep-0413.xml ├── xep-0414.xml ├── xep-0415.xml ├── xep-0416.xml ├── xep-0417.xml ├── xep-0418.xml ├── xep-0419.xml ├── xep-0420.xml ├── xep-0421.xml ├── xep-0422.xml ├── xep-0423.xml ├── xep-0424.xml ├── xep-0425.xml ├── xep-0426.xml ├── xep-0427.xml ├── xep-0428.xml ├── xep-0429.xml ├── xep-0430.xml ├── xep-0431.xml ├── xep-0432.xml ├── xep-0433.xml ├── xep-0434.xml ├── xep-0435.xml ├── xep-0436.xml ├── xep-0437.xml ├── xep-0438.xml ├── xep-0439.xml ├── xep-0440.xml ├── xep-0441.xml ├── xep-0442.xml ├── xep-0443.xml ├── xep-0444.xml ├── xep-0445.xml ├── xep-0446.xml ├── xep-0447.xml ├── xep-0448.xml ├── xep-0449.xml ├── xep-0450.xml ├── xep-0451.xml ├── xep-0452.xml ├── xep-0453.xml ├── xep-0454.xml ├── xep-0455.xml ├── xep-0456.xml ├── xep-0457.xml ├── xep-0458.xml ├── xep-0459.xml ├── xep-0460.xml ├── xep-0461.xml ├── xep-0462.xml ├── xep-0463.xml ├── xep-0464.xml ├── xep-0465.xml ├── xep-0466.xml ├── xep-0467.xml ├── xep-0468.xml ├── xep-0469.xml ├── xep-0470.xml ├── xep-0471.xml ├── xep-0472.xml ├── xep-0473.xml ├── xep-0474.xml ├── xep-0475.xml ├── xep-0476.xml ├── xep-0477.xml ├── xep-0478.xml ├── xep-0479.xml ├── xep-0480.xml ├── xep-0481.xml ├── xep-0482.xml ├── xep-0483.xml ├── xep-0484.xml ├── xep-0485.xml ├── xep-0486.xml ├── xep-0487.xml ├── xep-0488.xml ├── xep-0489.xml ├── xep-0490.xml ├── xep-0491.xml ├── xep-0492.xml ├── xep-0493.xml ├── xep-0494.xml ├── xep-0495.xml ├── xep-0496.xml ├── xep-0497.xml ├── xep-0498.xml ├── xep-0499.xml ├── xep-0500.xml ├── xep-0501.xml ├── xep-0502.xml ├── xep-0503.xml ├── xep-README.xml ├── xep-template.xml ├── xep.dtd ├── xep.ent ├── xep.xsd ├── xep.xsl ├── xep2texml.xsl ├── xepinfo.py ├── xeputil.py └── xmpp.css /.gitattributes: -------------------------------------------------------------------------------- 1 | *.xml text 2 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | **Note:** The issue tracker is only for tracking editorial and maintenance issues. Technical (protocol) issues need to be discussed on the official standards mailing list standards@xmpp.org (see more info here: https://mail.jabber.org/listinfo/standards/ ). 2 | 3 | **Examples of things which *do* belong here:** 4 | 5 | * Typographical issues in the XEPs (although a pull request would be more appreciated ;-)) 6 | * Issues with the XEP build process, (partially) the editor workflow (such as sending emails) 7 | * Things which need to be done by an editor, e.g. applying council decisions, applying automatic deferrals, etc. 8 | 9 | **Examples of things which *do not* belong here, but instead on standards@:** 10 | 11 | * "XEP X is missing feature Y" 12 | * "The way X is done in protocol Y described in XEP Z is imperfect, we should be doing W instead" 13 | 14 | Unsure? stop by in xmpp:xsf@muc.xmpp.org?join and ask what’s appropriate. We won’t bite. 15 | 16 | **Now for your actual issue** Please delete this part of the template once you’ve read it. 17 | 18 | --- 19 | 20 | * What is broken and where? e.g. Link to external resource XYZ is broken in XEP-2345 / What needs to be done? e.g. XEP-1234 needs to be Deprecated 21 | * If needed, please link the decision of the Approving Body 22 | -------------------------------------------------------------------------------- /.github/workflows/auto-triage.yml: -------------------------------------------------------------------------------- 1 | name: Triage 2 | on: 3 | pull_request_target: 4 | types: 5 | - opened 6 | - edited 7 | branches: 8 | - master 9 | paths: 10 | - 'xep-*.xml' 11 | jobs: 12 | label_pr: 13 | runs-on: ubuntu-latest 14 | permissions: 15 | pull-requests: write 16 | steps: 17 | - uses: awalsh128/cache-apt-pkgs-action@latest 18 | with: 19 | packages: libxml2-utils 20 | version: cachetag1 21 | - uses: actions/checkout@v4 22 | with: 23 | fetch-depth: 0 24 | - name: Copy trusted version of script 25 | run: cp tools/github_auto_triage_pr.sh /tmp 26 | - name: Setup PR branch locally 27 | run: gh pr checkout ${{ github.event.pull_request.number }} 28 | env: 29 | GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} 30 | GH_REPO: ${{ github.repository }} 31 | - run: bash /tmp/github_auto_triage_pr.sh ${{ github.event.pull_request.number }} 32 | env: 33 | GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} 34 | GH_REPO: ${{ github.repository }} 35 | -------------------------------------------------------------------------------- /.github/workflows/xep-validation.yml: -------------------------------------------------------------------------------- 1 | name: XEP validation 2 | 3 | on: 4 | pull_request: 5 | branches: 6 | - master 7 | 8 | jobs: 9 | build: 10 | runs-on: ubuntu-latest 11 | name: Validate any XEP changes 12 | steps: 13 | - uses: actions/checkout@v4 14 | with: 15 | fetch-depth: 0 16 | 17 | - name: Detect changes to XEP files 18 | id: changed-xeps 19 | uses: tj-actions/changed-files@v46 20 | with: 21 | files: | 22 | xep-*.xml 23 | inbox/* 24 | 25 | - name: Validate changed file(s) 26 | if: steps.changed-xeps.outputs.any_changed == 'true' 27 | env: 28 | ALL_CHANGED_FILES: ${{ steps.changed-xeps.outputs.all_changed_files }} 29 | run: | 30 | sudo apt-get install -y libxml2-utils 31 | result=0 32 | for xep in ${ALL_CHANGED_FILES}; do 33 | if ! tools/validate-xep0001-conformance.sh "$xep"; then 34 | result=1 35 | fi 36 | if [[ ${xep} == xep-* ]]; then 37 | echo Checking ${xep} by invoking \"make .${xep}.check.ok\" 38 | if ! make ".${xep}.check.ok"; then 39 | result=1 40 | fi 41 | fi 42 | done 43 | exit $result 44 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Python 2 | # https://github.com/github/gitignore/blob/master/Python.gitignore 3 | 4 | # Byte-compiled / optimized / DLL files 5 | __pycache__/ 6 | *.py[cod] 7 | *$py.class 8 | 9 | # C extensions 10 | *.so 11 | 12 | # Distribution / packaging 13 | .Python 14 | env/ 15 | build/ 16 | develop-eggs/ 17 | dist/ 18 | downloads/ 19 | eggs/ 20 | .eggs/ 21 | lib/ 22 | lib64/ 23 | parts/ 24 | sdist/ 25 | var/ 26 | *.egg-info/ 27 | .installed.cfg 28 | *.egg 29 | 30 | # PyInstaller 31 | # Usually these files are written by a python script from a template 32 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 33 | *.manifest 34 | *.spec 35 | 36 | # Installer logs 37 | pip-log.txt 38 | pip-delete-this-directory.txt 39 | 40 | # Unit test / coverage reports 41 | htmlcov/ 42 | .tox/ 43 | .coverage 44 | .coverage.* 45 | .cache 46 | nosetests.xml 47 | coverage.xml 48 | *,cover 49 | 50 | # Translations 51 | *.mo 52 | *.pot 53 | 54 | # Django stuff: 55 | *.log 56 | 57 | # Sphinx documentation 58 | docs/_build/ 59 | 60 | # PyBuilder 61 | target/ 62 | 63 | # Vim 64 | # https://github.com/github/gitignore/blob/master/Global/Vim.gitignore 65 | 66 | [._]*.s[a-w][a-z] 67 | [._]s[a-w][a-z] 68 | *.un~ 69 | Session.vim 70 | .netrwhist 71 | *~ 72 | 73 | *.pdf 74 | /tools/old-xeplist.xml 75 | /tools/xeps-email.conf 76 | /tmp/ 77 | /pr-worktree/ 78 | 79 | .*.xml.check.ok 80 | -------------------------------------------------------------------------------- /.gitlab-ci.yml: -------------------------------------------------------------------------------- 1 | stages: 2 | - build 3 | - export 4 | 5 | "build@main": 6 | image: registry.gitlab.com/xsf/docker-images/xep-buildspace/image:0.1.0 7 | stage: build 8 | script: 9 | - python3 tools/ci-restore-timestamps.py 10 | - make html inbox-html inbox-xml pdf xeplist refs xml 11 | - bash tools/ci-prune-build.sh 12 | rules: 13 | - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' 14 | when: never 15 | - if: '$CI_COMMIT_REF_NAME =~ /^main$/' 16 | when: always 17 | - when: never 18 | cache: 19 | key: build-cache 20 | paths: 21 | - build/ 22 | artifacts: 23 | paths: 24 | - build/ 25 | expire_in: '1 day' 26 | resource_group: xep-build 27 | 28 | "pack@main": 29 | image: docker:19.03.11 30 | stage: export 31 | services: 32 | - docker:19.03.11-dind 33 | script: 34 | - 'export IMAGE_REF="${CI_REGISTRY_IMAGE}/packed:main-$(date -Idate)-${CI_COMMIT_SHORT_SHA}"' 35 | - 'export LATEST_REF="${CI_REGISTRY_IMAGE}/packed:main-latest"' 36 | - 'docker build -t "$IMAGE_REF" -f pack-only.Dockerfile .' 37 | - 'docker image tag "$IMAGE_REF" "$LATEST_REF"' 38 | - 'docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY' 39 | - 'docker push "$IMAGE_REF"' 40 | - 'docker push "$LATEST_REF"' 41 | rules: 42 | - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' 43 | when: never 44 | - if: '$CI_COMMIT_REF_NAME =~ /^main$/' 45 | when: on_success 46 | - when: never 47 | resource_group: xep-pack 48 | 49 | "attic@main": 50 | image: python:3 51 | stage: export 52 | script: 53 | - bash -x ./tools/ci-archive.sh 54 | cache: 55 | paths: 56 | - state/ 57 | key: attic-state 58 | rules: 59 | - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' 60 | when: never 61 | - if: '$CI_COMMIT_REF_NAME =~ /^main$/' 62 | when: on_success 63 | - when: never 64 | resource_group: xep-attic 65 | 66 | "announce@main": 67 | image: python:3 68 | stage: export 69 | script: 70 | - bash -x ./tools/ci-announce.sh 71 | cache: 72 | paths: 73 | - state/ 74 | key: announce-state 75 | rules: 76 | - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' 77 | when: never 78 | - if: '$CI_COMMIT_REF_NAME =~ /^main$/' 79 | when: on_success 80 | - when: never 81 | resource_group: xep-announce 82 | 83 | "build@mr": 84 | image: registry.gitlab.com/xsf/docker-images/xep-buildspace-slim/image:0.1.1 85 | stage: build 86 | script: 87 | - python3 tools/ci-restore-timestamps.py 88 | - make html inbox-html 89 | - git fetch --depth=50 origin main 90 | - bash tools/ci-changed-builds.sh origin/main 91 | rules: 92 | - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' 93 | when: always 94 | - when: never 95 | cache: 96 | key: build-cache 97 | paths: 98 | - build/ 99 | policy: pull 100 | artifacts: 101 | expose_as: "Changed Documents" 102 | paths: ["rendered-changes/"] 103 | expire_in: '7 days' 104 | 105 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | sudo: required 2 | services: 3 | - docker 4 | before_install: 5 | - docker pull xmppxsf/xeps-base 6 | script: 7 | - docker build -t xmppxsf/xeps . 8 | -------------------------------------------------------------------------------- /Dockerfile: -------------------------------------------------------------------------------- 1 | # Builds all XEPs by default, HTML & PDF 2 | # docker build . --build-arg NCORES=X --build-arg TARGETS="html pdf" 3 | # from Dockerfile.base 4 | FROM xmppxsf/xeps-base:latest as build 5 | 6 | ARG NCORES=1 7 | ARG TARGETS="html inbox-html inbox-xml pdf xeplist refs xml" 8 | 9 | COPY *.xml xep.* *.css *.xsl *.js *.xsl Makefile /src/ 10 | COPY resources/*.pdf /src/resources/ 11 | COPY tools/*.py /src/tools/ 12 | COPY inbox/*.xml inbox/*.ent inbox/*.dtd /src/inbox/ 13 | COPY texml-xsl/*.xsl /src/texml-xsl/ 14 | 15 | WORKDIR /src 16 | RUN OUTDIR=/var/www/html/extensions/ make -j$NCORES $TARGETS 17 | RUN bash -c 'rm -f /var/www/html/extensions/*.{log,aux,toc,tex,tex.xml,out}' 18 | 19 | FROM nginx:1-alpine 20 | RUN mkdir /usr/share/nginx/html/extensions/ 21 | COPY --from=build /var/www/html/extensions/ /usr/share/nginx/html/extensions/ 22 | RUN sed -ri '/root\s+\/usr\/share\/nginx\/html/s/^(.+)$/\1\nautoindex on;/' /etc/nginx/conf.d/default.conf 23 | EXPOSE 80 24 | -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | 2 | Unless otherwise indicated, all files in this repository are XMPP 3 | Extension Protocols (XEPs) published by the XMPP Standards Foundation 4 | in accordance with the XSF's Intellectual Property Rights Policy. The 5 | following copyrights, permissions, warranty, liability statement, and 6 | conformance statement apply to all XEPs. 7 | 8 | #### 9 | 10 | This XMPP Extension Protocol is copyright (c) 1999 - 2020 by the XMPP 11 | Standards Foundation (XSF). 12 | 13 | Permission is hereby granted, free of charge, to any person obtaining 14 | a copy of this specification (the "Specification"), to make use of the 15 | Specification without restriction, including without limitation the 16 | rights to implement the Specification in a software program, deploy the 17 | Specification in a network service, and copy, modify, merge, publish, 18 | translate, distribute, sublicense, or sell copies of the Specification, 19 | and to permit persons to whom the Specification is furnished to do so, 20 | subject to the condition that the foregoing copyright notice and this 21 | permission notice shall be included in all copies or substantial portions 22 | of the Specification. Unless separate permission is granted, modified 23 | works that are redistributed shall not contain misleading information 24 | regarding the authors, title, number, or publisher of the Specification, 25 | and shall not claim endorsement of the modified works by the authors, any 26 | organization or project to which the authors belong, or the XMPP Standards 27 | Foundation. 28 | 29 | ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, 30 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, 31 | including, without limitation, any warranties or conditions of TITLE, 32 | NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. 33 | In no event shall the XMPP Standards Foundation or the authors of this 34 | Specification be liable for any claim, damages, or other liability, 35 | whether in an action of contract, tort, or otherwise, arising from, out 36 | of, or in connection with the Specification or the implementation, 37 | deployment, or other use of the Specification. ## 38 | 39 | In no event and under no legal theory, whether in tort (including 40 | negligence), contract, or otherwise, unless required by applicable law 41 | (such as deliberate and grossly negligent acts) or agreed to in writing, 42 | shall the XMPP Standards Foundation or any author of this Specification 43 | be liable for damages, including any direct, indirect, special, 44 | incidental, or consequential damages of any character arising out of the 45 | use or inability to use the Specification (including but not limited to 46 | damages for loss of goodwill, work stoppage, computer failure or 47 | malfunction, or any and all other commercial damages or losses), even if 48 | the XMPP Standards Foundation or such author has been advised of the 49 | possibility of such damages. 50 | 51 | This XMPP Extension Protocol has been contributed in full conformance 52 | with the XSF's Intellectual Property Rights Policy (a copy of which may 53 | be found at https://xmpp.org/about/xsf/ipr-policy/ or obtained 54 | by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). 55 | 56 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![Docker Build Status](https://img.shields.io/docker/build/xmppxsf/xeps.svg)](https://hub.docker.com/r/xmppxsf/xeps/) 2 | [![Build Status](https://img.shields.io/travis/xsf/xeps.svg)](https://travis-ci.org/xsf/xeps) 3 | 4 | XMPP Extension Protocols (XEPs) 5 | =============================== 6 | 7 | About 8 | ----- 9 | 10 | This repository is used to manage work on XMPP Extension Protocols 11 | (XEPs), which are the specifications produced by the XMPP Standards 12 | Foundation (XSF). See http://xmpp.org/ for details. The rendered 13 | documents can be found here: 14 | 15 | https://xmpp.org/extensions/ 16 | 17 | Contribution 18 | ------------ 19 | 20 | Please use this repository to raise issues and submit pull requests: 21 | 22 | https://github.com/xsf/xeps/issues 23 | https://github.com/xsf/xeps/pulls 24 | 25 | For in-depth technical discussion, please post to the standards@xmpp.org 26 | email list: 27 | 28 | https://mail.jabber.org/mailman/listinfo/standards 29 | 30 | To submit a new proposal for consideration as a XEP, please read this 31 | page: 32 | 33 | https://xmpp.org/about/standards-process.html#submitting-a-xep 34 | 35 | [XEP-0001: XMPP Extension Protocols](https://xmpp.org/extensions/xep-0001.html) 36 | defines the standards process followed by the XMPP Standards Foundation. 37 | 38 | 39 | Editor 40 | ------ 41 | 42 | Documentation for Editors is in the [docs](docs/) folder. 43 | 44 | 45 | [modeline]: # ( vim: set fenc=utf-8 ff=unix spell spl=en textwidth=80: ) 46 | -------------------------------------------------------------------------------- /archive.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | # archive an old version of a XEP (before publishing new version) 3 | # usage: ./archive.sh xepnum version 4 | 5 | ## LICENSE ## 6 | # 7 | # Copyright (c) 1999 - 2010 XMPP Standards Foundation 8 | # 9 | # Permission is hereby granted, free of charge, to any person obtaining a copy 10 | # of this software and associated documentation files (the "Software"), to deal 11 | # in the Software without restriction, including without limitation the rights 12 | # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 13 | # copies of the Software, and to permit persons to whom the Software is 14 | # furnished to do so, subject to the following conditions: 15 | # 16 | # The above copyright notice and this permission notice shall be included in 17 | # all copies or substantial portions of the Software. 18 | # 19 | # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 20 | # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 21 | # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 22 | # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 23 | # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 24 | # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 25 | # THE SOFTWARE. 26 | # 27 | ## END LICENSE ## 28 | 29 | xeppath=/var/www/vhosts/xmpp.org/extensions 30 | 31 | cp $xeppath/xep-$1.html $xeppath/attic/xep-$1-$2.html 32 | 33 | # end 34 | -------------------------------------------------------------------------------- /checkdeadlinks.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | 3 | # File: checkdeadlinks.py 4 | # Version: 0.1 5 | # Description: a script for checking XEPs for dead links 6 | # Last Modified: 2016-10-03 7 | # Author: Tobias Markmann (tm@ayena.de) 8 | # License: public domain 9 | # HowTo: ./checkdeadlinks.py --xep=xepnum 10 | 11 | ## LICENSE ## 12 | # 13 | # Copyright (c) 1999 - 2010 XMPP Standards Foundation 14 | # 15 | # Permission is hereby granted, free of charge, to any person obtaining a copy 16 | # of this software and associated documentation files (the "Software"), to deal 17 | # in the Software without restriction, including without limitation the rights 18 | # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 19 | # copies of the Software, and to permit persons to whom the Software is 20 | # furnished to do so, subject to the following conditions: 21 | # 22 | # The above copyright notice and this permission notice shall be included in 23 | # all copies or substantial portions of the Software. 24 | # 25 | # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 26 | # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 27 | # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 28 | # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 29 | # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 30 | # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 31 | # THE SOFTWARE. 32 | # 33 | ## END LICENSE ## 34 | 35 | ''' 36 | A script for checking XEPs for dead links. 37 | ''' 38 | 39 | from __future__ import print_function 40 | 41 | from argparse import ArgumentParser 42 | import sys 43 | import re 44 | 45 | from xml.dom.minidom import parse 46 | 47 | try: 48 | from urllib.request import Request, urlopen 49 | except ImportError: 50 | # We are on python2 51 | from urllib2 import Request, urlopen 52 | 53 | def is_dead(url): 54 | if re.match("^(http|https)", url): 55 | if verbose: 56 | print(url + ' :', end=' ') 57 | try: 58 | request = Request(url) 59 | request.add_header('User-Agent', "Mozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101") 60 | urlopen(request).read() 61 | except Exception as e: 62 | reason = str(e) 63 | if verbose: 64 | print("XEP-" + xepnum + " - DEAD: " + url + " [" + reason + "]") 65 | return True 66 | else: 67 | if verbose: 68 | print('OK') 69 | return False 70 | else: 71 | return False 72 | 73 | def get_deadlinks(xep, is_verbose=False): 74 | global xepnum 75 | xepnum = '%04d' % xep 76 | 77 | global verbose 78 | verbose = is_verbose 79 | 80 | xepfile = 'xep-' + xepnum + '.xml' 81 | thexep = parse(xepfile) 82 | 83 | urls = [link.getAttribute("url") for link in thexep.getElementsByTagName("link")] 84 | urls += [image.getAttribute("src") for image in thexep.getElementsByTagName("img")] 85 | 86 | if verbose: 87 | print('Checking XEP-%s (%d links):' % (xepnum, len(urls))) 88 | 89 | return [url for url in set(urls) if is_dead(url)] 90 | 91 | def main(): 92 | parser = ArgumentParser(description=__doc__) 93 | parser.add_argument('-v', '--verbose', action='store_true', help='Enables more verbosity') 94 | parser.add_argument('-x', '--xep', type=int, help='Defines the number of the XEP to check') 95 | args = parser.parse_args() 96 | 97 | deadlinks = get_deadlinks(args.xep, args.verbose) 98 | 99 | if deadlinks: 100 | for url in deadlinks: 101 | print(url) 102 | sys.exit(1) 103 | 104 | if __name__ == "__main__": 105 | main() 106 | -------------------------------------------------------------------------------- /deferred.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | 3 | # File: deferred.py 4 | # Version: 0.3 5 | # Description: a script for setting a XEP to Deferred 6 | # Last Modified: 2006-11-01 7 | # Author: Peter Saint-Andre (stpeter@jabber.org) 8 | # License: public domain 9 | # HowTo: ./deferred.py xepnum 10 | 11 | ## LICENSE ## 12 | # 13 | # Copyright (c) 1999 - 2010 XMPP Standards Foundation 14 | # 15 | # Permission is hereby granted, free of charge, to any person obtaining a copy 16 | # of this software and associated documentation files (the "Software"), to deal 17 | # in the Software without restriction, including without limitation the rights 18 | # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 19 | # copies of the Software, and to permit persons to whom the Software is 20 | # furnished to do so, subject to the following conditions: 21 | # 22 | # The above copyright notice and this permission notice shall be included in 23 | # all copies or substantial portions of the Software. 24 | # 25 | # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 26 | # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 27 | # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 28 | # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 29 | # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 30 | # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 31 | # THE SOFTWARE. 32 | # 33 | ## END LICENSE ## 34 | 35 | # IMPORTS: 36 | # 37 | import glob 38 | import os 39 | from select import select 40 | import smtplib 41 | import socket 42 | from string import split,strip,join,find 43 | import sys 44 | import time 45 | from xml.dom.minidom import parse,parseString,Document 46 | 47 | def getText(nodelist): 48 | thisText = "" 49 | for node in nodelist: 50 | if node.nodeType == node.TEXT_NODE: 51 | thisText = thisText + node.data 52 | return thisText 53 | 54 | # get the seconds in the Unix era 55 | now = int(time.time()) 56 | 57 | # READ IN ARGS: 58 | # 59 | # 1. XEP number 60 | 61 | xepnum = sys.argv[1]; 62 | 63 | xepfile = 'xep-' + xepnum + '.xml' 64 | 65 | # PARSE XEP HEADERS: 66 | # 67 | # - title 68 | # - abstract 69 | # - version 70 | # - date 71 | # - initials 72 | # - remark 73 | 74 | thexep = parse(xepfile) 75 | xepNode = (thexep.getElementsByTagName("xep")[0]) 76 | headerNode = (xepNode.getElementsByTagName("header")[0]) 77 | titleNode = (headerNode.getElementsByTagName("title")[0]) 78 | title = getText(titleNode.childNodes) 79 | abstractNode = (headerNode.getElementsByTagName("abstract")[0]) 80 | abstract = getText(abstractNode.childNodes) 81 | statusNode = (headerNode.getElementsByTagName("status")[0]) 82 | xepstatus = getText(statusNode.childNodes) 83 | typeNode = (headerNode.getElementsByTagName("type")[0]) 84 | xeptype = getText(typeNode.childNodes) 85 | revNode = (headerNode.getElementsByTagName("revision")[0]) 86 | versionNode = (revNode.getElementsByTagName("version")[0]) 87 | version = getText(versionNode.childNodes) 88 | dateNode = (revNode.getElementsByTagName("date")[0]) 89 | date = getText(dateNode.childNodes) 90 | initialsNode = (revNode.getElementsByTagName("initials")[0]) 91 | initials = getText(initialsNode.childNodes) 92 | remarkNode = (revNode.getElementsByTagName("remark")[0]) 93 | remark = getText(remarkNode.childNodes) 94 | 95 | # SEND MAIL: 96 | # 97 | # From: editor@xmpp.org 98 | # To: standards@xmpp.org 99 | # Subject: DEFERRED: XEP-$xepnum ($title) 100 | # Body: 101 | # XEP-$xepnum ($title) has been Deferred because of inactivity. 102 | # 103 | # Abstract: $abstract 104 | # 105 | # URL: https://xmpp.org/extensions/xep-$xepnum.html 106 | # 107 | # If and when a new revision of this XEP is published, 108 | # its status will be changed back to Experimental. 109 | # 110 | 111 | fromaddr = "editor@xmpp.org" 112 | # for testing... 113 | # toaddrs = "stpeter@jabber.org" 114 | # for real... 115 | toaddrs = "standards@xmpp.org" 116 | 117 | thesubject = 'DEFERRED: XEP-' + xepnum + " (" + title + ")" 118 | introline = 'XEP-' + xepnum + ' (' + title + ') has been Deferred because of inactivity.' 119 | abstractline = 'Abstract: ' + abstract 120 | urlline = 'URL: https://xmpp.org/extensions/xep-' + xepnum + '.html' 121 | endline = 'If and when a new revision of this XEP is published, its status will be changed back to Experimental.' 122 | 123 | #msg = "From: %s\r\n" % fromaddr 124 | msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr 125 | msg = msg + "To: %s\r\n" % toaddrs 126 | msg = msg + "Subject: %s\r\n" % thesubject 127 | msg = msg + introline 128 | msg = msg + "\r\n\n" 129 | msg = msg + abstractline 130 | msg = msg + "\r\n\n" 131 | msg = msg + urlline 132 | msg = msg + "\r\n\n" 133 | msg = msg + endline 134 | msg = msg + "\r\n" 135 | 136 | server = smtplib.SMTP('localhost') 137 | server.set_debuglevel(1) 138 | server.sendmail(fromaddr, toaddrs, msg) 139 | server.quit() 140 | 141 | # END 142 | 143 | -------------------------------------------------------------------------------- /deps/tc-dvips.def: -------------------------------------------------------------------------------- 1 | %% Copyright (C) 2011-2012 by Martin Scharrer 2 | %% ---------------------------------------------------------------------- 3 | %% This work may be distributed and/or modified under the 4 | %% conditions of the LaTeX Project Public License, either version 1.3 5 | %% of this license or (at your option) any later version. 6 | %% The latest version of this license is in 7 | %% http://www.latex-project.org/lppl.txt 8 | %% and version 1.3 or later is part of all distributions of LaTeX 9 | %% version 2005/12/01 or later. 10 | %% 11 | %% This work has the LPPL maintenance status `maintained'. 12 | %% 13 | %% The Current Maintainer of this work is Martin Scharrer. 14 | %% 15 | %% This work consists of the files trimclip.dtx, adjustbox.ins 16 | %% and the derived files trimclip.sty, 17 | %% tc-dvips.def, tc-pdftex.def, tc-pgf.def and tc-xetex.def. 18 | %% Further author information are located in the .def files. 19 | %% 20 | \ProvidesFile{tc-dvips.def}[2012/05/13 v1.0 Clipping driver for dvips] 21 | \def\@cliptoboxdim#1{% 22 | \setbox#1=\hbox{% 23 | \adjsetlength\@tempdima{\ht#1+\dp#1}% 24 | \edef\TOTALHEIGHT{-\strip@pt\@tempdima\space}% 25 | \edef\DEPTH{\strip@pt\dp#1\space}% 26 | \edef\WIDTH{\strip@pt\wd#1\space}% 27 | \special{% 28 | ps: 29 | /mtrxc matrix currentmatrix def 30 | currentpoint gsave 31 | translate 32 | Resolution 72 div VResolution 72 div 33 | scale 34 | newpath 35 | 0 \DEPTH \WIDTH \TOTALHEIGHT rectclip 36 | newpath 37 | mtrxc setmatrix 38 | }% 39 | \box#1% 40 | \special{ps: grestore }% 41 | }% 42 | } 43 | \endinput 44 | %% 45 | %% End of file `tc-dvips.def'. 46 | -------------------------------------------------------------------------------- /deps/tc-pdftex.def: -------------------------------------------------------------------------------- 1 | %% Copyright (C) 2011-2012 by Martin Scharrer 2 | %% ---------------------------------------------------------------------- 3 | %% This work may be distributed and/or modified under the 4 | %% conditions of the LaTeX Project Public License, either version 1.3 5 | %% of this license or (at your option) any later version. 6 | %% The latest version of this license is in 7 | %% http://www.latex-project.org/lppl.txt 8 | %% and version 1.3 or later is part of all distributions of LaTeX 9 | %% version 2005/12/01 or later. 10 | %% 11 | %% This work has the LPPL maintenance status `maintained'. 12 | %% 13 | %% The Current Maintainer of this work is Martin Scharrer. 14 | %% 15 | %% This work consists of the files trimclip.dtx, adjustbox.ins 16 | %% and the derived files trimclip.sty, 17 | %% tc-dvips.def, tc-pdftex.def, tc-pgf.def and tc-xetex.def. 18 | %% Further author information are located in the .def files. 19 | %% 20 | \ProvidesFile{tc-pdftex.def}[2012/05/13 v1.0 Clipping driver for pdftex] 21 | \def\@cliptoboxdim#1{% 22 | \setbox#1=\hbox{% 23 | \Gin@defaultbp\WIDTH{\wd#1}% 24 | \Gin@defaultbp\DEPTH{\dp#1}% 25 | \@tempdima\ht#1% 26 | \advance\@tempdima\dp#1% 27 | \Gin@defaultbp\TOTALHEIGHT{\@tempdima}% 28 | \pdfsave 29 | \pdfliteral direct {% 30 | 0 -\DEPTH\space \WIDTH\space \TOTALHEIGHT\space re W n 31 | }% 32 | \hbox to 0pt{\copy#1\hss}% 33 | \pdfrestore 34 | \hskip \wd#1 35 | }% 36 | } 37 | \endinput 38 | %% 39 | %% End of file `tc-pdftex.def'. 40 | -------------------------------------------------------------------------------- /deps/tc-pgf.def: -------------------------------------------------------------------------------- 1 | %% Copyright (C) 2011-2012 by Martin Scharrer 2 | %% ---------------------------------------------------------------------- 3 | %% This work may be distributed and/or modified under the 4 | %% conditions of the LaTeX Project Public License, either version 1.3 5 | %% of this license or (at your option) any later version. 6 | %% The latest version of this license is in 7 | %% http://www.latex-project.org/lppl.txt 8 | %% and version 1.3 or later is part of all distributions of LaTeX 9 | %% version 2005/12/01 or later. 10 | %% 11 | %% This work has the LPPL maintenance status `maintained'. 12 | %% 13 | %% The Current Maintainer of this work is Martin Scharrer. 14 | %% 15 | %% This work consists of the files trimclip.dtx, adjustbox.ins 16 | %% and the derived files trimclip.sty, 17 | %% tc-dvips.def, tc-pdftex.def, tc-pgf.def and tc-xetex.def. 18 | %% Further author information are located in the .def files. 19 | %% 20 | \ProvidesFile{tc-pgf.def}[2012/05/13 v1.0 trimclip fall-back clipping driver using PGF] 21 | \RequirePackage{pgf} 22 | \def\@cliptoboxdim#1{% 23 | \setbox#1\hbox{\begin{pgfpicture}% 24 | \pgfpathmoveto{\pgfqpoint\z@{-\dp#1}}% 25 | \pgfpathlineto{\pgfqpoint\z@{\ht#1}}% 26 | \pgfpathlineto{\pgfqpoint{\wd#1}{\ht#1}}% 27 | \pgfpathlineto{\pgfqpoint{\wd#1}{-\dp#1}}% 28 | \pgfpathclose 29 | \pgfusepathqclip 30 | \pgfset{inner sep=\z@,outer sep=\z@,minimum size=\z@}% 31 | \pgfnode{rectangle}{base west}{\usebox#1}{}{}% 32 | \pgfsetbaselinepointnow{\pgfpoint\z@\z@}% 33 | \end{pgfpicture}}% 34 | } 35 | \endinput 36 | %% 37 | %% End of file `tc-pgf.def'. 38 | -------------------------------------------------------------------------------- /deps/tc-xetex.def: -------------------------------------------------------------------------------- 1 | %% Copyright (C) 2011-2012 by Martin Scharrer 2 | %% ---------------------------------------------------------------------- 3 | %% This work may be distributed and/or modified under the 4 | %% conditions of the LaTeX Project Public License, either version 1.3 5 | %% of this license or (at your option) any later version. 6 | %% The latest version of this license is in 7 | %% http://www.latex-project.org/lppl.txt 8 | %% and version 1.3 or later is part of all distributions of LaTeX 9 | %% version 2005/12/01 or later. 10 | %% 11 | %% This work has the LPPL maintenance status `maintained'. 12 | %% 13 | %% The Current Maintainer of this work is Martin Scharrer. 14 | %% 15 | %% This work consists of the files trimclip.dtx, adjustbox.ins 16 | %% and the derived files trimclip.sty, 17 | %% tc-dvips.def, tc-pdftex.def, tc-pgf.def and tc-xetex.def. 18 | %% Further author information are located in the .def files. 19 | %% 20 | \ProvidesFile{tc-xetex.def}[2012/05/13 v1.0 Clipping driver for xetex] 21 | \def\@cliptoboxdim#1{% 22 | \setbox#1=\hbox{% 23 | \Gin@defaultbp\WIDTH{\wd#1}% 24 | \Gin@defaultbp\DEPTH{\dp#1}% 25 | \@tempdima\ht#1% 26 | \advance\@tempdima\dp#1% 27 | \Gin@defaultbp\TOTALHEIGHT{\@tempdima}% 28 | \special{pdf:bcontent }% 29 | \special{% 30 | pdf:literal direct 31 | 0 -\DEPTH\space \WIDTH\space \TOTALHEIGHT\space re 32 | }% 33 | \special{pdf:literal direct W }% 34 | \special{pdf:literal direct n }% 35 | \box#1% 36 | \special{pdf:econtent }% 37 | }% 38 | } 39 | \endinput 40 | %% 41 | %% End of file `tc-xetex.def'. 42 | -------------------------------------------------------------------------------- /docs/MODERATION.md: -------------------------------------------------------------------------------- 1 | # Moderation 2 | 3 | ## Discussions 4 | 5 | Technical discussions SHOULD NOT happen in the xeps repository. If you see a 6 | discussion evolve into technical (as opposed to editorial) matters, do the 7 | following: 8 | 9 | 1. Lock the conversation. 10 | 2. Copy the technical discussion parts into an email to standards@. My 11 | preferred format for this would be something along the lines of: 12 | 13 | Subject: [insert PR title here, or something more appropriate] 14 | 15 | There was some discussion on the xeps repository an XEP-1234, which got 16 | technical. I moved this discussion to standards@ so that the whole 17 | community is aware of the issue and can participate. 18 | 19 | @user1 wrote: 20 | > quote user1 here ... 21 | 22 | @user2 wrote: 23 | > quote user2 here ... 24 | 25 | Remove clearly editorial discussion and mark the removal with ``[…]``. 26 | 27 | 3. Add the [Needs List Discussion] label to the PR and link the standards@ 28 | thread you just created. Remove other labels (such as [Needs Author]). 29 | 30 | 4. Monitor the thread; when the discussion is resolved, the PR opener will 31 | usually prepare an update. Unlock the conversation to allow editorial 32 | discussion to continue, if needed. Remove the [Needs List Discussion] label 33 | and re-triage the PR as described above. 34 | 35 | **Note:** The locking is mostly used here as a tool to avoid a race 36 | condition, not to exclude people from participating. (It would be 37 | unfortunate if you had to add more comments to your already-sent email.) 38 | Feel free to unlock at some point during the list discussion when you’re 39 | sure that all participants have taken note of the move. 40 | -------------------------------------------------------------------------------- /docs/README.md: -------------------------------------------------------------------------------- 1 | Editor Guide 2 | ============ 3 | 4 | The XMPP Extensions Editor (or, for short, XEP Editor) manages the XMPP 5 | extensions process as defined in XMPP Extension Protocols ([XEP-0001]). 6 | In addition, the XEP Editor functions as the XMPP Registrar as defined in XMPP 7 | Registrar Function ([XEP-0053]). 8 | Read those documents first, since this README focuses on mechanics instead of 9 | philosophy or policy. 10 | 11 | 12 | This is the entrypoint definitive guide for Editors. 13 | 14 | - [Using the repository](REPOSITORY.md) 15 | 16 | Information about how to build XEPs and how the repository is laid out. 17 | 18 | 24 | 25 | - [Triaging](TRIAGING.md) 26 | 27 | Rules for labelling and guiding inbound Pull Requests (Merge Requests). 28 | 29 | - [Processing](PROCESSING.md) 30 | 31 | Rules and guidelines for processing inbound Pull Requests (Merge Requests) 32 | towards master/main. 33 | 34 | - [Moderation](MODERATION.md) 35 | 36 | Rules and guidelines for moderating the discussions in the PRs. 37 | 38 | 39 | [XEP-0053]: https://xmpp.org/extensions/xep-0053.html 40 | -------------------------------------------------------------------------------- /docs/REPOSITORY.md: -------------------------------------------------------------------------------- 1 | Using the repository 2 | ==================== 3 | 4 | Building XEPs 5 | ------------- 6 | 7 | You'll need xmllint and xsltproc. 8 | 9 | On Ubuntu, you can install them with `sudo apt install libxml2-utils xsltproc` 10 | 11 | To build a single XEP as HTML simply run: 12 | 13 | make xep-xxxx.html 14 | 15 | To build PDFs, you'll need to install [TeXML](http://getfo.org/texml/) (probably 16 | in a Python 2 virtual environment). 17 | You can then build PDFs with: 18 | 19 | make xep-xxxx.pdf 20 | 21 | To change the output directory, set the variable `OUTDIR`, eg. 22 | 23 | OUTDIR=/tmp/xeps make all 24 | 25 | For more information try `make help`. 26 | 27 | Using Docker 28 | ------------ 29 | 30 | A full set of HTML and PDFs can be generated inside a docker container, with no 31 | dependencies on the host other than Docker itself, and served by nginx in the 32 | container. To build the template `make docker`, to run it `make testdocker` 33 | (serves on http://localhost:3080), and to stop/delete it afterwards `make 34 | stopdocker` 35 | -------------------------------------------------------------------------------- /examples.xsl: -------------------------------------------------------------------------------- 1 | 2 | 3 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | These are the examples for XSF XEP-: 35 | 36 | 37 | 38 | 39 | 40 | 41 | Example 42 | 43 | 44 | 45 | 46 | -------------------------------------------------------------------------------- /inbox/bookmark-pinning.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | %ents; 6 | ]> 7 | 8 | 9 |
10 | Bookmark Pinning 11 | This document defines an XMPP protocol extension to allow users to pin PEP Native Bookmarks. 12 | &LEGALNOTICE; 13 | xxxx 14 | ProtoXEP 15 | Standards Track 16 | Standards 17 | Council 18 | 19 | XMPP Core 20 | XMPP IM 21 | XEP-0402 22 | 23 | 24 | 25 | bookmarkspinning 26 | &edhelas; 27 | 28 | 0.0.1 29 | 2020-05-17 30 | am 31 |

Initial version.

 32 | 33 |
34 | 35 |

The &xep0402; defines a way to store Bookmarks using user PEP nodes and brings a support for extensions

36 |

Some users might be interested to pin some important Bookmarks when managing them.

37 | 38 | 39 |

This extensions allow clients to pin important bookmarks.

40 | 41 | 42 |

When saving a &xep0402; pinned item the client MUST add a new 'pinned' element within the 'extensions' element having the '&namespace;' namespace.

43 | 45 | 46 | 47 | 48 | 51 | JC 52 | 53 | 54 | 55 | 56 | 57 | 58 | ... 59 | 60 | 61 | ]]> 62 | 63 | 64 |

When handling a pinned item, a client SHOULD prioritize it and treat it as important. A client MAY display it using visual specificities (e.g., ordering, icon, color) to differenciate it from non-pinned items.

65 | 66 | 67 |

See considerations in &xep0402;.

68 | 69 | 70 |

This document requires no interaction with &IANA;.

71 | 72 | 73 | 74 |

This specification defines the following XML namespace:

75 |
    76 |
  • &namespace;
    • 77 |
78 |

The ®ISTRAR; includes this namespace in the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

79 | 80 | 81 | &NSVER; 82 | 83 | 84 | 85 | 87 | 88 | 93 | 94 | 95 | 96 | The protocol documented by this schema is defined in 97 | XEP-0402: http://www.xmpp.org/extensions/xep-0402.html 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | ]]> 111 | 112 | 113 | -------------------------------------------------------------------------------- /inbox/bookmarks-conversion.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
9 | Bookmarks Conversion 10 | This specification describes a method to migrate to PEP based bookmarks without loosing compatibility with client that still use Private XML. 11 | &LEGALNOTICE; 12 | xxxx 13 | ProtoXEP 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XEP-0084 20 | XEP-0153 21 | 22 | 23 | 24 | bookmarks-conversion 25 | 26 | Daniel 27 | Gultsch 28 | daniel@gultsch.de 29 | daniel@gultsch.de 30 | 31 | 32 | 0.1.0 33 | 2018-09-18 34 | dg 35 |

First draft.

 36 | 37 |
38 | 39 |

&xep0048; has a long time ago moved from &xep0049; as a storage backend to using &xep0163; instead. However lots of implementations are still using Private XML which creates a bit of a chicken and egg problem since clients who want to use the more efficient PEP method would either have to support both and synchronize them properly or render themselves incompatible with other clients. An easy way out of that conundrum is to have the server do the conversion for us.

40 |

This XEP defines a method to convert between the different storage backends of XEP-0048 and is not influenced by the existence of &xep0402;. Bookmarks 2 defines its own conversion mechanism but the adoption of Bookmarks 2 - at the time of writing this XEP - is questionable.

41 | 42 | 43 |

The conversion is transparent to the publishing entity. However an entity might want to discover if a service will be performing the conversion and soley rely on PEP to access bookmarks without segregating clients that only support Private XML.

44 |

The service MUST include a &xep0030; feature of "urn:xmpp:bookmarks-conversion:0" on the account.

45 | 50 | 51 | ]]> 52 | 57 | 58 | 59 | 60 | ]]> 61 | 62 | 63 |

Modern clients are expected to use PEP (XEP-0084) as interface to upload and retrieve their bookmarks and not explicitly request bookmarks from private XML anymore. Thus a service MUST support conversion from PEP to Private XML and vice versa. Whether PEP and Private XML are fed from the same data source or if they get copied over when ever one of them gets written is out of scope of this document.

64 |

When a legacy client modifies bookmarks over Private XML the service MUST send out notification messages to all subscribers of the 'storage:bookmarks' node.

65 | 66 | 67 |

For server implementations where the data is just copied over the server should make sure that the data gets copied from Private XML to PEP before the user logs in for the first time. Otherwise it won’t generate a PEP notification and clients that only rely on PEP will not be aware of any preexisting bookmarks.

68 | 69 | 70 |

PEP nodes can have an access model other than 'whitelist'. When copying data over from Private XML Storage to PEP the service MUST make that the user is the only one who has access to that node. This can happen by either changing the access model accordingly or not doing the conversion.

71 | 72 | 73 |

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

74 | 75 | 76 |

This specification defines the following XML namespace:

77 |
    78 |
  • urn:xmpp:bookmarks-conversion:0
    • 79 |
80 | 81 | 82 |

tbd

83 | 84 | 85 |

Special thanks to Emmanuel Gil Peyrot who created a proof of concept module for Prosody.

86 | 87 | 88 | -------------------------------------------------------------------------------- /inbox/fulltext.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | 6 | 7 | ]> 8 | 9 | 10 |
11 | Full Text Search in MAM 12 | This specification proposes a field in the MAM form for full text searching. 13 | &LEGALNOTICE; 14 | XXXX 15 | ProtoXEP 16 | Standards Track 17 | Standards 18 | 19 | XMPP Core 20 | XEP-0313 21 | 22 | 23 | 24 | fulltextmam 25 | &dcridland; 26 | 27 | 0.0.1 28 | 2020-01-21 29 | dwd 30 | 31 |
    32 |
  • Initial Revision
    • 33 |
34 | 35 | 36 |
37 | 38 | 39 |

&xep0313; has an extensible form. This specification extends the extensible form with an extension which extends MAM to perform full text searching. A number of existing implementations of this extension exist - extending their existing extensions to confirm to the extension in this specification now it exists is intended to be trivial.

40 | 41 | 42 | 43 | 44 |

Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature 45 | of &ns;.

46 | 47 | 48 |

Searching using full text is performed by the client supplying an additional text key, which if non-empty is used as input to a full text search of some form. The precise meaning of this field is left entirely implementation-defined at this time. Future revisions of this specification might impose additional constraints.

49 | 50 | 51 | 52 | 53 | 54 |

A text input field of {&ns;}fulltext is hereby defined for the 'urn:xmpp:mam:2' FORM_TYPE, as conforming to the syntax defined in &xep0068;

55 | 56 | 57 |

The precise matching of the supplied text string is left implementation-defined. Servers MAY use any full-text search engine. While this might mean that certain characters are deemed "special", clients are RECOMMENDED not to attempt any support for these, as they are unlikely to be portable between implementations. A conformant implementation of this protocol could be made, therefore, by accepting any string in the text field and returning nothing (or everything). Any server developer implementing this protocol in such a way MUST buy beers for everyone.

58 | 59 | 60 | 61 | 62 |

Not sure this is needed at all.

63 | 64 | 65 | 66 |

None?

67 | 68 | 69 | 70 |

This XEP requires no interaction with &IANA;.

71 | 72 | 73 | 74 |

Registration of the field pointing to this document.

75 | 76 | 77 | 78 |

Guus der Kinderen nudged me into doing this.

79 | 80 | 81 | 82 | -------------------------------------------------------------------------------- /inbox/gdpr.xml: -------------------------------------------------------------------------------- 1 |  2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
9 | Best practices for GDPR compliant deployment of XMPP 10 | This informational XEP provides information on deploying XMPP in way that is compliant with the General Data Protection Regulation (GDPR) of the European Union. 11 | &LEGALNOTICE; 12 | xxxx 13 | ProtoXEP 14 | Informational 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XEP-0001 20 | 21 | 22 | 23 | NOT_YET_ASSIGNED 24 | 25 | Winfried 26 | Tilanus 27 | winfried@tilanus.com 28 | winfried@tilanus.com 29 | 30 | 31 | 0.0.1 32 | 2018-05-22 33 | wt 34 |

First draft.

 35 | 36 |
37 | 38 |

The General Data Protection Regulation (GDPR) is an European Union wide regulation about handling personal data. This XEP is a central place with information for server operators who need (or want) to have their server GDPR compliant. This information is general and still subject to debate amongst lawyers, it doesn't offer a legal advice. When in doubt consult your own lawyer.

39 |

These best practices are aimed at operators of public jabbers servers that are federating with other public jabber servers. Though this XEP is written with a typical server setup in mind, it contains also some considerations for other setups. This XEP does not fully cover the requirements for private XMPP deployments, like an in company server and this XEP does not cover situations where the XMPP traffic is used to observe and analyse the behaviour of users.

40 |

The XMPP core specifications and many of the XMPP Extension Protocols describe handling of data that is regulated by the GDRP. But XMPP is deployed in many different jurisdictions and the aim of the protocols is to ensure interoperability, not to encode (local) laws into the protocols. So the protocols will only contain general information on the data that processed and will offer general functionality that is not specific for one jurisdiction. This XEP is the central point for gathering all information regarding setting up a server that is compliant with the GDPR. This XEP is accompanied by several other documents, including a template for Terms of Service and a template for a Privacy Statement.

41 | 42 | 43 |

The aim of this XEP is to make it easy for operators of public XMPP servers to setup a GDPR compliant server. This XEP does not cover private setups or setups where the processed data is used for any purpose other then the communication between the end users.

44 | 45 | 46 |

TBD

47 | 48 | 49 | 50 | 51 | 52 | 53 |
XEPRelevance
54 | 55 | 56 |

TBD

57 | 58 | 59 | 60 |

TBD

61 | 62 | 63 |

TBD

64 | 65 | 66 |

TBD

67 | 68 | 69 | 70 | 71 |

TBD

72 | 73 | 74 |

TBD

75 | 76 | 77 | 78 |

REQUIRED.

79 | 80 | 81 |

REQUIRED.

82 | 83 | 84 |

REQUIRED.

85 | 86 | 87 | -------------------------------------------------------------------------------- /inbox/gre-encrypter-openpgp.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
9 | GRE Encrypter: OpenPGP 10 | This GRE Encrypter uses OpenPGP to encrypt payload. 11 | 12 | &LEGALNOTICE; 13 | xxxx 14 | ProtoXEP 15 | Standards Track 16 | Standards 17 | Council 18 | 19 | XMPP Core 20 | XEP-0001 21 | XEP-0373 22 | 23 | 24 | 25 | gre-encrypter-openpgp 26 | 27 | gre 28 | encrypter 29 | 30 | 31 | Jérôme 32 | Poisson 33 | goffi@goffi.org 34 | goffi@jabber.fr 35 | 36 | 37 | 0.0.1 38 | 2025-01-12 39 | jp 40 |

First draft.

 41 | 42 |
43 | 44 | 45 |

This XEP defines a GRE Encrypter that uses OpenPGP. It is based on &xep0373; and uses the mechanisms defined there to handle keys.

46 | 47 | 48 | 49 |

The design goals of this GRE Encrypter are:

50 |
    51 |
  • Compliance with OpenPGP.
    • 52 |
  • Re-use existing mechanisms of &xep0373;.
    • 53 |
54 | 55 | 56 | 57 |

The encryption process using OpenPGP involves the following steps:

58 |
    59 |
  1. Data Preparation: The client prepares the data to be encrypted according to the specified formatter.
    2. 60 |
  2. Key Exchange: The client retrieves or generates the necessary public key(s) from the gateway as specified in &xep0373;.
    3. 61 |
  3. Encryption: The payload is encrypted using OpenPGP's public key(s) of recipient(s).
    4. 62 |
  4. Payload Construction: The encrypted data is encoded using base64 then wrapped in the <encrypted/> element as described in XEP-0XXX: Gateway Relayed Encryption, with appropriate attributes for formatter and encrypter namespaces.
    5. 63 |
64 | 65 | 66 | 67 |

If an entity supports the MIME GRE Formatter, it MUST advertise it by including the "urn:xmpp:gre:encrypter:openpgp:0" discovery feature in response to a &xep0030; information request.

68 | 73 | 74 | ]]> 75 | 80 | 81 | ... 82 | 83 | 84 | ... 85 | 86 | ]]> 87 | 88 | 89 | 90 | 91 |

The security consideration of &xep0373; apply.

92 | 93 | 94 | 95 |

This document does not require interaction with &IANA;.

96 | 97 | 98 | 99 |

TODO

100 | 101 | 102 | 103 |

Thanks to NLNet foundation/NGI Zero Core for funding the work on this specification.

104 | 105 | 106 | 107 | -------------------------------------------------------------------------------- /inbox/gre-formatter-mime.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
9 | GRE Formatter: MIME 10 | This GRE Formatter uses Multipurpose Internet Mail Extensions (MIME) to format payload. 11 | 12 | &LEGALNOTICE; 13 | xxxx 14 | ProtoXEP 15 | Standards Track 16 | Standards 17 | Council 18 | 19 | XMPP Core 20 | XEP-0001 21 | 22 | 23 | 24 | gre-formatter-mime 25 | 26 | gre 27 | formatter 28 | 29 | 30 | Jérôme 31 | Poisson 32 | goffi@goffi.org 33 | goffi@jabber.fr 34 | 35 | 36 | 0.0.1 37 | 2025-01-12 38 | jp 39 |

First draft.

 40 | 41 |
42 | 43 | 44 |

This XEP defines a GRE Formatter that uses Multipurpose Internet Mail Extensions (MIME) as specified in RFC 2045, RFC 2046, RFC 2047, RFC 2183, and RFC 2231. This formatter will ensure that payloads are structured according to the MIME standards, allowing for proper formatting before encryption.

45 | 46 | 47 | 48 |

The design goals of this GRE Formatter are:

49 |
    50 |
  • Be usable with email gateways to send and receive end-to-end encrypted emails.
    • 51 |
  • The formatter should be capable of handling attachments by creating appropriate MIME parts.
    • 52 |
  • Compliance with RFC 2045, RFC 2046, RFC 2047, RFC 2183, and RFC 2231.
    • 53 |
54 | 55 | 56 | 57 |

MIME payloads must conform to the following structure:

58 |
    59 |
  • Text Content: For text/plain and other text-based MIME types, the payload SHOULD be encoded in UTF-8.
    • 60 |
  • Attachments: Attachments should be enclosed within a multipart/mixed container. Each attachment should have its own MIME part with appropriate headers like Content-Type and Content-Disposition.
    • 61 |
62 |

Formatted payload MUST be constructed according to the rules defined in RFCs 2045 through 2231.

63 | 64 | 65 | 66 |

The following business rules apply to the MIME GRE Formatter:

67 |
    68 |
  • The use of &xep0247; is recommended to avoid reaching stanza limits, especially when attachments are used.
    • 69 |
  • The use of Content-Disposition headers for attachments is recommended to facilitate proper handling by legacy systems.
    • 70 |
71 | 72 | 73 | 74 |

If an entity supports the MIME GRE Formatter, it MUST advertise it by including the "urn:xmpp:gre:formatter:mime:0" discovery feature in response to a &xep0030; information request.

75 | 80 | 81 | ]]> 82 | 87 | 88 | ... 89 | 90 | 91 | ... 92 | 93 | ]]> 94 | 95 | 96 | 97 | 98 |

This document introduces no security considerations above and beyond those already defined in XEP-0XXX Gateway Relayed Encryption.

99 | 100 | 101 | 102 |

This document does not require interaction with &IANA;.

103 | 104 | 105 | 106 |

TODO

107 | 108 | 109 | 110 |

Thanks to NLNet foundation/NGI Zero Core for funding the work on this specification.

111 | 112 | 113 | 114 | -------------------------------------------------------------------------------- /inbox/server-rosters.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
9 | Server Rosters 10 | This specification defines a convention for trust between XMPP server deployments. 11 | &LEGALNOTICE; 12 | xxxx 13 | ProtoXEP 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | 20 | 21 | 22 | NOT_YET_ASSIGNED 23 | operators 24 | 25 | Artur 26 | Hefczyc 27 | artur.hefczyc@gmail.com 28 | artur.hefczyc@tigase.org 29 | 30 | 31 | Florian 32 | Jensen 33 | admin@flosoft.biz 34 | admin@im.flosoft.biz 35 | 36 | 37 | Mickaël 38 | Rémond 39 | mickael.remond@process-one.net 40 | mremond@process-one.net 41 | 42 | &stpeter; 43 | 44 | Matthew 45 | Wild 46 | mwild1@gmail.com 47 | mwild1@jaim.at 48 | 49 | 50 | 0.0.1 51 | 2009-04-30 52 | ah/fj/psa/mr/mw 53 |

First draft, split from the incident reporting proposal.

 54 | 55 |
56 | 57 | 58 |

In XMPP, rosters and presence subscriptions have been used to date only among IM users (see &xmppim;). However, nothing prevents the application of these concepts to other XMPP entities, such as components and servers. Given that a presence subscription typically indicates some level of trust in a peer, server deployments can use the sharing of XMPP presence information as a way to indicate that a given server has a trust relationship with a peer server. The server might then share certain kinds of additional information only with trusted peers (for example, incident reports).

59 |

To establish a trust relationship with a peer, a server shall send a presence subscription request to the peer, just as is done between XMPP users.

60 | 64 | ]]> 65 |

A server MUST NOT send such a presence subscription request unless explicitly requested to do so by the server administrator(s).

66 |

Upon receiving such a presence subscription request, the XMPP server software running at the peer MUST prompt the server administrator(s) to approve the request, rather than automatically approving it. Methods for doing so are out of scope for this specification.

67 |

If the server administrator(s) approve the request, the peer server shall then inform the originating server that the request has been approved.

68 | 72 | ]]> 73 |

The peer SHOULD also send a subscription request to the originating server.

74 | 78 | ]]> 79 |

If an XMPP server implementation supports this usage of presence subscriptions, it MUST keep a list of approved entities, which we denote a "server roster". The implementation MAY use that roster for access control purposes defined in other specifications.

80 | 81 | 82 | 83 |

To follow.

84 | 85 | 86 | 87 |

This document requires no interaction with &IANA;.

88 | 89 | 90 | 91 | -------------------------------------------------------------------------------- /inbox/sige2ee.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
9 | Special Interests Group End to End Encryption 10 | This document proposes the formation of a Special Interest Group (SIG) within the XSF devoted to the development of end-to-end encryption within the context of XMPP. 11 | &LEGALNOTICE; 12 | XXXX 13 | ProtoXEP 14 | Procedural 15 | None 16 | Council 17 | 18 | 19 | 20 | SIG-E2EE 21 | &paulschaub; 22 | 23 | 0.0.1 24 | 2019-12-30 25 | ps 26 | Initial published version. 27 | 28 |
29 | 30 |

End-to-end encryption presents a vital tool for users to protect their communications against third parties. To ensure a good user experience it is important to agree on shared standards which are widely rolled out and adopted by implementations.

31 |

There already exists a number of encryption protocols with different properties and scopes. It is necessary to coordinate the efforts of further improving those standards to identify and unify common problems and patterns.

32 | 33 | 34 |

The role of the SIG shall be as follows:

35 |
    36 |
  • Produce, or coordinate the production and maintenance of relevant XMPP Extension Protocol (XEP) documents as described below under Deliverables.
    • 37 |
  • Represent the interests and requirements of the XMPP community during the development of end-to-end encryption protocols that are non-exclusive to XMPP.
    • 38 |
  • Provide recommendations for implementers.
    • 39 |
40 |

The SIG-E2EE shall not itself approve XMPP extension protocols (XEPs), which tasks shall remain under the purview of the XMPP Council.

41 |

The scope of the SIG is limited to end-to-end encryption in contexts which are useful for instant messaging.

42 | 43 | 44 |

The SIG-E2EE shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Anyone who works with, or is interested in encryption protocols is invited to take part.

45 |

Discussions shall be conducted in a dedicated openly accessible mailing list.

46 | 47 | 48 |

The SIG-E2EE shall be a standing SIG, and shall exist as long as the XMPP Council deems it useful.

49 | 50 | 51 |

The SIG-E2EE should maintain active existing end-to-end encryption specifications and keep them up to date.

52 |

It should also coordinate the production of future end-to-end encryption specifications to keep up with the state of the art.

53 | 54 | 55 | -------------------------------------------------------------------------------- /inbox/websocket-s2s.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
9 | WebSocket S2S 10 | This specification defines a procedure to make s2s XMPP connections over WebSocket. 11 | &LEGALNOTICE; 12 | xxxx 13 | ProtoXEP 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XEP-0156 20 | 21 | 22 | 23 | NOT_YET_ASSIGNED 24 | 25 | Travis 26 | Burtrum 27 | travis@burtrum.org 28 | travis@burtrum.org 29 | 30 | 31 | 0.0.1 32 | 2022-06-13 33 | tjb 34 |

First draft.

 35 | 36 |
37 | 38 |

&rfc7395; specifies how to make c2s connections over WebSocket. This XEP extends that to also support s2s connections over WebSocket.

39 | 40 | 41 |

Everything mentioned in &rfc7395; should be followed with the following changes:

42 |
    43 |
  1. Connection details are discovered by using &xep0156;
    2. 44 |
  2. For c2s, &rfc7395; requires replacing the 'jabber:client' namespace with 'urn:ietf:params:xml:ns:xmpp-framing', for s2s, the 'jabber:server' namespace should be replaced with 'urn:ietf:params:xml:ns:xmpp-framing-server'.
    3. 45 |
  3. wss (TLS) upgraded to a MUST be used, therefore SASL EXTERNAL authentication can be used as defined in &xmppcore;
    4. 46 |
47 | 48 | 49 |

Some hosting services only allow HTTPS proxies to access servers, meaning federating XMPP servers cannot be ran on these hosts unless s2s is accessible over HTTPS.

50 | 51 | 52 |

Identical to RFC 7395 Security Considerations.

53 | 54 | 55 | 56 |

A URN sub-namespace for framing of s2s Extensible Messaging and Presence 57 | Protocol (XMPP) streams is defined as follows.

58 | 59 |

URI: urn:ietf:params:xml:ns:xmpp-framing-server

60 | 61 |

Specification: this document

62 | 63 |

Registrant Contact: IESG <iesg@ietf.org>

64 | 65 | 66 | 67 |

This document requires no interaction with the ®ISTRAR;.

68 | 69 | 70 | -------------------------------------------------------------------------------- /inbox/xep-iwe.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
9 | Implicit XMPP WebSocket Endpoints 10 | This document specifies implicit connection endpoints for XMPP over WebSocket (RFC 7395). 11 | &LEGALNOTICE; 12 | xxxx 13 | ProtoXEP 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XEP-0001 20 | Etc. 21 | 22 | 23 | 24 | iwe 25 | &flow; 26 | 27 | 0.0.1 28 | 2020-01-28 29 | fs 30 |

First draft.

 31 | 32 |
33 | 34 | 35 | 36 |

Unlike for XMPP connections via TCP as specified in &rfc6120;, 37 | there exists no specificiation of implicit connection endpoints for 38 | XMPP over WebSocket (&rfc7395;). As a result, XMPP services which 39 | whish to provide WebSocket connectivity need to announce their 40 | WebSocket endpoints, so that clients are able to discover them (RFC 41 | 7395 § 4). This XEP fills this gap. It eventually enables, under 42 | certain conditions, XMPP services to provide WebSocket connectivty, 43 | without resorting to &xep0156; nor requiring manual configuration by 44 | the user.

45 | 46 | 47 | 48 | 49 | 50 |

The following implicit XMPP WebSocket endpoints are specified:

51 |
    52 |
  • wss://<xmpp-service-name>:5443/ws
    • 53 |
  • ws://<xmpp-service-name>:5443/ws
    • 54 |
  • wss://<xmpp-service-name>/ws
    • 55 |
  • ws://<xmpp-service-name>/ws
    • 56 |
57 | 58 |

TODO: Use implicit endpoints only if no other endpoints were 59 | discovered?

60 | 61 | 62 | 63 | 64 | 65 |

Implementations should note that due this XEP, the collection of 66 | potential endpoints may contain duplicates. This is because the 67 | implicit WebSocket connection endpoints defined herein may match the 68 | ones that where discovered (RFC 7395 § 4, XEP-0156). Implementations 69 | may want to ensure that no such duplicates exist.

70 | 71 |

Furthermore, implementations attempting to connect to the 72 | discovered endpoints serially, as opposed to concurrently, may use 73 | the implicit endpoints only as last resort.

74 | 75 | 76 | 77 | 78 | 79 |

Since the implicit WebSocket connection endpoints are defined to 80 | include the XMPP service name, the verification required when using 81 | the secured variant of the WebSocket transport provides the 82 | necessary security.

83 | 84 | 85 | 86 | 87 | 88 |

This document requires no interaction with &IANA;.

89 | 90 | 91 | 92 | 93 | 94 |

This document requires no interaction with the XMPP registrar.

95 | 96 | 97 | 98 | 99 | 100 |

No XML schema specification is required, as this XEP does not 101 | specify any XML data.

102 | 103 | 104 | 105 | 106 | -------------------------------------------------------------------------------- /inbox/xep-sasl-cb-types.xml: -------------------------------------------------------------------------------- 1 | 2 | RFC 5056 RFC 5056: On the Use of Channel Bindings to Secure Channels <http://tools.ietf.org/html/rfc5056>." > 4 | IANA Channel-Binding Types Registry IANA Channel-Binding Types Registry <https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml>." > 5 | 6 | %ents; 7 | ]> 8 | 9 | 10 |
11 | SASL Channel-Binding Type Capability 12 | This specification allows servers to annouce their supported SASL channel-binding types to clients. 13 | &LEGALNOTICE; 14 | xxxx 15 | ProtoXEP 16 | Standards Track 17 | Standards 18 | Council 19 | 20 | XMPP Core 21 | 22 | 23 | 24 | sasl-cb-types 25 | &flow; 26 | 27 | 0.0.1 28 | 2020-05-20 29 | fs 30 |

First draft.

 31 | 32 |
33 | 34 | 35 |

SASL channel-binding is a technique to increase the security of 36 | connections (&rfc5056;). Unfortunately, the SASL profile specified 37 | in &rfc6120; lacks a method for the server to announce its supported 38 | channel-binding types. This hinders the adoption of channel-binding, 39 | especially since the error protocol to execute after a client 40 | requested a channel-binding type unsupported by the server is 41 | basically unspecified.

42 | 43 |

The extension defined herein fills the gap left by &rfc6120;, by 44 | allowing the server the announce its supported channel-binding 45 | types.

46 | 47 | 48 | 49 | 50 | 51 |

This protocol consists of a single optional extension element 52 | named 'sasl-channel-binding' qualified by the 'urn:xmpp:sasl-cb:0' 53 | namespace. The 'sasl-channel-binding' element MUST contain one or 54 | more 'channel-binding' elements, of which each MUST have an 55 | attribute with the name 'type'. The value of the 'type' attribute 56 | SHOULD be the "Channel-binding unique prefix" of a channel-binding 57 | type which was registered with the &iana-cb-types;.

58 | 59 |

A server declares that it supports particular channel-binding 60 | types by listing the supported types via the 'sasl-channel-binding' 61 | element defined herein. The 'sasl-channel-binding' element could 62 | appear as child element to the SASL <mechanisms/> 63 | stream-feature element, qualified by the 64 | 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, as specified in 65 | &rfc6120;. Another potential appearance of 66 | <sasl-channel-binding> is as child element of the 67 | <mechanisms/> stream-feature element as specified in the 68 | &xep0388;.

69 | 70 | 72 | 73 | EXTERNAL 74 | SCRAM-SHA-1-PLUS 75 | PLAIN 76 | 77 | 78 | 79 | 80 | 81 | ]]> 82 | 83 | 84 | 85 | 86 | 87 |

The author belives that this document itself does not yield any 88 | new security considerations.Hopefully somebody will correct him, in 89 | case he is wrong.

90 | 91 | 92 | 93 | 94 | 95 |

This document requires no interaction with &IANA;.

96 | 97 | 98 | 99 | 100 | 101 |

This document requires no interaction with the XMPP registrar.

102 | 103 | 104 | 105 | 106 | 107 |

TODO: Add if the XEP is scheduled for the state after 'experimental'.

108 | 109 | 110 | 111 | 112 | 113 |

Thanks to Sam Whited for the discussion about the underlying 114 | issue and incentivizing me to come up with this extension.

115 | 116 | 117 | 118 | 119 | -------------------------------------------------------------------------------- /inbox/xep.dtd: -------------------------------------------------------------------------------- 1 | ../xep.dtd -------------------------------------------------------------------------------- /inbox/xep.ent: -------------------------------------------------------------------------------- 1 | ../xep.ent -------------------------------------------------------------------------------- /inbox/xep.xsl: -------------------------------------------------------------------------------- 1 | ../xep.xsl -------------------------------------------------------------------------------- /pack-only.Dockerfile: -------------------------------------------------------------------------------- 1 | FROM nginx:1-alpine 2 | RUN mkdir /usr/share/nginx/html/extensions/ 3 | COPY build/ /usr/share/nginx/html/extensions/ 4 | RUN sed -ri '/root\s+\/usr\/share\/nginx\/html/s/^(.+)$/\1\nautoindex on;/' /etc/nginx/conf.d/default.conf 5 | EXPOSE 80 6 | -------------------------------------------------------------------------------- /prettify.css: -------------------------------------------------------------------------------- 1 | /* Pretty printing styles. Used with prettify.js. */ 2 | 3 | .str { color: #080; } 4 | .kwd { color: #008; } 5 | .com { color: #800; } 6 | .typ { color: #606; } 7 | .lit { color: #066; } 8 | .pun { color: #660; } 9 | .pln { color: #000; } 10 | .tag { color: #008; } 11 | .atn { color: #606; } 12 | .atv { color: #080; } 13 | .dec { color: #606; } 14 | 15 | @media print { 16 | .str { color: #060; } 17 | .kwd { color: #006; font-weight: bold; } 18 | .com { color: #600; font-style: italic; } 19 | .typ { color: #404; font-weight: bold; } 20 | .lit { color: #044; } 21 | .pun { color: #440; } 22 | .pln { color: #000; } 23 | .tag { color: #006; font-weight: bold; } 24 | .atn { color: #404; } 25 | .atv { color: #060; } 26 | } 27 | 28 | @media screen and ( prefers-color-scheme: dark ) { 29 | .str { color: #0d0; } 30 | .kwd { color: #00d; } 31 | .com { color: #f88; } 32 | .typ { color: #d0d; } 33 | .lit { color: #0dd; } 34 | .pun { color: #dd0; } 35 | .pln { color: #fff; } 36 | .tag { color: #88f; font-weight: bold; } 37 | .atn { color: #f8f; } 38 | .atv { color: #8f8; } 39 | .dec { color: #f8f; } 40 | } 41 | -------------------------------------------------------------------------------- /protopage.xsl: -------------------------------------------------------------------------------- 1 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | <xsl:value-of select='/xep/header/shortname'/> 35 | 36 | 37 | 38 | alternate 39 | http://xmpp.org/extensions/xep-.html 40 | 41 | 42 | 43 | DC.Title 44 | 45 | 46 | 47 | DC.Publisher 48 | XMPP Standards Foundation 49 | 50 | 51 | DC.Date 52 | 53 | 54 | 55 | 56 | 57 |

58 |

This page provides information about the XML namespaces defined in 59 | 60 | 61 | http://xmpp.org/extensions/xep- 62 | 63 | .html 64 | 65 | XEP-: 66 | 67 | (part of the XEP series published by the XMPP Standards Foundation).

68 | 69 | 70 | 71 |

The following XML schemas are available for the protocol:

72 |
    73 | 74 |
75 | 76 | 77 |

Last Updated:

78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 |
    • 89 |     90 | 91 |
    • 92 |     93 |     94 |     95 | 96 |     97 | -------------------------------------------------------------------------------- /resources/xmpp-text.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/xsf/xeps/a84e713859c88ff5f6c8908b4e43cb7c4104464d/resources/xmpp-text.pdf -------------------------------------------------------------------------------- /resources/xmpp.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/xsf/xeps/a84e713859c88ff5f6c8908b4e43cb7c4104464d/resources/xmpp.pdf -------------------------------------------------------------------------------- /texml-xsl/example.xsl: -------------------------------------------------------------------------------- 1 | 2 | 3 | 10 | 11 | 12 | 13 | 14 | $Id$ 15 | 16 | 17 | Ball 18 | Steve 19 | 20 | 21 | 2001 22 | Steve Ball 23 | 24 | 25 | 26 | Example Stylesheet 27 | 28 | 29 |
    30 | Introduction 31 | 32 | This module provides a template for adding stylesheet modules to the XSLT Standard Library. 33 | To add a new module to the library, follow these easy steps: 34 | 35 | 36 | Copy this file and replace its contents with the new module templates and documentation. 37 | 38 | 39 | Copy the corresponding test file in the test directory. Replace its contents with tests for the new module. 40 | 41 | 42 | Add an include element in the stdlib.xsl stylesheet. 43 | 44 | 45 | Add an entry in the test/test.xml file. 46 | 47 | 48 | Add entries in the test/test.xsl stylesheet. 49 | 50 | 51 | Add an entry in the doc/build.xml file. 52 | 53 | 54 | 55 | The example.xsl stylesheet provides a more extensive example. 56 | 57 |
    58 |     59 | 60 |     61 | 62 | 63 | Template Example 64 | 65 | 66 | Provides a template for writing templates. Replace this paragraph with a description of your template 67 | 68 | 69 | 70 | 71 | 72 | text 73 | 74 | The example string 75 | 76 | 77 | 78 | 79 | 80 | 81 | Returns nothing. 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 |     90 | 91 | -------------------------------------------------------------------------------- /tools/archive.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | import pathlib 3 | import shutil 4 | import subprocess 5 | import sys 6 | 7 | import xml.etree.ElementTree as etree 8 | 9 | from datetime import datetime, timedelta 10 | 11 | from xeplib import load_xepinfos, Status 12 | 13 | 14 | def do_archive(xeps_dir, attic, xep, old_version, new_version, build): 15 | curr_file = xeps_dir / "xep-{:04d}.html".format(xep) 16 | attic_file = attic / "xep-{:04d}-{}.html".format(xep, new_version) 17 | 18 | print("XEP-{:04d}:".format(xep), old_version, "->", new_version) 19 | 20 | if build: 21 | subprocess.check_call(["make", "build/xep-{:04d}.html".format(xep)]) 22 | 23 | shutil.copy(str(curr_file), str(attic_file)) 24 | 25 | 26 | def main(): 27 | import argparse 28 | 29 | parser = argparse.ArgumentParser( 30 | description="Show the XEPs which need to be changed to deferred." 31 | ) 32 | 33 | parser.add_argument( 34 | "old", 35 | type=argparse.FileType("rb"), 36 | help="Old XEP list" 37 | ) 38 | 39 | parser.add_argument( 40 | "new", 41 | type=argparse.FileType("rb"), 42 | help="New XEP list" 43 | ) 44 | 45 | parser.add_argument( 46 | "-d", "--xeps-dir", 47 | type=pathlib.Path, 48 | default=pathlib.Path.cwd() / "build", 49 | help="Path to the built XEPs (defaults to ./build)" 50 | ) 51 | 52 | parser.add_argument( 53 | "-a", "--attic", 54 | type=pathlib.Path, 55 | default=pathlib.Path.cwd() / '../xep-attic/content/', 56 | help="Path to the attic (defaults to ../xep-attic/content/)" 57 | ) 58 | 59 | parser.add_argument( 60 | "--no-build", 61 | action="store_false", 62 | dest="build", 63 | default=True, 64 | ) 65 | 66 | parser.add_argument( 67 | "xeps", 68 | nargs="*", 69 | type=int, 70 | help="Additional XEPs (by their number) to archive. Useful for " 71 | "purely editorial changes." 72 | ) 73 | 74 | args = parser.parse_args() 75 | 76 | with args.old as f: 77 | old_tree = etree.parse(f) 78 | 79 | old_accepted, _ = load_xepinfos(old_tree) 80 | 81 | with args.new as f: 82 | new_tree = etree.parse(f) 83 | 84 | new_accepted, _ = load_xepinfos(new_tree) 85 | 86 | changed = False 87 | 88 | force_archive = set(args.xeps) 89 | 90 | for xep, new_info in new_accepted.items(): 91 | old_version = old_accepted.get(xep, {}).get("last_revision", {}).get( 92 | "version" 93 | ) 94 | new_version = new_info["last_revision"]["version"] 95 | 96 | if old_version == new_version: 97 | continue 98 | 99 | force_archive.discard(xep) 100 | do_archive(args.xeps_dir, args.attic, xep, old_version, new_version, args.build) 101 | changed = True 102 | 103 | for xep in force_archive: 104 | old_version = old_accepted.get(xep, {}).get("last_revision", {}).get( 105 | "version" 106 | ) 107 | new_version = new_accepted[xep]["last_revision"]["version"] 108 | 109 | do_archive(args.xeps_dir, args.attic, xep, old_version, new_version, args.build) 110 | changed = True 111 | 112 | if changed: 113 | print( 114 | "{}: do not forget to commit & push the attic!".format( 115 | sys.argv[0] 116 | ), 117 | file=sys.stderr 118 | ) 119 | else: 120 | print("{}: nothing to do".format(sys.argv[0]), 121 | file=sys.stderr) 122 | 123 | 124 | if __name__ == "__main__": 125 | main() 126 | -------------------------------------------------------------------------------- /tools/ci-announce.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | state_dir=state 4 | old_xeplist="$state_dir/old-xeplist.xml" 5 | new_xeplist="build/xeplist.xml" 6 | mkdir -p "$state_dir" 7 | 8 | function update_state() { 9 | cp "$new_xeplist" "$old_xeplist" 10 | } 11 | 12 | if [ ! -f "$old_xeplist" ]; then 13 | printf '%q does not exist; assuming this is the first run!' "$old_xeplist" >&2 14 | update_state 15 | exit 0 16 | fi 17 | 18 | ./tools/send-updates.py -y -c "$EMAIL_CFG" --no-editorial -- "$old_xeplist" "$new_xeplist" $EMAIL_RECIPIENTS 19 | update_state 20 | -------------------------------------------------------------------------------- /tools/ci-archive.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | state_dir=state 4 | old_xeplist="$state_dir/old-xeplist.xml" 5 | new_xeplist="build/xeplist.xml" 6 | mkdir -p "$state_dir" 7 | 8 | function update_state() { 9 | cp "$new_xeplist" "$old_xeplist" 10 | } 11 | 12 | if [ ! -f "$old_xeplist" ]; then 13 | printf '%q does not exist; assuming this is the first run!' "$old_xeplist" >&2 14 | update_state 15 | exit 0 16 | fi 17 | 18 | chmod 0600 "$ATTIC_ID_RSA" 19 | export GIT_SSH_COMMAND="ssh -i \"\$ATTIC_ID_RSA\" -o StrictHostKeyChecking=no" 20 | git clone git@gitlab.com:xsf/xep-attic 21 | python3 tools/archive.py -a xep-attic/content/ --no-build "$old_xeplist" "$new_xeplist" 22 | pushd xep-attic 23 | git add content 24 | git update-index --refresh 25 | if ! git diff-index --quiet HEAD --; then 26 | git config user.name "$GIT_AUTHOR_NAME" 27 | git config user.email "$GIT_AUTHOR_EMAIL" 28 | git commit \ 29 | -m "Automated XEP build ${CI_JOB_ID}" \ 30 | -m "Job-URL: ${CI_JOB_URL}" 31 | git push 32 | fi 33 | popd 34 | update_state 35 | -------------------------------------------------------------------------------- /tools/ci-changed-builds.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | IFS=$'\n' 4 | if ! merge_base="$(git merge-base "$1" HEAD)"; then 5 | echo 'Failed to find merge base to detect changed files' >&2 6 | echo 'This indicates that your branch is too old and needs to be rebased' >&2 7 | exit 2 8 | fi 9 | filenames="$(git diff-tree -r --no-commit-id --name-status "$merge_base" HEAD | ( grep -P '^[AM]\t(xep-[0-9]{4}|inbox/[^/]+)\.xml$' || true) | cut -f2)" 10 | if [ -z "$filenames" ]; then 11 | exit 0 12 | fi 13 | mkdir -p rendered-changes/ 14 | cp xmpp.css prettify.css rendered-changes/ 15 | for filename in $filenames; do 16 | built_filename="build/${filename/%.xml/.html}" 17 | cp "$built_filename" rendered-changes/ 18 | done 19 | -------------------------------------------------------------------------------- /tools/ci-prune-build.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | outdir="build" 4 | # clean out tex build logs etc. 5 | find "$outdir" -type f '(' -iname "*.aux" -o -iname "*.log" -o -iname "*.toc" -o -iname "*.tex" -o -iname "*.tex.xml" -o -iname "*.out" ')' -print0 | xargs -0r -- rm 6 | 7 | find "$outdir" -type f '(' -iname "*.xml" -o -iname "*.html" -o -iname "*.pdf" ')' -print0 | while read -d $'\0' filename; do 8 | if [ "$filename" = 'build/xmpp.pdf' ] || [ "$filename" = 'build/xmpp-text.pdf' ] || [ "$filename" = 'build/xeplist.xml' ]; then 9 | continue 10 | fi 11 | 12 | if [[ "$filename" =~ build/refs/reference.*.xml ]]; then 13 | base_filename="$(echo "$filename" | sed -r 's#^build/refs/reference\.XSF\.XEP-([0-9]+)\.xml#xep-\1.xml#')" 14 | else 15 | base_filename="$(echo "$filename" | sed -r 's#^build/(.+)\.[^.]+$#\1.xml#')" 16 | fi 17 | 18 | if [ ! -e "$base_filename" ]; then 19 | printf 'deleting %q for which no source file (%q) exists\n' "$filename" "$base_filename" 20 | rm "$filename" 21 | fi 22 | done 23 | -------------------------------------------------------------------------------- /tools/ci-restore-timestamps.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/python3 2 | import os 3 | import pathlib 4 | import subprocess 5 | import time 6 | 7 | 8 | def parse_timestamp_line(s: str): 9 | author_ts, committer_ts = s.split(" ", 1) 10 | return max(int(author_ts), int(committer_ts)) 11 | 12 | 13 | def restore_commit_timestamps(basedir: pathlib.Path): 14 | env = dict(os.environ) 15 | env["LANG"] = "C.UTF-8" 16 | # NOTE: the build image is still only on Python 3.4 because texml and stuff 17 | # so we cannot use encoding= here and have to do decoding ourselves. 18 | proc = subprocess.Popen( 19 | [ 20 | "git", "log", "--pretty=%at %ct", "--name-status", 21 | ], 22 | stdout=subprocess.PIPE, 23 | env=env, 24 | ) 25 | 26 | seen = set() 27 | last_timestamp = None 28 | for line in proc.stdout: 29 | if not line: 30 | continue 31 | if not line.endswith(b"\n"): 32 | raise ValueError("line not terminated") 33 | line = line[:-1].decode("utf-8") 34 | if not line: 35 | continue 36 | 37 | try: 38 | timestamp = parse_timestamp_line(line) 39 | except ValueError: 40 | pass 41 | else: 42 | last_timestamp = timestamp 43 | continue 44 | 45 | _, filename = line.split("\t", 1) 46 | if filename in seen: 47 | continue 48 | seen.add(filename) 49 | filepath = basedir / filename 50 | try: 51 | os.utime(str(filepath), (last_timestamp, last_timestamp)) 52 | except FileNotFoundError: 53 | pass 54 | 55 | 56 | def main(): 57 | basedir = pathlib.Path.cwd() 58 | 59 | t0 = time.monotonic() 60 | try: 61 | restore_commit_timestamps(basedir) 62 | finally: 63 | t1 = time.monotonic() 64 | print("timestamp restoration took {:.2f}s".format(t1-t0)) 65 | 66 | return 0 67 | 68 | 69 | if __name__ == "__main__": 70 | import sys 71 | sys.exit(main() or 0) 72 | -------------------------------------------------------------------------------- /tools/find-lcs.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | ( echo -ne ''; xpath -e '/xep-infos/xep[string(status)="Proposed"]' build/xeplist.xml 2>/dev/null | tr -d '\n'; echo -ne '' ) | python3 -c 'import lxml.etree, sys; tree = lxml.etree.fromstring(sys.stdin.read()) 3 | for xep in tree: print("XEP-{number:04d} ({title}), LC ends: {enddate}; https://xmpp.org/extensions/xep-{number:04d}.html".format(number=int(xep.find("number").text), enddate=xep.find("lastcall").text, title=xep.find("title").text))' 4 | -------------------------------------------------------------------------------- /tools/local-triage.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | 3 | # Run this on its own (in the root of the xeps repo checkout) to iterate 4 | # over open PRs triaging them. It's a wrapper around the `gh` github command 5 | # and the triage.sh script, checking out each PR (as requested) in 6 | # a distinct worktree, and binning it afterwards. 7 | # 8 | # Supply a single parameter of a GitHub PR number to only look at that PR. 9 | # 10 | # I make no claim about the quality of the Python involved, this was a quick 11 | # hack for my (Kev's) benefit. 12 | 13 | import subprocess 14 | import sys 15 | 16 | class PR: 17 | def __init__(self, line): 18 | s = line.split('\t') 19 | self.number = s[0] 20 | self.title = s[1] 21 | self.branch = s[2] 22 | self.state = s[3] 23 | 24 | def __str__(self): 25 | return f'PR#{self.number}({self.branch}): {self.title}' 26 | 27 | 28 | def exec(command) -> str: 29 | process = subprocess.Popen(command, stdout=subprocess.PIPE, shell=True) 30 | (stdout, stderr) = process.communicate() 31 | exit_code = process.wait() 32 | if exit_code == 0: 33 | return stdout.decode() 34 | return "" 35 | 36 | 37 | def exec_with_err(command, cwd=None) -> str: 38 | process = subprocess.Popen( 39 | command, stdout=subprocess.PIPE, shell=True, cwd=cwd) 40 | (stdout, stderr) = process.communicate() 41 | exit_code = process.wait() 42 | return stdout.decode() + ('\n' + stderr.decode() if stderr else "") 43 | 44 | 45 | def open_prs() -> list[str]: 46 | lines = exec("gh pr list -R xsf/xeps --limit=100").splitlines() 47 | prs = [] 48 | for line in lines: 49 | prs.append(PR(line)) 50 | return prs 51 | 52 | 53 | exec("git fetch") 54 | prs = open_prs() 55 | print(f'{len(prs)} PRs') 56 | for pr in prs: 57 | if len(sys.argv) > 1 and pr.number != sys.argv[1]: 58 | continue 59 | if pr.state != 'OPEN': 60 | print(f"Skipping PR in state {pr.state}:\n{pr}") 61 | continue 62 | print(pr) 63 | choice = 'invalid' 64 | while choice != 'c' and choice != '': 65 | choice = input("Check labels (c), Open on GitHub (o) or skip (enter):") 66 | if choice == 'o': 67 | exec(f'gh pr view -w -R xsf/xeps {pr.number}') 68 | if choice == '': 69 | continue 70 | worktree_path = f'pr-worktree/{pr.number}' 71 | exec(f'git fetch origin +refs/pull/{pr.number}/merge') 72 | exec(f'git worktree add {worktree_path} FETCH_HEAD') 73 | triage = exec_with_err(f'../../tools/triage.sh "{pr.title}"', worktree_path) 74 | print(triage) 75 | print(f'Worktree checked out in {worktree_path}') 76 | input('Enter to remove worktree and continue') 77 | exec(f'git worktree remove {worktree_path}') 78 | -------------------------------------------------------------------------------- /tools/makeent.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | import html 3 | import xml.etree.ElementTree as etree 4 | 5 | from xeplib import load_xepinfos 6 | 7 | 8 | def main(): 9 | import argparse 10 | 11 | parser = argparse.ArgumentParser() 12 | parser.add_argument( 13 | "-l", "--xeplist", 14 | type=argparse.FileType("r"), 15 | default=None, 16 | ) 17 | parser.add_argument( 18 | "xeps", 19 | metavar="NUM", 20 | type=int, 21 | nargs="+", 22 | ) 23 | 24 | args = parser.parse_args() 25 | 26 | if args.xeplist is None: 27 | args.xeplist = open("build/xeplist.xml", "r") 28 | 29 | with args.xeplist as f: 30 | tree = etree.parse(f) 31 | 32 | accepted, _ = load_xepinfos(tree) 33 | 34 | for num in args.xeps: 35 | info = accepted[num] 36 | print( 37 | """""" 38 | """{title} (XEP-{number:04d}) """ 39 | """XEP-{number:04d}: {title} <""" 40 | """{url}>." >""".format( 41 | title=html.escape(info["title"]), 42 | number=num, 43 | url="https://xmpp.org/extensions/xep-{:04d}.html".format( 44 | num, 45 | ) 46 | ) 47 | ) 48 | 49 | if __name__ == "__main__": 50 | main() 51 | -------------------------------------------------------------------------------- /tools/md-diff.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # md-diff 3 | # arguments: file commit commit [diff tool with args] 4 | 5 | if [ $# -lt 3 ]; then 6 | echo 'arguments: file commit commit [diff tool with args]' >&2 7 | exit 1; 8 | fi 9 | 10 | ${4:-diff} \ 11 | <(git show "$2:$1" | ${0%/*}/xep2md.sh -) \ 12 | <(git show "$3:$1" | ${0%/*}/xep2md.sh -) 13 | -------------------------------------------------------------------------------- /tools/merge-helper.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | echo "Ensure you have ../xep-attic, then press enter" 4 | read 5 | echo "Generating pre-merge xeplist" 6 | make build/xeplist.xml 7 | cp build/xeplist.xml tools/old-xeplist.xml 8 | echo "Do your merges now and update the local checkout if you did that remotely (enter)" 9 | echo "(Follow https://github.com/xsf/xeps/blob/master/docs/PROCESSING.md )" 10 | read 11 | make build/xeplist.xml 12 | echo "Now archiving (enter)" 13 | read 14 | ./tools/archive.py tools/old-xeplist.xml build/xeplist.xml 15 | pushd ../xep-attic 16 | git add content/xep-* 17 | git commit -a -m "Add latest changes" 18 | echo "Showing commit (enter)" 19 | read 20 | git show 21 | echo "If that looks good, push (enter)" 22 | read 23 | git push origin master 24 | popd 25 | echo "Now generate the docker image and upload it (enter)" 26 | read 27 | echo "Performing dry-run email using ./tools/xeps-email.conf (create if you don't have it) (enter)" 28 | read 29 | ./tools/send-updates.py -c tools/xeps-email.conf --dry-run tools/old-xeplist.xml build/xeplist.xml standards@xmpp.org 30 | echo "Assuming that was right, running the real emails (enter)" 31 | read 32 | ./tools/send-updates.py -c tools/xeps-email.conf tools/old-xeplist.xml build/xeplist.xml standards@xmpp.org 33 | -------------------------------------------------------------------------------- /tools/xep2md.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | xmllint --nonet --noent --loaddtd "$@" | lua5.3 -lluarocks.loader ${0%/*}/xep2md.lua 4 | -------------------------------------------------------------------------------- /tools/xeplist-to-csv.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/python3 2 | import csv 3 | import sys 4 | 5 | import xml.etree.ElementTree as etree 6 | 7 | from xeplib import load_xepinfos 8 | 9 | 10 | def main(): 11 | import argparse 12 | 13 | parser = argparse.ArgumentParser() 14 | 15 | parser.add_argument( 16 | "-l", "--xeplist", 17 | type=argparse.FileType("rb"), 18 | default=None, 19 | help="XEP list to use (defaults to ./build/xeplist.xml)" 20 | ) 21 | 22 | parser.add_argument( 23 | "-d", "--dialect", 24 | default="unix", 25 | ) 26 | 27 | parser.add_argument( 28 | "outfile", 29 | ) 30 | 31 | args = parser.parse_args() 32 | 33 | if args.xeplist is None: 34 | args.xeplist = open("./build/xeplist.xml", "rb") 35 | 36 | with args.xeplist as f: 37 | tree = etree.parse(f) 38 | 39 | accepted, _ = load_xepinfos(tree) 40 | 41 | with open(args.outfile, "w") as f: 42 | writer = csv.writer(f, args.dialect) 43 | for number, info in sorted(accepted.items()): 44 | writer.writerow([ 45 | number, 46 | info["title"], 47 | info["status"].value, 48 | info["last_revision"]["date"].date(), 49 | info["last_revision"]["version"], 50 | ]) 51 | 52 | 53 | if __name__ == "__main__": 54 | main() 55 | -------------------------------------------------------------------------------- /xep-0002.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Special Interest Groups (SIGs) 10 | A definition of Special Interest Groups within the XMPP Standards Foundation. 11 | &LEGALNOTICE; 12 | 0002 13 | Active 14 | Procedural 15 | None 16 | Board 17 | 18 | 19 | 20 | N/A 21 | &stpeter; 22 | 23 | 1.1 24 | 2002-01-11 25 | psa 26 | Clarified some details and added information about cut-offs for inactivity. 27 | 28 | 29 | 1.0 30 | 2001-06-28 31 | psa 32 | First release, modified from Rahul Dave's modification of my original post. 33 | 34 |
    35 | 36 |

    A Special Interest Group (SIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).

    37 |     38 | 39 |

    The main function of most SIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs For information about XMPP Extension Protocols, see http://www.xmpp.org/extensions/xep-0001.html.) within a reasonably limited period of time. However, at the discretion of the XMPP Council, a handful of standing SIGs may be approved (e.g., to address security or standards compliance).

    40 |

    Anyone (not limited to members of the XMPP Standards Foundation) may propose the formation of a SIG by completing a XMPP Extension Protocol outlining the need for the SIG and its proposed focus. However, SIG leaders must be members of the XMPP Standards Foundation. The number of leaders for a SIG is flexible, and shall be determined by each SIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to SIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each SIG has its own mailing list, which is archived for public review). SIG members do not need to be members of the XMPP Standards Foundation, and any member of the general public may subscribe to SIG mailing lists.

    41 |

    It is expected that all SIGs (other than certain standing SIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the SIG's area of focus. However, if a SIG does not show signs of activity for an extended period of time (usually six months of inactivity on the SIG's mailing list), the SIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the SIG members (usually in the form of an email sent to the SIG's mailing list).

    42 |     43 |     44 | -------------------------------------------------------------------------------- /xep-0005.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Jabber Interest Groups 10 | This is the official list and summary information of the Jabber Interest Groups. 11 | &LEGALNOTICE; 12 | 0005 13 | Obsolete 14 | Informational 15 | None 16 | 17 | XMPP Core 18 | 19 | 20 | 21 | N/A 22 | 23 | Jeremie 24 | Miller 25 | jer@jabber.org 26 | 27 | 28 | 1.1 29 | 2002-05-08 30 | psa 31 | Changed Status to Obsolete per approval of XEP-0019. 32 | 33 | 34 | 1.0 35 | 2001-07-03 36 | jer 37 | First Post! ;) 38 | 39 |
    40 | 41 | 42 |
      43 |
    • Michael Bauer / bauer@jabber.com
      • 44 |
    • Julian Missig / julian@jabber.org
      • 45 |
    • Terry Smelser / tsmelser@sltscommunications.net
      • 46 |
    • DJ Adams / dj.adams@pobox.com
      • 47 |
    • Mike Szczerban / mikeszcz@delanet.com
      • 48 |
    49 |

    Determine standards for implementing derivative trademarks (e.g., "100% Jabber Protocol Compliant") and test software and services for compliance.

    50 |     51 | 52 | 53 |
      54 |
    • Ryan Eatmon / reatmon@jabber.org
      • 55 |
    • Jer / jer@jabber.org
      • 56 |
    • Stephen Lee / srlee@myjabber.org
      • 57 |
    • Jim Powell / PowellJF@navair.navy.mil
      • 58 |
    • Zad / zadk@mynet.com
      • 59 |
    • Michael J. Emswiler / memswiler@hotmail.com
      • 60 |
    61 |

    Resolve issues around using the jabber:*:oob namespaces, and explore extending them to support additional requirements for managing multimedia streams (SIP). 62 | Create additional protocols and methods to assist exchanging OOB data in heterogeneous environments where direct connections are not possible (PASS).

    63 |     64 | 65 | 66 |
      67 |
    • Thomas Muldowney / temas@jabber.org
      • 68 |
    • Al Sutton / al@alsutton.com
      • 69 |
    • Rahul Dave / rahul@mozdev.org
      • 70 |
    71 |

    Focusing on authentication, message encryption, connection security, etc.

    72 |     73 | 74 | 75 |
      76 |
    • Ryan Eatmon / reatmon@jabber.org
      • 77 |
    • Thomas Muldowney / temas@jabber.org
      • 78 |
    • Adam Theo / adamtheo@theoretic.com
      • 79 |
    • Mike Szczerban / mikeszcz@delanet.com
      • 80 |
    • Michael J. Emswiler / memswiler@hotmail.com
      • 81 |
    82 |

    To define a new namespace for dynamic forms. Minimally to supplant jabber:iq:register and jabber:iq:search.

    83 |     84 | 85 | 86 |
      87 |
    • Julian Missig / julian@jabber.org
      • 88 |
    • Michael J. Emswiler / memswiler@hotmail.com
      • 89 |
    90 |

    Will determine the protocol for sending and receiving formatted messages in Jabber (XHTML-Basic)

    91 |     92 | 93 | 94 |
      95 |
    • Jer / jer@jabber.org
      • 96 |
    • Peter Millard / me@pgmillard.com
      • 97 |
    • David Waite / dwaite@jabber.com
      • 98 |
    99 |

    The replacement for agents, including extensible directory lookups and namespace feature negotiation. Defined as a draft protocol but needs additional work.

    100 |     101 | 102 | 103 |
      104 |
    • Dave Smith / dave@jabber.org
      • 105 |
    • Oliver Wing / owing@vianetworks.co.uk
      • 106 |
    • David Waite / dwaite@jabber.com
      • 107 |
    • Rahul Dave / rahul@mozdev.org
      • 108 |
    • Peter Millard / me@pgmillard.com
      • 109 |
    110 |

    Describe in detail how presence management currently works, and work on proposals for things like invisibility.

    111 |     112 | 113 |     114 | 115 | -------------------------------------------------------------------------------- /xep-0010.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Whiteboarding SIG 10 | A proposal to form a SIG to develop a protocol for whiteboarding over Jabber. 11 | &LEGALNOTICE; 12 | 0010 13 | Obsolete 14 | SIG Formation 15 | None 16 | Board 17 | 18 | 19 | 20 | N/A 21 | 22 | Niklas 23 | Gustavsson 24 | niklas@protocol7.com 25 | nikgus@jabber.org 26 | 27 | 28 | 1.1 29 | 2002-05-08 30 | psa 31 | Changed Status to Obsolete per approval of XEP-0019. 32 | 33 | 34 | 1.0 35 | 2001-09-30 36 | ng 37 | Initial release 38 | 39 |
    40 | 41 |

    Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value.

    42 |

    There exists today a protocol draft for sending streaming XPM over Jabber. XPM is a bitmap format, which makes it well-suited for certain applications (e.g., smaller drawings and sketches). However, significant changes in an XPM image will require sending large amounts of XML data (even with the compression described in the protocol draft). Also, for example, XPM does not scale without loss of resolution, nor does it support metadata. In addition, the current draft specifies the data format only, not the way the data will be sent or handled by Jabber servers and clients.

    43 |

    Therefore, the Whiteboard SIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing SIG.

    44 |     45 | 46 |

    The Whiteboarding SIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):

    47 | 48 |

    A set of requirements that the proposed protocol should fulfill.

    49 |     50 | 51 |

    There are today at least four different attempts "Distributed SVG documents" (formerly at http://www.jabber.org/?oid=1025) SVG over Jabber (http://www.protocol7.com/jabber/whiteboard_proposal.txt) Jabberzilla Whiteboard (http://jabberzilla.mozdev.org/) to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.

    52 |     53 | 54 |

    One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.

    55 |     56 | 57 |

    The actual protocol for how the graphics data is sent over Jabber. This will also include an analysis of any associated functionality that must be performed by Jabber servers and clients.

    58 |     59 |     60 |     61 | -------------------------------------------------------------------------------- /xep-0014.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Message Tone 10 | A proposal for including the sender's tone in messages. 11 | &LEGALNOTICE; 12 | 0014 13 | Rejected 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | 20 | 21 | 22 | N/A 23 | 24 | Mike 25 | Mintz 26 | psicoder@yahoo.com 27 | mikem@jabber.org 28 | 29 | 30 | 0.2 31 | 2002-01-16 32 | psa 33 | First release to CVS, including editorial changes and assignment of number. 34 | 35 | 36 | 0.1 37 | 2001-11-17 38 | mm 39 | Initial version. 40 | 41 |
    42 | 43 |

    When people speak to one another, they use various tones of voice and body language to express themselves. When communicating online, people have no easy way of expressing themselves clearly. By incorporating message tones into Jabber, people will be able to convey tones such as anger, sarcasm, and confusion.

    44 |     45 | 46 |

    Tone can be added only to messages, and it is added as an <x> tag inside a message. The <x> tag will look something like this:

    47 | 48 | <x xmlns='jabber:x:tone'>angry</x> 49 | 50 |

    The specified tone is included as CDATA within the <x> element.

    51 | 52 |

    Here is an example of a message with a tone:

    53 | 54 | <message to='mikem@jabber.org'> 55 | <body> 56 | Why the hell did they reject my idea? 57 | </body> 58 | <x xmlns='jabber:x:tone'>angry</x> 59 | </message> 60 | 61 |     62 |     63 | 64 |

    Tones are not meant to be sent with every message. They should be used only in cases where a tone dramatically applies. The overuse of tones will cause them to lose their effect.

    65 |

    Because tones are abstract and not clearly defined, there is no standard list of tones. Clients should receive the tone as it is and display it as plain text, in such a way that it is linked to a specific message. Clients may want to have a specified list of tones that a user can select from when sending a message.

    66 |

    Tones should be short and simple. Here is a list of good tones:

    67 |
      68 |
    • angry
      • 69 |
    • confused
      • 70 |
    • excited
      • 71 |
    • joking
      • 72 |
    • sad
      • 73 |
    • sarcastic
      • 74 |
    • serious
      • 75 |
    76 |     77 |     78 | -------------------------------------------------------------------------------- /xep-0028.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | No Such XEP 10 | This document was removed from the XSF website and source control at the request of the author. 11 | &LEGALNOTICE; 12 | 0028 13 | Retracted 14 | Informational 15 | Standards 16 | 17 | 18 | 19 | N/A 20 | &dizzyd; 21 | 22 | 0.1 23 | 2001-08-20 24 | none 25 |

    No such specification.

     26 |     27 |
    28 | 29 |

    This document was removed from the XSF website and source control at the request of the author. If you have any questions about this specification, please contact the &EDITOR;.

    30 |     31 |     32 | -------------------------------------------------------------------------------- /xep-0061.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Shared Notes 10 | A simplistic mechanism for shared notes, modeled after common stickie note applications. 11 | &LEGALNOTICE; 12 | 0061 13 | Deferred 14 | Informational 15 | Standards 16 | XMPP Core 17 | 18 | 19 | Not yet assigned 20 | 21 | Jeremie 22 | Miller 23 | jer@jabber.org 24 | jer@jabber.org 25 | 26 | 27 | 0.2 28 | 2003-09-30 29 | psa 30 | At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational. 31 | 32 | 33 | 0.1 34 | 2002-12-06 35 | jer 36 | Initial version. 37 | 38 |
    39 | 40 |

    A very simple namespace contaning display hints for the content in a message. Can be used for 41 | person-person collaboration, or by a service managing notes.

    42 |     43 | 44 | 45 |

    Normal messages are sent, with a sharednote namespace extending them hinting to any supporting client on 46 | how to display the message as a note instead. Any changes to the note within that client should then be sent 47 | back to the sender, either automatically or when the user saves the note (depending on the update element, by 48 | default on a save action by the user).

    49 | 50 | 52 | 1X544O 53 | Council Votes 54 | Need votes from bob, tom, and jane yet for XEP-0000 55 | 56 | #001122 57 | #221100 58 | font-name 59 | %left 60 | %top 61 | # 62 | % 63 | % 64 | auto|user 65 | 66 | 67 | ]]> 68 | 69 |

    Any element not specified in the note should use the last known setting or client defaults, so that when a 70 | change is sent, only the changed elements are returned.

    71 | 72 |     73 | 74 | 75 | 76 |

    Each thread is a different shared note. Auto updates should use an internal client timer and batch large 77 | changes into chunks, when the user is typing every 5-10 seconds or so. When the user has made changes that 78 | haven't been sent and an update comes in on the same thread the client should prompt the user with the 79 | changes offering to replace or save their changes.

    80 | 81 |     82 |     83 | 84 | -------------------------------------------------------------------------------- /xep-0063.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | %ents; 6 | ]> 7 | 8 | 9 | 10 | 11 |
    12 | Basic Filtering Operations 13 | A module that provides basic conditions and actions for packet filtering. 14 | &LEGALNOTICE; 15 | 0063 16 | Deferred 17 | Informational 18 | Standards 19 | XEP-0062 20 | 21 | 22 | Not yet assigned 23 | 24 | Robert 25 | Norris 26 | rob@cataclysm.cx 27 | rob@cataclysm.cx 28 | 29 | 30 | 0.2 31 | 2003-09-30 32 | psa 33 | At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational. 34 | 35 | 36 | 0.1 37 | 2002-12-05 38 | rn 39 | Initial version. 40 | 41 |
    42 | 43 | 44 |

    This document defines a module for &xep0062; that provides some basic conditions and actions to perform common packet filtering tasks.

    45 | 46 |

    This module operates in the "http://jabber.org/protocol/filter/basic" namespace.

    47 |     48 | 49 | 50 |

    This module defines the fullowing conditions:

    51 | 52 |
      53 |
    • <message/> - true if the packet is a <message/> packet.
      • 54 |
    • <presence/> - true if the packet is a <presence/> packet.
      • 55 |
    • <iq/> - true if the packet is a <iq/> packet. If this element contains CDATA, then it must match the namespace of the first element inside the packet (typically <query/>) in order to be true.
      • 56 |
    • <to/> - true when the CDATA of this element matches the "to" attribute of the packet.
      • 57 |
    • <from/> - true when the CDATA of this element matches the "from" attribute of the packet.
      • 58 |
    • <type/> - true when the CDATA of this element matches the "type" attribute of the packet.
      • 59 |
    60 | 61 | 63 | ]]> 64 | 65 | jabber:iq:version 67 | ]]> 68 | 69 | user@company.com 71 | ]]> 72 | 73 |     74 | 75 | 76 |

    This module defines the fullowing actions:

    77 | 78 |
      79 |
    • <drop/> - drops the packet
      • 80 |
    • <bounce/> - bounces the packet with the error specified in the "code" attribute of this element.
      • 81 |
    • <redirect/> - redirects the packet to the JID specified in the CDATA of this element.
      • 82 |
    • <copy/> - sends a copy of the packet to the JID specified in the CDATA of this element, while giving the original packet to the user.
      • 83 |
    84 | 85 | 87 | ]]> 88 | 89 | me@home.com 91 | ]]> 92 | 93 |     94 | 95 | 96 |

    There are no security features or concerns related to this proposal.

    97 |     98 | 99 | 100 |

    This document requires no interaction with the IANA.

    101 |     102 | 103 | 104 |

    No namespaces or parameters need to be registered with JANA as a result of this document.

    105 |     106 | 107 |     108 | -------------------------------------------------------------------------------- /xep-0064.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | %ents; 6 | ]> 7 | 8 | 9 | 10 | 11 |
    12 | XPath Filtering 13 | A module that provides an XPath matching condition for packet filtering. 14 | &LEGALNOTICE; 15 | 0064 16 | Deferred 17 | Informational 18 | Standards 19 | XEP-0062 20 | 21 | 22 | Not yet assigned 23 | 24 | Robert 25 | Norris 26 | rob@cataclysm.cx 27 | rob@cataclysm.cx 28 | 29 | 30 | 0.2 31 | 2003-09-30 32 | psa 33 | At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational. 34 | 35 | 36 | 0.1 37 | 2002-12-05 38 | rn 39 | Initial version. 40 | 41 |
    42 | 43 | 44 |

    This document defines a module for &xep0062; that provides an XPath matching condition for packet filtering.

    45 | 46 |

    This module operates in the "http://jabber.org/protocol/filter/xpath" namespace.

    47 |     48 | 49 | 50 |

    This module defines the fullowing conditions:

    51 | 52 |
      53 |
    • <xpath/> - true if the XPath expression contained in the CDATA of this element, when applied to the packet, returns one or more nodes.
      • 54 |
    55 | 56 | /message/subject 58 | ]]> 59 | 60 | /presence/x[namespace-uri()=='jabber:x:delay'] 62 | ]]> 63 | 64 |     65 | 66 | 67 |

    There are no security features or concerns related to this proposal.

    68 |     69 | 70 | 71 |

    This document requires no interaction with the IANA.

    72 |     73 | 74 | 75 |

    No namespaces or parameters need to be registered with JANA as a result of this document.

    76 |     77 | 78 |     79 | -------------------------------------------------------------------------------- /xep-0069.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Compliance SIG 10 | A proposal to form a SIG devoted to issues related to protocol compliance. 11 | &LEGALNOTICE; 12 | 0069 13 | Deferred 14 | SIG Formation 15 | None 16 | 17 | 18 | 19 | N/A 20 | &stpeter; 21 | 22 | 0.1 23 | 2003-01-29 24 | psa 25 | Initial release 26 | 27 |
    28 | 29 |

    The XMPP Standards Foundation has an initiative underway to define and implement compliance testing of software that is based on XMPP and XSF-approved protocols. To date, participation in this compliance program has been limited to elected members of the XSF. However, not all matters related to the compliance program need to be limited to XSF members. In particular, it would be valuable to receive community feedback and input regarding test plans, testing software, and the like. In order to broaden participation, we propose that the XSF form a standing Jabber Interest Group devoted to compliance.

    30 |     31 | 32 |

    The Compliance SIG shall provide a public forum for discussion and development of systems for testing compliance with the protocols defined and accepted by the XSF. It shall not have ultimate accountability for the XSF compliance program; rather, that accountability shall rest with the members-only Compliance Team. The Compliance SIG shall act in an advisory capacity in relation to the Compliance Team. In essence, the relationship between the Compliance SIG and the Compliance Team is analagous to the relationship between the Standards SIG and the Jabber Council.

    33 |

    In particular, the Compliance SIG shall work with the Compliance Team to define the processes, standards, test cases, and testing software required by the compliance program. However, the Compliance SIG shall not be privy to actual testing results, which shall be available only to the Compliance Team.

    34 |     35 | 36 |

    The Compliance SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Compliance SIG discussions shall be conducted on a dedicated mailing list <compliance-jig@jabber.org> as well as in the <foundation@conference.jabber.org> chatroom.

    37 |     38 | 39 |

    The Compliance SIG shall be a standing SIG, and shall exist as long as the XSF compliance program is in operation.

    40 |     41 | 42 |

    The Compliance SIG shall produce at least the following deliverables:

    43 |
      44 |
    • Documentation of the testing process
      • 45 |
    • Compliance test plans
      • 46 |
    • Compliance testing software
      • 47 |
    • Logo requirements
      • 48 |
    49 |     50 |     51 | -------------------------------------------------------------------------------- /xep-0089.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Generic Alerts 10 | A protocol for generic alerts (similar to .NET Alerts service). 11 | &LEGALNOTICE; 12 | 0089 13 | Deferred 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | 19 | 20 | Not yet assigned 21 | 22 | 23 | 24 | Richard 25 | Dobson 26 | richard@dobson-i.net 27 | richard@dobson-i.net 28 | 29 | 30 | 0.2 31 | 2003-05-16 32 | red 33 | Changed element from x to alert. 34 | 35 | 36 | 0.1 37 | 2003-05-12 38 | red 39 | Initial version. 40 | 41 |
    42 | 43 |

    Generic Alerts is a way to extend headlines to allow functionality similar to .NET Alerts.

    44 |     45 | 46 |

    The motivations for this document are:

    47 |
      48 |
    • To allow services to send alerts to users, e.g. like an auction notifying you when you are outbid or that you have won
      • 49 |
    50 |     51 | 52 | 53 |

    Generic Alerts extend headline messages to specify such things as a logo (32x32 png) and url to goto when the alert is clicked:

    54 | 56 | Auction Alert 57 | You have been outbid! 58 | 59 | http://www.auction.com/alert.png 60 | http://www.auction.com/item?1292192 61 | 62 | ]]> 63 |     64 |     65 | 66 |

    The following guidelines may assist client developers.

    67 |
      68 |
    • The existance of an alert element of the namespace 'http://jabber.org/protocol/alert' means this is an alert and not a normal headline.
      • 69 |
    • Alerts should be displayed differently, possibly in toast popups.
      • 70 |
    • The logo is an optional graphic to display representing the service being alerted on, e.g. ebay logo.
      • 71 |
    • When clicked on the users web browser will be opened to the specified url.
      • 72 |
    73 |     74 | 75 |

    None.

    76 |     77 | 78 |

    No IANA interaction required.

    79 |     80 | 81 |

    The ®ISTRAR; will need to register the new namespace of "http://jabber.org/protocol/alert".

    82 |     83 |     84 | -------------------------------------------------------------------------------- /xep-0182.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Application-Specific Error Conditions 10 | This document defines a registry of application-specific error conditions. 11 | &LEGALNOTICE; 12 | 0182 13 | Active 14 | Procedural 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | 20 | 21 | 22 | errors 23 | 24 | &stpeter; 25 | 26 | 1.1 27 | 2008-03-05 28 | psa 29 |

    Changed namespace from http://jabber.org/protocol/errors to urn:xmpp:errors.

     30 |     31 | 32 | 1.0 33 | 2006-05-16 34 | psa 35 |

    Per a vote of the Jabber Council, advanced status to Active; also added example.

     36 |     37 | 38 | 0.2 39 | 2006-04-28 40 | psa 41 |

    Added note about scope of registry.

     42 |     43 | 44 | 0.1 45 | 2006-03-23 46 | psa 47 |

    Initial version.

     48 |     49 | 50 | 0.0.1 51 | 2006-03-21 52 | psa 53 |

    First draft.

     54 |     55 |
    56 | 57 |

    &xmppcore; specifies that an XMPP error stanza may include a child element qualified by an XML namespace other than 'urn:ietf:params:xml:ns:xmpp-stanzas'. This enables any XMPP protocol extension to define its own application-specific error conditions, such as the following:

    58 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | ]]> 69 |

    Although the inclusion of application-specific error conditions introduces a great deal of flexibility, it may also lead to confusion regarding possible conditions. Therefore, this document defines a registry of application-specific error conditions, to be maintained by the ®ISTRAR;. In addition, this document registers a namespace of 'urn:xmpp:errors' as a fallback namespace for generalized error conditions that are not specific to a particular protocol (e.g., <stanza-too-big/> as a particular form of the ¬acceptable; condition).

    70 |     71 | 72 | 73 |

    The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).

    74 |

    All application-specific error conditions that are defined in XMPP Extension Protocol specifications MUST be included in this registry. Application-specific error conditions that are defined outside of the XMPP Standards Foundation's standards process (see &xep0001;) MAY be included in this registry, but it is not required for them to be so registered.

    75 | 76 | ®PROCESS; 77 | 79 | the XML namespace that qualifies the condition 80 | the XML element of the error condition 81 | a natural-language description of the error condition 82 | the document in which the condition is specified 83 | 84 | ]]> 85 |

    The registrant may register more than one condition at a time, each contained in a separate <condition/> element.

    86 |     87 |     88 | 89 |

    The ®ISTRAR; includes 'urn:xmpp:errors' in its registry of protocol namespaces.

    90 |     91 |     92 | 93 |

    This document introduces no known security vulnerabilities.

    94 |     95 | 96 |

    This document requires no interaction with &IANA;.

    97 |     98 |     99 | -------------------------------------------------------------------------------- /xep-0190.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Best Practice for Closing Idle Streams 10 | This document specifies a best practice for closing an XML stream that is perceived to be idle. 11 | &LEGALNOTICE; 12 | 0190 13 | Obsolete 14 | Informational 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | 20 | 21 | 22 | RFC 6120 23 | 24 | N/A 25 | 26 | Carlo 27 | von Loesch 28 | lynX@jabber.getting.psyced.org 29 | lynX@ve.symlynX.com 30 | 31 | 32 | 1.1 33 | 2012-03-06 34 | psa 35 |

    Changed status to Obsolete because it is superseded by RFC 6120.

     36 |     37 | 38 | 1.0 39 | 2007-01-04 40 | psa 41 | Per a vote of the XMPP Council, advanced status to Active. 42 | 43 | 44 | 0.1 45 | 2006-07-26 46 | psa 47 |

    Initial version.

     48 |     49 | 50 | 0.0.2 51 | 2006-06-30 52 | cvl 53 | Second draft. 54 | 55 | 56 | 0.0.1 57 | 2006-05-31 58 | cvl 59 | First draft. 60 | 61 |
    62 | 63 | 64 |

    &rfc3920; describes several ways to terminate an XML stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.

    65 |

    Note: The recommendation described herein has been incorporated into &rfc6120;.

    66 |     67 | 68 | 69 | 70 |

    As shown in the basic "session" example in the Simplified Stream Examples (4.8 of RFC 3920), it is a valid transaction to close the outgoing stream by sending

    71 | ]]> 72 |

    then wait for the other entity to close its stream, like this:

    73 | ]]> 74 |

    and shut down the underlying TCP connection.

    75 |

    This will ensure that, should the other entity have transmitted any data, it will arrive and be processed before the TCP connection is terminated.

    76 |

    Special care MUST be taken that under no circumstance further packets may be written to the socket after the stream was closed, until the other side shuts down the socket.

    77 |

    On the outgoing TCP connection, an implementation MAY do a read-only shutdown of the socket, as long as the other side will safely be able to send its stream termination token.

    78 |     79 | 80 |

    In case the other entity fails to close the stream within a reasonable time frame, the entity that started the handshake is entitled to terminate the TCP connection. Since the stream has already been closed, it is correct not to produce an error condition.

    81 |     82 |     83 | 84 | 85 |

    Existing implementations should be updated to use the 'Handshake Stream Shutdown' strategy when shutting down streams that are no longer needed. This strategy is fully backwards-compatible and does not introduce any known communication problems.

    86 |     87 | 88 | 89 |

    This proposal introduces no new security aspects.

    90 |     91 | 92 | 93 |

    This proposal requires no interaction with &IANA;.

    94 |     95 | 96 | 97 |

    This proposal requires no interaction with the ®ISTRAR;.

    98 |     99 | 100 |     101 | -------------------------------------------------------------------------------- /xep-0211.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | XMPP Basic Client 2008 10 | This document defines the XMPP Basic Client 2008 compliance level. 11 | &LEGALNOTICE; 12 | 0211 13 | Obsolete 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XMPP IM 20 | XEP-0030 21 | XEP-0106 22 | XEP-0115 23 | XEP-0138 24 | 25 | 26 | 27 | XEP-0242 28 | 29 | N/A 30 | &stpeter; 31 | 32 | 1.0 33 | 2007-07-11 34 | psa 35 |

    Per a vote of the XMPP Council, advanced to Draft.

     36 |     37 | 38 | 0.6 39 | 2007-07-11 40 | psa 41 |

    Changed XEP-0115 to recommended.

     42 |     43 | 44 | 0.5 45 | 2007-06-18 46 | psa 47 |

    Removed implementation note about XMPP ICA.

     48 |     49 | 50 | 0.4 51 | 2007-06-14 52 | psa 53 |

    Per community discussion, changed XMPP Core and XMPP IM references back to RFCs with recommendation for developers to also consult bis drafts; added reference to XEP-0178; suggested bundling of root certificate for XMPP ICA.

     54 |     55 | 56 | 0.3 57 | 2007-06-11 58 | psa 59 |

    Changed XMPP Core and XMPP IM references to bis drafts; added implementation notes.

     60 |     61 | 62 | 0.2 63 | 2007-05-11 64 | psa 65 |

    Added JID Escaping (XEP-0106) and Stream Compression (XEP-0138) as recommended.

     66 |     67 | 68 | 0.1 69 | 2007-04-20 70 | psa 71 |

    Initial published version.

     72 |     73 | 74 | 0.0.1 75 | 2007-03-30 76 | psa 77 |

    First draft, split from XEP-0073.

     78 |     79 |
    80 | 81 |

    The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the XMPP Basic Client 2008 certification level.

    82 |     83 | 84 |

    The XMPP Basic Client 2008 certification level is defined as follows:

    85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 |
    SpecificationRequirement Level
    &rfc6120;REQUIRED
    &rfc6121;REQUIRED
    &xep0030;REQUIRED
    &xep0106;RECOMMENDED
    &xep0115;RECOMMENDED
    &xep0138;RECOMMENDED
    115 |     116 | 117 |

    Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.

    118 |

    Developers are advised to refer to &xep0178; regarding proper implementation of the SASL EXTERNAL mechanism in XMPP.

    119 |     120 | 121 |

    This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.

    122 |     123 | 124 |

    This document requires no interaction with &IANA;.

    125 |     126 | 127 |

    This document requires no interaction with the ®ISTRAR;.

    128 |     129 |     130 | -------------------------------------------------------------------------------- /xep-0212.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | XMPP Basic Server 2008 10 | This document defines the XMPP Basic Server 2008 compliance level. 11 | &LEGALNOTICE; 12 | 0212 13 | Obsolete 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XMPP IM 20 | XEP-0030 21 | XEP-0078 22 | XEP-0086 23 | XEP-0138 24 | 25 | 26 | 27 | XEP-0243 28 | 29 | N/A 30 | &stpeter; 31 | 32 | 1.0 33 | 2007-07-11 34 | psa 35 |

    Per a vote of the XMPP Council, advanced to Draft.

     36 |     37 | 38 | 0.5 39 | 2007-06-18 40 | psa 41 |

    Removed implementation note about XMPP ICA.

     42 |     43 | 44 | 0.4 45 | 2007-06-15 46 | psa 47 |

    Per community discussion, changed XMPP Core and XMPP IM references back to RFCs with recommendation for developers to also consult bis drafts; added reference to XEP-0178; suggested bundling of root and intermediate certificates for XMPP ICA.

     48 |     49 | 50 | 0.3 51 | 2007-06-11 52 | psa 53 |

    Removed JID Escaping (XEP-0106) as recommended since it applies to native clients but not native servers; changed XMPP Core and XMPP IM references to bis drafts added implementation notes.

     54 |     55 | 56 | 0.2 57 | 2007-05-11 58 | psa 59 |

    Added JID Escaping (XEP-0106) and Stream Compression (XEP-0138) as recommended.

     60 |     61 | 62 | 0.1 63 | 2007-04-20 64 | psa 65 |

    Initial published version.

     66 |     67 | 68 | 0.0.1 69 | 2007-03-30 70 | psa 71 |

    First draft, split from XEP-0073.

     72 |     73 |
    74 | 75 |

    The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the XMPP Basic Server 2008 certification level.

    76 |     77 | 78 |

    The XMPP Basic Server 2008 certification level is defined as follows:

    79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 |
    SpecificationRequirement Level
    &rfc6120;REQUIRED
    &rfc6121;REQUIRED
    &xep0030;REQUIRED
    &xep0078;RECOMMENDED *
    &xep0086;RECOMMENDED *
    &xep0138;RECOMMENDED
    109 |

    * Note: Support for XEP-0078 and XEP-0086 is recommended for backward compatibility only. It is likely that compliance definitions for future years will remove these recommendations.

    110 |     111 | 112 |

    Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.

    113 |

    Developers are advised to refer to &xep0178; regarding proper implementation of the SASL EXTERNAL mechanism in XMPP.

    114 |     115 | 116 |

    This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.

    117 |     118 | 119 |

    This document requires no interaction with &IANA;.

    120 |     121 | 122 |

    This document requires no interaction with the ®ISTRAR;.

    123 |     124 |     125 | -------------------------------------------------------------------------------- /xep-0213.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | XMPP Intermediate IM Client 2008 10 | This document defines the XMPP Intermediate IM Client 2008 compliance level. 11 | &LEGALNOTICE; 12 | 0213 13 | Obsolete 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XEP-0211 19 | XEP-0016 20 | XEP-0045 21 | XEP-0054 22 | XEP-0085 23 | XEP-0155 24 | 25 | 26 | 27 | XEP-0242 28 | 29 | N/A 30 | &stpeter; 31 | 32 | 1.0 33 | 2007-07-11 34 | psa 35 |

    Per a vote of the XMPP Council, advanced to Draft.

     36 |     37 | 38 | 0.5 39 | 2007-07-11 40 | psa 41 |

    Added XEP-0155 as recommended.

     42 |     43 | 44 | 0.4 45 | 2007-06-11 46 | psa 47 |

    Added implementation notes.

     48 |     49 | 50 | 0.3 51 | 2007-05-30 52 | psa 53 |

    Per list discussion, removed XHTML-IM.

     54 |     55 | 56 | 0.2 57 | 2007-05-11 58 | psa 59 |

    Per list discussion, modified MUC support, added privacy lists, and added vCard support.

     60 |     61 | 62 | 0.1 63 | 2007-04-20 64 | psa 65 |

    Initial published version.

     66 |     67 | 68 | 0.0.1 69 | 2007-03-30 70 | psa 71 | First draft, split from XEP-0117. 72 | 73 |
    74 | 75 |

    The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the XMPP Intermediate IM Client 2008 certification level.

    76 |     77 | 78 |

    The XMPP Intermediate IM Client 2008 certification level is defined as follows:

    79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 |
    SpecificationRequirement Level
    &xep0211;REQUIRED
    &xep0016;RECOMMENDED
    &xep0045;, Entity Use Cases and Occupant Use CasesREQUIRED
    &xep0054;RECOMMENDED
    &xep0085;REQUIRED
    &xep0155;RECOMMENDED
    109 |     110 | 111 |

    Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.

    112 |     113 | 114 |

    This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.

    115 |     116 | 117 |

    This document requires no interaction with &IANA;.

    118 |     119 | 120 |

    This document requires no interaction with the ®ISTRAR;.

    121 |     122 |     123 | -------------------------------------------------------------------------------- /xep-0216.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | XMPP Intermediate IM Server 2008 10 | This document defines the XMPP Intermedate IM Server 2008 compliance level. 11 | &LEGALNOTICE; 12 | 0216 13 | Obsolete 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XEP-0212 19 | XEP-0016 20 | XEP-0045 21 | XEP-0054 22 | XEP-0163 23 | 24 | 25 | 26 | XEP-0243 27 | 28 | N/A 29 | &stpeter; 30 | 31 | 1.0 32 | 2007-07-11 33 | psa 34 |

    Per a vote of the XMPP Council, advanced to Draft.

     35 |     36 | 37 | 0.2 38 | 2007-06-11 39 | psa 40 |

    Added implementation notes.

     41 |     42 | 43 | 0.1 44 | 2007-04-20 45 | psa 46 |

    Initial published version.

     47 |     48 | 49 | 0.0.1 50 | 2007-05-11 51 | psa 52 |

    First draft.

     53 |     54 |
    55 | 56 |

    The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the XMPP Intermediate IM Server 2008 certification level.

    57 |     58 | 59 |

    The XMPP Intermediate IM Server 2008 certification level is defined as follows:

    60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 |
    SpecificationRequirement Level
    &xep0212;REQUIRED
    &xep0016;REQUIRED
    &xep0045;REQUIRED
    &xep0054;REQUIRED
    &xep0163;RECOMMENDED
    86 |     87 | 88 |

    Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.

    89 |

    It is an implementation decision how to enable support for multi-user chat, e.g., directly or by means of an external component (see &xep0114;).

    90 |     91 | 92 |

    This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.

    93 |     94 | 95 |

    This document requires no interaction with &IANA;.

    96 |     97 | 98 |

    This document requires no interaction with the ®ISTRAR;.

    99 |     100 |     101 | -------------------------------------------------------------------------------- /xep-0240.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Auto-Discovery of JabberIDs 10 | This specification defines a recommended best practice for linking to JabberIDs from documents hosted on the World Wide Web. 11 | &LEGALNOTICE; 12 | 0240 13 | Deferred 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | 20 | 21 | 22 | NOT_YET_ASSIGNED 23 | &stpeter; 24 | &ralphm; 25 | 26 | 0.1 27 | 2008-04-30 28 | psa 29 |

    Initial published version.

     30 |     31 | 32 | 0.0.1 33 | 2008-04-28 34 | psa/rm 35 |

    First draft.

     36 |     37 |
    38 | 39 | 40 |

    &w3html; defines a <link/> element that defines a relationship between a document and another resource on the Internet. Such a resource can be a JabberID. Examples include the JabberID of a document author, a &xep0045; room where the document can be discussed, or a &xep0060; node where RSS or Atom feeds related to the document are hosted (e.g., see &rfc4287;). This specification defines a recommended approach for linking to JabberIDs in this way.

    41 |     42 | 43 | 44 |

    The RECOMMENDED format is as follows.

    45 | 49 | ]]> 50 |

    The 'href' attribute is REQUIRED and its value MUST be an XMPP URI or IRI that conforms to &rfc5122;. The URI SHOULD NOT include an action as described in &xep0147; and registered at &QUERYTYPES;, so that the URI can be appropriately dereferenced as described below. The URI MAY include a node key as shown in the examples below.

    51 |

    The 'rel' attribute is RECOMMENED and its value SHOULD be a link relation as registered in the &ianalinks; or other registry.

    52 |

    In addition to 'href' and 'rel', the HTML and XHTML specifications define a number of other allowable attributes for the <link/> element. These attributes MAY be included. However, because a JabberID is a bare address and there is no hosted media associated with a JabberID, the 'charset', 'media', and 'type' attribute SHOULD NOT be included.

    53 |     54 | 55 | 56 |

    When an application encounters an auto-discovery link to a JabberID, it SHOULD pass it to an appropriate helper application (such as an XMPP client). The helper application then SHOULD dereference the URI, and send an XMPP &xep0030; request to the referenced JID, passing the optional node parameter. The service discovery response therefore enables a full range of future actions.

    57 |     58 | 59 | 60 |

    The following example shows a JabberID that points to the same entity as the document itself (e.g., the author of an "about-the-author" page).

    61 | 63 | ]]> 64 |

    The following example shows a JabberID that points to a multi-user chat room where the document can be discussed.

    65 | 67 | ]]> 68 |

    The following example shows a JabberID that points to a publish-subscribe node where notifications related to the document can be retrieved.

    69 | 71 | ]]> 72 |     73 | 74 | 75 |

    Advertising an XMPP address so that it can be automatically discovered may expose that address to abusive communications. Care should be taken when choosing whether to advertise a JID that corresponds to an end user's primary XMPP address.

    76 |     77 | 78 | 79 |

    This document currently requires no interaction with &IANA;. However, a future version of this specification may register new link relations with the IANA.

    80 |     81 | 82 | 83 |

    This document requires no interaction with the ®ISTRAR;.

    84 |     85 | 86 |     87 | -------------------------------------------------------------------------------- /xep-0242.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | XMPP Client Compliance 2009 10 | This document defines XMPP client compliance levels for 2009. 11 | &LEGALNOTICE; 12 | 0242 13 | Obsolete 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XMPP IM 20 | XEP-0016 21 | XEP-0030 22 | XEP-0045 23 | XEP-0054 24 | XEP-0085 25 | XEP-0115 26 | XEP-0191 27 | 28 | 29 | XEP-0211 30 | XEP-0213 31 | 32 | 33 | XEP-0270 34 | 35 | N/A 36 | &stpeter; 37 | 38 | 1.0 39 | 2008-09-08 40 | psa 41 |

    Per a vote of the XMPP Council, advanced specification to Draft.

     42 |     43 | 44 | 0.2 45 | 2008-06-18 46 | psa 47 |

    Changed compliance level names, updated required support per Council discussion.

     48 |     49 | 50 | 0.1 51 | 2008-05-28 52 | psa 53 |

    Initial published version, incorporating Council feedback.

     54 |     55 | 56 | 0.0.1 57 | 2008-05-27 58 | psa 59 |

    First draft, copied and modified from XEP-0211.

     60 |     61 |
    62 | 63 |

    The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the 2009 compliance levels for XMPP clients. Support for the listed specifications is REQUIRED for compliance purposes.

    64 |     65 | 66 |

    The XMPP Core Client 2009 certification level is defined as follows:

    67 |
      68 |
    • &rfc3920;
      • 69 |
    • &rfc3921;
      • 70 |
    • &xep0030;
      • 71 |
    • &xep0115;
      • 72 |
    73 |     74 | 75 |

    The XMPP Advanced Client 2009 certification level is defined as follows:

    76 |
      77 |
    • XMPP Core Client 2009 (see above)
      • 78 |
    • &xep0016; and &xep0191;
      • 79 |
    • &xep0045; (Entity Use Cases and Occupant Use Cases)
      • 80 |
    • &xep0054;
      • 81 |
    • &xep0085;
      • 82 |
    83 |     84 | 85 |

    Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.

    86 |

    Developers are advised to refer to &xep0178; regarding proper implementation of the SASL EXTERNAL mechanism in XMPP.

    87 |     88 | 89 |

    This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.

    90 |     91 | 92 |

    This document requires no interaction with &IANA;.

    93 |     94 | 95 |

    This document requires no interaction with the ®ISTRAR;.

    96 |     97 |     98 | -------------------------------------------------------------------------------- /xep-0243.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | XMPP Server Compliance 2009 10 | This document defines XMPP server compliance levels for 2009. 11 | &LEGALNOTICE; 12 | 0243 13 | Obsolete 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XMPP IM 20 | XEP-0016 21 | XEP-0030 22 | XEP-0045 23 | XEP-0054 24 | XEP-0124 25 | XEP-0163 26 | XEP-0191 27 | XEP-0206 28 | 29 | 30 | XEP-0212 31 | XEP-0216 32 | 33 | 34 | XEP-0270 35 | 36 | N/A 37 | &stpeter; 38 | 39 | 1.0 40 | 2008-09-08 41 | psa 42 |

    Per a vote of the XMPP Council, advanced specification to Draft.

     43 |     44 | 45 | 0.3 46 | 2008-07-16 47 | psa 48 |

    Added PEP as required for Advanced level per Council discussion.

     49 |     50 | 51 | 0.2 52 | 2008-06-18 53 | psa 54 |

    Changed compliance level names, updated required support per Council discussion.

     55 |     56 | 57 | 0.1 58 | 2008-05-28 59 | psa 60 |

    Initial published version, incorporating Council feedback.

     61 |     62 | 63 | 0.0.1 64 | 2009-05-27 65 | psa 66 |

    First draft, copied and modified from XEP-0212.

     67 |     68 |
    69 | 70 |

    The &XSF; defines protocol suites for the purpose of compliance testing and software certification. This document specifies the 2009 compliance levels for XMPP servers. Support for the listed specifications is REQUIRED for compliance purposes.

    71 |     72 | 73 |

    The XMPP Core Server 2009 certification level is defined below. Support for these specifications is REQUIRED for compliance purposes.

    74 |
      75 |
    • &rfc3920;
      • 76 |
    • &rfc3921;
      • 77 |
    • &xep0030;
      • 78 |
    79 |     80 | 81 |

    The XMPP Advanced Server 2009 certification level is defined as follows:

    82 |
      83 |
    • XMPP Core Server 2009 (see above)
      • 84 |
    • &xep0016; and &xep0191;
      • 85 |
    • &xep0045; (support may be enabled via an external component or an internal server module/plugin)
      • 86 |
    • &xep0054;
      • 87 |
    • &xep0124; and &xep0206; (support may be enabled via an external component or an internal server module/plugin)
      • 88 |
    • &xep0163;
      • 89 |
    90 |     91 | 92 |

    Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.

    93 |

    Developers are advised to refer to &xep0178; regarding proper implementation of the SASL EXTERNAL mechanism in XMPP.

    94 |     95 | 96 |

    This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.

    97 |     98 | 99 |

    This document requires no interaction with &IANA;.

    100 |     101 | 102 |

    This document requires no interaction with the ®ISTRAR;.

    103 |     104 |     105 | -------------------------------------------------------------------------------- /xep-0378.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | Off-the-Record Messaging Protocol version 3 Off-the-Record Messaging Protocol (OTR) version 3 <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> (Accessed 2015-08-30)." > 5 | %ents; 6 | ]> 7 | 8 | 9 |
    10 | OTR Discovery 11 | 12 | This document provides a mechanism by which OTR encryption support can be 13 | discovered in XMPP, without relying on OTRs protocol agnostic discovery 14 | mechanism. 15 | 16 | &LEGALNOTICE; 17 | 0378 18 | Deferred 19 | Standards Track 20 | Standards 21 | Council 22 | 23 | XMPP Core 24 | XEP-0030 25 | 26 | 27 | 28 | OTR-DISCO 29 | &sam; 30 | 31 | 0.1 32 | 2017-09-11 33 | XEP Editor (jwi) 34 | Defer due to lack of activity. 35 | 36 | 37 | 0.0.1 38 | 2016-07-15 39 | ssw 40 |

    Initial version approved by the Council.

     41 |     42 |
    43 | 44 |

    45 | The Off-the-Record messaging protocol (OTR) is widely layered on top of 46 | XMPP to provide end-to-end encryption. Current use of the protocol is 47 | described in &xep0364;. OTR provides its own discovery mechanism in which 48 | it sends messages with special whitespace characters to indicate support. 49 | While this works when initializing a session, there is no way to query a 50 | client for support and to know in advance that a particular version of 51 | OTR is supported. This specification aims to solve that by providing an 52 | in-band mechanism for discovering OTR support in XMPP. 53 |

    54 |

    55 | It should be noted that newer, more secure encryption protocols exist for 56 | XMPP, and that new implementations of OTR are discouraged. This protocol 57 | is primarily intended to solve issues with existing implementations of 58 | OTR. 59 |

    60 |     61 | 62 |

    63 | If an entity supports OTR it MUST advertise the fact by returning a 64 | feature of 'urn:xmpp:otr:0' &VNOTE; in response to a &xep0030; information 65 | request. This indicates support for OTRv3 as defined by &otr3;. 66 |

    67 | ]]> 69 |

    70 | If older versions of OTR are required, they may be discovered out of band 71 | using OTRs built in mechanism which is beyond the scope of this document. 72 |

    73 |     74 | 75 |

    76 | Because OTR support is advertised outside of any end-to-end encrypted 77 | stream, it may be subject to downgrade attacks (eg. the server operator 78 | may remove OTR from the features list). 79 |

    80 |     81 | 82 |

    83 | This document requires no interaction with the Internet Assigned Numbers 84 | Authority (IANA). 85 |

    86 |     87 | 88 |

    This specification defines the following XML namespaces:

    89 |
      90 |
    • urn:xmpp:otr:0
      • 91 |
    92 |

    93 | The ®ISTRAR; shall include the foregoing namespaces in its disco 94 | features registry as defined in &xep0030;. 95 |

    96 | 98 | urn:xmpp:otr:0 99 | Indicates support for Off-the-Record Messaging (OTR) version 3 100 | XEP-0378 101 | ]]> 102 |     103 |     104 | -------------------------------------------------------------------------------- /xep-0381.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Internet of Things Special Interest Group (IoT SIG) 10 | This document proposes the formation of a Special Interest Group SIG) within the XSF devoted to the application of XMPP technologies to the Internet of Things (IoT). 11 | &LEGALNOTICE; 12 | 0381 13 | Active 14 | 2020-12-15 15 | 2017-03-14 16 | Procedural 17 | None 18 | Council 19 | 20 | 21 | 22 | N/A 23 | &stpeter; 24 | 25 | Rikard 26 | Strid 27 | rikard@clayster.com 28 | 29 | 30 | 1.0.0 31 | 2021-07-27 32 | XEP Editor: jsc 33 | Accepted by Council 34 | 35 | 36 | 0.1.0 37 | 2016-11-23 38 | XEP Editor: ssw 39 | Initial published version. 40 | 41 | 42 | 0.0.1 43 | 2016-07-29 44 | psa 45 | Initial version. 46 | 47 |
    48 | 49 |

    The Internet of Things (IoT) involves the application of Internet technologies to physical things such as machines, vehicles, buildings, appliances, and industrial infrastructure. XMPP-based implementations already exist in several areas of IoT, including demand-response systems for power grids via the OpenADR Alliance <http://www.openadr.org/> and smart transducer interfaces via the IEEE XMPP Interface Working Group <http://standards.ieee.org/develop/wg/XMPPI.html>. In addition, a number of XMPP Extension Protocols (XEPs) have been proposed at the XMPP Standards Foundation (XSF) over the years related to the Internet of Things.

    50 |

    Unfortunately, there has been a lack of communication and coordination among the various IoT initiatives in the broader XMPP community of developers and standards development organization. To improve matters, the authors of this document propose to create a forum and process for constructive discussions within the XSF, in the form of an Internet of Things Special Interest Group (IoT SIG) that shall be structured in compliance with &xep0002; and that shall report to the &COUNCIL; in accordance with Article VIII of the XSF's &BYLAWS;.

    51 |     52 | 53 |

    The role of the IoT SIG shall be as follows:

    54 |
      55 |
    • Produce, or coordinate the production, of relevant XMPP Extension Protocol (XEP) documents as described below under Deliverables.
      • 56 |
    • Provide advice to the XMPP Council regarding work within the XSF on IoT topics.
      • 57 |
    • Provide advice to the XMPP Council and the XSF Board of Directors regarding work outside the XSF happening at other standards development organizations.
      • 58 |
    • Manage a dedicated forum for discussion of IoT topics within the XMPP community.
      • 59 |
    60 |

    The IoT SIG shall not itself approve XMPP extension protocols (XEPs), which tasks shall remain under the purview of the XMPP Council.

    61 |     62 | 63 |

    The IoT SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. IoT SIG discussions shall be conducted in open forums, including a dedicated mailing list at <iot@xmpp.org> (which already exists).

    64 |     65 | 66 |

    The IoT SIG shall be a standing SIG, and shall exist as long as the XMPP Council deems it useful.

    67 |     68 | 69 |

    The IoT SIG should at a minumum produce an informational XEP that provides an overview of the XMPP IoT "landscape"; this document could help the XMPP community (including XSF members, leadership, and teams) understand the Intenet of Things and especially the applicability of XMPP to common IoT use cases.

    70 |

    The IoT SIG should also produce or coordinate the production of core protocol specifications or profiles that are suitable for use in common IoT use cases. If the IoT SIG produces such protocol specifications, they should be designed so that they can be extended by private parties or other standards development organizations for more particular use cases. In coordination with the XMPP Council, the IoT SIG may also produce a requirements document or roadmap to guide its work on protocol specifications.

    71 |     72 |     73 | -------------------------------------------------------------------------------- /xep-0429.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Special Interests Group End to End Encryption 10 | This document proposes the formation of a Special Interest Group (SIG) within the XSF devoted to the development of end-to-end encryption within the context of XMPP. 11 | &LEGALNOTICE; 12 | 0429 13 | Active 14 | 2020-12-15 15 | 2020-03-10 16 | Procedural 17 | None 18 | Council 19 | 20 | 21 | 22 | SIG-E2EE 23 | &paulschaub; 24 | 25 | 1.1.0 26 | 2021-08-10 27 | mw 28 | Add discussion venue after creation by the Infrastructure Team. 29 | 30 | 31 | 1.0.0 32 | 2021-07-27 33 | XEP Editor: jsc 34 | Accepted by Council 35 | 36 | 37 | 0.2.0 38 | 2020-01-28 39 | ps 40 | Allow only XSF members to act as ambassadors 41 | 42 | 43 | 0.1.0 44 | 2020-01-28 45 | XEP Editor (jsc) 46 | Accepted by vote of Council on 2020-01-08. 47 | 48 | 49 | 0.0.1 50 | 2019-12-30 51 | ps 52 | Initial published version. 53 | 54 |
    55 | 56 |

    End-to-end encryption presents a vital tool for users to protect their communications against third parties. To ensure a good user experience it is important to agree on shared standards which are widely rolled out and adopted by implementations.

    57 |

    There already exists a number of encryption protocols with different properties and scopes. It is necessary to coordinate the efforts of further improving those standards to identify and unify common problems and patterns.

    58 |     59 | 60 |

    The role of the SIG shall be as follows:

    61 |
      62 |
    • Produce, or coordinate the production and maintenance of relevant XMPP Extension Protocol (XEP) documents as described below under Deliverables.
      • 63 |
    • Represent the interests and requirements of the XMPP community during the development of end-to-end encryption protocols that are non-exclusive to XMPP. Note: Only elected members of the XSF may act as ambassadors.
      • 64 |
    • Provide recommendations for implementers.
      • 65 |
    66 |

    The SIG-E2EE shall not itself approve XMPP extension protocols (XEPs), which tasks shall remain under the purview of the XMPP Council.

    67 |

    The scope of the SIG is limited to end-to-end encryption in contexts which are useful for instant messaging.

    68 |     69 | 70 |

    The SIG-E2EE shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Anyone who works with, or is interested in encryption protocols is invited to take part. Only elected members of the XSF however may act as ambassadors.

    71 | 72 |

    The following discussion venues have been selected for SIG-E2EE:

    73 | 74 |
      75 |
    • Mailing list: standards@xmpp.org
      • 76 |
    • MUC: e2ee@muc.xmpp.org
      • 77 |
    78 |     79 | 80 |

    The SIG-E2EE shall be a standing SIG, and shall exist as long as the XMPP Council deems it useful.

    81 |     82 | 83 |

    The SIG-E2EE should maintain active existing end-to-end encryption specifications and keep them up to date.

    84 |

    It should also coordinate the production of future end-to-end encryption specifications to keep up with the state of the art.

    85 |     86 |     87 | -------------------------------------------------------------------------------- /xep-0431.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | 6 | 7 | ]> 8 | 9 | 10 |
    11 | Full Text Search in MAM 12 | This specification proposes a field in the MAM form for full text searching. 13 | &LEGALNOTICE; 14 | 0431 15 | Deferred 16 | Standards Track 17 | Standards 18 | Council 19 | 20 | XMPP Core 21 | XEP-0313 22 | 23 | 24 | 25 | fulltextmam 26 | &dcridland; 27 | 28 | 0.2.0 29 | 2020-01-29 30 | dwd 31 | 32 |
      33 |
    • No More Beer
      • 34 |
    • Quasi-normative language around syntactic implementation
      • 35 |
    36 |     37 |     38 | 39 | 0.1.0 40 | 2020-01-29 41 | XEP Editor (jsc) 42 | Accepted by vote of Council on 2020-01-22. 43 | 44 | 45 | 0.0.1 46 | 2020-01-21 47 | dwd 48 | 49 |
      50 |
    • Initial Revision
      • 51 |
    52 |     53 |     54 |
    55 | 56 | 57 |

    &xep0313; has an extensible form. This specification extends the extensible form with an extension which extends MAM to perform full text searching. A number of existing implementations of this extension exist - extending their existing extensions to confirm to the extension in this specification now it exists is intended to be trivial.

    58 |     59 | 60 | 61 | 62 |

    Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature 63 | of &ns;.

    64 |     65 | 66 |

    Searching using full text is performed by the client supplying an additional text key, which if non-empty is used as input to a full text search of some form. The precise meaning of this field is left entirely implementation-defined at this time. Future revisions of this specification might impose additional constraints.

    67 |     68 |     69 | 70 | 71 | 72 |

    A text input field of {&ns;}fulltext is hereby defined for the 'urn:xmpp:mam:2' FORM_TYPE, as conforming to the syntax defined in &xep0068;

    73 |     74 | 75 |

    The precise matching of the supplied text string is left implementation-defined. Servers MAY use any full-text search mechanism. While this might mean that certain characters are deemed "special", clients are RECOMMENDED not to attempt any support for these, as they are unlikely to be portable between implementations. While many implementations of this protocol might conform in a purely syntactic sense, it is to be noted that the intent is that a reasonable full-text search is performed based on the input - servers SHOULD therefore honour this intent despite the lack of a formal strict definition.

    76 |     77 |     78 | 79 | 80 |

    Not sure this is needed at all.

    81 |     82 | 83 | 84 |

    None?

    85 |     86 | 87 | 88 |

    This XEP requires no interaction with &IANA;.

    89 |     90 | 91 | 92 |

    Registration of the field pointing to this document.

    93 |     94 | 95 | 96 |

    Guus der Kinderen nudged me into doing this. Matthew Wild and Kev Smith argued reasonably that nobody should have to buy beer.

    97 |     98 | 99 |     100 | -------------------------------------------------------------------------------- /xep-0442.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | Pubsub Message Archive Management 10 | This document defines a protocol to query and control a pubsub node's message archive. 11 | &LEGALNOTICE; 12 | 0442 13 | Experimental 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XEP-0030 20 | XEP-0059 21 | XEP-0060 22 | XEP-0297 23 | XEP-0313 24 | 25 | 26 | 27 | pubsub-mam 28 | &mwild; 29 | &ksmith; 30 | 31 | 0.2.0 32 | 2020-08-25 33 | XEP Editor (jsc) 34 | Accepted by vote of Council on 2020-08-19. 35 | 36 | 37 | 0.1.0 38 | 2020-03-30 39 | mw 40 | 41 |

    Split off from XEP-0313 v0.6.3 to ease advancement of that XEP and allow further clarification and expansion of pubsub use cases.

    42 |     43 |     44 |
    45 | 46 | 47 |

    This document specifies how to use &xep0313; in combination with &xep0060; to host and query archives on pubsub nodes.

    48 |     49 | 50 | 51 |

    When querying a pubsub node's archive, the 'node' attribute is added to the <query> element.

    52 | 54 | 55 | ]]> 56 | 57 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | Soliloquy 68 | 69 | To be, or not to be: that is the question: 70 | Whether 'tis nobler in the mind to suffer 71 | The slings and arrows of outrageous fortune, 72 | Or to take arms against a sea of troubles, 73 | And by opposing end them? 74 | 75 | 77 | tag:denmark.lit,2003:entry-32397 78 | 2003-12-13T18:30:02Z 79 | 2003-12-13T18:30:02Z 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | ]]> 88 |     89 | 90 | 91 |

    A PubSub service offering MAM SHOULD store each of the items published to each node. When responding to MAM requests it MUST construct the message stanza within the <forwarded> element in the same manner as the notifications sent to subscribers for the item, except that specifying the 'from' 'to' and 'id' attributes are OPTIONAL. Pubsub items must be returned one per message stanza (i.e. there MUST NOT be multiple <item> elements within the <items> element).

    92 |     93 |     94 | -------------------------------------------------------------------------------- /xep-0468.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | %ents; 5 | ]> 6 | 7 | 8 |
    9 | WebSocket S2S 10 | This specification defines a procedure to make s2s XMPP connections over WebSocket. 11 | &LEGALNOTICE; 12 | 0468 13 | Experimental 14 | Standards Track 15 | Standards 16 | Council 17 | 18 | XMPP Core 19 | XEP-0156 20 | 21 | 22 | 23 | NOT_YET_ASSIGNED 24 | 25 | Travis 26 | Burtrum 27 | travis@burtrum.org 28 | travis@burtrum.org 29 | 30 | 31 | 0.1.0 32 | 2022-07-13 33 | XEP Editor (jsc) 34 | Accepted by vote of Council on 2022-06-22. 35 | 36 | 37 | 0.0.1 38 | 2022-06-13 39 | tjb 40 |

    First draft.

     41 |     42 |
    43 | 44 |

    &rfc7395; specifies how to make c2s connections over WebSocket. This XEP extends that to also support s2s connections over WebSocket.

    45 |     46 | 47 |

    Everything mentioned in &rfc7395; should be followed with the following changes:

    48 |
      49 |
    1. Connection details are discovered by using &xep0156;
      2. 50 |
    2. For c2s, &rfc7395; requires replacing the 'jabber:client' namespace with 'urn:ietf:params:xml:ns:xmpp-framing', for s2s, the 'jabber:server' namespace should be replaced with 'urn:ietf:params:xml:ns:xmpp-framing-server'.
      3. 51 |
    3. wss (TLS) upgraded to a MUST be used, therefore SASL EXTERNAL authentication can be used as defined in &xmppcore;
      4. 52 |
    53 |     54 | 55 |

    Some hosting services only allow HTTPS proxies to access servers, meaning federating XMPP servers cannot be ran on these hosts unless s2s is accessible over HTTPS.

    56 |     57 | 58 |

    Identical to RFC 7395 Security Considerations.

    59 |     60 | 61 | 62 |

    A URN sub-namespace for framing of s2s Extensible Messaging and Presence 63 | Protocol (XMPP) streams is defined as follows.

    64 | 65 |

    URI: urn:ietf:params:xml:ns:xmpp-framing-server

    66 | 67 |

    Specification: this document

    68 | 69 |

    Registrant Contact: IESG <iesg@ietf.org>

    70 | 71 |     72 | 73 |

    This document requires no interaction with the ®ISTRAR;.

    74 |     75 |     76 | -------------------------------------------------------------------------------- /xep-0469.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | %ents; 6 | ]> 7 | 8 | 9 |
    10 | Bookmark Pinning 11 | This document defines an XMPP protocol extension to allow users to pin PEP Native Bookmarks. 12 | &LEGALNOTICE; 13 | 0469 14 | Experimental 15 | Standards Track 16 | Standards 17 | Council 18 | 19 | XMPP Core 20 | XMPP IM 21 | XEP-0402 22 | 23 | 24 | 25 | bookmarkspinning 26 | &edhelas; 27 | 28 | 0.1.0 29 | 2022-08-23 30 | XEP Editor (jsc) 31 | Accepted by vote of Council on 2022-07-27. 32 | 33 | 34 | 0.0.1 35 | 2020-05-17 36 | am 37 |

    Initial version.

     38 |     39 |
    40 | 41 |

    The &xep0402; defines a way to store Bookmarks using user PEP nodes and brings a support for extensions

    42 |

    Some users might be interested to pin some important Bookmarks when managing them.

    43 |     44 | 45 |

    This extensions allow clients to pin important bookmarks.

    46 |     47 | 48 |

    When saving a &xep0402; pinned item the client MUST add a new 'pinned' element within the 'extensions' element having the '&namespace;' namespace.

    49 | 51 | 52 | 53 | 54 | 57 | JC 58 | 59 | 60 | 61 | 62 | 63 | 64 | ... 65 | 66 | 67 | ]]> 68 |     69 | 70 |

    When handling a pinned item, a client SHOULD prioritize it and treat it as important. A client MAY display it using visual specificities (e.g., ordering, icon, color) to differenciate it from non-pinned items.

    71 |     72 | 73 |

    See considerations in &xep0402;.

    74 |     75 | 76 |

    This document requires no interaction with &IANA;.

    77 |     78 | 79 | 80 |

    This specification defines the following XML namespace:

    81 |
      82 |
    • &namespace;
      • 83 |
    84 |

    The ®ISTRAR; includes this namespace in the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

    85 |     86 | 87 | &NSVER; 88 | 89 |     90 | 91 | 93 | 94 | 99 | 100 | 101 | 102 | The protocol documented by this schema is defined in 103 | XEP-0402: http://www.xmpp.org/extensions/xep-0402.html 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | ]]> 117 | 118 |     119 | -------------------------------------------------------------------------------- /xepinfo.py: -------------------------------------------------------------------------------- 1 | # File: xepinfo.py 2 | # Version: 0.2 3 | # Description: xepinfo class 4 | # Last Modified: 2009 5 | # Author: Tobias Markmann (tm@ayena.de) 6 | 7 | ## LICENSE ## 8 | # 9 | # Copyright (c) 1999 - 2009 XMPP Standards Foundation 10 | # 11 | # Permission is hereby granted, free of charge, to any person obtaining a copy 12 | # of this software and associated documentation files (the "Software"), to deal 13 | # in the Software without restriction, including without limitation the rights 14 | # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 15 | # copies of the Software, and to permit persons to whom the Software is 16 | # furnished to do so, subject to the following conditions: 17 | # 18 | # The above copyright notice and this permission notice shall be included in 19 | # all copies or substantial portions of the Software. 20 | # 21 | # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 22 | # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 23 | # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 24 | # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 25 | # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 26 | # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 27 | # THE SOFTWARE. 28 | # 29 | ## END LICENSE ## 30 | 31 | from xml.dom.minidom import parse,parseString,Document,getDOMImplementation 32 | 33 | def getText(nodelist): 34 | thisText = "" 35 | for node in nodelist: 36 | if node.nodeType == node.TEXT_NODE: 37 | thisText = thisText + node.data 38 | return thisText 39 | 40 | class XEPInfo: 41 | def __init__(self, filename, parseStr): 42 | thexep = "" 43 | if parseStr: 44 | thexep = parseString(filename) 45 | else: 46 | thexep = parse(filename) 47 | xepNode = (thexep.getElementsByTagName("xep")[0]) 48 | headerNode = (xepNode.getElementsByTagName("header")[0]) 49 | titleNode = (headerNode.getElementsByTagName("title")[0]) 50 | self.title = getText(titleNode.childNodes) 51 | self.nr = getText((headerNode.getElementsByTagName("number")[0]).childNodes) 52 | shortnameNode = headerNode.getElementsByTagName("shortname") 53 | if shortnameNode: 54 | self.shortname = getText((shortnameNode[0]).childNodes) 55 | else: 56 | self.shortname = "NOT YET ASSIGNED" 57 | abstractNode = (headerNode.getElementsByTagName("abstract")[0]) 58 | self.abstract = getText(abstractNode.childNodes) 59 | statusNode = (headerNode.getElementsByTagName("status")[0]) 60 | self.status = getText(statusNode.childNodes) 61 | self.type = getText((headerNode.getElementsByTagName("type")[0]).childNodes) 62 | revNode = (headerNode.getElementsByTagName("revision")[0]) 63 | self.version = getText((revNode.getElementsByTagName("version")[0]).childNodes) 64 | self.date = getText((revNode.getElementsByTagName("date")[0]).childNodes) 65 | 66 | titleNode = (headerNode.getElementsByTagName("interim")) 67 | if titleNode: 68 | self.interim = True; 69 | else: 70 | self.interim = False; 71 | 72 | depNode = headerNode.getElementsByTagName("dependencies") 73 | self.depends = [] 74 | if depNode: 75 | depNode = depNode[0] 76 | for dep in depNode.getElementsByTagName("spec"): 77 | self.depends.append(getText(dep.childNodes)) 78 | 79 | def getInterim(self): 80 | return self.interim 81 | 82 | def getNr(self): 83 | return self.nr 84 | 85 | def getTitle(self): 86 | return self.title 87 | 88 | def getShortname(self): 89 | return self.shortname 90 | 91 | def getAbstract(self): 92 | return self.abstract 93 | 94 | def getStatus(self): 95 | return self.status 96 | 97 | def getVersion(self): 98 | return self.version 99 | 100 | def getType(self): 101 | return self.type 102 | 103 | def getDate(self): 104 | return self.date 105 | 106 | def getDepends(self): 107 | return self.depends 108 | 109 | -------------------------------------------------------------------------------- /xeputil.py: -------------------------------------------------------------------------------- 1 | # File: xeputil.py 2 | # Version: 0.2 3 | # Description: xep utility functions 4 | # Last Modified: 2010 5 | # Author: Tobias Markmann (tm@ayena.de) 6 | 7 | ## LICENSE ## 8 | # 9 | # Copyright (c) 1999 - 2009 XMPP Standards Foundation 10 | # 11 | # Permission is hereby granted, free of charge, to any person obtaining a copy 12 | # of this software and associated documentation files (the "Software"), to deal 13 | # in the Software without restriction, including without limitation the rights 14 | # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 15 | # copies of the Software, and to permit persons to whom the Software is 16 | # furnished to do so, subject to the following conditions: 17 | # 18 | # The above copyright notice and this permission notice shall be included in 19 | # all copies or substantial portions of the Software. 20 | # 21 | # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 22 | # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 23 | # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 24 | # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 25 | # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 26 | # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 27 | # THE SOFTWARE. 28 | # 29 | ## END LICENSE ## 30 | 31 | import os 32 | import tempfile 33 | from xepinfo import XEPInfo 34 | from xml.dom.minidom import parse,parseString,Document,getDOMImplementation 35 | 36 | from mercurial import ui, hg 37 | from mercurial.node import hex 38 | 39 | def getText(nodelist): 40 | thisText = "" 41 | for node in nodelist: 42 | if node.nodeType == node.TEXT_NODE: 43 | thisText = thisText + node.data 44 | return thisText 45 | 46 | class XEP: 47 | def __init__(self, BASEDIR, nr): 48 | self.nr = nr 49 | self.BASEDIR = BASEDIR 50 | 51 | def revisions(self): 52 | repo = hg.repository(ui.ui(), self.BASEDIR) 53 | fctx = repo.filectx("xep-" + self.nr + ".xml", 'tip') 54 | revs = [] 55 | for rev in fctx.filelog(): 56 | revs.append(fctx.filectx(rev).rev()) 57 | 58 | return sorted(revs) 59 | 60 | def contentOfRevision(self, revision): 61 | repo = hg.repository(ui.ui(), self.BASEDIR) 62 | fctx = repo.filectx("xep-" + self.nr + ".xml", revision) 63 | 64 | # load content for that revision 65 | file_text = fctx.data() 66 | return file_text 67 | 68 | def globalLatestRevison(self): 69 | repo = hg.repository(ui.ui(), self.BASEDIR) 70 | cctx = repo['tip'] 71 | return cctx.rev() 72 | 73 | 74 | def getLatestXEPFilename(XEPDIR, nr, no_interim=True): 75 | try: 76 | xep = XEP(XEPDIR, nr) 77 | revs = xep.revisions() 78 | revs.reverse() 79 | content = "" 80 | if no_interim: 81 | for rev in revs: 82 | tmp_content = xep.contentOfRevision(rev) 83 | info = XEPInfo(tmp_content, " ") 84 | if not info.interim: 85 | content = tmp_content 86 | break; 87 | 88 | else: 89 | content = xep.contentOfRevision(revs[len(revs)-1]) 90 | 91 | (fd, name) = tempfile.mkstemp(); 92 | handle = os.fdopen(fd, "w+b") 93 | handle.write(content) 94 | handle.close() 95 | return name; 96 | except: 97 | return False; 98 | --------------------------------------------------------------------------------