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='jul...@shakespeare.lit'from='ro...@montague.lit'><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: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to