[Standards] Proposed XMPP Extension: Explicit Message Encryption

Sam Whited sam at samwhited.com
Thu Aug 18 02:19:01 UTC 2016


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).

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.

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.

—Sam


More information about the Standards mailing list