mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-27 11:42:17 -05:00
Merge branch 'premerge' into 'main'
Premerge See merge request xsf/xeps!32
This commit is contained in:
Jonas Schäfer
commit
36ee4ec0b2
@ -10,6 +10,8 @@ stages:
|
||||
- make html inbox-html inbox-xml pdf xeplist refs xml
|
||||
- bash tools/ci-prune-build.sh
|
||||
rules:
|
||||
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
|
||||
when: never
|
||||
- if: '$CI_COMMIT_REF_NAME =~ /^main$/'
|
||||
when: always
|
||||
- when: never
|
||||
@ -37,6 +39,8 @@ stages:
|
||||
- 'docker push "$IMAGE_REF"'
|
||||
- 'docker push "$LATEST_REF"'
|
||||
rules:
|
||||
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
|
||||
when: never
|
||||
- if: '$CI_COMMIT_REF_NAME =~ /^main$/'
|
||||
when: on_success
|
||||
- when: never
|
||||
@ -52,6 +56,8 @@ stages:
|
||||
- state/
|
||||
key: attic-state
|
||||
rules:
|
||||
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
|
||||
when: never
|
||||
- if: '$CI_COMMIT_REF_NAME =~ /^main$/'
|
||||
when: on_success
|
||||
- when: never
|
||||
@ -67,6 +73,8 @@ stages:
|
||||
- state/
|
||||
key: announce-state
|
||||
rules:
|
||||
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
|
||||
when: never
|
||||
- if: '$CI_COMMIT_REF_NAME =~ /^main$/'
|
||||
when: on_success
|
||||
- when: never
|
||||
|
||||
388
README.md
388
README.md
@ -4,6 +4,9 @@
|
||||
XMPP Extension Protocols (XEPs)
|
||||
===============================
|
||||
|
||||
About
|
||||
-----
|
||||
|
||||
This repository is used to manage work on XMPP Extension Protocols
|
||||
(XEPs), which are the specifications produced by the XMPP Standards
|
||||
Foundation (XSF). See http://xmpp.org/ for details. The rendered
|
||||
@ -11,6 +14,9 @@ documents can be found here:
|
||||
|
||||
https://xmpp.org/extensions/
|
||||
|
||||
Contribution
|
||||
------------
|
||||
|
||||
Please use this repository to raise issues and submit pull requests:
|
||||
|
||||
https://github.com/xsf/xeps/issues
|
||||
@ -19,7 +25,7 @@ https://github.com/xsf/xeps/pulls
|
||||
For in-depth technical discussion, please post to the standards@xmpp.org
|
||||
email list:
|
||||
|
||||
http://mail.jabber.org/mailman/listinfo/standards
|
||||
https://mail.jabber.org/mailman/listinfo/standards
|
||||
|
||||
To submit a new proposal for consideration as a XEP, please read this
|
||||
page:
|
||||
@ -29,387 +35,11 @@ https://xmpp.org/about/standards-process.html#submitting-a-xep
|
||||
[XEP-0001: XMPP Extension Protocols](https://xmpp.org/extensions/xep-0001.html)
|
||||
defines the standards process followed by the XMPP Standards Foundation.
|
||||
|
||||
Building XEPs
|
||||
-------------
|
||||
|
||||
You'll need xmllint and xsltproc.
|
||||
|
||||
On Ubuntu, you can install them with `sudo apt install libxml2-utils xsltproc`
|
||||
|
||||
To build a single XEP as HTML simply run:
|
||||
|
||||
make xep-xxxx.html
|
||||
|
||||
To build PDFs, you'll need to install [TeXML](http://getfo.org/texml/) (probably
|
||||
in a Python 2 virtual environment).
|
||||
You can then build PDFs with:
|
||||
|
||||
make xep-xxxx.pdf
|
||||
|
||||
To change the output directory, set the variable `OUTDIR`, eg.
|
||||
|
||||
OUTDIR=/tmp/xeps make all
|
||||
|
||||
For more information try `make help`.
|
||||
|
||||
Using Docker
|
||||
------------
|
||||
|
||||
A full set of HTML and PDFs can be generated inside a docker container, with no
|
||||
dependencies on the host other than Docker itself, and served by nginx in the
|
||||
container. To build the template `make docker`, to run it `make testdocker`
|
||||
(serves on http://localhost:3080), and to stop/delete it afterwards `make
|
||||
stopdocker`
|
||||
|
||||
|
||||
Gardening (Issue triaging by non-editors)
|
||||
-----------------------------------------
|
||||
|
||||
For new PRs, anyone with permission may perform gardening tasks.
|
||||
The [Go wiki] summarizes "gardening" as:
|
||||
|
||||
> the background maintenance tasks done to keep the project healthy & growing &
|
||||
> nice looking.
|
||||
|
||||
In this repo, gardening is mostly triaging issues.
|
||||
An issue is considered triaged when an editor has been assigned to it.
|
||||
Untriaged issues that are in need of attention can be found using the following
|
||||
filter: [`is:open is:pr no:assignee`]
|
||||
|
||||
To triage new issues or PRs, see the [Triaging a PR][#triaging-a-pr] section below.
|
||||
|
||||
|
||||
Editor
|
||||
======
|
||||
------
|
||||
|
||||
The XMPP Extensions Editor (or, for short, XEP Editor) manages the XMPP
|
||||
extensions process as defined in XMPP Extension Protocols ([XEP-0001]).
|
||||
In addition, the XEP Editor functions as the XMPP Registrar as defined in XMPP
|
||||
Registrar Function ([XEP-0053]).
|
||||
Read those documents first, since this README focuses on mechanics instead of
|
||||
philosophy or policy.
|
||||
Documentation for Editors is in the [docs](docs/) folder.
|
||||
|
||||
|
||||
All PRs
|
||||
-------
|
||||
|
||||
For all PRs, start by ensuring that the IP release has been signed and that CI
|
||||
has run and no issues were detected before merging.
|
||||
|
||||
|
||||
Triaging a PR
|
||||
-------------
|
||||
|
||||
If the PR is not touching a XEP, this guide does not apply. If the PR touches
|
||||
multiple XEPs, go through the steps for each XEP and exit at the first which
|
||||
applies.
|
||||
|
||||
1. Is the PR a ProtoXEP?
|
||||
|
||||
1. Does the PR touch existing XEPs? Close as [invalid] and ask the Opener
|
||||
to split the two things.
|
||||
|
||||
2. Add the [ProtoXEP] and [Ready to Merge] labels.
|
||||
3. Stop.
|
||||
|
||||
2. Sanity checks
|
||||
|
||||
1. Ensure that all XEPs are mentioned in the title as `XEP-XXXX`. E.g. `XEP-0084, XEP-0123: something`.
|
||||
2. Continue.
|
||||
|
||||
3. Are the changes *for all XEPs* purely editorial?
|
||||
|
||||
1. Add the [Editorial Change] and [Ready to Merge] labels.
|
||||
2. If the PR does not add a revision block, add the [Needs Version Block] label.
|
||||
3. If the PR adds a revision block and does not only bump the patch-level (third) version number part, add the [Needs Version Block] label and a comment explaining the situation.
|
||||
4. Stop.
|
||||
|
||||
4. Is the XEP **not** in Experimental state?
|
||||
|
||||
(Changes to Non—Experimental XEPs need approval by the approving body as
|
||||
defined in the XEP file itself.)
|
||||
|
||||
1. Add the [Needs Council]/[Needs Board] label.
|
||||
2. Send an email to the council chair and/or announce the PR in [The Council Room].
|
||||
3. If the PR does not add a revision block, add the [Needs Version Block] label.
|
||||
4. If the PR adds a revision block and does not bump the minor-level (second) version number part, add the [Needs Version Block] label and a comment explaining the situation.
|
||||
5. Stop.
|
||||
|
||||
5. Is the XEP in Experimental state and the PR opener is not an author of the
|
||||
XEP?
|
||||
|
||||
1. If the PR does not a revision block, add the [Needs Version Block] label.
|
||||
2. If the PR adds a revision block and does not bump the minor-level (second) version number part, add the [Needs Version Block] label and a comment explaining the situation.
|
||||
3. If the issue has not been discussed on the standards list *or* if
|
||||
the authors have not been involved in the discussion *or* the author
|
||||
has not explicitly ACKed the PR:
|
||||
|
||||
1. Make sure the standards@ discussion (if it exists) is linked in the
|
||||
PR.
|
||||
2. Add the [Needs Author] label.
|
||||
3. Stop.
|
||||
|
||||
6. Mark the PR as [Ready to Merge].
|
||||
|
||||
Discussions
|
||||
-----------
|
||||
|
||||
Technical discussions SHOULD NOT happen in the xeps repository. If you see a
|
||||
discussion evolve into technical (as opposed to editorial) matters, do the
|
||||
following (I haven’t tried that myself yet, so feel especially free to improve
|
||||
the process):
|
||||
|
||||
1. Lock the conversation.
|
||||
2. Copy the technical discussion parts into an email to standards@. My
|
||||
preferred format for this would be something along the lines of:
|
||||
|
||||
Subject: XEP-1234: [insert PR subject here, or something more appropriate]
|
||||
|
||||
There was some discussion on the xeps repository an XEP-1234, which got
|
||||
technical. I moved this discussion to standards@ so that the whole
|
||||
community is aware of the issue and can participate.
|
||||
|
||||
@user1 wrote:
|
||||
> quote user1 here ...
|
||||
|
||||
@user2 wrote:
|
||||
> quote user2 here ...
|
||||
|
||||
Remove clearly editorial discussion and mark the removal with ``[…]``.
|
||||
|
||||
3. Add the [Needs List Discussion] label to the PR and link the standards@
|
||||
thread you just created. Remove other labels (such as [Needs Author]).
|
||||
|
||||
4. Monitor the thread; when the discussion is resolved, the PR opener will
|
||||
usually prepare an update. Unlock the conversation to allow editorial
|
||||
discussion to continue, if needed. Remove the [Needs List Discussion] label
|
||||
and re-triage the PR as described above.
|
||||
|
||||
**Note:** The locking is mostly used here as a tool to avoid a race
|
||||
condition, not to exclude people from participating. (It would be
|
||||
unfortunate if you had to add more comments to your already-sent email.)
|
||||
Feel free to unlock at some point during the list discussion when you’re
|
||||
sure that all participants have taken note of the move.
|
||||
|
||||
|
||||
General notes on making changes
|
||||
-------------------------------
|
||||
|
||||
This section has some hints on the python scripts which help you doing the
|
||||
more tedious tasks of sending emails and properly archiving XEPs.
|
||||
|
||||
*Before* you start working on merging a Pull Request:
|
||||
|
||||
* Ideally, you have the [xep-attic] repository cloned next to the xeps
|
||||
repository.
|
||||
|
||||
* Before starting to prepare a merge and push, ensure that you have the XEP
|
||||
metadata up-to-date locally:
|
||||
|
||||
$ make build/xeplist.xml
|
||||
|
||||
* Make a copy of the metadata:
|
||||
|
||||
$ cp build/xeplist.xml tools/old-xeplist.xml
|
||||
|
||||
(avoid putting random XML files in the xeps root directory, the build
|
||||
tooling might mistake them as XEPs; so we put it somewhere else.)
|
||||
|
||||
*While* you’re working on a Pull Request:
|
||||
|
||||
* Use the lokal docker build to ensure that everything is syntactically
|
||||
correct. The process is described above in "Using Docker".
|
||||
|
||||
When you have *merged* the Pull Request and the change went through to the
|
||||
webserver (see also the [Docker Build] to track the build progress):
|
||||
|
||||
* Send out the emails. First ensure that the new metadata is up-to-date:
|
||||
|
||||
$ make build/xeplist.xml
|
||||
|
||||
Check that the emails which will be sent are correct (the ``--dry-run``
|
||||
switch prevents the tool from actually sending emails):
|
||||
|
||||
$ ./tools/send-updates.py --dry-run tools/old-xeplist.xml build/xeplist.xml standards@xmpp.org
|
||||
|
||||
(See also the ``--help`` output for more information.)
|
||||
|
||||
Once you’ve verified that the correct emails will be sent, actually send
|
||||
them using (note the missing ``--dry-run`` flag):
|
||||
|
||||
$ ./tools/send-updates.py tools/old-xeplist.xml build/xeplist.xml standards@xmpp.org
|
||||
|
||||
A few tips:
|
||||
|
||||
1. You can also test-send them to your own address by replacing
|
||||
``standards@xmpp.org`` with your own address.
|
||||
2. To avoid having to enter your email account details every time, use a
|
||||
configuration file. Invoke the tool with ``--help`` for more
|
||||
information and ask [jonasw]/[@horazont] if things are still unclear.
|
||||
|
||||
If the tool misbehaves, pester [jonasw]/[@horazont] about it.
|
||||
|
||||
* Don’t forget to archive the new versions of the XEPs. If you have the
|
||||
[xep-attic] cloned next to the xeps repository, you can simply run:
|
||||
|
||||
$ ./tools/archive.py tools/old-xeplist.xml build/xeplist.xml
|
||||
|
||||
Otherwise, you will have to explicitly give the path to the attic:
|
||||
|
||||
$ ./tools/archive.py --attic /path/to/xep-attic/content/ tools/old-xeplist.xml build/xeplist.xml
|
||||
|
||||
(note that the path must point to the ``content`` subdirectory of the
|
||||
[xep-attic].)
|
||||
|
||||
Don’t forget to commit & push the changes to [xep-attic].
|
||||
|
||||
|
||||
New ProtoXEPs
|
||||
-------------
|
||||
|
||||
- Make sure the protoxep is in the `inbox/` tree and has a name that does not
|
||||
start with "xep-" (you may change this or ask the author to change it).
|
||||
- Make sure the version is `0.0.1` and the status is `ProtoXEP` (you may fix
|
||||
this or ask the author to fix it).
|
||||
- You may want to build the protoxep locally and ensure the HTML and PDF look
|
||||
okay.
|
||||
- Merge the PR as described in "Merging a PR". Once the email has been sent,
|
||||
continue here.
|
||||
- Create a card for the protoxep on the [Council Trello] under "Proposed
|
||||
Agendums".
|
||||
- Attach the PR to the card and link the generated HTML.
|
||||
- Comment on the PR with a link to the card, thanking the author for their
|
||||
submission and letting them know that their XEP will be voted on within the
|
||||
next two weeks.
|
||||
- If the council forgets and doesn't vote on the protoxep, pester them until
|
||||
they do.
|
||||
- If the council rejects the XEP, you're done (leave the XEP in the inbox and
|
||||
inform the author of the councils decision). Otherwise, see
|
||||
"Promoting a ProtoXEP".
|
||||
|
||||
|
||||
Promoting a ProtoXEP
|
||||
--------------------
|
||||
|
||||
- It is easiest to start a new branch, in case you screw something up on the way.
|
||||
- Once the council approves a ProtoXEP, *copy* it out of the inbox and into the
|
||||
root, assigning it the next available number in the XEP series.
|
||||
- Modify the `<number/>` element in the XML file to match.
|
||||
- Set the version to `0.1` and the initials to `XEP Editor: xyz` (replacing "xyz" with your own initials).
|
||||
- Remove the `<interim/>` element from the XML file if it is included.
|
||||
- Set the status to `Experimental`.
|
||||
- Add a reference to the XEP in `xep.ent`.
|
||||
- Make a commit.
|
||||
- Treat your branch as you would treat a [Ready to Merge] PR in "Merging a PR".
|
||||
(you don’t need to create another branch though.)
|
||||
|
||||
|
||||
Promoting XEPs
|
||||
--------------
|
||||
|
||||
Ensure that the following sections exist (if not, ask the author to add them
|
||||
before promoting the XEP):
|
||||
|
||||
- Security Considerations
|
||||
- IANA Considerations
|
||||
- XMPP Registrar Considerations
|
||||
- XML Schema (for protocol specifications)
|
||||
|
||||
You can also refer to `xep-template.xml` for a recommended list of sections and
|
||||
whether or not they are required.
|
||||
For a helpful graph of how XEP promotion works, see [XEP-0001].
|
||||
|
||||
|
||||
Deferring XEPs
|
||||
--------------
|
||||
|
||||
Before Deferring XEPs, read the "General notes on making changes" section.
|
||||
|
||||
XEPs get deferred after 12 months of inactivity. There is a tool which handles
|
||||
that process automatically, if it is invoked regularly.
|
||||
|
||||
First of all, you need an up-to-date ``xeplist.xml``:
|
||||
|
||||
make build/xeplist.xml
|
||||
|
||||
To get a list of XEPs which need to be deferred (without changing anything),
|
||||
run:
|
||||
|
||||
./tools/deferrals.py -v
|
||||
|
||||
To apply the deferrals, make a new feature branch and execute:
|
||||
|
||||
./tools/deferrals.py -m 'initials'
|
||||
|
||||
where you replace ``initials`` with your editor initials so that it is obvious
|
||||
who made the change (those initials will be used in the revision block).
|
||||
|
||||
This will modify the XEPs in-place. It uses heuristics for incrementing the
|
||||
version number, finding and inserting the revision block as well as changing
|
||||
the status. Yes, it involves regular expressions (because we don’t want to
|
||||
fully re-write the XML to keep the diffs minimal). It is thus vital that you
|
||||
**use `git diff` to ensure that the changes are sane**. If the changes
|
||||
are sane, make a commit and merge to master as described in "Merging a PR",
|
||||
in accordance with the "General notes on making changes".
|
||||
|
||||
|
||||
Merging a PR
|
||||
------------
|
||||
|
||||
Before Merging a PR, read the "General notes on making changes" section.
|
||||
|
||||
When you get to the point that the PR is [Ready to Merge], do the following:
|
||||
|
||||
1. Create a new branch off master called ``feature/xep-1234`` (if the PR
|
||||
touches multiple XEPs, I call it ``feature/xep-0678,xep-0789``).
|
||||
|
||||
2. Merge all [Ready to Merge] PRs which affect the XEP(s) into that branch.
|
||||
|
||||
3. Resolve conflicts.
|
||||
|
||||
4. If the PRs introduced multiple revision blocks, squash it down to a single
|
||||
revision block. Set "XEP Editor (initials)" as author of the revision block
|
||||
and add the initials of the original PR authors to the changelog entries.
|
||||
(If that doesn’t make sense to you, you’ll find plenty examples in the
|
||||
XEPs.)
|
||||
|
||||
5. Ensure that everything builds by performing a full docker build (see above).
|
||||
|
||||
(Once the docker build reaches the point where the XEPs are built, you can
|
||||
switch branches and work on another PR.)
|
||||
|
||||
6. If the build passes, check that the generated files look sane by running the
|
||||
docker container.
|
||||
|
||||
7. Merge the PR into master. If you are working on independent changes to
|
||||
multiple XEPs, you can merge them all in one go.
|
||||
|
||||
8. If you merged multiple things into master, re-do the docker build check.
|
||||
|
||||
9. Push.
|
||||
|
||||
10. Go back to "General notes on making changes".
|
||||
|
||||
|
||||
|
||||
[XEP-0001]: https://xmpp.org/extensions/xep-0001.html
|
||||
[XEP-0053]: https://xmpp.org/extensions/xep-0053.html
|
||||
[Editor Trello]: https://trello.com/b/gwcOFnCr
|
||||
[Council Trello]: https://trello.com/b/ww7zWMlI
|
||||
[Needs Council]: https://github.com/xsf/xeps/labels/Needs%20Council
|
||||
[Needs Board]: https://github.com/xsf/xeps/labels/Needs%20Board
|
||||
[ProtoXEP]: https://github.com/xsf/xeps/labels/ProtoXEP
|
||||
[Go wiki]: https://golang.org/wiki/Gardening
|
||||
[`is:open is:pr no:assignee`]: https://github.com/xsf/xeps/pulls?utf8=%E2%9C%93&q=is%3Aopen%20is%3Apr%20no%3Aassignee%20
|
||||
[Needs Author]: https://github.com/xsf/xeps/labels/Needs%20Author
|
||||
[Ready to Merge]: https://github.com/xsf/xeps/labels/Ready%20to%20Merge
|
||||
[Needs List Discussion]: https://github.com/xsf/xeps/labels/Needs%20List%20Discussion
|
||||
[Needs Version Block]: https://github.com/xsf/xeps/labels/Needs%20Version%20Block
|
||||
[Editorial Change]: https://github.com/xsf/xeps/labels/Editorial%20Change
|
||||
[xep-attic]: https://github.com/xsf/xep-attic
|
||||
[Docker Build]: https://hub.docker.com/r/xmppxsf/xeps/builds/
|
||||
[@horazont]: https://github.com/horazont/
|
||||
[jonasw]: https://wiki.xmpp.org/web/User:Jwi
|
||||
[The Council Room]: xmpp:council@muc.xmpp.org?join
|
||||
|
||||
[modeline]: # ( vim: set fenc=utf-8 ff=unix spell spl=en textwidth=80: )
|
||||
|
||||
39
docs/MODERATION.md
Normal file
39
docs/MODERATION.md
Normal file
@ -0,0 +1,39 @@
|
||||
# Moderation
|
||||
|
||||
## Discussions
|
||||
|
||||
Technical discussions SHOULD NOT happen in the xeps repository. If you see a
|
||||
discussion evolve into technical (as opposed to editorial) matters, do the
|
||||
following:
|
||||
|
||||
1. Lock the conversation.
|
||||
2. Copy the technical discussion parts into an email to standards@. My
|
||||
preferred format for this would be something along the lines of:
|
||||
|
||||
Subject: [insert PR title here, or something more appropriate]
|
||||
|
||||
There was some discussion on the xeps repository an XEP-1234, which got
|
||||
technical. I moved this discussion to standards@ so that the whole
|
||||
community is aware of the issue and can participate.
|
||||
|
||||
@user1 wrote:
|
||||
> quote user1 here ...
|
||||
|
||||
@user2 wrote:
|
||||
> quote user2 here ...
|
||||
|
||||
Remove clearly editorial discussion and mark the removal with ``[…]``.
|
||||
|
||||
3. Add the [Needs List Discussion] label to the PR and link the standards@
|
||||
thread you just created. Remove other labels (such as [Needs Author]).
|
||||
|
||||
4. Monitor the thread; when the discussion is resolved, the PR opener will
|
||||
usually prepare an update. Unlock the conversation to allow editorial
|
||||
discussion to continue, if needed. Remove the [Needs List Discussion] label
|
||||
and re-triage the PR as described above.
|
||||
|
||||
**Note:** The locking is mostly used here as a tool to avoid a race
|
||||
condition, not to exclude people from participating. (It would be
|
||||
unfortunate if you had to add more comments to your already-sent email.)
|
||||
Feel free to unlock at some point during the list discussion when you’re
|
||||
sure that all participants have taken note of the move.
|
||||
203
docs/PROCESSING.md
Normal file
203
docs/PROCESSING.md
Normal file
@ -0,0 +1,203 @@
|
||||
# Processing a PR
|
||||
|
||||
## General notes on making changes
|
||||
|
||||
This section has some hints on the python scripts which help you doing the
|
||||
more tedious tasks of sending emails and properly archiving XEPs.
|
||||
|
||||
### Before you start working on merging a Pull Request
|
||||
|
||||
* Ideally, you have the [xep-attic] repository cloned next to the xeps
|
||||
repository.
|
||||
|
||||
* Before starting to prepare a merge and push, ensure that you have the XEP
|
||||
metadata up-to-date locally:
|
||||
|
||||
$ make build/xeplist.xml
|
||||
|
||||
* Make a copy of the metadata:
|
||||
|
||||
$ cp build/xeplist.xml tools/old-xeplist.xml
|
||||
|
||||
(avoid putting random XML files in the xeps root directory, the build
|
||||
tooling might mistake them as XEPs; so we put it somewhere else.)
|
||||
|
||||
### While you’re working on a Pull Request
|
||||
|
||||
* Use the local docker build to ensure that everything is syntactically
|
||||
correct. The process is described above in "Using Docker".
|
||||
|
||||
### After merging the Pull Request
|
||||
|
||||
When you have *merged* the Pull Request and the change went through to the
|
||||
webserver (see also the [Docker Build] to track the build progress):
|
||||
|
||||
* Send out the emails. First ensure that the new metadata is up-to-date:
|
||||
|
||||
$ make build/xeplist.xml
|
||||
|
||||
Check that the emails which will be sent are correct (the ``--dry-run``
|
||||
switch prevents the tool from actually sending emails):
|
||||
|
||||
$ ./tools/send-updates.py --dry-run tools/old-xeplist.xml build/xeplist.xml standards@xmpp.org
|
||||
|
||||
(See also the ``--help`` output for more information.)
|
||||
|
||||
Once you’ve verified that the correct emails will be sent, actually send
|
||||
them using (note the missing ``--dry-run`` flag):
|
||||
|
||||
$ ./tools/send-updates.py tools/old-xeplist.xml build/xeplist.xml standards@xmpp.org
|
||||
|
||||
A few tips:
|
||||
|
||||
1. You can also test-send them to your own address by replacing
|
||||
``standards@xmpp.org`` with your own address.
|
||||
2. To avoid having to enter your email account details every time, use a
|
||||
configuration file. Invoke the tool with ``--help`` for more
|
||||
information and ask [jonas’]/[@horazont] if things are still unclear.
|
||||
|
||||
If the tool misbehaves, pester [jonas’]/[@horazont] about it.
|
||||
|
||||
* Don’t forget to archive the new versions of the XEPs. If you have the
|
||||
[xep-attic] cloned next to the xeps repository, you can simply run:
|
||||
|
||||
$ ./tools/archive.py tools/old-xeplist.xml build/xeplist.xml
|
||||
|
||||
Otherwise, you will have to explicitly give the path to the attic:
|
||||
|
||||
$ ./tools/archive.py --attic /path/to/xep-attic/content/ tools/old-xeplist.xml build/xeplist.xml
|
||||
|
||||
(note that the path must point to the ``content`` subdirectory of the
|
||||
[xep-attic].)
|
||||
|
||||
Don’t forget to commit & push the changes to [xep-attic].
|
||||
|
||||
|
||||
## New ProtoXEPs
|
||||
|
||||
- Make sure the protoxep is in the `inbox/` tree and has a name that does not
|
||||
start with "xep-" (you may change this or ask the author to change it).
|
||||
- Make sure the version is `0.0.1` and the status is `ProtoXEP` (you may fix
|
||||
this or ask the author to fix it).
|
||||
- You may want to build the protoxep locally and ensure the HTML and PDF look
|
||||
okay.
|
||||
- Merge the PR as described in "Merging a PR". Once the email has been sent,
|
||||
continue here.
|
||||
- Create a card for the protoxep on the [Council Trello] under "Proposed
|
||||
Agendums".
|
||||
- Attach the PR to the card and link the generated HTML.
|
||||
- Comment on the PR with a link to the card, thanking the author for their
|
||||
submission and letting them know that their XEP will be voted on within the
|
||||
next two weeks.
|
||||
- If the council forgets and doesn't vote on the protoxep, pester them until
|
||||
they do.
|
||||
- If the council rejects the XEP, you're done (leave the XEP in the inbox and
|
||||
inform the author of the councils decision). Otherwise, see
|
||||
"Promoting a ProtoXEP".
|
||||
|
||||
|
||||
## Promoting a ProtoXEP to Experimental
|
||||
|
||||
- It is easiest to start a new branch, in case you screw something up on the way.
|
||||
- Once the council approves a ProtoXEP, *copy* it out of the inbox and into the
|
||||
root, assigning it the next available number in the XEP series.
|
||||
- Modify the `<number/>` element in the XML file to match.
|
||||
- Set the version to `0.1` and the initials to `XEP Editor: xyz` (replacing "xyz" with your own initials).
|
||||
- Remove the `<interim/>` element from the XML file if it is included.
|
||||
- Set the status to `Experimental`.
|
||||
- Add a reference to the XEP in `xep.ent`.
|
||||
- Make a commit.
|
||||
- Treat your branch as you would treat a [Ready to Merge] PR in "Merging a PR".
|
||||
(you don’t need to create another branch though.)
|
||||
|
||||
|
||||
## Promoting XEPs beyond Experimental
|
||||
|
||||
Ensure that the following sections exist (if not, ask the author to add them
|
||||
before promoting the XEP):
|
||||
|
||||
- Security Considerations
|
||||
- IANA Considerations
|
||||
- XMPP Registrar Considerations
|
||||
- XML Schema (for protocol specifications)
|
||||
|
||||
You can also refer to `xep-template.xml` for a recommended list of sections and
|
||||
whether or not they are required.
|
||||
For a helpful graph of how XEP promotion works, see [XEP-0001].
|
||||
|
||||
|
||||
## Deferring XEPs
|
||||
|
||||
Before Deferring XEPs, read the "General notes on making changes" section.
|
||||
|
||||
XEPs get deferred after 12 months of inactivity. There is a tool which handles
|
||||
that process automatically, if it is invoked regularly.
|
||||
|
||||
First of all, you need an up-to-date ``xeplist.xml``:
|
||||
|
||||
make build/xeplist.xml
|
||||
|
||||
To get a list of XEPs which need to be deferred (without changing anything),
|
||||
run:
|
||||
|
||||
./tools/deferrals.py -v
|
||||
|
||||
To apply the deferrals, make a new feature branch and execute:
|
||||
|
||||
./tools/deferrals.py -m 'initials'
|
||||
|
||||
where you replace ``initials`` with your editor initials so that it is obvious
|
||||
who made the change (those initials will be used in the revision block).
|
||||
|
||||
This will modify the XEPs in-place. It uses heuristics for incrementing the
|
||||
version number, finding and inserting the revision block as well as changing
|
||||
the status. Yes, it involves regular expressions (because we don’t want to
|
||||
fully re-write the XML to keep the diffs minimal). It is thus vital that you
|
||||
**use `git diff` to ensure that the changes are sane**. If the changes
|
||||
are sane, make a commit and merge to master as described in "Merging a PR",
|
||||
in accordance with the "General notes on making changes".
|
||||
|
||||
|
||||
## Merging a PR
|
||||
|
||||
Before Merging a PR, read the "General notes on making changes" section.
|
||||
|
||||
When you get to the point that the PR is [Ready to Merge], do the following:
|
||||
|
||||
1. Create a new branch off master called ``feature/xep-1234`` (if the PR
|
||||
touches multiple XEPs, I call it ``feature/xep-0678,xep-0789``).
|
||||
|
||||
2. Merge all [Ready to Merge] PRs which affect the XEP(s) into that branch.
|
||||
|
||||
3. Resolve conflicts.
|
||||
|
||||
4. If the PRs introduced multiple revision blocks, squash it down to a single
|
||||
revision block. Set "XEP Editor (initials)" as author of the revision block
|
||||
and add the initials of the original PR authors to the changelog entries.
|
||||
(If that doesn’t make sense to you, you’ll find plenty examples in the
|
||||
XEPs.)
|
||||
|
||||
5. Ensure that everything builds by performing a full docker build (see above).
|
||||
|
||||
(Once the docker build reaches the point where the XEPs are built, you can
|
||||
switch branches and work on another PR.)
|
||||
|
||||
6. If the build passes, check that the generated files look sane by running the
|
||||
docker container.
|
||||
|
||||
7. Merge the PR into master. If you are working on independent changes to
|
||||
multiple XEPs, you can merge them all in one go.
|
||||
|
||||
8. If you merged multiple things into master, re-do the docker build check.
|
||||
|
||||
9. Push.
|
||||
|
||||
10. Go back to "General notes on making changes".
|
||||
|
||||
[XEP-0001]: https://xmpp.org/extensions/xep-0001.html
|
||||
[Ready to Merge]: https://github.com/xsf/xeps/labels/Ready%20to%20Merge
|
||||
[Council Trello]: https://trello.com/b/ww7zWMlI
|
||||
[xep-attic]: https://github.com/xsf/xep-attic
|
||||
[Docker Build]: https://hub.docker.com/r/xmppxsf/xeps/builds/
|
||||
[@horazont]: https://github.com/horazont/
|
||||
[jonas’]: https://wiki.xmpp.org/web/User:Jwi
|
||||
39
docs/README.md
Normal file
39
docs/README.md
Normal file
@ -0,0 +1,39 @@
|
||||
Editor Guide
|
||||
============
|
||||
|
||||
The XMPP Extensions Editor (or, for short, XEP Editor) manages the XMPP
|
||||
extensions process as defined in XMPP Extension Protocols ([XEP-0001]).
|
||||
In addition, the XEP Editor functions as the XMPP Registrar as defined in XMPP
|
||||
Registrar Function ([XEP-0053]).
|
||||
Read those documents first, since this README focuses on mechanics instead of
|
||||
philosophy or policy.
|
||||
|
||||
|
||||
This is the entrypoint definitive guide for Editors.
|
||||
|
||||
- [Using the repository](REPOSITORY.md)
|
||||
|
||||
Information about how to build XEPs and how the repository is laid out.
|
||||
|
||||
<!--
|
||||
- [Tools](TOOLS.md)
|
||||
|
||||
Information about tools provided with the repository which should help in
|
||||
your daily editor duties.
|
||||
-->
|
||||
|
||||
- [Triaging](TRIAGING.md)
|
||||
|
||||
Rules for labelling and guiding inbound Pull Requests (Merge Requests).
|
||||
|
||||
- [Processing](PROCESSING.md)
|
||||
|
||||
Rules and guidelines for processing inbound Pull Requests (Merge Requests)
|
||||
towards master/main.
|
||||
|
||||
- [Moderation](MODERATION.md)
|
||||
|
||||
Rules and guidelines for moderating the discussions in the PRs.
|
||||
|
||||
|
||||
[XEP-0053]: https://xmpp.org/extensions/xep-0053.html
|
||||
34
docs/REPOSITORY.md
Normal file
34
docs/REPOSITORY.md
Normal file
@ -0,0 +1,34 @@
|
||||
Using the repository
|
||||
====================
|
||||
|
||||
Building XEPs
|
||||
-------------
|
||||
|
||||
You'll need xmllint and xsltproc.
|
||||
|
||||
On Ubuntu, you can install them with `sudo apt install libxml2-utils xsltproc`
|
||||
|
||||
To build a single XEP as HTML simply run:
|
||||
|
||||
make xep-xxxx.html
|
||||
|
||||
To build PDFs, you'll need to install [TeXML](http://getfo.org/texml/) (probably
|
||||
in a Python 2 virtual environment).
|
||||
You can then build PDFs with:
|
||||
|
||||
make xep-xxxx.pdf
|
||||
|
||||
To change the output directory, set the variable `OUTDIR`, eg.
|
||||
|
||||
OUTDIR=/tmp/xeps make all
|
||||
|
||||
For more information try `make help`.
|
||||
|
||||
Using Docker
|
||||
------------
|
||||
|
||||
A full set of HTML and PDFs can be generated inside a docker container, with no
|
||||
dependencies on the host other than Docker itself, and served by nginx in the
|
||||
container. To build the template `make docker`, to run it `make testdocker`
|
||||
(serves on http://localhost:3080), and to stop/delete it afterwards `make
|
||||
stopdocker`
|
||||
157
docs/TRIAGING.md
Normal file
157
docs/TRIAGING.md
Normal file
@ -0,0 +1,157 @@
|
||||
# Triaging a PR
|
||||
|
||||
## Dramatis Personae
|
||||
|
||||
- Author: Generally the author of the PR or MR.
|
||||
- XEP Author: The Author of the XEP.
|
||||
- Approving Body: Either the XMPP Council or the XSF Board. Which of those two
|
||||
can be determined by looking at the `<approver/>` tag of the respective XEP.
|
||||
- Processing Editor: The Editor which ultimately merges a PR to master.
|
||||
|
||||
## Labels
|
||||
|
||||
### Approval categories
|
||||
|
||||
- [Needs Council]: The changes need approval by the XMPP Council.
|
||||
- [Needs Board]: The changes need approval by the XSF Board.
|
||||
- [Needs Author]: The changes need approval by the XEP Author.
|
||||
- [Needs List Discussion]: The changes need more discussion on the standards@
|
||||
(or, in rare cases, members@) mailing lists; in general, there should be a
|
||||
link to a mailing list thread in those PRs.
|
||||
- [Editorial Change]: The changes do not need approval by anyone except the
|
||||
Editor.
|
||||
|
||||
### Process categories
|
||||
|
||||
- [ProtoXEP]: The PR adds a new XEP to the inbox.
|
||||
- [Ready to Merge]: The PR can be worked on by a Processing Editor. Note that
|
||||
this does **not** imply that no further changes are needed.
|
||||
- [Needs Version Block]: A version block needs to be added or modified before
|
||||
the changes can enter master.
|
||||
- [Needs Editor Action]: The Processing Editor needs to do something while
|
||||
merging the PR, aside of or in addition to modifying a version block.
|
||||
- [invalid]: The changes cannot be processed as-is at all; the PR is closed
|
||||
without merge and without being handed to an approver.
|
||||
|
||||
## Process
|
||||
|
||||
### A General Note
|
||||
|
||||
Some of the cases where the below process suggests to ask the Author to do
|
||||
something can also be handled by the Processing Editor. If it is realistic
|
||||
that the workload for the Editors would be reduced by handling the task
|
||||
themselves, use the [Needs Editor Action] label an an explanatory comment
|
||||
instead.
|
||||
|
||||
### "Flowchart"
|
||||
|
||||
If the PR is not touching a XEP, this guide does not apply.
|
||||
|
||||
1. Is the PR a ProtoXEP?
|
||||
|
||||
1. Does the PR touch existing XEPs? Close as [invalid] and ask the Author
|
||||
to split the two things.
|
||||
|
||||
2. Validate that the `<type/>` makes sense for the content (consult
|
||||
[XEP-0001] if necessary). If it does not make sense, either add a
|
||||
comment to let the Processing Editor know (adding the
|
||||
[Needs Editor Action] label) or ask the Author to correct the problem.
|
||||
3. Add the [ProtoXEP] and [Ready to Merge] labels.
|
||||
4. Make sure the title of the PR is `XEP-XXXX: Title of the new XEP`.
|
||||
5. Stop.
|
||||
|
||||
2. Sanity checks
|
||||
|
||||
1. Ensure that all XEPs are mentioned in the title as `XEP-XXXX`. E.g. `XEP-0084, XEP-0123: something`.
|
||||
2. Continue.
|
||||
|
||||
3. Are the changes *for all XEPs* purely editorial?
|
||||
|
||||
Editorial changes are changes which do not touch normative language and
|
||||
which do not change the meaning of the text. When in doubt, treat as
|
||||
non-Editorial.
|
||||
|
||||
1. Add the [Editorial Change] and [Ready to Merge] labels.
|
||||
2. If the PR does not add a revision block, add the [Needs Version Block]
|
||||
label.
|
||||
3. If the PR adds a revision block and does not only bump the patch-level
|
||||
(third) version number part, add the [Needs Version Block] label and a
|
||||
comment explaining the situation.
|
||||
4. Stop.
|
||||
|
||||
4. Does the PR touch more than one XEP?
|
||||
|
||||
In general, we want to avoid PRs which touch multiple XEPs or which do
|
||||
multiple non-Editorial changes at once. This is because the approving body
|
||||
may disagree with part of the PR, which causes extra work.
|
||||
|
||||
Suggest the author to split the PR for that reason, unless it seems
|
||||
realistic or obvious that the changes need to be done together to make
|
||||
sense (an example is updating multiple XEPs which belong together, such
|
||||
as the MIX family).
|
||||
|
||||
4. Is the XEP **not** in Experimental or Deferred state?
|
||||
|
||||
Changes to Non—Experimental or non-Deferred XEPs need approval by the
|
||||
approving body as defined in the XEP file itself.
|
||||
|
||||
1. Add the [Needs Council]/[Needs Board] label. To know which, check the
|
||||
`<approver/>` of the XEPs. If the touched XEPs have different approvers
|
||||
go back to the previous step and closely examine if the PR should not
|
||||
be split; it is very likely that it should be split in this situation.
|
||||
If so, tag as [invalid] and inform the author, asking them to do a
|
||||
split.
|
||||
2. **For Council:** Send an email to the council chair and/or announce the
|
||||
PR in [The Council Room].
|
||||
**For Board:** Send an email to info@xmpp.org and/or talk directly to
|
||||
Board members.
|
||||
3. If the PR does not add a revision block, add the [Needs Version Block]
|
||||
label.
|
||||
4. If the PR adds a revision block and does not bump the minor-level
|
||||
(second) version number part, add the [Needs Version Block] label and a
|
||||
comment explaining the situation for the next Editor (the Author does
|
||||
not need to do anything here).
|
||||
6. Stop.
|
||||
|
||||
5. Is the XEP in Experimental or Deferred state and the PR opener is not an
|
||||
author of the XEP?
|
||||
|
||||
Changes to Experimental XEPs are approved by the XEP Authors themselves.
|
||||
If the PR touches multiple XEPs and the XEP Authors do not overlap, ask
|
||||
the Author to split the PR.
|
||||
|
||||
1. If the PR does not a revision block, add the [Needs Version Block]
|
||||
label.
|
||||
2. If the PR adds a revision block and does not bump the minor-level
|
||||
(second) version number part, add the [Needs Version Block] label and a
|
||||
comment explaining the situation for the Processing Editor.
|
||||
3. If the XEP is in Deferred state and the changes are not purely editorial,
|
||||
add a note to move the XEP to Experimental state and mark the PR as
|
||||
[Needs Editor Action].
|
||||
4. If the issue has not been discussed on the standards list *or* if
|
||||
the XEP Author has not been involved in the discussion *or* the
|
||||
XEP Author has not explicitly ACKed the PR:
|
||||
|
||||
1. Make sure the standards@ discussion (if it exists) is linked in the
|
||||
PR.
|
||||
2. Add the [Needs Author] label.
|
||||
3. Try to make the XEP Author aware of the change. If you do not know
|
||||
a GitHub handle of the XEP Author, use the contact info available
|
||||
for each author in either the XEP or in xep.ent.
|
||||
4. Stop.
|
||||
|
||||
5. Otherwise, mark the PR as [Ready to Merge], linking the XEP Author’s
|
||||
approval for documentation purposes.
|
||||
|
||||
6. Mark the PR as [Ready to Merge].
|
||||
|
||||
[ProtoXEP]: https://github.com/xsf/xeps/labels/ProtoXEP
|
||||
[Ready to Merge]: https://github.com/xsf/xeps/labels/Ready%20to%20Merge
|
||||
[Needs Author]: https://github.com/xsf/xeps/labels/Needs%20Author
|
||||
[Needs List Discussion]: https://github.com/xsf/xeps/labels/Needs%20List%20Discussion
|
||||
[Needs Version Block]: https://github.com/xsf/xeps/labels/Needs%20Version%20Block
|
||||
[Needs Editor Action]: https://github.com/xsf/xeps/labels/Needs%20Editor%20Action
|
||||
[Editorial Change]: https://github.com/xsf/xeps/labels/Editorial%20Change
|
||||
[Needs Council]: https://github.com/xsf/xeps/labels/Needs%20Council
|
||||
[Needs Board]: https://github.com/xsf/xeps/labels/Needs%20Board
|
||||
[invalid]: https://github.com/xsf/xeps/labels/invalid
|
||||
193
inbox/ibr-token.xml
Normal file
193
inbox/ibr-token.xml
Normal file
@ -0,0 +1,193 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Pre-Authenticated In-Band Registration</title>
|
||||
<abstract>This document extends the In-Band-Registration protocol to use
|
||||
invitation tokens, e.g. for registering accounts on non-public
|
||||
servers.
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0077</spec>
|
||||
<spec>XEP-0147</spec>
|
||||
<spec>XEP-0379</spec>
|
||||
<spec>XEP-0401</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>ibr-token</shortname>
|
||||
<author>
|
||||
<firstname>Georg</firstname>
|
||||
<surname>Lukas</surname>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2020-10-28</date>
|
||||
<initials>gl</initials>
|
||||
<remark>First version based on XEP-0401.</remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>There are two typical mechanisms to register an account on an XMPP server:</p>
|
||||
<ul>
|
||||
<li>Out-of-band account creation, after which the account JID and password
|
||||
need to be manually entered into an XMPP client, and</li>
|
||||
<li>&xep0077; (IBR) where an account is created and fully configured right
|
||||
from the XMPP client.</li>
|
||||
</ul>
|
||||
<p>The IBR mechanism is much more convenient for users, but also opens up
|
||||
the server to abuse, e.g. due to the mass-registration of spam bot
|
||||
accounts. Captchas, while heavily impacting well-intentioned users, are
|
||||
not a reliable mechanism to prevent abuse. This specification allows to
|
||||
restrict the IBR mechanism by requiring a registration token, e.g. for
|
||||
giving users access to a private server, without exposing their password
|
||||
to the server administrator.</p>
|
||||
<p>This specification is part of a series of documents aiming at improving
|
||||
user onboarding:</p>
|
||||
<ul>
|
||||
<li>&xep0379; to automatically accept roster subscriptions based on a
|
||||
token.</li>
|
||||
<li>&xep0401; to generate tokens that can be used for authenticating IBR.</li>
|
||||
</ul>
|
||||
<p>While this specification is designed to work together with &xep0401;, it
|
||||
can be used with invitation tokens obtained by any other mechanism. XMPP
|
||||
URIs can then be used out-of-band to deliver the invitation to a new user.</p>
|
||||
<p>A client that obtains such an XMPP URI should allow the user to register
|
||||
an XMPP account with the server that generated the URI.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Use Cases'>
|
||||
<p>A client that implements this specification needs to understand the
|
||||
&xep0147; specification, to make use of the <tt>register</tt> query
|
||||
action and the <tt>preauth</tt> parameter. Three URI formats
|
||||
are defined.</p>
|
||||
<section2 topic="Registration with pre-defined account name">
|
||||
<p>An invitation to register an account can contain a specific XMPP
|
||||
address (with a pre-defined user account name) to be registered. A
|
||||
client should populate the address field in the IBR dialog with this
|
||||
address and disallow changing the address.</p>
|
||||
<code caption="Registration URI with pre-defined account name">xmpp:juliet@example.com?register;preauth=TOKEN</code>
|
||||
</section2>
|
||||
|
||||
<section2 topic="Registration on a server">
|
||||
<p>An invitation to register an account can contain just the server domain
|
||||
to register on. A client should populate the address field in the IBR
|
||||
dialog with this domain and allow entering the desired account name.</p>
|
||||
<code caption="Registration URI without account name">xmpp:example.com?register;preauth=TOKEN</code>
|
||||
</section2>
|
||||
|
||||
<section2 topic="Contact Invitation with IBR">
|
||||
<p>A contact invitation with a registration token (&xep0379;) might
|
||||
indicate that the token can also be used to register an account on that
|
||||
server (<tt>ibr=y</tt>). If the receiving client already has an account
|
||||
configured, it may skip account registration and simply add the contact
|
||||
as defined in <cite>XEP-0379</cite>. The client may also register a new
|
||||
account on the domain of the proposed contact, allowing the user to
|
||||
enter the desired account name.</p>
|
||||
<code caption="Contact URI with Pre-Authenticated IBR support">xmpp:romeo@example.com?roster;preauth=TOKEN;ibr=y</code>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Discovery' anchor='discover'>
|
||||
<p>While a registration URI is an indication that the respective server
|
||||
supports Pre-Authenticated IBR, a URI might be manipulated and is not
|
||||
guaranteed to be reliable.</p>
|
||||
<p>Therefore, when performing the account creation, the client needs to
|
||||
ensure that the server supports the Pre-Authenticated IBR protocol, as denoted by
|
||||
the <strong><register xmlns='urn:xmpp:invite'></strong>
|
||||
stream feature:</p>
|
||||
<example caption="Stream features of a server that accepts invitations"><![CDATA[
|
||||
<stream:features>
|
||||
<mechanisms xmlns='urn:xmpp:sasl:0'>
|
||||
<mechanism>EXTERNAL</mechanism>
|
||||
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
|
||||
<mechanism>SCRAM-SHA-1</mechanism>
|
||||
<mechanism>PLAIN</mechanism>
|
||||
</mechanisms>
|
||||
<register xmlns='urn:xmpp:invite'/>
|
||||
<register xmlns='http://jabber.org/features/iq-register'/>
|
||||
</stream:features>
|
||||
]]></example>
|
||||
</section1>
|
||||
<section1 topic='Pre-Authenticated In-Band Registration' anchor='preauth-ibr'>
|
||||
<p>In order to allow invited users to register on a server, the
|
||||
registration processs as defined in &xep0077; needs to be extended. The
|
||||
invited user's client needs to connect to the server and check that the
|
||||
invitation stream feature
|
||||
(<strong><register xmlns='urn:xmpp:invite'></strong>) is present.
|
||||
After that, the client initiates the registration flow by sending the
|
||||
preauth token to the server:</p>
|
||||
<example caption="Client initiates pre-authenticated IBR"><![CDATA[
|
||||
<iq type='set' to='example.com' id='pa1'>
|
||||
<preauth xmlns='urn:xmpp:pars:0' token='TOKEN' />
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Upon receiving the preauth request, the server must validate that the
|
||||
token is acceptable for account registration. However, single-use tokens
|
||||
MUST NOT be considered used until the actual registration has succeeded.
|
||||
</p>
|
||||
<p>In addition, if the token has an expiration time, it MUST only be
|
||||
checked at this point. Subsequent actions performed by the client during
|
||||
the current session that require a valid token MUST NOT be rejected due
|
||||
to token expiry.
|
||||
</p>
|
||||
<p>If the token is acceptable, the server responds with success, and
|
||||
indicates the client may now proceed with account registration:
|
||||
</p>
|
||||
<example caption="Server accepts invitation token"><![CDATA[
|
||||
<iq type='result' from='example.com' id='pa1' />
|
||||
]]></example>
|
||||
<p>If the token provided by the client was unknown, invalid or expired, the
|
||||
server should return an appropriate error to the client:</p>
|
||||
<example caption="Server rejects invitation token"><![CDATA[
|
||||
<iq type="error" from="example.com" id="pa1">
|
||||
<error type='cancel'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<text>The provided token is invalid or expired</text>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>In the success case, the client proceeds with registration as defined in
|
||||
&xep0077;. If the token is rejected by the server, the client still MAY
|
||||
attempt to perform IBR if the server allows that.</p>
|
||||
</section1>
|
||||
<section1 topic='Business Rules' anchor='rules'>
|
||||
<p>If a username was specified when creating an invitation token, the
|
||||
server SHOULD NOT create an account on the server until the invitee
|
||||
actually registers it with the corresponding token.
|
||||
The server MUST reserve the username at least until the corresponding
|
||||
token expires.</p>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section2 topic='XMPP Server Suggestion for Invitees'>
|
||||
<p>If the invitee opens an invitation URI with <strong>ibr=y</strong> and
|
||||
chooses to create a new account, the client SHOULD pre-fill the
|
||||
inviter JID's domain part as the new account's domain. The client MAY
|
||||
provide a mechanism to enter or choose a different server, though.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>See security considerations in &xep0379;.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>This document only makes use of the XMPP URI elements defined in
|
||||
&xep0401;</p>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<p>REQUIRED for protocol specifications.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
@ -10,7 +10,7 @@
|
||||
<abstract>This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0292</number>
|
||||
<status>Proposed</status>
|
||||
<status>Deferred</status>
|
||||
<lastcall>2019-02-19</lastcall>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
|
||||
@ -21,6 +21,12 @@
|
||||
<supersededby/>
|
||||
<shortname>message-correct</shortname>
|
||||
&ksmith;
|
||||
<revision>
|
||||
<version>1.2.0</version>
|
||||
<date>2020-10-20</date>
|
||||
<initials>gl</initials>
|
||||
<remark><p>Reword note about how to handle LMC in cases where it is not clear that all recipients support it.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.1.0</version>
|
||||
<date>2019-05-15</date>
|
||||
@ -80,7 +86,7 @@
|
||||
...
|
||||
</query>
|
||||
</iq>]]></example>
|
||||
<p>It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. There may be environments (particularly within a &xep0045; MUC room) where it is unknown whether some or all recipients support this extension, and implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments. It is suggested that when the support of recipients is not known a sending client will make the user aware of the potential for duplicate messages to be interpreted by the recipients.</p>
|
||||
<p>Message corrections sent to clients that do not support them will be rendered as duplicate (corrected) messages. In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it is unknown whether some or all receiving devices support this extension. It is suggested that a client should always allow sending corrections, but may make the user aware of the potential for duplicate messages to be interpreted by the recipients. In restricted environments, implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments.</p>
|
||||
</section1>
|
||||
<section1 topic='Use Case' anchor='usecase'>
|
||||
<p>When a user indicates to the client that he wants to correct the most recently sent message to a contact, the client will resend the corrected message with a new id, and with the replace payload refering to the previous message by id. The receiving client then treats the newly received payloads as completely replacing all payloads of the original message.</p>
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
<abstract>This document defines a way for the client to indicate its active/inactive state.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0352</number>
|
||||
<status>Proposed</status>
|
||||
<status>Draft</status>
|
||||
<lastcall>2020-08-18</lastcall>
|
||||
<lastcall>2017-12-21</lastcall>
|
||||
<lastcall>2017-11-15</lastcall>
|
||||
@ -28,6 +28,12 @@
|
||||
<supersededby/>
|
||||
<shortname>csi</shortname>
|
||||
&mwild;
|
||||
<revision>
|
||||
<version>1.0.0</version>
|
||||
<date>2020-10-14</date>
|
||||
<initials>XEP Editor (jsc)</initials>
|
||||
<remark>Accepted as Draft as per Council vote from 2020-08-26.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.3.0</version>
|
||||
<date>2018-11-08</date>
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
<abstract>This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0353</number>
|
||||
<status>Proposed</status>
|
||||
<status>Deferred</status>
|
||||
<lastcall>2019-08-13</lastcall>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
|
||||
@ -24,6 +24,12 @@
|
||||
<supersededby/>
|
||||
<shortname>stanza-id</shortname>
|
||||
&flow;
|
||||
<revision>
|
||||
<version>0.6.1</version>
|
||||
<date>2020-11-03</date>
|
||||
<initials>gh/@melvo</initials>
|
||||
<remark><p>Correct example caption</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.6.0</version>
|
||||
<date>2018-10-01</date>
|
||||
@ -127,7 +133,7 @@
|
||||
<p>
|
||||
Some use cases require the originating entity, e.g. a client, to generate the stanza ID. In this case, the client MUST use the &origin-id; element extension element qualified by the 'urn:xmpp:sid:0' namespace. Note that originating entities often want to conceal their XMPP address and therefore the &origin-id; element has no 'by' attribute.
|
||||
</p>
|
||||
<example caption='A message stanza with the stanza ID extension.'><![CDATA[
|
||||
<example caption='A message stanza with the origin ID extension.'><![CDATA[
|
||||
<message xmlns='jabber:client'
|
||||
to='room@muc.example.com'
|
||||
type='groupchat'>
|
||||
|
||||
12
xep-0369.xml
12
xep-0369.xml
@ -35,6 +35,12 @@
|
||||
<shortname>MIX-CORE</shortname>
|
||||
&ksmithisode;
|
||||
&skille;
|
||||
<revision>
|
||||
<version>0.14.5</version>
|
||||
<date>2020-11-03</date>
|
||||
<initials>gh/@melvo</initials>
|
||||
<remark><p>Fix various typos</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.14.4</version>
|
||||
<date>2020-03-26</date>
|
||||
@ -1007,7 +1013,7 @@
|
||||
<section2 topic='Common User Use Cases' anchor='usecases-user'>
|
||||
<section3 topic="Model for Join and Leave" anchor="usecase-jl-model">
|
||||
<p>
|
||||
MIX Join and Leave communication goes through the clients server. The full specification of client interaction with the client's server is specified in MIX-PAM. This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server.
|
||||
MIX Join and Leave communication goes through the client's server. The full specification of client interaction with the client's server is specified in MIX-PAM. This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Joining a Channel' anchor='usecase-user-join'>
|
||||
@ -1116,11 +1122,11 @@
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>
|
||||
A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it will generally be necessary to include a nick when joining an channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result.
|
||||
A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it will generally be necessary to include a nick when joining a channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Leaving a Channel' anchor='usecase-user-leaving'>
|
||||
<p>Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel. </p>
|
||||
<p>Users generally remain in a channel for an extended period of time. In particular the user remains as a participant of the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel. </p>
|
||||
<example caption="User's Server sends Leave Request to a Channel"><![CDATA[
|
||||
<iq type='set'
|
||||
from='hag66@shakespeare.example'
|
||||
|
||||
14
xep-0405.xml
14
xep-0405.xml
@ -38,6 +38,12 @@
|
||||
<shortname>MIX-PAM</shortname>
|
||||
&ksmithisode;
|
||||
&skille;
|
||||
<revision>
|
||||
<version>0.5.1</version>
|
||||
<date>2020-11-03</date>
|
||||
<initials>gh/@melvo</initials>
|
||||
<remark><p>Fix various typos</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.5.0</version>
|
||||
<date>2019-09-30</date>
|
||||
@ -192,9 +198,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
<body>Harpier cries: 'tis time, 'tis time.</body>
|
||||
<mix xmlns='urn:xmpp:mix:core:1'>
|
||||
<nick>thirdwitch</nick>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
<mix xmlns='urn:xmpp:mix:core:1'>
|
||||
<nick>thirdwitch</nick>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
</mix>
|
||||
</message>
|
||||
|
||||
@ -506,7 +512,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</section2>
|
||||
|
||||
<section2 topic="MIX Roster Item Capability Sharing" anchor="mix-roster-capability-sharing">
|
||||
<p>It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>
|
||||
<p>It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server returns this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>
|
||||
<example caption="Roster Get Requesting MIX Information"><![CDATA[
|
||||
<iq from='juliet@example.com/balcony'
|
||||
id='bv1bs71f'
|
||||
|
||||
14
xep-0407.xml
14
xep-0407.xml
@ -36,6 +36,12 @@
|
||||
<shortname>MIX-MISC</shortname>
|
||||
&ksmithisode;
|
||||
&skille;
|
||||
<revision>
|
||||
<version>0.1.2</version>
|
||||
<date>2020-11-03</date>
|
||||
<initials>gh/@melvo</initials>
|
||||
<remark><p>Fix various typos</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1.1</version>
|
||||
<date>2018-11-03</date>
|
||||
@ -218,7 +224,7 @@
|
||||
</section1>
|
||||
<section1 topic='Inviting another User to join a Channel that the user does not have Permission to Join' anchor='usecase-user-invite'>
|
||||
<p> Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel or if the inviter is a channel participant and the channel allows invitation by participants (this channel capability is controlled by the channel configuration variable 'Participation Addition by Invitation from Participant'). Invitation by reference is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation.
|
||||
When a channel participant(the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:
|
||||
When a channel participant (the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:
|
||||
|
||||
</p>
|
||||
<ol>
|
||||
@ -230,7 +236,7 @@
|
||||
<li>The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.</li>
|
||||
</ol>
|
||||
<p>
|
||||
The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:misc:0' namespace. <invite/> contains an <invitation/> child element, which contain <inviter/>, <invitee/>, <channel/> and <token/> child elements.
|
||||
The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:misc:0' namespace. <invite/> contains an <invitation/> child element, which contains <inviter/>, <invitee/>, <channel/> and <token/> child elements.
|
||||
</p>
|
||||
<example caption='Inviter Requests and Receives Invitation'><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/UUID-h5z/0253'
|
||||
@ -264,14 +270,14 @@
|
||||
<message from='hag66@shakespeare.example/UUID-h5z/0253'
|
||||
id='f5pp2toz'
|
||||
to='cat@shakespeare.example'>
|
||||
<body>Would you like to join the coven?<body>
|
||||
<body>Would you like to join the coven?</body>
|
||||
<invitation xmlns='urn:xmpp:mix:misc:0'>
|
||||
<inviter>hag66@shakespeare.example</inviter>
|
||||
<invitee>cat@shakespeare.example</invitee>
|
||||
<channel>coven@mix.shakespeare.example</channel>
|
||||
<token>ABCDEF</token>
|
||||
</invitation>
|
||||
</iq>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>The invitation can now be used by the invitee to join a channel. The <invitation/> child element is simply added to the standard channel <join/> element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.</p>
|
||||
<example caption="User Joins a Channel with an Invitation"><![CDATA[
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
<abstract>This specification describes a method to migrate to PEP based bookmarks without loosing compatibility with client that still use Private XML.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0411</number>
|
||||
<status>Proposed</status>
|
||||
<status>Draft</status>
|
||||
<lastcall>2020-10-14</lastcall>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
@ -29,6 +29,12 @@
|
||||
<email>daniel@gultsch.de</email>
|
||||
<jid>daniel@gultsch.de</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>1.0.0</version>
|
||||
<date>2020-10-20</date>
|
||||
<initials>XEP Editor (jsc)</initials>
|
||||
<remark>Accepted as Draft by vote of Council on 2020-10-14.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.2.1</version>
|
||||
<date>2020-05-25</date>
|
||||
|
||||
12
xep-0420.xml
12
xep-0420.xml
@ -30,6 +30,12 @@
|
||||
<supersededby/>
|
||||
<shortname>SCE</shortname>
|
||||
&paulschaub;
|
||||
<revision>
|
||||
<version>0.3.1</version>
|
||||
<date>2020-11-03</date>
|
||||
<initials>gh/@melvo</initials>
|
||||
<remark><p>Fix misspelling of 'whose'</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.3.0</version>
|
||||
<date>2020-07-03</date>
|
||||
@ -112,19 +118,19 @@
|
||||
<tr>
|
||||
<td>&time;</td>
|
||||
<td>Timestamp</td>
|
||||
<td>Prevent replay attacks using old messages. This element MUST have one attribute 'stamp', whos value is a timestamp following the format described in &xep0082;. The timestamp represents the time at which the message was encrypted by the sender.</td>
|
||||
<td>Prevent replay attacks using old messages. This element MUST have one attribute 'stamp', whose value is a timestamp following the format described in &xep0082;. The timestamp represents the time at which the message was encrypted by the sender.</td>
|
||||
<td>Receiving clients MUST check whether the difference between the timestamp and the sending time derived from the stanza itself lays within a reasonable margin. The client SHOULD use the content of the timestamp element when displaying the send date of the message</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>&to;</td>
|
||||
<td>Recipient of the message</td>
|
||||
<td>Prevent spoofing of the recipient. This element MUST have one attribute 'jid', whos value is the JID of the intended recipient.</td>
|
||||
<td>Prevent spoofing of the recipient. This element MUST have one attribute 'jid', whose value is the JID of the intended recipient.</td>
|
||||
<td>Receiving clients MUST check, if the JID matches the to attribute of the enclosing stanza and otherwise alert the user/reject the message</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>&from;</td>
|
||||
<td>Sender of the message</td>
|
||||
<td>Prevent spoofing of the sender. This element MUST have one attribute 'jid', whos value is the JID of the sender of the message.</td>
|
||||
<td>Prevent spoofing of the sender. This element MUST have one attribute 'jid', whose value is the JID of the sender of the message.</td>
|
||||
<td>Receiving clients MUST check, if the value matches the from attribute of the enclosing stanza and otherwise alert the user/reject the message</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
67
xep-0443.xml
67
xep-0443.xml
@ -22,7 +22,8 @@
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0443</number>
|
||||
<status>Experimental</status>
|
||||
<status>Proposed</status>
|
||||
<lastcall>2020-11-03</lastcall>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies>
|
||||
@ -62,6 +63,12 @@
|
||||
<email>georg@op-co.de</email>
|
||||
<jid>georg@yax.im</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.2.0</version>
|
||||
<date>2020-10-20</date>
|
||||
<initials>dg</initials>
|
||||
<remark>Added section about A/V calls</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2020-10-06</date>
|
||||
@ -114,7 +121,7 @@
|
||||
<section2 topic='Changes since 2020' anchor='changes-2020'>
|
||||
<p>The following changes were made to the Compliance Suites since &xep0423;:</p>
|
||||
<ul>
|
||||
<li>TODO</li>
|
||||
<li>Introduced new category for <strong>A/V Calling</strong>.</li>
|
||||
</ul>
|
||||
</section2>
|
||||
<section2 topic='Changes since 2019' anchor='changes'>
|
||||
@ -457,6 +464,62 @@
|
||||
<li>&xep0286;</li>
|
||||
</ul>
|
||||
</section2>
|
||||
<section2 topic='A/V Calling Compliance Suite' anchor='av'>
|
||||
<p>
|
||||
To be considered XMPP A/V calling compliant, all features from the core
|
||||
compliance category must be met, as well as all features in this suite.
|
||||
</p>
|
||||
<table caption='A/V Calling Compliance Levels'>
|
||||
<tr>
|
||||
<th>Feature</th>
|
||||
<th>Core Server</th>
|
||||
<th>Core Client</th>
|
||||
<th>Advanced Server</th>
|
||||
<th>Advanced Client</th>
|
||||
<th>Providers</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Call Setup</strong></td>
|
||||
<td align='center'>N/A</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td align='center'>N/A</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td>&xep0167;, &xep0353;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Transport</strong></td>
|
||||
<td align='center'>N/A</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td align='center'>N/A</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td>&xep0176;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Encryption</strong></td>
|
||||
<td align='center'>N/A</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td align='center'>N/A</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td>&xep0320;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>STUN/TURN server discovery</strong></td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td>&xep0215;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Quality and Performance improvements</strong></td>
|
||||
<td align='center'>N/A</td>
|
||||
<td align='center'>&no;</td>
|
||||
<td align='center'>N/A</td>
|
||||
<td align='center'>&yes;</td>
|
||||
<td>&xep0293;, &xep0294;, &xep0338;, &xep0339;</td>
|
||||
</tr>
|
||||
</table>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Future Development' anchor='future'>
|
||||
<p>This section outlines the protocol specifications that are relevant for
|
||||
|
||||
Loading…
Reference in New Issue
Block a user