26 Apr
2026
26 Apr
'26
5:44 a.m.
On Sat, 2026-04-25 at 14:22 +0000, Stephen Paul Weber
wrote:
I have read it. It says it was written because it disagrees with the design
of sims, which is not the same as being used in sims. If sims used it them
sim and sfs would be the same, but of course my main objection is to
xep0446.
This element was invented for SFS and is my main
objection to the
XEP. Many
equivalent elements exist in other XEP and RFC no need for yet
another.
In fact it was invented for SIMS. It makes me wonder if you had read
the introduction of XEP-0446. Also, XEP-0234 mandates (MUST) the use of a
<hash/> or <hash-used/>
inside the <file/> which
Since this is most of the purpose of using sims or sfs (to get the hash) it
seems reasonable? Though if we really had some actual use case to make it
optional I don't see why we could not.
If you are referring to other standards for file
metadata that would be
reasonable to pick up in XMPP context, I'd be happy to hear about them.
Sure, for example https://datatracker.ietf.org/doc/html/rfc5854 also defines
an equivalent element.
So can SIMS.
The M in SIMS may stand for "media" but this is as in
"medir
type" aka all files.
It is your understanding that "inline media" can also be interpreted as
"not-inline any-file". A lot of the wording in XEP-0385 indicates it is
meant for media in the sense of audio, video and images and that the
client is intended to "display the media inline of the chat". It even
recommends (SHOULD) specific media codecs and container formats for
this (including the patent-encombered, royalty-bearing H.264 codec for
video). Anyway, SFS was always intended as a successor to SIMS,
not a
competitor.
Then why the new XEP number and changed design?
Also supported
not just by SIMS but even by OOB.
Now for SIMS, the wording in XEP-0385 always uses the singular "a" ("a
photo", "a reference to a media-shring"), which I would typically
interpret as a single file. Of course other interpretations are
possible, but there is definitely no intention to allow for multiple
files visible in the XEP. Even if it was allowed, SIMS does not support
for any backwards compatibility with the above mentioned oob convention
(neither for single files nor for multiple). - They tend to ignore the body when a media-sharing
reference is
present. Even if not 100% explicit, the example clearly shows that the
body in SIMS messages is to be displayed to the user next to the SIMS
file.
Indeed. OOB also clearly shows this and I always show both body and
atdachments even for just OOB. Snipping out fallbacks of course but that's
just a UI choice.
I fail to understand what's so bad about SFS that
you reject it and
what's so good about SIMS that you want to stick with it (or your non-
standard interpretation of it). I'm not saying SFS is perfect, but I
would be more than happy to hear what's wrong with it so it can be
improved.
I think I've been pretty clear oves the years that my main objection is the
use of xep0446.