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

On Sat, 2026-04-25 at 14:22 +0000, Stephen Paul Weber wrote: 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, while nice to have and useful in some context, might be unnecessary compute work in other context. SFS recommends using hashes, but also has clear rules for when the sending entity decides against using them. This would not be possible when reusing the Jingle File Transfer <file/>. XEP-0446 explicitly defines that any use of its <file/> may impose new rules. The idea is that eventually, a future version of XEP-0234 could use XEP-0446 instead of defining its own element. Same for XEP-0385. 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. 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. It's fully backwards compatible to SIMS and adds new features. The changes over SIMS would not be possible without a namespace bump, so if it makes you happier, consider SFS a namespace bump over SIMS. On Sat, 2026-04-25 at 14:26 +0000, Stephen Paul Weber wrote: What is a feature to some always is a complication to others. Using source attaching is optional. If with OOB as a file transfer method, you're referring to jabber:iq:oob from XEP-0066, that only supports a single file transfer per iq. If with OOB you are referring to the jabber:x:oob from XEP-0066, I need to let you know that this element as per XEP-0066 does not constitute a file transfer request. It's merely "used to communicate a URI to another user or application", which may be a URI pointing to a file, but may just as well be one pointing to a website to be opened in the browser or a sip:-URI to start a SIP call. This is actually made explicit in the XEP itself (section 5). The XEP does not make any claim on the number of jabber:x:oob <x/> element that can be in a message, so I'm happy to assume one can use it to communicate more than one URI (that may or may not be a file download). Where OOB becomes useful as a file transfer it through a non-standard convention that if a message has a single OOB element and the URI in that OOB element matches the content of the body, some clients would interpret that as a file transfer request (and then either display that inline or provide a way to download/save the file). This convention is reasonably backwards compatible to clients not supporting OOB (which will just display the link). While it would be possible to extend this non-standard convention to support multiple files, this would not be possible without breaking backwards compatibility (either by making the additional files invisible to existing clients or by turning the files into just a message of multiple URIs for existing clients). 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). Now when it comes to existing SIMS implementations, they all are non- compliant with SIMS in various aspects: - 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. The reason clients don't do this is that otherwise they couldn't send a message that both follows the oob convention and uses SIMS. - They often also don't support multiple references to media-sharing. So even if we interpret the XEP that this is allowed, doing to would not be compatible with existing SIMS implementations. - As I wrote above, SIMS mandates (MUST) a <hash/> element inside Jingle File Transfer <file/>. Guess how many implementations actually do that. - There's also a bunch of other non-standard shenanigans done by existing clients that claim compliance with SIMS, but they're not relevant for this discussion, so I'll keep them out (although they're probably relevant for anyone trying to implement SIMS and be compatible with existing implementations) Both SIMS and OOB don't have any way to indicate encryption keys. OOB is just a URI and https-URIs don't carry encryption keys. For SIMS, one could in theory do an extension that does support this, which would actually be close to XEP-0448 and thus just emphasizes my point that XEP-0447 is really mostly a continuation of SIMS. So in summary, I consider SIMS dead. The specification document has all kinds of open ends and uncertainties and the implementations in the wild significantly divert from it. It is also not actively developed, last change in 2018. There was a mailing list discussion on the <hash/> element issue in 2021 but no follow-up update. The author of SIMS also didn't extend their XSF membership last year. SFS is a successor, it's being actively developed, is more flexible and by now should have a superset of the features of SIMS and better backwards compatibility. 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. Marvin