mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 18:22:24 -05:00
changed several SHOULDs to MUSTs
This commit is contained in:
parent
c73a9a3d4d
commit
c97395720d
@ -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 <open/> 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'
|
||||
@ -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'>
|
||||
|
Loading…
Reference in New Issue
Block a user