diff --git a/xep-0155.xml b/xep-0155.xml
index b2d62701..5e85427c 100644
--- a/xep-0155.xml
+++ b/xep-0155.xml
@@ -22,14 +22,14 @@
   </dependencies>
   <supersedes/>
   <supersededby/>
-  <shortname>TBD</shortname>
+  <shortname>TO BE ASSIGNED</shortname>
   &ianpaterson;
   &stpeter;
   <revision>
     <version>0.14</version>
-    <date>2006-12-12</date>
+    <date>2006-12-21</date>
     <initials>psa/ip</initials>
-    <remark><p>Specified state chart; added optional presence sharing; harmonized treatment of renegotiation; per XEP-0053, specified use of provisional namespace until spec advances to Draft.</p></remark>
+    <remark><p>Specified state chart; added optional presence sharing; renamed otr field to logging; harmonized treatment of renegotiation; per XEP-0053, specified use of provisional namespace until spec advances to Draft.</p></remark>
   </revision>
   <revision>
     <version>0.13</version>
@@ -168,17 +168,18 @@ PENDING  o---------------+
   <p>[1] A chat session negotiation is initiated when the user sends a message containing a data form of type "form" with an "accept" field.</p>
   <p>[2] A chat session negotiation is accepted when the contact sends a message containing a data form of type "submit" with an "accept" field whose value is "1" or "true".</p>
   <p>[3] A chat session negotiation is rejected when the contact sends a message containing a data form of type "submit" with an "accept" field whose value is "0" or "false".</p>
-  <p>[4] A chat session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "0" or "false".</p>
+  <p>[4] A chat session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "1" or "true".</p>
   <p>[5] A chat session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "0" or "false".</p>
   <p>[6] An existing chat session is re-negotiated when either party sends a message containing a data form of type "form" with a "renegotiate" field whose value is "1" or "true".</p>
   <p>[7] A chat session re-negotiation is accepted when the other party sends a message containing a data form of type "submit" with a "renegotiate" field whose value is "1" or "true".</p>
-  <p>[8] A chat session is terminated when either party sends a message containing a data form of type "submit" with a "terminate" field whose value is "1" or "true".</p>
+  <p>[8] A chat session re-negotiation is rejected when the other party sends a message containing a data form of type "submit" with a "renegotiate" field whose value is "0" or "false"; however, the session remains in the active state with the previously-negotiated parameters in force.</p>
+  <p>[9] A chat session is terminated when either party sends a message containing a data form of type "submit" with a "terminate" field whose value is "1" or "true".</p>
 </section1>
 <section1 topic='Negotiating a New Chat Session' anchor='new'>
   <section2 topic='Initiating a Chat Session' anchor='new-initiate'>
-    <p>In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE; <note>The &MESSAGE; stanza is used because the user does not necessarily know which of the contact's resources is most available (or indeed if the contact is online).</note> stanza to the receiving party ("contact") containing a &lt;feature/&gt; child qualified by the 'http://jabber.org/protocol/feature-neg' namespace. The &MESSAGE; stanza MUST NOT contain a &BODY; child element (as specified in &rfc3921;). The &MESSAGE; stanza type SHOULD be "normal" (either explicitly or by non-inclusion of the 'type' attribute). The stanza MUST contain a &THREAD; element for tracking purposes (where the newly-generated ThreadID is unique to the proposed session). The data form MUST contain a hidden FORM_TYPE field whose value is "http://www.xmpp.org/extensions/xep-0155.html#ns" and MUST contain a boolean field named "accept". &BOOLEANNOTE; The inclusion of "otr", "disclosure" and "security" fields is also RECOMMENDED. Note: The options within any 'list-single' fields SHOULD appear in order of preference.</p>
+    <p>In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE; <note>The &MESSAGE; stanza is used because the user does not necessarily know which of the contact's resources is most available (or indeed if the contact is online).</note> stanza to the receiving party ("contact") containing a &lt;feature/&gt; child qualified by the 'http://jabber.org/protocol/feature-neg' namespace. The &MESSAGE; stanza MUST NOT contain a &BODY; child element (as specified in &rfc3921;). The &MESSAGE; stanza type SHOULD be "normal" (either explicitly or by non-inclusion of the 'type' attribute). The stanza MUST contain a &THREAD; element for tracking purposes (where the newly-generated ThreadID is unique to the proposed session). The data form MUST contain a hidden FORM_TYPE field whose value is "http://www.xmpp.org/extensions/xep-0155.html#ns" and MUST contain a boolean field named "accept". &BOOLEANNOTE; The inclusion of "logging", "disclosure" and "security" fields is also RECOMMENDED. Note: The options within any 'list-single' fields SHOULD appear in order of preference.</p>
     <p>Note: Chat sessions may be conducted between entities who are never online at the same time. However, if the user is interested only in an <em>immediate</em> chat session then the user SHOULD instruct the contact's server not to store the message for later delivery (see &xep0160;) using the &xep0079; protocol.</p>
-    <p>In the following example of a negotiation request, Romeo requests a chat with Juliet and also queries her regarding whether she wants to enable all message logging (see &xep0136;) <note>A client MUST NOT set the 'otr' field to 'true' unless it has confirmed that its server will allow it to switch off Automated Archiving (see <cite>Message Archiving</cite>).</note> and support the &xep0071; and &xep0085; extensions during this chat session. He asks Juliet's client if it is prepared to make a (legally binding) guarantee that it does not intentionally implement any feature (not even a disabled feature) that might disclose the content of the chat, any associated (decryption) keys or his identity to any third-party (see <cite>Encrypted Session Negotiation</cite>). He also requires that they are both connected securely to their servers, and asks which language she prefers amoungst those he can write. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.)</p>
+    <p>In the following example of a negotiation request, Romeo requests a chat with Juliet and also queries her regarding whether she is able to disallow all message logging (see &xep0136;) <note>A client MUST NOT set the 'logging' field to 'mustnot' unless it has confirmed that its server will allow it to switch off Automated Archiving (see <cite>Message Archiving</cite>).</note>, whether she wants to temporarily share presence for this session (see the <link url='#impl-presence'>Sharing Presence</link> section of this document), and whether she wants to support the &xep0071; and &xep0085; extensions during this chat session. He asks Juliet's client if it is prepared to make a (legally binding) guarantee that it does not intentionally implement any feature (not even a disabled feature) that might disclose the content of the chat, any associated (decryption) keys, or his identity to any third-party (see <cite>Encrypted Session Negotiation</cite>). He also requires that they are both connected securely to their servers, and asks which language she prefers amongst those he can write. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.)</p>
     <example caption="User requests chat session"><![CDATA[
 <message type='normal'
          from='romeo@montague.net/orchard'
@@ -194,7 +195,7 @@ PENDING  o---------------+
         <value>true</value>
         <required/>
       </field>
-      <field label='Message logging' type='list-single' var='otr'>
+      <field label='Message logging' type='list-single' var='logging'>
         <value>mustnot</value>
         <option label='Allow message logging'>
           <value>may</value>
@@ -279,13 +280,13 @@ PENDING  o---------------+
         <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
       </field>
       <field var='accept'><value>true</value></field>
-      <field var='otr'><value>0</value></field>
-      <field var='disclosure'><value>never</value></field>
+      <field var='logging'><value>mustnot</value></field>
+      <field var='disclosure'><value>mustnot</value></field>
       <field var='http://jabber.org/protocol/xhtml-im'>
-        <value>0</value>
+        <value>may</value>
       </field>
       <field var='http://jabber.org/protocol/chatstates'>
-        <value>0</value>
+        <value>may</value>
       </field>
       <field var='security'><value>c2s</value></field>
       <field var='language'><value>it</value></field>
@@ -350,7 +351,7 @@ PENDING  o---------------+
   <error code='501' type='cancel'>
     <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     <feature xmlns='http://jabber.org/protocol/feature-neg'>
-      <field var='otr'/>
+      <field var='logging'/>
     </feature>
   </error>
 </message>
@@ -466,10 +467,10 @@ PENDING  o---------------+
         <value>1</value>
         <required/>
       </field>
-      <field label='Message logging' type='list-single' var='otr'>
+      <field label='Message logging' type='list-single' var='logging'>
         <value>mustnot</value>
         <option label='Disallow all message logging'>
-          <value>mustnot</value>
+          <value>may</value>
         </option>
         <required/>
       </field>
@@ -490,7 +491,7 @@ PENDING  o---------------+
         <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
       </field>
       <field var='renegotiate'><value>1</value></field>
-      <field var='otr'><value>1</value></field>
+      <field var='logging'><value>may</value></field>
     </x>
   </feature>
 </message>
@@ -510,7 +511,7 @@ PENDING  o---------------+
         <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
       </field>
       <field var='renegotiate'><value>0</value></field>
-      <field var='otr'><value>1</value></field>
+      <field var='logging'><value>may</value></field>
     </x>
   </feature>
 </message>
@@ -590,13 +591,16 @@ PENDING  o---------------+
   </section2>
   <section2 topic='Localization' anchor='secure-local'>
     <p>If a client is configured to show a request &lt;form/&gt; to a human user instead of responding automatically, it SHOULD replace the content of the &lt;title/&gt; element and of all label attributes of the known and registered &lt;field/&gt; and &lt;option/&gt; elements with its own localised versions before showing the form to the user -- even if the form already appears to be in the correct language.</p>
-    <p>Note: If a client fails to localize the form, a malicious contact might, for example, either switch the labels on the 'security' and 'otr' fields, or use the &lt;title/&gt; to mislead the user regarding the identity of the contact.</p>
+    <p>Note: If a client fails to localize the form, a malicious contact might, for example, either switch the labels on the 'security' and 'logging' fields, or use the &lt;title/&gt; to mislead the user regarding the identity of the contact.</p>
   </section2>
 </section1>
 <section1 topic='IANA Considerations' anchor='iana'>
   <p>This document requires no interaction with &IANA;.</p>
 </section1>
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <section2 topic='Protocol Namespaces' anchor='ns'>
+    <p>Until this specification advances to a status of Draft, its associated namespace (as used in the negotiation FORM_TYPE) shall be "http://www.xmpp.org/extensions/xep-0155.html#ns"; upon advancement of this specification, the XMPP Registrar shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
+  </section2>
   <section2 topic='Service Discovery Features' anchor='registrar-features'>
     <p>The &REGISTRAR; shall include 'http://www.xmpp.org/extensions/xep-0155.html#ns' in its registry of Service Discovery features.</p>
     <code caption='Registry Submission'><![CDATA[
@@ -670,14 +674,14 @@ PENDING  o---------------+
              value appears in order of preference and
              conforms to RFC 4646 and the IANA registry)'/>
   <field
-      var='otr'
+      var='logging'
       type='list-single'
       label='Whether allowed to log messages (i.e., 
              whether Off-The-Record mode is required)'>
-    <option label='May Log Messages'>
+    <option label='Allow Message Logging'>
       <value>may</value>
     </option>
-    <option label='Must Not Log Messages (i.e., must 
+    <option label='Disallow All Message Logging (i.e., must 
                    disable absolutely all message
                    logging including automatic archiving
                    -- see XEP-0136'>
@@ -716,7 +720,4 @@ PENDING  o---------------+
 <section1 topic='Acknowledgements' anchor='ack'>
   <p>Thanks to Thomas Charron and Jean-Louis Seguineau for their feedback.</p>
 </section1>
-<section1 topic='Namespace' anchor='ns'>
-  <p>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0155.html#ns"; upon advancement of this specification, the XMPP Registrar shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
-</section1>
 </xep>