This commit is contained in:
stpeter 2011-10-06 16:04:45 -06:00
parent 9277d89c8e
commit 57fa0c2086
1 changed files with 15 additions and 2 deletions

View File

@ -29,6 +29,12 @@
<email>dj.adams@pobox.com</email>
<jid>dj@gnu.mine.nu</jid>
</author>
<revision>
<version>2.2rc1</version>
<date>2011-10-06</date>
<initials>psa</initials>
<remark>Corrected element name in XML schema from "Base64" to "base64".</remark>
</revision>
<revision>
<version>2.1</version>
<date>2006-02-09</date>
@ -64,6 +70,7 @@
<p>The &IQ; stanza contains a single &QUERY; sub-element in the jabber:iq:rpc namespace. The direct child of the &QUERY; element will be either a single &lt;methodCall/&gt; element (in the case of a request) or a single &lt;methodResponse/&gt; element (in the case of a response). This child element will contain the XML-RPC payload. Note that the XML declaration that normally appears at the head of an XML-RPC request or response when transported as the payload of an HTTP POST request MUST BE omitted when it is transported via a Jabber &IQ; stanza.</p>
<p>The encoding of the Jabber XML stream is UTF-8. It is assumed that the encoding of the XML-RPC payload is also UTF-8.</p>
<p>Application-level errors will be indicated within the XML-RPC payload (as is the case with the traditional HTTP-based XML-RPC mechanism). Transport level errors will be indicated in the normal way for &IQ; stanzas -- namely, by an &IQ; stanza of type "error" and the addition of an &lt;error/&gt; tag as a direct child of the &IQ; stanza. There are no specific XML-RPC-related, transport-level errors.</p>
<p class='box'>In September of 2011, it was discovered that the XML schema quoted in <link url='#schema'>Section 8</link> contains an error, showing a child element of &lt;Base64/&gt; (uppercase "B") instead of &lt;base64/&gt; (lowercase "b"). A review of the XML-RPC specification and of numerous XML-RPC and Jabber-RPC implementations showed that the element name is properly "base64" and that the borrowed schema was in error by having an element name of "Base64". Therefore this specification was modified to use the correct element name: "base64". It is possible that some existing Jabber-RPC implementations might send a child element of &lt;Base64/&gt;.</p>
</section1>
<section1 topic='Examples'>
<example caption='A typical request'><![CDATA[
@ -157,7 +164,7 @@
<p>The XMPP Registrar includes a Service Discovery type of "rpc" within the "automation" category in its registry of service discovery identities.</p>
</section2>
</section1>
<section1 topic='XML Schema'>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
@ -263,7 +270,13 @@
<xs:element name="int" type="xs:int"/>
<xs:element name="string" type="ASCIIString"/>
<xs:element name="double" type="xs:decimal"/>
<xs:element name="Base64" type="xs:base64Binary"/>
<xs:element name="base64" type="xs:base64Binary">
<xs:annotation>
<xs:documentation>
Corrected from "Base64" to "base64" in version 2.2 of XEP-0009.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="boolean" type="NumericBoolean"/>
<xs:element name="dateTime.iso8601" type="xs:dateTime"/>
<xs:element name="array" type="ArrayType"/>