[Standards] SIMS issues

Jonas Schäfer jonas at wielicki.name
Sat Sep 7 11:18:05 UTC 2019


On Samstag, 7. September 2019 13:08:39 CEST Daniel Gultsch wrote:
> 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/s
> > ummit.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.

+1.

This also neatly solves the issue of packing multiple media sharing elements 
in a single message.

If we want to use References at some point to establish a relationship between 
<media-sharing/> elements and parts of the text, that could be solved by a 
proper URI scheme or child element in the References tag which then 
references(!) the respective <media-sharing/> element.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190907/a5b96af4/attachment-0001.sig>


More information about the Standards mailing list