On Samstag, 7. September 2019 13:08:39 CEST Daniel Gultsch wrote: > Am Sa., 7. Sept. 2019 um 10:51 Uhr schrieb Marvin W <[email protected]>: > > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
