Grammatical/Typo changes

Patch: Pooja Chandak

This closes #2271

5 files changed, 16 insertions, 16 deletions

diff --git a/doc/specs/HeaderFormat.md b/doc/specs/HeaderFormat.md
index 0456f1ea7..9b74159a5 100644
--- a/doc/specs/HeaderFormat.md
+++ b/doc/specs/HeaderFormat.md
@@ -46,7 +46,7 @@ doesn't know about the transform ID, an error MUST be returned as we
 don't know how to transform the data.
 
 Conversely, data in the info headers is ignorable.  This should only
-be things like timestamps, debuging tracing, etc.  Using the header
+be things like timestamps, debugging tracing, etc.  Using the header
 size you should be able to skip this data and read the payload safely
 if you don't know the info ID.
 
@@ -61,7 +61,7 @@ Info ID's and transform ID's should share the same ID space.
 Header will be padded out to next 4-byte boundary with `0x00`.
 
 Max frame size is `0x3FFFFFFF`, which is slightly less than `HTTP_MAGIC`.
-This allows us to distingush between different (older) transports.
+This allows us to distinguish between different (older) transports.
 
 ### Transform IDs:
 
diff --git a/doc/specs/idl.md b/doc/specs/idl.md
index 75633107a..39b2dddb0 100644
--- a/doc/specs/idl.md
+++ b/doc/specs/idl.md
@@ -104,7 +104,7 @@ A service provides the interface for a set of functionality provided by a Thrift
 
 ### Field Requiredness
 
-There are two explicit requiredness values, and a third one that is applied implicity if neither  *required* nor *optional* are given: *default* requiredness.
+There are two explicit requiredness values, and a third one that is applied implicitly if neither  *required* nor *optional* are given: *default* requiredness.
 
     [18] FieldReq        ::=  'required' | 'optional' 
 
@@ -144,7 +144,7 @@ The major point to keep in mind here is the fact, that any unwritten default val
 
 ### XSD Options
 
-N.B.: These have  some internal purpose at Facebook but serve no current purpose in Thrift. Use of these options is strongly discouraged.
+N.B.: These have some internal purpose at Facebook but serve no current purpose in Thrift. The use of these options is strongly discouraged.
 
     [19] XsdFieldOptions ::=  'xsd_optional'? 'xsd_nillable'? XsdAttrs?
 
@@ -236,7 +236,7 @@ Initialization of Base Types for all Languages?
 Why does position of `CppType` vary between `SetType` and `ListType`?
 
  * std::set does sort the elements automatically, that's the design. see [Thrift Types](/docs/types) or the [C++ std:set reference][] for further details
- * The question is, how other languages are doing that? What about custom objects, do they have a Compare function the set the order correctly?
+ * The question is, how other languages are doing that? What about custom objects, do they have a Compare function to set the order correctly?
 
  [C++ std:set reference]: http://www.cplusplus.com/reference/stl/set/
 
diff --git a/doc/specs/thrift-binary-protocol.md b/doc/specs/thrift-binary-protocol.md
index a85268517..fc3338f6b 100644
--- a/doc/specs/thrift-binary-protocol.md
+++ b/doc/specs/thrift-binary-protocol.md
@@ -24,10 +24,10 @@ under the License.
 --------------------------------------------------------------------
 -->
 
-This documents describes the wire encoding for RPC using the older Thrift *binary protocol*.
+This document describes the wire encoding for RPC using the older Thrift *binary protocol*.
 
 The information here is _mostly_ based on the Java implementation in the Apache thrift library (version 0.9.1 and
-0.9.3). Other implementation however, should behave the same.
+0.9.3). Other implementation, however, should behave the same.
 
 For background on Thrift see the [Thrift whitepaper (pdf)](https://thrift.apache.org/static/files/thrift-20070401.pdf).
 
@@ -150,7 +150,7 @@ determine how to decode the field value.
 Note that the field name is not encoded so field renames in the IDL do not affect forward and backward compatibility.
 
 The default Java implementation (Apache Thrift 0.9.1) has undefined behavior when it tries to decode a field that has
-another field-type then what is expected. Theoretically this could be detected at the cost of some additional checking.
+another field-type than what is expected. Theoretically, this could be detected at the cost of some additional checking.
 Other implementation may perform this check and then either ignore the field, or return a protocol exception.
 
 A *Union* is encoded exactly the same as a struct with the additional restriction that at most 1 field may be encoded.
@@ -213,7 +213,7 @@ Where:
 
 The element-type values are the same as field-types. The full list is included in the struct section above.
 
-The maximum list/set size is configurable. By default there is no limit (meaning the limit is the maximum int32 value:
+The maximum list/set size is configurable. By default, there is no limit (meaning the limit is the maximum int32 value:
 2147483647).
 
 ## Map
diff --git a/doc/specs/thrift-protocol-spec.md b/doc/specs/thrift-protocol-spec.md
index 0c1a61cb2..080487e1b 100644
--- a/doc/specs/thrift-protocol-spec.md
+++ b/doc/specs/thrift-protocol-spec.md
@@ -33,7 +33,7 @@ implementation, but this document specifies the minimum required
 structure. There are some "dumb" terminals like STRING and INT
 that take the place of an actual encoding specification.
 
-They key point to notice is that ALL messages are just one wrapped
+The key point to notice is that ALL messages are just one wrapped
 `<struct>`. Depending upon the message type, the `<struct>` can be
 interpreted as the argument list to a function, the return value
 of a function, or an exception.
diff --git a/doc/specs/thrift-rpc.md b/doc/specs/thrift-rpc.md
index d45c06f30..fbff3b6a1 100644
--- a/doc/specs/thrift-rpc.md
+++ b/doc/specs/thrift-rpc.md
@@ -24,15 +24,15 @@ under the License.
 --------------------------------------------------------------------
 -->
 
-This document describes the high level message exchange between the Thrift RPC client and server.
+This document describes the high-level message exchange between the Thrift RPC client and server.
 See [thrift-binary-protocol.md] and [thrift-compact-protocol.md] for a description of how the exchanges are encoded on
 the wire.
 
-In addition, this document compares the binary protocol with the compact protocol. Finally it describes the framed vs.
+In addition, this document compares the binary protocol with the compact protocol. Finally, it describes the framed vs.
 unframed transport.
 
 The information here is _mostly_ based on the Java implementation in the Apache thrift library (version 0.9.1 and
-0.9.3). Other implementation however, should behave the same.
+0.9.3). Other implementation, however, should behave the same.
 
 For background on Thrift see the [Thrift whitepaper (pdf)](https://thrift.apache.org/static/files/thrift-20070401.pdf).
 
@@ -93,14 +93,14 @@ in the Thrift IDL file, or some other part of the Thrift stack throws an excepti
 not encode or decode a message or struct.
 
 In the Java implementation (0.9.3) there is different behavior for the synchronous and asynchronous server. In the async
-server all exceptions are send as a `TApplicationException` (see 'Response struct' below). In the synchronous Java
+server all exceptions are sent as a `TApplicationException` (see 'Response struct' below). In the synchronous Java
 implementation only (undeclared) exceptions that extend `TException` are send as a `TApplicationException`. Unchecked
 exceptions lead to an immediate close of the connection.
 
 Type `Oneway` is only used starting from Apache Thrift 0.9.3. Earlier versions do _not_ send TMessages of type `Oneway`,
 even for service methods defined with the `oneway` modifier.
 
-When client sends a request with type `Oneway`, the server must _not_ send a response (steps 3 and 4 are skipped). Note
+When the client sends a request with type `Oneway`, the server must _not_ send a response (steps 3 and 4 are skipped). Note
 that the Thrift IDL enforces a return type of `void` and does not allow exceptions for oneway services.
 
 ## Request struct
@@ -151,7 +151,7 @@ always slightly faster.
 ## Compatibility
 
 A server could automatically determine whether a client talks the binary protocol or the compact protocol by
-investigating the first byte. If the value is `1000 0001` or `0000 0000` (assuming a name shorter then ±16 MB) it is the
+investigating the first byte. If the value is `1000 0001` or `0000 0000` (assuming a name shorter than ±16 MB) it is the
 binary protocol. When the value is `1000 0010` it is talking the compact protocol.
 
 ## Framed vs. unframed transport