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

On Sun, 2026-04-26 at 20:07 -0500, Stephen Paul Weber wrote: I'm pretty sure that "SHOULD" does not mean implementations are permitted to break if not followed. That would make "SHOULD" effectively equivalent to "MUST" and thus useless. It is also not an uncommon pattern in RFCs to have "SHOULD do X. MAY not do X if Y", which semantically wouldn't work if "SHOULD" is similar to "MUST". Instead, "SHOULD" means you could be not doing that under circumstances and not doing so has implications. You already found some of the implications listed in the XEP itself (no hash means that none of the provided hashes is available in the local storage, source attaching can't be used), but there may be others (e.g. the recipient might not be able to cache the file at all and thus unable to display inline). I think all current implementations of SFS do support source attaching at least incoming from the same sender and many also use it outgoing when they are the original sender. Also note that the backwards compatibility for sharing multiple files (as described in §4.2) relies on source attaching (as this allows for good backwards compatibility with previous file sharing implementations that only support a single file per message). If source attaching was an optional feature to support incoming, there would be no means for the original sending clients to discover it's supported, so they can't know if they can make use of the "attaching the primary source later" usecase described in §3.3. It would also be weird to not have it in there, because some of the normative language elsewhere only makes sense because there is source attaching (notably that it is optional to provide <sources/> in the <file-sharing/> itself). I guess inline display and preview/thumbnail display are not exactly the same, but the idea of disposition attachment is the same as the Content-Disposition header in HTTP [1]. In fact the behavior described in the XEP pretty much matches the behavior you see in browsers (if Content-Type indicates that it can't be displayed in the browser or of Content-Disposition is set to attachment, browsers don't display the file inline and instead download / show save file dialog). Now your user interface implementation could for example show a download button for the file and display a file type icon next to it, which it replaces with a preview for image files. Similar to the behavior that some desktop file explorers have. But that's an implementation detail of how you realize the offer to download or save the file that is displayed instead of the inline image. And of course you can always ignore this if you have good reason (hence it's a SHOULD and not a MUST). Just like browsers can ignore the Content-Disposition header. However, just like with servers setting Content-Disposition, the assumption by the sender when they set disposition attachment is that the recipient probably doesn't want the file to be displayed inline. An example here could be audio files: if I send you a voice messages, that likely should have disposition inline, but if I send you an 16 hours audiobook file, you're probably better off not to listen to it with your XMPP client and be stuck on the chat for 16 hours, so I will use disposition attachment. As the sender may have some extra context that not always can be reasonable represented using metadata, they are in a better position to make that decision than the receiving client. Marvin [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content…