Remove trailing spaces

Author: mnot

draft-ietf-httpapi-idempotency-key-header.md

@@ -15,13 +15,13 @@ author:
     organization: PayPal, Inc.
     email: [email protected]
 
-  -        
+  -
     ins: S. Dalal
     name: Sanjay Dalal
     email: [email protected]
     uri: https://github.com/sdatspun2
 
-  -    
+  -
    ins: E. Wilde
    name: Erik Wilde
    email: [email protected]
@@ -46,7 +46,7 @@ Idempotency is important in building a fault-tolerant HTTP API. An HTTP request
 
 Let's say a client of an HTTP API wants to create (or update) a resource using a `POST` method. Since `POST` is NOT an idempotent method, calling it multiple times can result in duplication or wrong updates. Consider a scenario where the client sent a `POST` request to the server, but it got a timeout. Following questions arise :  Is the resource actually created (or updated)? Did the timeout occur during sending of the request, or when receiving of the response? Can the client safely retry the request, or does it need to figure out what happened in the first place? If `POST` had been an idempotent method, such questions may not arise. Client would safely retry a request until it actually gets a valid response from the server.
 
-For many use cases of HTTP APIs, duplicated resources are a severe problem from a business perspective. For example, duplicate records for requests involving any kind of money transfer `MUST NOT` be allowed. In other cases, processing of duplicate webhook delivery is not expected.  
+For many use cases of HTTP APIs, duplicated resources are a severe problem from a business perspective. For example, duplicate records for requests involving any kind of money transfer `MUST NOT` be allowed. In other cases, processing of duplicate webhook delivery is not expected.
 
 
 ##  Notational Conventions
@@ -158,7 +158,7 @@ If the request is retried, while the original request is still being processed,
     Link: <https://developer.example.com/idempotency>;
     rel="describedby"; type="text/html"
 
-Error scenarios above describe the status of failed idempotent requests, after the resource server prcocesses them. Clients MUST correct the requests before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors. 
+Error scenarios above describe the status of failed idempotent requests, after the resource server prcocesses them. Clients MUST correct the requests before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors.
 
 For other 4xx/5xx errors, such as 401, 403, 500, 502, 503, 504, 429, or any other HTTP error code that is not listed here, the client SHOULD act appropriately by following the resource server's documentation.