From f1a7164227bd2027f5f57347ae259484600c42d1 Mon Sep 17 00:00:00 2001 From: stpeter Date: Wed, 23 Feb 2011 15:42:32 -0700 Subject: [PATCH] 1.3rc3 --- xep-0047.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/xep-0047.xml b/xep-0047.xml index 820be6d1..4eb5cf07 100644 --- a/xep-0047.xml +++ b/xep-0047.xml @@ -26,10 +26,10 @@ &infiniti; &stpeter; - 1.3rc2 - in progress, last updated 2010-03-10 + 1.3rc3 + in progress, last updated 2011-02-23 psa -

Clarified error handling and block construction.

 +

Clarified error handling, block construction, and bytestream closing.

 1.2 @@ -100,7 +100,7 @@ -

This document describes In-Band Bytestreams (IBB), an XMPP protocol extension that enables two entities to establish a virtual bytestream over which they can exchange Base64-encoded chunks of data over XMPP itself. Because IBB provides a generic bytestream, its usage is open-ended. To date it has been used as a fallback method for sending files when out-of-band methods such as &xep0065; are not available. However, IBB could also be useful for any kind of relatively low-bandwidth activity, such as games, shell sessions, or encrypted text.

+

This document describes In-Band Bytestreams (IBB), an XMPP protocol extension that enables two entities to establish a virtual bytestream over which they can exchange Base64-encoded chunks of data over XMPP itself. Because IBB provides a generic bytestream, its usage is open-ended. To date it has been used as a fallback method for sending files (see &xep0096; and &xep0234;) when out-of-band methods such as &xep0065; are not available. However, IBB could also be useful for any kind of relatively low-bandwidth activity, such as games, shell sessions, or encrypted text.

 @@ -225,7 +225,7 @@ ]]> -

The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result.

+

The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result (however, the receiving party might wait until it has had a chance to send any remaining data in the other direction, if the bytestream is bidirectional; in this case, the party that sent the original <close/> element SHOULD wait to receive the IQ response from the receiving party before considering the bytestream to be closed).