Hi, On Thu, 2026-11-05 at 11:17 +0000, Dave Cridland wrote:
I'd be curious as to what those changes are in detail.
The new disposition type is for "don't show this on its own, only in context of something else", where "something else" could be another XEP, like XEP-0514. This is conceptually not a refinement of inline and attachment and I agree that for every other potential disposition I could agree that they can be built as a refinement of either of those three (attachment, inline, hidden*). Right now messages using XEP-0514 would have their custom emojis displayed as files (either inline or attachment) to legacy clients not supporting XEP-0514 and the preferred behavior might be to not display them at all. The alternative would be to move those sfs entries into some child element of the emoji markup element, which IMO would increase complexity more. * I haven't actually picked the name for the disposition yet and would be happy to hear suggestions ;)
[With process-wonk hat on, XEP-0001 section 7 says Authors are supposed to collect and apply feedback from the community, so soliciting feedback rather than just making changes seems to fit better]
This is based on feedback from the community, either here on the list or in the discussion channel.
- The jabber:x:oob added to messages is "used to communicate a URI to another user or application". It is specifically not about file transfers, we just have some recipient side rules to interpret those as oob in some cases. But purely from the spec, it may as well be used to communicate a Zoom link to invite someone to a call.
XEP-0482? Maybe one of the authors of that could chip in. ;-)
I didn't want to suggest or recommend using jabber:x:oob for sending a Zoom invite link, I was just bringing it as an example how vague the jabber:x:oob specification is, which IMO is a good reason to deprecate it. jabber:x:oob also optionally allows for a description of the resource behind the URI communcated, again something I expect most implementations to not support. There is also voices claiming that jabber:x:oob may appear more than once in a messaage to support sending multiple files in a single message. That is not specified at all and likely also not supported by most if not all implementations.
As I've said before, I think in retrospect SFS could have been a series of incremental changes to SIMS.
As an Experimental XEP is owned by an author, this would have needed author approval and/or community consensus to pull off. One of the stated goals of SFS (as is written in its introduction) is to not use XEP-0372 references, which remained desired by some in the community at that point in time and thus was not negotiable for SIMS. It is also worth noting that through this, SIMS (via example, not specification) does support something that SFS (deliberately) does not support: referencing files from a sub-part (via begin- and end-index) of the message body. While potentially an interesting feature for some use cases, I don't see it common in popular messaging apps of the time, so the added complexity seemed not worth it for me. YMMV. And with no intent to talk bad about people's work here, I think the implementation experience about SIMS XEP can be roughly described as "it defines an element and syntax I can use partially and then assign my own semantics and business rules". Marvin