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

On Sun, 2026-04-26 at 15:13 +0000, Stephen Paul Weber wrote:
> > Are we reading the same words? Let me quote the introduction of
> > XEP-
> > 0446 for you.
> > 
> > > This resulted in the situation that XEPs like Stateless
> > > Inline Media Sharing (XEP-0385) [2] depend on the mostly
> > > unrelated
> > > Jingle (XEP-0166) [3] just for the metadata element. The
> > > motiviation
> > > of this XEP is to get rid of such dependencies and have a
> > > dedicated
> > > place to define a file metadata element.
> 
> This is the quote right here. Says it doesn't like what was done in
> SIMS and 
> so this XEP exists to change that.

Uhm. SIMS took the element from Jingle File Transfer because that was
the one that available. I don't think the authors wanted to say "it
makes sense to depend on jingle file transfer for this metadata
element" but I think it was rather "unfortunately I have to reference
Jingle File Transfer here, as the metadata that is largely unrelated to
Jingle is specified there". Having the concept of file metadata
specified in something related to Jingle, a specific transfer method,
for me is pretty obvious to be a bad design, but it's not an issue of
SIMS, but rather an issue of Jingle File Transfer, SIMS is just the
victim of that earlier bad design.

> I didn't know anyone was really doing thumbnails but sure that's
> another very visible use if so.

Isn't Cheogram the client sending those `image/thumbhash` thumbnails?
(which is not registered with IANA and thus rather should be
`image/vnd.<name>.thumbhash`)

> No one has to implement Jingle File Transfer

XEP-0385 says "a client supporting this XEP MUST implement Jingle File
Transfer (XEP-0234)". I'm not sure how to not read that as a MUST. 

Also, XEP-0234 is still Experimental (or Deferred to be precise),
meaning that SIMS can't be turned stable without turning Jingle File
Transfer stable first. It also shows again why having the metadata
element in its own XEP is a good idea, as it reduces dependencies on
protocols that are not strictly needed.


> Name, size, description, mime

Metalink doesn't even have mime type as a property, you can only
specify the mediatype of metaurl (like torrent) and signatures, but not
for the file itself. And if I look at existing implementations of both
SIMS and SFS, they seem to be interested in at least width and height
(as those can be used to prepare a "hole" of the correct size within
the user interface while still fetching the image).

Marvin
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]