fix typos

spec/requirements.md

@@ -398,7 +398,7 @@ The non-use of a ticket may be proven by documents that were provided to the
 customer/traveler on a train or at a station. This proof can also be provided in
 electronic form by a carrier.
 
-The customer must be able to make the claim via a retailer to the disributor
+The customer must be able to make the claim via a retailer to the distributor
 who needs to forward the request to the involved carriers.
 
 ## Functional Requirements of a Distributor

spec/technical-principles.md

@@ -7,42 +7,72 @@ permalink: /spec/technical-principles/
 
 ## Design Guidelines
 
-- **Do not reinvent the wheel** - Use existing concepts whenever possible (e.g. type system of OpenAPI, Problem details,...).
-- Strive for a Level 3 of [REST maturity](https://martinfowler.com/articles/richardsonMaturityModel.html).
+- **Do not reinvent the wheel** - Use existing concepts whenever possible (e.g.
+  type system of OpenAPI, Problem details,...).
+- Strive for a Level 3 of
+  [REST maturity](https://martinfowler.com/articles/richardsonMaturityModel.html).
 - Use [semantic versioning](https://semver.org).
 
 ## Derived Guidelines
 
-- Whenever a resource returned in a response can contain embedded resources, the request must allow specifying whether and which embedded resources should be returned in full or as references.
-- Follow [Zalando RESTful API and Event Scheme guidelines](https://opensource.zalando.com/restful-api-guidelines/)
+- Whenever a resource returned in a response can contain embedded resources, the
+  request must allow specifying whether and which embedded resources should be
+  returned in full or as references.
+- Follow
+  [Zalando RESTful API and Event Scheme guidelines](https://opensource.zalando.com/restful-api-guidelines/)
 - Use of the JSON Problem element
 - Standard Patch operations (not JSON PATCH)
-- A resource is either represented in full or as a reference. The reference element has the name of the resource post-fixed with "Ref". References normally only contains the URL to the referenced resource and a title element allowing to summarize the resource in one short string
-- Although examples or recommendations are provided as to which information should best be represented in the title string, each implementor as the freedom to modify it to best suit his needs.
-- Enumerations for very stable entities with limited set only, otherwise code lists. Stations codes are code lists.
+- A resource is either represented in full or as a reference. The reference
+  element has the name of the resource post-fixed with "Ref". References
+  normally only contains the URL to the referenced resource and a title element
+  allowing to summarize the resource in one short string
+- Although examples or recommendations are provided as to which information
+  should best be represented in the title string, each implementor as the
+  freedom to modify it to best suit his needs.
+- Enumerations for very stable entities with limited set only, otherwise code
+  lists. Stations codes are code lists.
 - Where possible, existing UIC code lists should be favored.
-- Creation/ modification calls return the created/modified resource (not just an ok code)
+- Creation/ modification calls return the created/modified resource (not just an
+  ok code)
 
 ## Error Handling
 
-In order to communicate errors to a consumer we support [RFC7807](https://tools.ietf.org/html/rfc7807).
+In order to communicate errors to a consumer we support
+[RFC7807](https://tools.ietf.org/html/rfc7807).
 
-This RFC defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.
+This RFC defines a "problem detail" as a way to carry machine- readable details
+of errors in a HTTP response to avoid the need to define new error response
+formats for HTTP APIs.
 
 A problem details object can have the following members:
 
-- `type`: A URI reference [RFC3986](https://tools.ietf.org/html/rfc3986) that identifies the problem type. This specification encourages that, when dereferenced, it provide human-readable documentation for the problem type (e.g., using HTML [W3C.REC-html5-20141028]). When this member is not present, its value is assumed to be "about:blank".
-- `title`: A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231](https://tools.ietf.org/html/rfc7231), Section 3.4).
-- `status`: The HTTP status code ([RFC7231](https://tools.ietf.org/html/rfc7231), Section 6) generated by the origin server for this occurrence of the problem.
-- `detail`: A human-readable explanation specific to this occurrence of the problem.
-- `instance`: A URI reference that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced.
-
-Consumers MUST use the `type` string as the primary identifier for the problem type; the `title` string is advisory and included only for users who are not aware of the semantics of the URI and do not have the ability to discover them (e.g., offline log analysis). Consumers SHOULD NOT automatically dereference the type URI.
+- `type`: A URI reference [RFC3986](https://tools.ietf.org/html/rfc3986) that
+  identifies the problem type. This specification encourages that, when
+  dereferenced, it provide human-readable documentation for the problem type
+  (e.g., using HTML [W3C.REC-html5-20141028]). When this member is not present,
+  its value is assumed to be "about:blank".
+- `title`: A short, human-readable summary of the problem type. It SHOULD NOT
+  change from occurrence to occurrence of the problem, except for purposes of
+  localization (e.g., using proactive content negotiation; see
+  [RFC7231](https://tools.ietf.org/html/rfc7231), Section 3.4).
+- `status`: The HTTP status code
+  ([RFC7231](https://tools.ietf.org/html/rfc7231), Section 6) generated by the
+  origin server for this occurrence of the problem.
+- `detail`: A human-readable explanation specific to this occurrence of the
+  problem.
+- `instance`: A URI reference that identifies the specific occurrence of the
+  problem. It may or may not yield further information if dereferenced.
+
+Consumers MUST use the `type` string as the primary identifier for the problem
+type; the `title` string is advisory and included only for users who are not
+aware of the semantics of the URI and do not have the ability to discover them
+(e.g., offline log analysis). Consumers SHOULD NOT automatically dereference the
+type URI.
 
 ## Functional Errors and Error Codes
 
-In order that OSDM implementations  behave consistently in error situations,
-a list of [error codes and warnings](../errors-warnings/) have been defined that
+In order that OSDM implementations behave consistently in error situations, a
+list of [error codes and warnings](../errors-warnings/) have been defined that
 must be supported in case of functional errors by all implementations.
 
 ## Authentication
@@ -51,25 +81,38 @@ The following three design principles are binding for each implementor:
 
 1. Don't reinvent crypto, thus we are using **OAuth2**.
 
-2. The JWTs in use for the authentication should be **short-lived** (think of timeout
-duration single-digit multiples)
+2. The JWTs in use for the authentication should be **short-lived** (think of
+   timeout duration single-digit multiples)
 
-3. The JWTs sent by the consumer, regardless of where they are generated, must be **digitally signed** using a private key for which the provider is able to find the matching public key
+3. The JWTs sent by the consumer, regardless of where they are generated, must
+   be **digitally signed** using a private key for which the provider is able to
+   find the matching public key
 
 These principles can be implemented as follows:
 
-- A **registration service** allows a consumer to register the necessary data (like: organization, technical admin, commercial admin, support line, other non-functional requirements like throttling limits) for approvement by the team providing access.
-any registered consumer will be approved or rejected if approved a unique, technical "ClientId" results and will be passed to the consumer
+- A **registration service** allows a consumer to register the necessary data
+  (like: organization, technical admin, commercial admin, support line, other
+  non-functional requirements like throttling limits) for approvement by the
+  team providing access. any registered consumer will be approved or rejected if
+  approved a unique, technical "ClientId" results and will be passed to the
+  consumer
 
-- A **login service** allows to request a valid token (for e.g. OAauth2) by the registered ClientId and related secret per configuration the validity duration of the token may be set (for e.g. 10min.), after that the token must be renewed by the consumer optionally the token might be revoked (for e.g. if your devOps realizes the consumer does not behave as expected)
+- A **login service** allows to request a valid token (for e.g. OAauth2) by the
+  registered ClientId and related secret per configuration the validity duration
+  of the token may be set (for e.g. 10min.), after that the token must be
+  renewed by the consumer optionally the token might be revoked (for e.g. if
+  your devOps realizes the consumer does not behave as expected)
 
-In multi-environments (like DEV, TEST, INT, PROD) consumers might register for each environment separately.
+In multi-environments (like DEV, TEST, INT, PROD) consumers might register for
+each environment separately.
 
-The detailled flow for machine-to-machine authentication can be found in [Authentication](../authentication/).
+The detailed flow for machine-to-machine authentication can be found in
+[Authentication](../authentication/).
 
 ### User Lookup
 
-From a devOps perspective it might by hard to control who uses your API (for e.g. `ClientId` and secret might by passed around or hacked).
+From a devOps perspective it might by hard to control who uses your API (for
+e.g. `ClientId` and secret might by passed around or hacked).
 
 The following issues should be defined outside of OSDM: