On Wed, Aug 17, 2016 at 1:48 PM, Emmanuel Gil Peyrot <linkma...@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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
