diff --git a/doc/README.interfaces.html b/doc/README.interfaces.html
index 015857d05d..3d86b7a206 100644
--- a/doc/README.interfaces.html
+++ b/doc/README.interfaces.html
@@ -3,11 +3,12 @@
 <HEAD>
 	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
 	<TITLE></TITLE>
-	<META NAME="GENERATOR" CONTENT="OpenOffice 4.0.1  (Unix)">
+	<META NAME="GENERATOR" CONTENT="OpenOffice 4.1.1  (Unix)">
 	<META NAME="AUTHOR" CONTENT="alex ">
 	<META NAME="CREATED" CONTENT="20130531;10003100">
 	<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
-	<META NAME="CHANGED" CONTENT="20131106;14262300">
+	<META NAME="CHANGED" CONTENT="20141113;13173600">
+	<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
 	<STYLE TYPE="text/css">
 	<!--
 		@page { size: 8.5in 11in; margin: 0.79in }
@@ -47,11 +48,11 @@ time by BLR (binary language representation) of that request. But SQL
 operator does not contain description of message format and therefore
 decision was taken &ndash; surround each message with short BLR
 sequence (hard to call that program) describing it's format. For a
-reason they had decided to follow that rule too exactly &ndash; and
-each fetch of data from server now required sending BLR for it, i.e.
-formatting BLR was sent not only at SQL compile time. The reason for
-such strange at the first glance solution was presence of one more
-layer on top of that messages based API - familiar to you SQLDA
+reason they had decided to follow that rule too exactly &ndash; it
+was possible to send modified BLR for each fetch of data from server,
+i.e. formatting BLR was sent not only at SQL compile time. The reason
+for such strange at the first glance solution was presence of one
+more layer on top of that messages based API - familiar to you SQLDA
 (XSQLDA). Rather obvious that manually accompanying each SQL
 statement with BLR is not efficient programming style, therefore
 SQLDA was invented. But it encapsulates in same object both location
@@ -121,16 +122,17 @@ IStatus it's better to have simpler way to destroy it, i.e. dispose()
 function.</FONT></P>
 <P STYLE="margin-bottom: 0in"><BR>
 </P>
-<P STYLE="margin-bottom: 0in"><FONT COLOR="#ff0000"><FONT SIZE=4>Careful!</FONT></FONT><FONT SIZE=4>
-An ability to upgrade interface version places one important limit on
-implementation of interfaces: it should not contain virtual functions
-(including virtual destructor) except those defined in interface
-definition. This is because interface upgrade process modifies table
-of virtual functions, and for successful upgrade, number of functions
-in interface implementation should exactly match one in its
-definition. Pointer to functions, missing in interface definition but
-added in its implementation, may be </FONT><FONT COLOR="#ff0000"><FONT SIZE=4>overwritten</FONT></FONT><FONT SIZE=4>
-with a pointer to function used to upgrade interface.</FONT></P>
+<P STYLE="margin-bottom: 0in"><FONT COLOR="#ff0000"><FONT SIZE=4>Careful!</FONT></FONT>
+<FONT SIZE=4>An ability to upgrade interface version places one
+important limit on implementation of interfaces: it should not
+contain virtual functions (including virtual destructor) except those
+defined in interface definition. This is because interface upgrade
+process modifies table of virtual functions, and for successful
+upgrade, number of functions in interface implementation should
+exactly match one in its definition. Pointer to functions, missing in
+interface definition but added in its implementation, may be
+</FONT><FONT COLOR="#ff0000"><FONT SIZE=4>overwritten</FONT></FONT>
+<FONT SIZE=4>with a pointer to function used to upgrade interface.</FONT></P>
 <P STYLE="margin-bottom: 0in"><BR>
 </P>
 <P STYLE="margin-bottom: 0in"><FONT SIZE=4>Discussing in details all
diff --git a/doc/README.plugins.html b/doc/README.plugins.html
index d8f9d3ad94..767713809a 100644
--- a/doc/README.plugins.html
+++ b/doc/README.plugins.html
@@ -3,9 +3,10 @@
 <HEAD>
 	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
 	<TITLE></TITLE>
-	<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.4.1  (Unix)">
+	<META NAME="GENERATOR" CONTENT="OpenOffice 4.1.1  (Unix)">
 	<META NAME="CREATED" CONTENT="20130417;16154700">
-	<META NAME="CHANGED" CONTENT="20130621;20102600">
+	<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
+	<META NAME="CHANGED" CONTENT="20141113;13254700">
 	<STYLE TYPE="text/css">
 	<!--
 		@page { margin: 0.79in }
@@ -91,18 +92,22 @@ set of plugin types:</FONT></P>
 special Firebird interfaces (see README.interfaces about interfaces
 in Firebird). All plugin-specific interfaces are reference counted,
 i.e. have explicitly controlled lifetime. Interfaces are declared in
-Plugin.h include file. There is a simple example of writing plugin
-module &ndash; DbCrypt_example. It does not perform any actual
+Interfaces.h include file. There is a simple example of writing
+plugin module &ndash; DbCrypt_example. It does not perform any actual
 encryption &ndash; just a sample of how to write plugin. Complete
 instruction of how to write plugins is out of this document's scope.
 Here is provided a short list of plugin features:</FONT></P>
 <UL>
 	<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>plugin may be written
-	using any language, supporting pure virtual interfaces (you will
-	need to rewrite interfaces declarations for your language if they
-	are missing);</FONT></P>
+	using any language, supporting function pointers in a
+	structure/record (or at least arrays of function pointers);</FONT></P>
+	<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>currently interfaces
+	description is available only for C++ language, at release time
+	plain-C and delphi/fpc descriptions will be present (you will need
+	to write your interfaces declarations generator for your language if
+	you need something else);</FONT></P>
 	<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>like with UDFs you
-	are free to add any reasonable code yo your plugin, but pay
+	are free to add any reasonable code to your plugin, but pay
 	attention to word &ldquo;reasonable&rdquo; - asking a question from
 	plugin at server's console is hardly good idea;</FONT></P>
 	<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>it's OK to use
@@ -272,8 +277,10 @@ connect to pre-FB3 servers. (Yes &ndash; it still transfers almost
 plain passwords over the wire. Compatibility...) On server it works
 with security database from FB 2.5, and should be avoided except
 cases when you understand well what are you doing. To use Legacy_Auth
-on server you should also disable network traffic encryption in
+on server you should set lower level of network traffic encryption in
 firebird.conf:</FONT></P>
+<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>WireCrypt = Enabled</I></FONT></P>
+<P STYLE="margin-bottom: 0in"><FONT SIZE=4>or in the worst case:</FONT></P>
 <P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>WireCrypt = Disabled</I></FONT></P>
 <P STYLE="margin-bottom: 0in"><BR>
 </P>
diff --git a/doc/README.providers.html b/doc/README.providers.html
index 8f58ce8d4f..97aa5e5461 100644
--- a/doc/README.providers.html
+++ b/doc/README.providers.html
@@ -3,9 +3,10 @@
 <HEAD>
 	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
 	<TITLE></TITLE>
-	<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.4.1  (Unix)">
+	<META NAME="GENERATOR" CONTENT="OpenOffice 4.1.1  (Unix)">
 	<META NAME="CREATED" CONTENT="0;0">
-	<META NAME="CHANGED" CONTENT="20130611;16182500">
+	<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
+	<META NAME="CHANGED" CONTENT="20141113;13283500">
 	<STYLE TYPE="text/css">
 	<!--
 		@page { margin: 0.79in }
@@ -115,8 +116,9 @@ name or whatever else you choose). In this sample when database name
 used caching provider accepts such connection and invokes YValve once
 again with traditional database name </SPAN><I>RemoteHost:dbname</I><SPAN STYLE="font-style: normal">.
 But when user later performs any call to his database caching
-provider gets control on it before </SPAN><SPAN STYLE="font-style: normal"><B>Remote</B></SPAN><SPAN STYLE="font-style: normal">
-one and for locally cached table can avoid calls to remote server.</SPAN></FONT></P>
+provider gets control on it before </SPAN><SPAN STYLE="font-style: normal"><B>Remote</B></SPAN>
+<SPAN STYLE="font-style: normal">one and for locally cached table can
+avoid calls to remote server.</SPAN></FONT></P>
 <P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
 <FONT SIZE=4>Using chaining one can implement a lot of other useful
 things like database replication without need in triggers - just
@@ -158,7 +160,8 @@ problem migrating to Firebird 3?</FONT></P>
 <P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
 <FONT SIZE=4>A. Definitely no problems. Old API is supported for
 backward compatibility in Firebird 3 and will be supported in future
-versions as long as people need it.</FONT></P>
+versions as long as people need it. Moreover, since Firebird 3 one
+can access from XSQLDA API records longer than 64Kbytes.</FONT></P>
 <P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
 <FONT SIZE=4>Q. And what about performance when using old API?</FONT></P>
 <P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
@@ -171,8 +174,7 @@ execute SQL operator and fetch data from it. But SQLDA and related to
 it data moves has never been the most fast place of functional API,
 it was one the reasons to have new API and logic between new and old
 API does not add much to that old overhead.</FONT></P>
-<P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
-<BR>
+<P STYLE="text-indent: 0.39in; margin-bottom: 0in"><BR>
 </P>
 </BODY>
-</HTML>
+</HTML>
\ No newline at end of file
