> http://logs.xmpp.org/council/2018-06-06/#15:01:24

> 3) Proposed XMPP Extension: OMEMO Media sharing - 
> https://xmpp.org/extensions/inbox/omemo-media-sharing.html

This is a horrible protocol. Seriously. Still, it is better to have a
horrible protocol documented than to pass it on as tribal knowledge, so
I'm not going to -1 this on *formal* grounds. I have no hard feelings
regarding whether this should be "Informational" or "Historical" or just
a page on our wiki.

However, I have some objections on the protocol spec itself, in the
order of severity:

- the receiving side needs to determine whether the message contains "a
  valid aesgcm URL". While "contain" is not the same as "consist of",
  the question alone of what is a valid URL requires significant
  research and implementation effort. I already see implementations
  handling this by `if body.startsWith("aesgcm://")`
- The spec fails to address the typical failure scenarios:
  - what if the aesgcm URL is invalid?
  - what if the HTTP request fails permanently (file deleted)
  - what if the decryption of the downloaded file fails
  (that said, there is really no description for how to do the receiving
  side, besides of determining URL validity)
- The authentication tag size is not specified
- it is not clear from this spec whether key size and IV size are
  parameters to AES-GCM chosen by the XEP author or inherent properties
  of AES-GCM
- it is not defined what an "OMEMO message" is, I had to read that up in
  0384, where it is not formally defined either

The first three are my reasons for -1ing this XEP, but as there are
multiple other -1s, I'm not sure what you'll make of it.

> 4) Proposed XMPP Extension: Ephemeral Messages - 
> https://xmpp.org/extensions/inbox/ephemeral-messages.html

-1 because I'm really not convinced of the need for a dedicated
<ephemeral> element around the body (and how to handle other elements of
the <message>), and because this interfaces poorly with multi-client
scenarios. The latter is not per-se a problem of this XEP, but of the
sad state of Hints and the practical irrelevance of <no-permanent-store/>


Georg

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to