What about a slightly different scenario? Romeo sees a funny picture on funnypics.com, copies it to a messenger's input field. The messenger prefetches the whole picture, generates a thumbnail (at least it's impossible to have a thumbnail without fetching everything), computes hashes and then sends. Optionally the picture can be put to a local cache and also become available over Jingle and other transfer methods. Now Juliet having a thumbnail knows exactly if she wants to download a whole size picture.
But this is just about pictures. Probably sharing a bluray video by the link from the web won't work this well in this case. So I tend to agree having alternative integrity checks looks reasonable. Also sharing arbitrary files via SIMS, not just multimedia, may require splitting the presentation and sharing into two dedicated XEPs. Best Regards, Sergey пт, 2 июл. 2021 г. в 13:17, JC Brand <[email protected]>: > Hi everyone > > > I've been reading XEP-0385 SIMS with an eye towards potentially > implementing it, when I noticed that a XEP-0300 hash is required, in > order to allow integrity checking and caching. > > In the introduction of SIMS, the following is written: > "This proposal aims to provide a protocol that will enable XMPP clients > to implement a great user experience (UX) around the process of sharing > media in conversations." > > I think making inclusion of the file hash mandatory is at odds with that > goal, the reason being that a lot of the media being shared in chats is > shared as URLs to 3rd parties where the media is hosted. > In other words, the sharer of the media doesn't necessarily know the > hash of the media because it was never on their own machine to begin with. > > Here's the use-case I have in mind: > > Romeo sees a funny picture on funnypics.com. He right-clicks on the > picture, copies the URL and sends it to Juliet. Before the message is > sent, Romeo's client does an HTTP HEAD request, to get information on > the URL, and learns that its an image. > > Here's the response: > > HTTP/2 200 > last-modified: Fri, 02 Jul 2021 02:46:55 GMT > etag: "a1d5ea7e796f5da6980bed86a8396664" > content-type: image/jpeg > cache-control: public, max-age=31536000 > accept-ranges: bytes > date: Fri, 02 Jul 2021 06:44:39 GMT > access-control-allow-methods: GET, OPTIONS > access-control-allow-origin: * > content-length: 110220 > > The "content-type" header can be used for the SIMS <media-type> tag and > the "content-length" header for the <size>. > > The server also responds with an "etag" header, which can be used for > caching, but unfortunately not for integrity checking, since the method > by which it's generated is not specified. > If the etag is passed along via SIMS (instead of the hash), the > receiving client could also check whether it matches what's returned by > the webserver, although I'm not sure what conclusions can be drawn if > they don't match. > > Before someone says that this scenario is not relevant to what SIMS is > trying to do, please note that this problem also occurs when someone > shares a file via HTTP upload and then the receiving party copies and > pastes that URL in a message to someone else. Perhaps an intelligent > enough client might go and get the hash from the original SIMS data and > then add that to the newly sent message, but that seems a bit contrived > to me and might not always be feasible. > > So... back to the scenario. After Romeo's client has received the HEAD > headers, it can then construct a SIMS element with it. > > > <messageto='[email protected]'from='[email protected]'><body>Look > at this funny cat > > picture</body><referencexmlns='urn:xmpp:reference:0'begin='17'end='20'type='data'><media-sharingxmlns='urn:xmpp:sims:1'><filexmlns='urn:xmpp:jingle:apps:file-transfer:5'><media-type>image/jpeg</media-type><name>icanhazcheeseburger.jpg</name><size>110220</size><headersxmlns=' > http://jabber.org/protocol/shim'><headername='ETag'>some-long-opaque-string</header></headers><desc>Fat > > cat that looks like it wants a > > cheeseburger</desc></file><sources><referencexmlns='urn:xmpp:reference:0'type='data'uri=' > https://funnypics.com/icanhazcheeseburger.jpg'/ > ></sources></media-sharing></reference></message> > > > Note the inclusion of the ETag header (as defined in "XEP-0150: Use of > Entity Tags in XMPP Extensions") and the omission of a XEP-0300 hash > element. > > If, for some reason the content-type and content-length headers can't be > used for the <size> and <media-type> tags, then they can also be > included as XEP-0131 headers (like the Etag). > > So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash > requirement gets relaxed to a SHOULD and that the inclusion of the Etag > header be documented as an alternative in case a hash is not feasible. > There might also be cases where neither a hash or an Etag header is > available. > > I'd be happy to make the necessary changes and submit a pull request. > > Regards > JC > > > > > > > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
