aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorstpeter <stpeter@stpeter.im>2011-05-11 09:36:22 -0600
committerstpeter <stpeter@stpeter.im>2011-05-11 09:36:22 -0600
commit1a157e8663be3641cf3f200a3039e3f9b5a250cd (patch)
treee657e59bfed7bd70f5954fe4a0d4ad9989dc2f25
parentd951d1fb8d278e3cff9b348ffdeefda46e79e233 (diff)
more bis cleanup
-rw-r--r--xep-0247.xml2
-rw-r--r--xep-0280.xml2
-rw-r--r--xep-0295.xml2
-rw-r--r--xep-0296.xml2
4 files changed, 4 insertions, 4 deletions
diff --git a/xep-0247.xml b/xep-0247.xml
index d5af7ee..837c830 100644
--- a/xep-0247.xml
+++ b/xep-0247.xml
@@ -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'
diff --git a/xep-0280.xml b/xep-0280.xml
index 1661891..3db6324 100644
--- a/xep-0280.xml
+++ b/xep-0280.xml
@@ -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
diff --git a/xep-0295.xml b/xep-0295.xml
index 0bdcf06..7635f54 100644
--- a/xep-0295.xml
+++ b/xep-0295.xml
@@ -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>
diff --git a/xep-0296.xml b/xep-0296.xml
index cef7dc3..35e5538 100644
--- a/xep-0296.xml
+++ b/xep-0296.xml
@@ -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>