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

On Sun, 2026-04-26 at 11:44 +0000, Stephen Paul Weber wrote: Are we reading the same words? Let me quote the introduction of XEP- 0446 for you. Nowhere does it say it doesn't like the design of SIMS. I didn't know that was the main purpose of SIMS or SFS. Also surprises me, given that some implementation neither send nor process the hash. I'm pretty sure the main reason so far for people to implement SIMS or SFS is to get thumbnails. I think there is a huge difference between a jpg being mentioned in a non-normative example without any indication if it is meant to be displayed inline or just as a savable file (as in OOB) and a normative text saying to display files inline with a "RECOMMENDED" (=SHOULD) to support decoding H.264. YMMV. XEP numbers are cheap. It's an easier process to create a new XEP than to bring a XEP back to life. Further, keeping the document alive that describes what some clients implement just makes sense (look at OMEMO where most clients implement something that people have to find in the attic). The design wasn't changed hugely, ideas and motivation remained the same. The introduction of XEP-0447 even says its an reiteration of SIMS with some changes and lists them. The acknowledgement section also mentions SIMS and it has descriptions on how to best be backwards compatible with existing SIMS implementations. Most clients can receive more than one file, they just can't group them together. I think that the most reasonable fallback to sending a group of 3 files is to send 3 messages with 1 file each rather than a message with 3 URLs. Needless to say that this is all a mute argument, because when you send 3 files in a single message using SIMS, it will break existing implementations (that often only take the first or last occurrence of a SIMS in each message). Have fun doing that UI choice when the fallback is more than just one URI. Are those URIs separated by commas, spaces, newlines? Will someone potentially put "URI and URI" with literal "and" in the body. And then translate that to the users preferred language. Even if you call it a UI choice, what we provide as protocols should allow for such reasonable UI choices to be made. If our protocols prevent you from doing the choices you want to do for your UI, the protocol becomes unfit for the purpose. I get that now. Though it makes me wonder why you prefer the <file/> from Jingle File Transfer that puts restrictions and rules in place that are not required for the generic case of file metadata and also means everyone has to suddenly implement Jingle File Transfer only because they want to do file metadata? First, the purpose of Metalink is to allow to link to multiple instances of the same file (e.g. different mirrors or protocols). The way it refers to files (by URI) does not allow for encryption to be added or more complex file retrieval instructions that don't fit a URI, but let's ignore that and say we would only use the file metadata aspects of it (which is the same 0446 provides and what SIMS takes from Jingle). The metadata elements provided by Metalink are largely mismatching the ones people look for in messaging context. There is no metadata specific to media files at all (dimensions, length) or that are useful for clients to discover if they want to automatically download the file or try to display it inline (media type). However it has a lot of fields specific to software publishing (which is what it was designed for) like "identity" and "version" (which refer to the file being downloaded, with the example being "Firefox" and "3.5" for Firefox 3.5) that we likely won't use. With the overlap being essentially file name, file size and description, it feels weird to pull in a dependency on a largely unrelated specification for just those 3 file properties. (Metalink also specifies a hash property, but we do have one that is also stable for a while in XMPP so I didn't count that). So yeah, if the options are: 1. Create an RFC to extend Metalink so it can be used for our purpose + create a XEP that says how to use Metalink with that extension so such XEP can be referenced elsewhere (like Jingle File Transfer or SIMS/SFS) 2. Create a XEP that goes without Metalink and requires me to specify 3 undercomplex file properties (name, size and description) that Metalink could have given me for free I definitely opt for the second. It's less work to write, easier to handle for developers and doesn't depend on any external parties with a completely different usecase. YMMV.