[Standards] SIMS issues

Daniel Gultsch daniel at gultsch.de
Sat Sep 7 11:08:39 UTC 2019


Am Sa., 7. Sept. 2019 um 10:51 Uhr schrieb Marvin W <xmpp at larma.de>:
>
> On 07.09.19 11:55, Daniel Gultsch wrote:
> > To cover the use case Sergey is talking about here (stand alone voice
> > message, stand alone image, stand alone file) without any description
> > wouldn’t it make more sense to be able to put a sims as a direct child
> > of a message (and essentially the only child ( + origin-id, 184
> > request)?
> >
> > I mean it is nice and all that it can _also_ be used within a
> > reference but i don’t understand the hard dependency (that the XEP in
> > it's current state implies) on references.
>
> I actually think the current way of SIMS is even semantically wrong,
> because it puts <media-sharing> into <reference />. However the message
> usually does not reference a media sharing, it *is* the media sharing
> that maybe has a comment attached (like in the examples in XEP-0385 itself).
>
> Therefor even the case of referencing might even be better realized
> using two messages where one is the media sharing and one is a message
> with a reference to that media sharing:
>
> <message id=A>
>   <media-sharing>[...]</media-sharing>
> </message>
>
> and
>
> <message>
>   <body>[...]</body>
>   <reference uri="xmpp:jid?message=A"/>
> </message>.
>
> This has the positive side-effect that SIMS can have a proper fallback body:
>
> <message id=A>
>
> <body>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg
> (summit.jpg, 3032449 byte)</body>
>   <media-sharing>[...]</media-sharing>
> </message>
>
>
> > As I see it a lot of developers are currently in the market for a
> > replacement for the current usage of the x-oob tag and are not
> > necessarily looking for anything more complicated like references
> > (which involve having to implement an URI parser among other things)
> > Therefor I see a danger in essentially forcing those people to
> > implement half-assed references that are only an empty, mostly unused
> > reference wrapper around the sims element. This has the potential of
> > getting us into compatibility trouble if later we will actually use
> > references for something more than this.
> The clients would still need to implement XEP-0372 (or parts thereof)
> for the <reference />s inside the <media-sharing>'s <sources>. I
> actually like using the concept of references here, because it seems to
> be exactly what XEP-0372 is for: referencing resources, both external
> (http url) and internal (jingle).
>
> As we now do have XEP-0420 (even though not realized yet) and XEP-0373,
> we don't need to rely on transporting the download link and encryption
> information in the only encrypted part of messages, the body (like in
> OMEMO Media sharing protoxep), so I feel SIMS might become more
> widespread soonish.
>
> In the context of encryption, I'd also like to express my hope that we
> also make up some concept for sharing encrypted files with SIMS, so that
> we can get rid of `aesgcm://` links longterm and don't need to use them
> inside <media-sharing>...


Well even ignoring encryption and the less than ideal aesgcm URI
scheme for a moment here I'm afraid that people will very soon
implement SIMS because they are looking for a modern alternative to
out of band data.

However if I just want to send you a voice message I simply want to
send you this:
<message to="bob" from="peter">
<media-sharing>
…
</media-sharing>
</message>
Without any body or anything else.
I don’t understand (and consider it harmful) to needlessly wrap this
into a reference that is not referencing anything. Yes we established
that start and end can be empty but how do you suppose the message
stanza is going to look like?
<message to="bob" from="peter">
<reference type="data">
<media-sharing>
…
</media-sharing>
</reference>
</message>

Then what is this reference referring to? I'm afraid that if we don’t
fix this know people will implement the later even though it makes no
sense at all.

cheers
Daniel


More information about the Standards mailing list