On 02.07.21 12:42, Sergey Ilinykh wrote:
What about a slightly different scenario?
Romeo sees a funny picture on funnypics.com <http://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.
Yeah, I'd be quite annoyed if I shared a link to a video and my client
first insists on downloading the entire file so that it can send out a
hash to the recipient.
-JC
пт, 2 июл. 2021 г. в 13:17, JC Brand <[email protected]
<mailto:[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
<http://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
<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'/
<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
<https://mail.jabber.org/mailman/listinfo/standards>
Unsubscribe: [email protected]
<mailto:[email protected]>
_______________________________________________
_______________________________________________
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]
_______________________________________________
