relocate and reword design rationale (#919)

---------

Co-authored-by: Roberto C. Sánchez <[email protected]>

README.md

@@ -95,15 +95,6 @@ If there are errors with cmake configuration, send the set of steps you performe
 
 If there are compilation or linker errors, run `make` again, setting `VERBOSE=1` in the environment or on the command line (which shows exact compile and link commands), and send the output to the maintainers of this project.
 
-### Design Principles ###
-The design of libmongocrypt adheres to these principles.
-
-#### Easy to integrate ####
-The main reason behind creating a C library is to make it easier for drivers to support FLE. Some consequences of this principle: the API is minimal, structs are opaque, and global initialization is lazy.
-
-#### Lightweight ####
-We decided against the "have libmongocrypt do everything" approach because it complicated integration, especially with async drivers. Because of this we decided no I/O occurs in libmongocrypt.
-
 ### Releasing ###
 
 See [releasing](./doc/releasing.md).

integrating.md

@@ -9,6 +9,24 @@ There are two major parts to integrating libmongocrypt into your driver:
 -   Writing a language-specific binding to libmongocrypt
 -   Using the binding in your driver to support client side encryption
 
+## Design Rationale
+
+### Simple interface
+
+The library interface is intended to be used with multiple languages.
+
+The API tries to be minimal. Most structs are opaque. Global initialization
+is lazy.
+
+Much of the API passes and returns BSON since all drivers can produce and parse
+BSON.
+
+### No I/O
+
+libmongocrypt deliberately does not do I/O to avoid poor behavior with some
+language runtimes. Example: in Go a blocking C call may block an OS thread,
+rather than a goroutine.
+
 ## Part 1: Writing a Language-Specific Binding ##
 
 The binding is the glue between your driver\'s native language and