From 0f3629bc87c7bb2b77bdc914e91d454b500f85b8 Mon Sep 17 00:00:00 2001
From: Sam Whited <sam@samwhited.com>
Date: Mon, 14 Nov 2016 13:37:03 -0600
Subject: [PATCH] Clarify text in burner JID protoxep

---
 inbox/burner.xml | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/inbox/burner.xml b/inbox/burner.xml
index 66ac6ac3..ff675569 100644
--- a/inbox/burner.xml
+++ b/inbox/burner.xml
@@ -22,7 +22,7 @@
   </dependencies>
   <supersedes/>
   <supersededby/>
-  <shortname>NOT_YET_ASSIGNED</shortname>
+  <shortname>burner</shortname>
   &sam;
   <revision>
     <version>0.0.1</version>
@@ -36,18 +36,18 @@
     In many XMPP applications it is desirable to be able to act anonymously to
     prevent leaking personally identifiable information (PII) to a third party.
     Traditionally this is accomplished using SASL authentication and the
-    ANONYMOUS mechanism as detailed in &xep0175;, however, ANONYMOUS auth
-    provides no mechanism for changing identities (requesting a new JID) without
-    creating a new session, nor does it provide authentication of users.
+    ANONYMOUS mechanism as detailed in &xep0175;, however, the ANONYMOUS
+    mechanism is in reality an authorization mechanism and does not provide
+    authentication of users.
   </p>
   <p>
     This specification solves these problems by decoupling anonymous identity
-    management from authentication.
+    management from authentication (auth) and authorization (authz).
     This allows logged in users (authenticated or anonymous at the server
     operators disgression) to request a new temporary identifier, a "burner"
     JID, which may be used by its owner to construct a new session with the
-    server that is anonymous to third parties but is (optionally) locally
-    authenticated.
+    server that is authorized to communicate anonymously with third parties and
+    is (optionally) locally authenticated.
   </p>
 </section1>
 <section1 topic='Glossary' anchor='glossary'>
@@ -145,19 +145,20 @@
     to='caiusmarcius@example.net/corioli'
     id='k3hs5174'>
   <query xmlns='http://jabber.org/protocol/disco#info'>
-    <identity category='conference' type='text'/>
-    <identity category='authz' type='ephemeral'/>
+    <identity type='im' name='MyServer' category='server'/>
+    <identity type='pep' name='MyServer' category='pubsub'/>
+    <identity type='ephemeral' category='authz'/>
     …
     <feature var='http://jabber.org/protocol/disco#info'/>
     <feature var='http://jabber.org/protocol/disco#items'/>
     <feature var='http://jabber.org/protocol/muc'/>
-…]]></example>
+    …]]></example>
 </section1>
 <section1 topic='Implementation Notes' anchor='impl'>
   <p>
     It may be impractical to store verification information for every burner JID
     issued by the system.
-    To this end servers that implement this specification may choose to encode
+    To this end servers that implement this specification MAY choose to encode
     information into the localpart of issued burner JIDs which can be verified
     when a user attempts to authorize a new session to use the burner JID.
     If an implementation chooses to do this it is RECOMMENDED that an