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

fixed anchors

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2824 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-03-04 20:14:24 +00:00
parent 2f6bba2557
commit 1cb2f5cbe8
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
xep-0047.xml
View File

@ -251,7 +251,7 @@
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Usage Guidelines' anchor='intro'> <section1 topic='Usage Guidelines' anchor='usage'>
<ul> <ul>
<li>Generally, in-band bytestreams SHOULD be used only as a last resort. <strong>SOCKS5 Bytestreams</strong> will almost always be preferable.</li> <li>Generally, in-band bytestreams SHOULD be used only as a last resort. <strong>SOCKS5 Bytestreams</strong> will almost always be preferable.</li>
<li>A server MAY rate limit a connection, depending on the size and frequency of data packets.</li> <li>A server MAY rate limit a connection, depending on the size and frequency of data packets.</li>
@ -260,12 +260,12 @@
</ul> </ul>
</section1> </section1>
<section1 topic='Security Considerations' anchor='intro'> <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>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. 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>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='intro'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
@ -275,7 +275,7 @@
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='intro'> <section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[ <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>