moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 02:32:18 -05:00
Code Issues Releases Wiki Activity

typo

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@446 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-30 17:00:56 +00:00
parent 813b580084
commit 10d3c5f583
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0134.xml
View File

@ -60,7 +60,7 @@
<p><em>Meaning</em></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 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><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" speficiations (see &xep0119;), which are built on top of XEP-0060 rather than overloading the &PRESENCE; stanza.</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> </section2>
<section2 topic='Keep Clients Simple' anchor='simple'> <section2 topic='Keep Clients Simple' anchor='simple'>
<p><em>Background</em></p> <p><em>Background</em></p>