Merge pull request #241 from linkmauve/eme

Explicit Message Encryption ProtoXEP: Add a 0.0.2 version
xsf · Oct 26, 2016 · 557c240 · 557c240
2 parents b5f978c + bddc7bd
commit 557c240
Showing 1 changed file with 39 additions and 14 deletions.
diff --git a/inbox/eme.xml b/inbox/eme.xml
@@ -29,6 +29,20 @@
     <email>linkmauve@linkmauve.fr</email>
     <jid>linkmauve@linkmauve.fr</jid>
   </author>
+  <revision>
+    <version>0.0.2</version>
+    <date>2016-08-28</date>
+    <initials>egp</initials>
+    <remark><ul>
+      <li>Made the 'name' attribute optional for existing mechanisms.</li>
+      <li>Added a remark about the possibility to hide encrypted messages
+        following user input.</li>
+      <li>Made explicit that this protocol affects any encryption mechanism,
+        present or future, not only those listed here.</li>
+      <li>Display the namespace of the encryption mechanism in the default
+        messages.</li>
+    </ul></remark>
+  </revision>
   <revision>
     <version>0.0.1</version>
     <date>2016-08-14</date>
@@ -77,7 +91,6 @@
          id='secret1'>
   <body>?OTR?v23?...</body>
   <encryption xmlns='urn:xmpp:eme:0'
-              name='OTR'
               namespace='urn:xmpp:otr:0'/>
 </message>
 ]]></example>
@@ -86,7 +99,8 @@
     display that the message was encrypted but that it is not able to decrypt
     it instead of displaying the body, for example:</p>
   <div class='example'>
-    <p>🔒 This message was encrypted with OTR and could not be decrypted.</p>
+    <p>🔒 This message was encrypted with OTR (urn:xmpp:otr:0) and could not be
+      decrypted.</p>
   </div>
 
   <p>Juliet may then communicate to Romeo that she was unable to receive his
@@ -104,25 +118,26 @@
   </openpgp>
   <body>This message is encrypted with OpenPGP for XMPP.</body>
   <encryption xmlns='urn:xmpp:eme:0'
-              name='OpenPGP for XMPP'
               namespace='urn:xmpp:openpgp:0'/>
 </message>
 ]]></example>
 
   <p>Upon receiving this message, Juliet’s current client prompts her to enable
     a plugin, or even do it on its own, possible representations include:</p>
   <div class='example'>
-    <p>🔒 This message was encrypted with OpenPGP for XMPP, <link url="#">click
-      here</link> to enable this plugin.</p>
-  </div>
-  <div class='example'>
-    <p>🔒 This message was encrypted with OpenPGP for XMPP, downloading and
-      installing an appropriate plugin, your message will be displayed
-      shortly.</p>
+    <p>🔒 This message was encrypted with OpenPGP for XMPP
+      (urn:xmpp:openpgp:0), <link url="#">click here</link> to enable this
+      plugin.</p>
   </div>
 </section2>
 
 <section2 topic='Protocols Supported' anchor='protocols'>
+  <p>Any encryption mechanism using message as a transport is a candidate, and
+    MAY have a 'name' attribute to help the receiving client display it to the
+    user, in case this client doesn’t understand its namespace yet.  A 'name'
+    attribute SHOULD NOT be included for the protocols listed herein, and
+    SHOULD be ignored by a receiving client:</p>
+
   <table>
     <tr>
       <th>Name</th>
@@ -156,7 +171,7 @@
   <p>If an entity supports the Encrypted Message Extension protocol, it MUST
     report that by including a &xep0030; feature of "urn:xmpp:eme:0" in
     response to disco#info requests:</p>
-<example caption='Client queries for entity features'><![CDATA[
+  <example caption='Client queries for entity features'><![CDATA[
 <iq type='get'
     id='disco1'
     to='juliet@capulet.lit/balcony'
@@ -165,7 +180,7 @@
 </iq>
 ]]></example>
 
-<example caption='Entity responds with features'><![CDATA[
+  <example caption='Entity responds with features'><![CDATA[
 <iq type='result'
     id='disco1'
     to='romeo@montague.lit/orchard'
@@ -195,12 +210,22 @@
     recipient doesn’t advertise support for it in their disco, or isn’t
     currently connected, since the recipient may be using multiple clients with
     different capabilities.</p>
+  <p>A sender entity MAY include a 'name' attribute for any encryption
+    mechanism not listed in this specification, to help the receiving entity
+    present it to the user, but SHOULD NOT include one for the ones listed
+    here.</p>
+  <p>A receiving entity MUST NOT use the 'name' attribute if it is present and
+    they already have a name associated with it.</p>
+  <p>A receiving entity MAY not display anything in case an encrypted message
+    has been received, if the user agreed to that behaviour.</p>
 </section1>
 
 <section1 topic='Internationalization Considerations' anchor='i18n'>
   <p>When a message is marked with an encryption tag and can not be decrypted,
     the body can safely be ignored and a localized message displayed
     instead.</p>
+  <p>If an entity includes a 'name' attribute, it should attempt to localise it
+    to the best of its abilities for the receiving client.</p>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>
@@ -216,7 +241,7 @@
 
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
-	<p>This specification defines the following XML namespace:</p>
+    <p>This specification defines the following XML namespace:</p>
     <ul>
       <li>'urn:xmpp:eme:0'</li>
     </ul>
@@ -241,8 +266,8 @@
 
   <xs:element name="encryption">
     <xs:complexType>
-      <xs:attribute type="xs:string" use="required" name="name"/>
       <xs:attribute type="xs:string" use="required" name="namespace"/>
+      <xs:attribute type="xs:string" use="optional" name="name"/>
     </xs:complexType>
   </xs:element>