Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-09-02 Thread Emmanuel Gil Peyrot
Hi, On Thu, Sep 01, 2016 at 08:40:24PM -0600, Peter Saint-Andre wrote: […] > > The name metadata should either be qualified by a lang or simply be > > removed. I feel like removing is the right thing: Clients/Libraries > > either know the encryption mechanism by its namespace, and are possible >

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-28 Thread Emmanuel Gil Peyrot
Hello, I proposed a newer version[1] which tried to fix every piece of feedback I received on this thread and elsewhere, direct or indirect, please comment. :) I chose to keep the 'name' attribute, but made it optional, and let i18n issues be determined by the sending client if it wants to add

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-22 Thread Florian Schmaus
On 17.08.2016 20:48, Emmanuel Gil Peyrot wrote: > On Wed, Aug 17, 2016 at 01:31:28PM -0500, Sam Whited wrote: >> Having the name be an attribute doesn't seem very friendly to me. What >> if I want it in a different language or locale? How do RTL languages >> work? Even if we assume everything is

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-18 Thread Dave Cridland
On 18 Aug 2016 13:00, "Kim Alvefur" wrote: > > On 2016-08-18 13:09, Emmanuel Gil Peyrot wrote: > > 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

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-18 Thread Kim Alvefur
On 2016-08-18 13:09, Emmanuel Gil Peyrot wrote: > 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

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-18 Thread Emmanuel Gil Peyrot
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 > 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 > >

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-17 Thread Sam Whited
On Wed, Aug 17, 2016 at 1:48 PM, Emmanuel Gil Peyrot 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

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-17 Thread Dave Cridland
This one looks broadly sensible to me. I'll miss next week's council meeting unfortunately, so this email can constitute no objection to publication from me. On 17 Aug 2016 17:39, "XMPP Extensions Editor" wrote: > The XMPP Extensions Editor has received a proposal for a new

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-17 Thread Emmanuel Gil Peyrot
On Wed, Aug 17, 2016 at 01:31:28PM -0500, Sam Whited wrote: > Having the name be an attribute doesn't seem very friendly to me. What > if I want it in a different language or locale? How do RTL languages > work? Even if we assume everything is always English, what if my text > doesn't work well

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

2016-08-17 Thread Sam Whited
Having the name be an attribute doesn't seem very friendly to me. What if I want it in a different language or locale? How do RTL languages work? Even if we assume everything is always English, what if my text doesn't work well with all names "an [OTR] encrypted message" works fine, but "an [PGP]