Up to now, the xmpp-rs projects have been very strict about incoming
data. This has served us, as developers of the libraries, well,
uncovering bugs in our and remote implementations which we could then
get fixed.
However, this behaviour is unexpected to users of the library. In the
XMPP world, unexpected child elements and attributes are generally
expected to be ignored. While this could be opted-into previously, the
feature flag for that sounded more dangerous than it was
("disable-validation"). In addition, the tribal knowledge needed to know
about that feature flag may not have reached some people who tried the
library and gave up because of that.
With this change, we make the non-pedantic behaviour the default. For
development and debugging purposes, users can always opt into the
pedantic behaviour as needed, using the newly-introduced `pedantic`
feature flags on all affected crates.
This disables a bunch of tests when the component feature is disabled,
because that feature changes the namespace of the <message/> element,
which causes the tests to fail.
Thanks to debacle for finding this.
Features must never be duplicated, so we can use a BTreeSet instead of a
Vec to be nicer for users.
It makes the internal API for computing caps and ecaps2 a bit worse,
because it was expecting a slice directly, so for now let’s collect the
BTreeSet into a Vec when computing the thing. A refactor to use
Iterator might make it better eventually, but I won’t work on that
before profiling it.
This was already just a wrapper around a Vec<String>, but we can do away
with the wrapper thanks to #[xml(extract)].
I’ve also replaced Vec with BTreeSet, since that corresponds better to
how the mechanisms are.
XEP-0167 has been updated to version 1.2.3, to change the type of the
'ssrc' attribute to u32 (from String). This is in accordance with
RFC 3550 (RTP), which defines it as a randomly-chosen 32-bit unsigned
integer.
Additionally, the docstring was completely wrong.
This reverts commit 0a1b291574 once again.
This is currently required to connect to Prosody, otherwise the parser
will choke on the extra undocumented child.
I still wonder if required (4e0cd5d96b)
would be useful to support then, as it might also be found in the wild.
When the required child was added and subsequently reverted, it was
noted that optional and required were never defined, and only appeared
in old XEP-0198 examples. The XEP has been fixed already[1].
This basically reverts 0f0759b207.
[1] https://github.com/xsf/xeps/pull/1447
This was forgotten in 0f0759b207.
That element is only specified in the XML schema, its semantics aren’t
defined anywhere, but we can guess them anyway.
This is still far from being a full fix. Still, we can avoid the lang
attribute (by allowing discarding the `xml:lang` value via the feature
introduced a couple commits ago) and we can avoid emitting `xml:lang=""`
where no language was previously set using the mechanism introduced for
<message/> in 5172fb5e.
This function always appends to an existing string, so by passing it a
String directly we can avoid superfluous allocations.
Also tokio-xmpp was doing a bunch of &str to String for no reason around
there, let’s remove that too.
