From 1cb2f5cbe8774dfc9d8916da3bd9cc85faf23e7a Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 4 Mar 2009 20:14:24 +0000 Subject: [PATCH] fixed anchors git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2824 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0047.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xep-0047.xml b/xep-0047.xml index e4e3089f..b31cc2aa 100644 --- a/xep-0047.xml +++ b/xep-0047.xml @@ -251,7 +251,7 @@ ]]> - +
  • Generally, in-band bytestreams SHOULD be used only as a last resort. SOCKS5 Bytestreams will almost always be preferable.
  • A server MAY rate limit a connection, depending on the size and frequency of data packets.
    • @@ -260,12 +260,12 @@
- +

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.

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.

 - +

This document requires no interaction with &IANA;.

 @@ -275,7 +275,7 @@ - +