This is largely Dave Cridland's suggestion from the list, in response to Georg's
feedback, with Georg having checked the material details, along with others
in the xsf MUC. I believe everyone is happy with this.
Update to XEP-0434 version 0.6.0 and XEP-0384 version 0.8.0:
* Use Base64-encoded key identifiers in examples
* Update TM's namespace to 'urn:xmpp:tm:1'
* Update OMEMO's namespace to 'urn:xmpp:omemo:2'
Specify key identifier encoding, improve glossary and update to XEP-0384 version 0.8.0:
* Specify usage of Base64 encoding for key identifiers within trust messages
* Specify usage of Base16 encoding for key identifiers within Trust Message URIs
* Use Base64-encoded key identifiers in examples
* Add 'hash value' as example of key identifier
* Update OMEMO's namespace to 'urn:xmpp:omemo:2'
* Update namespace to 'urn:xmpp:tm:1'
The requirement to strip `<private/>` by the sending server was in the
XEP from day 1. It was later changed from "MUST" to "SHOULD" and from
"sending server" to "receiving server", so that the latter could also
prevent normal message routing.
As this behavior only ever affected the `<private/>` element and not the
`<no-copy/>` hint (introduced in 2017), which should be treated in a
similar but not equal way, and there is a security benefit in letting
the receiving client know that message routing was manipulated, it makes
sense to remove this requirement.
As there is no negative effect of keeping another element in delivered
messages, nobody complained about `<no-copy/>` not being stripped, and
bumping Carbons today would be rather unfortunate, this is done without
a namespace bump, despite "breaking" the specification.
Currently this only explains the difference between the before/after
parameters of RSM and the before-id/after-id parameters of mam#extended.
Signed-off-by: Sam Whited <sam@samwhited.com>
