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

changed several SHOULDs to MUSTs

This commit is contained in:
stpeter 2011-01-05 11:48:49 -07:00
parent c73a9a3d4d
commit c97395720d
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
xep-0047.xml
View File

@ -113,10 +113,11 @@
<section2 topic='Creating a Bytestream' anchor='create'>
<p>In order to set up an in-band bytestream, the initiator sends an IQ stanza of type "set" containing an &lt;open/&gt; element qualified by the 'http://jabber.org/protocol/ibb' namespace. This element possesses three attributes:</p>
<ul>
<li>The REQUIRED 'block-size' attribute defines the maximum size in bytes of each data chunk (which SHOULD NOT be greater than 65535).</li>
<li>The REQUIRED 'sid' attribute defines a unique session ID for this IBB session (which SHOULD match the NMTOKEN datatype).</li>
<li>The OPTIONAL 'stanza' attribute defines whether the data will be sent using IQ stanzas or message stanzas (the default value is "iq", and it is RECOMMENDED to send IBB data using IQ stanzas instead of message stanzas because IQ stanzas provide feedback to the sender regarding delivery to the recipient).</li>
<li>The REQUIRED 'block-size' attribute defines the maximum size in bytes of each data chunk (which MUST NOT be greater than 65535).</li>
<li>The REQUIRED 'sid' attribute defines a unique session ID for this IBB session (which MUST match the NMTOKEN datatype).</li>
<li>The OPTIONAL 'stanza' attribute defines whether the data will be sent using IQ stanzas or message stanzas (the default value is "iq")</li>
</ul>
<p>Note: It is RECOMMENDED to send IBB data using IQ stanzas instead of message stanzas because IQ stanzas provide feedback to the sender regarding delivery to the recipient).</p>
<example caption='Initiator requests session'><![CDATA[
<iq from='romeo@montague.net/orchard'
id='jn3h8g65'
@ -248,7 +249,7 @@
</section1>
<section1 topic='Bidirectionality' anchor='bidi'>
<p>An in-band bytestream is bidirectional. Therefore, either party to the bytestream is allowed to send data. Each sender MUST initialize the 'seq' attribute to zero and increment the 'seq' value by one with each chunk of data it sends. Each recipient MUST track chunks based on the 'seq' values it receives. The 'seq' values in each direction are independent of the values in the other direction. Thus there are two data sequences for each SessionID.</p>
<p>An in-band bytestream is bidirectional. Therefore, either party to the bytestream is allowed to send data. Each sender MUST initialize the 'seq' attribute to zero and increment the 'seq' value by one with each chunk of data it sends. Each recipient MUST track chunks based on the 'seq' values it receives. The 'seq' values in each direction are independent of the values in the other direction. Thus there are two data sequences for each Session ID.</p>
</section1>
<section1 topic='Use of Message Stanzas' anchor='message'>
@ -279,7 +280,7 @@
<section1 topic='Security Considerations' anchor='sec'>
<p>The In-Band Bytestreams protocol is as secure as the underlying XMPP transport. The application that uses IBB could have its own security layer, but this is outside of the scope of IBB.</p>
<p>An entity MUST verify any Base64 data received. An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the Base64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information. An implementation MUST NOT break on invalid input and MUST reject any sequence of Base64 characters containing the pad ('=') character if that character is included as something other than the last character of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow attacks and other attacks on the implementation. Base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. Base64 encoding MUST follow the definition in Section 4 of RFC 4648.</p>
<p>An entity MUST verify any Base64 data received. An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the Base64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information. An implementation MUST NOT break on invalid input and MUST reject any sequence of Base64 characters containing the pad ('=') character if that character is included as something other than the last character of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow attacks and other attacks on the implementation. Base64 encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. Base64 encoding MUST follow the definition in Section 4 of RFC 4648.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>