moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

more bis cleanup

This commit is contained in:
stpeter 2011-05-11 09:36:22 -06:00
parent d951d1fb8d
commit 1a157e8663
4 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0247.xml
View File

@ -148,7 +148,7 @@
to='juliet@capulet.lit/balcony'
version='1.0'>
]]></example>
<p>Note: In accordance with &rfc3921bis;, the initial stream header SHOULD include the 'to' and 'from' attributes, which SHOULD specify the full JIDs of the clients. If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in <cite>RFC 3920</cite>, then it SHOULD include the version='1.0' flag as shown in the previous example.</p>
<p>Note: In accordance with &xmppim;, the initial stream header SHOULD include the 'to' and 'from' attributes, which SHOULD specify the full JIDs of the clients. If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in <cite>RFC 3920</cite>, then it SHOULD include the version='1.0' flag as shown in the previous example.</p>
<example caption="Initial stream header (encoded in IBB) and IQ-result"><![CDATA[
<iq from='romeo@montague.net/orchard'
id='ur73n153'

2
xep-0280.xml
View File

@ -234,7 +234,7 @@
Carbons, clients MAY choose to always send chat type messages to
the bare JID. Until then, traditional resource locking is
RECOMMENDED. (Note: another XEP might be written to document
traditional resource locking, if the documentation in &rfc3921bis;
traditional resource locking, if the documentation in &xmppim;
is not sufficient.)</p>
<p>Also note that &xep0085; recommends sending chat state

2
xep-0295.xml
View File

@ -83,7 +83,7 @@
{"s":"<message to='alice@wonderland.lit' id='if00lu'><body>Hi you</body><body xml:lang='cy'>Prynhawn da</body><nick xmlns='http://jabber.org/protocol/nick'>Alice</nick><active xmlns='http://jabber.org/protocol/chatstates'/></message>"}
]]></example>
<p>To use this improved encoding (eminently suitable both for c2s and s2s connections), entities should follow the connection rules defined in &xmppcorebis; and immediately start sending JSON-encoded data. Receiving entities should detect the presence of an open-brace ('{') character as the first octet received on a stream to be a signal to continue with JSON encoding. Servers supporting only the legacy XML encoding will necessarily respond with an error when receiving the improved JSON format, and entities will know to reconnect and continue with the legacy format.</p>
<p>To use this improved encoding (eminently suitable both for c2s and s2s connections), entities should follow the connection rules defined in &xmppcore; and immediately start sending JSON-encoded data. Receiving entities should detect the presence of an open-brace ('{') character as the first octet received on a stream to be a signal to continue with JSON encoding. Servers supporting only the legacy XML encoding will necessarily respond with an error when receiving the improved JSON format, and entities will know to reconnect and continue with the legacy format.</p>
</section1>
<section1 topic='Examples' anchor='examples'>
<p>Hopefully the beauty of this approach will be apparent at this stage, but in case some lingering doubts remain (and with the hope of aiding interoperability), more examples are provided here:</p>

2
xep-0296.xml
View File

@ -43,7 +43,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Section 5.1 of &rfc3921bis; defines the concept of a "one-to-one chat session" and recommends that clients support the behavior described there, including:</p>
<p>Section 5.1 of &xmppim; defines the concept of a "one-to-one chat session" and recommends that clients support the behavior described there, including:</p>
<ol>
<li>Send the first message in a chat session to the bare JID &LOCALBARE; of the intended recipient</li>
<li>Send messages to the full JID &LOCALFULL; only after receiving a reply from the recipient (this is called "locking" into that full JID).</li>