[Standards] Proposed XMPP Extension: Explicit Message Encryption

Emmanuel Gil Peyrot linkmauve at linkmauve.fr
Thu Aug 18 11:09:25 UTC 2016

On Wed, Aug 17, 2016 at 09:19:01PM -0500, Sam Whited wrote:
> On Wed, Aug 17, 2016 at 1:48 PM, Emmanuel Gil Peyrot
> <linkmauve at linkmauve.fr> wrote:
> > The rationale for the presence of this name attribute is to have a
> > placeholder in case the client doesn’t know anything about the
> > encryption method in question.
> Yes, I understand the point, however, I don't think it covers that use
> case very well in its current form (see the objections from my earlier
> email).

My main fear is that this would bloat the message, since this will
eventually be included in every single encrypted message.

> If this feature is really desired I think that both the implementation
> needs to be changed (to account for i18n) and the examples need to be
> changed (to eg. show a list instead of using a sentence that includes
> the text since there's no good way to ensure that if the word is used
> in a sentence that it will end up being gramatically correct.

i18n here would only be a concern for future encryption mechanisms that
don’t exist already, since the existing ones could already have the
full sentences translated and QA’d, and @name ignored.

On that basis, maybe I could make @name optional, as in “MAY NOT be
included for those three XEPs already listed”, “SHOULD for any
mechanism not listed here”, and “SHOULD be ignored on a received
message if you already have a correct name for it and can present it to
the user”?

Anyway, no matter the solution chosen, I will include the reasoning and
other solutions that have not been taken in the next revision of this

> Alternatively, Instead of an encryption name, maybe we should just use
> a <text> element with an xml:lang attribute like many other XEPs do (eg. various
> types of errors). This text element would contain a fallback message
> instead of just the name, making the fallback the responsibility of
> the client sending the encrypted message instead of the client that
> can't receive the encrypted message. Either way both clients sitll
> have to support this XEP for this to work (to display the fallback),
> but this way the data is sent by one client (the one that sent the
> encrypted message) instead of part of the data being sent by that
> client (the name) and part of the data residing on the receiving
> client (the rest of the sentence) which feels messy.

In every case except OTR, the sending client already included that
sentence in the body of the message, potentially in multiple versions
with @xml:lang, for legacy clients.  If the receiving client decides to
do so, it could use this body instead of making a sentence itself, like
every current client does when they don’t understand a specific
encryption scheme.

The very reason for the existence of this XEP is to make it machine-
readable, that is to allow for a better representation in every case,
to allow for better interaction with the user, and that includes i18n
directly in the receiving client instead of in the sending one.

Maybe a future XEP could be written to retrieve a list of all of the
possible translations associated with a particular namespace, in which
the receiving client would trust the emitting client with that, and
would then use it for any incoming encrypted message.


Emmanuel Gil Peyrot

More information about the Standards mailing list