From 6188a429510bb3476d17872ac54b959a4f3ba2c0 Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre <stpeter@stpeter.im>
Date: Thu, 10 Oct 2013 16:46:39 -0600
Subject: [PATCH] 0.0.2

---
 inbox/json-containers.xml | 41 ++++++++++++++++++++++++++-------------
 1 file changed, 27 insertions(+), 14 deletions(-)

diff --git a/inbox/json-containers.xml b/inbox/json-containers.xml
index 47d900e2..921fe3ad 100644
--- a/inbox/json-containers.xml
+++ b/inbox/json-containers.xml
@@ -22,11 +22,18 @@
   <approver>Council</approver>
   <dependencies>
     <spec>XMPP Core</spec>
+    <spec>RFC 4627</spec>
   </dependencies>
   <supersedes/>
   <supersededby/>
   <shortname>NOT_YET_ASSIGNED</shortname>
   &mwild;
+  <revision>
+    <version>0.0.2</version>
+    <date>2013-10-09</date>
+    <initials>mw</initials>
+    <remark><p>Update namespace to urn:xmpp:json:0, add requirement for encapsulation within other protocols, and require conformance to RFC 4627.</p></remark>
+  </revision>
   <revision>
     <version>0.0.1</version>
     <date>2012-11-15</date>
@@ -40,27 +47,32 @@
   <p>This document aims to solve the problem by defining a standard way to embed JSON into any XMPP stanza, and even allowing its use with existing XMPP protocols where possible.</p>
 </section1>
 <section1 topic='Requirements' anchor='reqs'>
-  <p>This specication should:</p>
+  <p>This specification should:</p>
   <ul>
     <li>Allow stanza generators to unambiguously embed JSON within their stanzas.</li>
     <li>Allow stanza recipients a way to identify JSON content, and thus also validation.</li>
   </ul>
 </section1>
 <section1 topic='Use Cases' anchor='usecases'>
-  <p>Since JSON generally isn't designed for end-user presentation, most use-cases centre around JSON as part of machine-to-machine communication, or as part of a higher protocol.</p>
-  <example caption='Sending JSON inside a message'><![CDATA[
-    <message to="recipient@example.com" from="sender@example.com">
-      <json xmlns="urn:xmpp:json:tmp">
-        { "name": "romeo", "age": "421", "status": "single" }
-      </json>
-    </message>
+  <p>Since JSON generally isn't designed for end-user presentation, most use-cases centre around JSON as part of machine-to-machine communication, or as part of a higher protocol, such as &xep0060;.</p>
+  <example caption='JSON as a pubsub item payload'><![CDATA[
+    <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
+     <event xmlns='http://jabber.org/protocol/pubsub#event'>
+       <items node='princely_musings'>
+         <item id='ae890ac52d0df67ed7cfdf51b644e901'>
+           <json xmlns="urn:xmpp:json:0">
+           { "name": "romeo", "age": "421", "status": "single" }
+           </json>
+         </item>
+       </items>
+     </event>
+   </message>
   ]]></example>
 
-  <p>Outside of closed systems, it is much more desirable to place the JSON element within some greater context, for example as part of another protocol.</p>
-  <example caption='Sending JSON as part of another protocol'><![CDATA[
+  <example caption='JSON as part of a custom protocol'><![CDATA[
     <iq to="recipient.example.com" type="get" id="q1">
       <query xmlns="http://example.com/user-queries">
-        <json xmlns="urn:xmpp:json:tmp">
+        <json xmlns="urn:xmpp:json:0">
           { "name": "romeo" }
         </json>
       </query>
@@ -69,8 +81,9 @@
 
 </section1>
 <section1 topic='Business Rules' anchor='rules'>
-  <p>The &lt;json&gt; element MUST only contain character data, and the data MUST conform to the <link url='http://json.org/'>JSON specification</link>. Specifically, the element MUST NOT be empty, as the empty string is not valid JSON. The data MUST be encoded as UTF-8 (though officially unspecified, this is the de facto encoding for JSON today).</p>
+  <p>The &lt;json&gt; element MUST only contain character data, and the data MUST conform to &rfc4627;. Specifically, the element MUST NOT be empty, as the empty string is not valid JSON. The data MUST be encoded as UTF-8 (though officially unspecified, this is the de facto encoding for JSON today).</p>
   <p>Implementations SHOULD validate JSON they receive and intend to use, and be prepared to handle invalid data appropriately (such as by responding to the sender with the applicable XMPP error reply for the stanza type).</p>
+  <p>As the &lt;json&gt; element alone provides no context to the recipient about the kind of data it contains, only the format, it SHOULD always be encapsulated within another element that provides a context and SHOULD NOT be added as a direct child of a stanza.</p>
 </section1>
 <section1 topic='Implementation Notes' anchor='notes'>
   <p>The JSON container element is intended for communicating small pieces of generic JSON data within a particular context. XMPP entities MUST NOT attempt to interpret unexpected JSON data they receive, and servers SHOULD NOT inspect JSON data inside stanzas they are routing, other than for OPTIONAL validation.</p>
@@ -93,8 +106,8 @@
 
 <xs:schema
     xmlns:xs='http://www.w3.org/2001/XMLSchema'
-    targetNamespace='urn:xmpp:json:tmp'
-    xmlns='urn:xmpp:json:tmp'
+    targetNamespace='urn:xmpp:json:0'
+    xmlns='urn:xmpp:json:0'
     elementFormDefault='qualified'>
 
   <xs:annotation>