Re: SIMS and SFS, was: Re: Proposed XMPP Extension: Emoji Markup

>On Sat, 2026-04-25 at 14:22 +0000, Stephen Paul Weber wrote:
>> 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.

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.

>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).

Sure, the example in OOB is also of a jpg. Doesn't mean oob is only for 
pictures.

>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).

It's definitely compatible with the hack some clients use for single file, 
and AFAIK most SIMS implementations indeed follow this hack just for 
compatibility with such clients. For multi file there is no support in 
clients whech require the hack but including the fallback urls is still 
sensible of course so that they see something useful.

>- 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.
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]