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 > <[email protected]> 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 XEP. > > 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. Thanks, -- Emmanuel Gil Peyrot _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
