On Thu, 5 Nov 2026 at 12:19, Marvin W. <xmpp@larma.de> wrote:
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 ;)
There's a SIP case that's "by-reference", which'd be similar, but I broadly disagree with those, too. HTML email handles this by wrapping everything in multipart/related, with images referenced by the first text/html part by cid: scheme URIs being other parts in the multipart, Content-Disposition set to "attachment". In both cases, these are all embedded into a single entity at transmission time, though. I suppose XEP-0514 is too, though - what's the need for marking it differently? Put another way, what fails to interoperate if we just call it an attachment? Also, I was put in mind of XEP-0213 (BOB) when I dug into this. Feels like yet another case we could consolidate here.
[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.
Very much an aside - sorry, I realise that may have read as a direct criticism, absolutely not my intent.
- 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.
Right, I entirely agree it's difficult to use OOB in an interoperable way, without being reliant on "the way Gajim does it" as part of the spec, which is hardly helpful.
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".
I suspect, judging by the dates, that I was on Council at the time, so this is very much a retrospective view given what we know now, as I said. If I'm directly criticising anyone, I'm criticising past me - but mostly I'm just thinking out loud. Dave.