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