typo

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2093 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0134.xml

@@ -58,7 +58,7 @@
     <p><em>Background</em></p>
     <p>When the &XSF; submitted the <cite>XMPP Core</cite> and <cite>XMPP IM</cite> specifications to the &IETF;, it ceded change control over the core XML streaming technology developed by the Jabber community. However, the XSF has reserved the right to define extensions to XMPP; furthermore, that right is not exclusive to the XSF, since anyone can define their own public or private extensions to XMPP. These extensions are usually in the form of structured XML data that is qualified by a unique namespace other than those currently reserved by the IETF or the XSF.</p>
     <p><em>Meaning</em></p>
-    <p>When we say that "XMPP is Sacred", we mean that good protocol design must work within the context of XMPP and not require changes to the core protocols. For one thing, any such changes would need to be pursued within the IETF. Further, the core semantics most likely provide everything that a protocol designer needs. If you think that you need to define a new kind of top-level stanza (other than &MESSAGE;, &PRESENCE;, and &IQ;) or a new value of the 'type' attribute for any stanza kind, then you need to think again. Treat XMPP as a transport layer and build extensions on top of that layer (among other things, this implies that you must not modify the foundation when you are working on higher-level structures, for example by adding adding elements and attributes to the XMPP schemas on the theory that if applications will ignore them; define your own extensions in a separate namespace). A further implication of respecting XMPP is using structured data formats (e.g., applications of &w3xml; rather than binary or plaintext formats) whenever possible. Finally, as explained in <cite>XMPP Core</cite>, the &PRESENCE; stanza exists to broadcast network and communications availability only; for more advanced information publishing, use &xep0060;.</p>
+    <p>When we say that "XMPP is Sacred", we mean that good protocol design must work within the context of XMPP and not require changes to the core protocols. For one thing, any such changes would need to be pursued within the IETF. Further, the core semantics most likely provide everything that a protocol designer needs. If you think that you need to define a new kind of top-level stanza (other than &MESSAGE;, &PRESENCE;, and &IQ;) or a new value of the 'type' attribute for any stanza kind, then you need to think again. Treat XMPP as a transport layer and build extensions on top of that layer (among other things, this implies that you must not modify the foundation when you are working on higher-level structures, for example by adding elements and attributes to the XMPP schemas on the theory that if applications will ignore them; define your own extensions in a separate namespace). A further implication of respecting XMPP is using structured data formats (e.g., applications of &w3xml; rather than binary or plaintext formats) whenever possible. Finally, as explained in <cite>XMPP Core</cite>, the &PRESENCE; stanza exists to broadcast network and communications availability only; for more advanced information publishing, use &xep0060;.</p>
     <p><em>Examples</em></p>
     <p>A good example of honoring the XMPP specifications is &xep0126;; while the Jabber community had informally defined &lt;presence type='invisible'/&gt; at one point, that protocol was abandoned in favor of an XMPP-compliant approach. Another example is &xep0071;, which re-uses &w3xhtml; (a structured format that shares with XMPP a common root in XML) rather than &rtf; (an unstructured format that does not derive from XML). Further examples are the "extended presence" specifications (see &xep0119;), which are built on top of XEP-0060 rather than overloading the &PRESENCE; stanza.</p>
   </section2>