Hi all, I propose that we do SFS, and drop the others. It's a bit silly having three file sharing things. SIMS is Deferred, currently, which is as dead as an Experimental XEP can be, but adding a note at the top to state that it's recommended to do SFS instead seems sensible. OOB is Stable, I suggest we move it to Deprecated. SFS and FME are both Experimental, so need advancing through to sensibly Deprecate OOB. In summary then: 1) Last Call XEP-0446, move to Stable. 2) Last Call XEP-0447, move to Stable. 3) Deprecate XEP-0066 (with note pointing to XEP-0447). 4) Add similar note to XEP-0385 but leave in Deferred. I'd like to build consensus for this, so: - Does anyone object? If so, how, why, and what would fix this? - Does anyone agree with me? Can we improve the plan? Dave.
I propose that we do SFS, and drop the others. It's a bit silly having three file sharing things.
Last time this wes discussed there was a proposal to make Jingle File Transfer use XEP-0446 for metadata, at which point the logical update for SIMS (if it got made) would be to use that also, and then SIMS becomes basically a namespace change away from SFS anyway.
OOB is Stable, I suggest we move it to Deprecated.
What's wrong with OOB? It's currently the only thing actually widely implemented (even if implemented poorly in some cases).
On Wed, 4 Nov 2026 at 21:51, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I propose that we do SFS, and drop the others. It's a bit silly having three file sharing things.
Last time this wes discussed there was a proposal to make Jingle File Transfer use XEP-0446 for metadata, at which point the logical update for SIMS (if it got made) would be to use that also, and then SIMS becomes basically a namespace change away from SFS anyway.
Yes... I think SFS could have been an edit to SIMS, in retrospect, but it's possible I'm missing some history about why it wasn't. But anyway, agreed that Jingle FT could be made to use XEP-0446, though I'd be curious about Jingle FT implementation levels.
OOB is Stable, I suggest we move it to Deprecated.
What's wrong with OOB? It's currently the only thing actually widely implemented (even if implemented poorly in some cases).
Do we need it if we have SFS? And if so, can we incorporate that use-case into OOB? It's OK to have legacy code using legacy methods, but the intent of deprecating would be so we didn't need OOB outside backwards comnpatibility cases. Dave.
Hi, On Wed, 2026-11-04 at 21:33 +0000, Dave Cridland wrote:
1) Last Call XEP-0446, move to Stable. 2) Last Call XEP-0447, move to Stable. 3) Deprecate XEP-0066 (with note pointing to XEP-0447). 4) Add similar note to XEP-0385 but leave in Deferred.
I'd like to build consensus for this, so: - Does anyone object? If so, how, why, and what would fix this? - Does anyone agree with me? Can we improve the plan?
For XEP-0447 I have some pending local changes, that include a namespace bump to add extensibility for the disposition attribute. I have to double check if there was any other feedback pending, because I wanted to avoid doing more namespace bumps than necessary. I'd also like to note that OOB does not only apply to file transfers. Or more precisely, XEP-0066 specifies two things: - The jabber:iq:oob IQ is for some sort of file transfers, but nobody is implementing that - 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. Beside that, I do agree with the plan. On Wed, 2026-11-04 at 16:51 -0500, Stephen Paul Weber wrote:
and then SIMS becomes basically a namespace change away from SFS anyway.
You do know very well that SFS has significantly more features than SIMS, like disposition, multiple files, encryption, upload announcements and backwards compatibility for extended functionality. Marvin
On Wed, 2026-11-04 at 16:51 -0500, Stephen Paul Weber wrote:
and then SIMS becomes basically a namespace change away from SFS anyway.
You do know very well that SFS has significantly more features than SIMS, like disposition, multiple files, encryption, upload announcements and backwards compatibility for extended functionality.
As we've discussed many times, I don't agree. SIMS has all of that except disposition? Nevertheless if we end up following the plan it won't much matter if we agreed what SIMS could do since we won't be using it.
On Wed, 4 Nov 2026 at 22:20, Marvin W. via Standards <standards@xmpp.org> wrote:
Hi,
On Wed, 2026-11-04 at 21:33 +0000, Dave Cridland wrote:
1) Last Call XEP-0446, move to Stable. 2) Last Call XEP-0447, move to Stable. 3) Deprecate XEP-0066 (with note pointing to XEP-0447). 4) Add similar note to XEP-0385 but leave in Deferred.
I'd like to build consensus for this, so: - Does anyone object? If so, how, why, and what would fix this? - Does anyone agree with me? Can we improve the plan?
For XEP-0447 I have some pending local changes, that include a namespace bump to add extensibility for the disposition attribute. I have to double check if there was any other feedback pending, because I wanted to avoid doing more namespace bumps than necessary.
I'd be curious as to what those changes are in detail. Email has done pretty well on just two Content-Disposition values. From memory, I think MIME implementations are meant to treat unknown ones as attachment. The Web, in HTTP, has added one - "form-data" - and SIP has added dozens, many of which seem to be unused. If there's additional semantics, I'd prefer to start with "inline" and "attachment" and refine further with a child element. I'm vaguely (as in, not thought this through at all) thinking that WebXDC miniapps might have some extension here, but that would be a subset of "inline". [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]
I'd also like to note that OOB does not only apply to file transfers. Or more precisely, XEP-0066 specifies two things: - The jabber:iq:oob IQ is for some sort of file transfers, but nobody is implementing that
+1
- 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. ;-)
Beside that, I do agree with the plan.
On Wed, 2026-11-04 at 16:51 -0500, Stephen Paul Weber wrote:
and then SIMS becomes basically a namespace change away from SFS anyway.
You do know very well that SFS has significantly more features than SIMS, like disposition, multiple files, encryption, upload announcements and backwards compatibility for extended functionality.
As I've said before, I think in retrospect SFS could have been a series of incremental changes to SIMS. [Process wonk hat on again - this is a case that, if I were on Council at the time and had been paying attention, I'd have considered a veto on submission. Not suggesting that Council did the wrong thing here - hindsight makes a lot of things easier - and SIMS has sufficient support I might well have been persuaded to have both and see which one succeeded] But it wasn't, and we need to start from the situation we find ourselves in rather than what we might wish had happened instead.
Marvin _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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
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.
With respect. In the longer term, that argument be futile; and, all of these XEP specifications should to be deprecated in favour of Metalink format (RFC 5854), which already does it all. Schimon On Wed, 4 Nov 2026 21:33:23 +0000 Dave Cridland <dave@cridland.net> wrote:
Hi all,
I propose that we do SFS, and drop the others. It's a bit silly having three file sharing things.
SIMS is Deferred, currently, which is as dead as an Experimental XEP can be, but adding a note at the top to state that it's recommended to do SFS instead seems sensible. OOB is Stable, I suggest we move it to Deprecated. SFS and FME are both Experimental, so need advancing through to sensibly Deprecate OOB.
In summary then:
1) Last Call XEP-0446, move to Stable. 2) Last Call XEP-0447, move to Stable. 3) Deprecate XEP-0066 (with note pointing to XEP-0447). 4) Add similar note to XEP-0385 but leave in Deferred.
I'd like to build consensus for this, so: - Does anyone object? If so, how, why, and what would fix this? - Does anyone agree with me? Can we improve the plan?
Dave. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
With respect. In the longer term, that argument about SFS, SIMS, and OOB be futile; and, all of these XEP specifications should to be deprecated in favour of Metalink format (RFC 5854), which already does it all. I sent a similar message over ten hours ago; and, for some reason, which I be glad to know, it was not published, as of yet; so, I send this message, directly, to people who participated in this discussion. Schimon
participants (5)
-
Dave Cridland -
Marvin W. -
Schimon -
Stephen Paul Weber -
yiwei wu