rfc: reflow document

Author: maxmoehl

toc/rfc/rfc-draft-generic-per-route-features.md

@@ -10,22 +10,21 @@
 
 ## Problem
 
-Implementing per-route features in Cloud Foundry is a tedious process because it requires
-changes to multiple components in multiple working groups. Most components will only need to be
-made aware of new fields without adding any significant logic but the overhead of making the
-change still exists.
+Implementing per-route features in Cloud Foundry is a tedious process because it requires changes to
+multiple components in multiple working groups. Most components will only need to be made aware of
+new fields without adding any significant logic but the overhead of making the change still exists.
 
 On the other side are the components that actually need to be aware of the change. Mostly the
-routing components (gorouter, maybe route-emitter / -registrar), the API (cloud controller)
-and UIs (CLI).
+routing components (gorouter, maybe route-emitter / -registrar), the API (cloud controller) and
+UIs (CLI).
 
 ## Proposal
 
 To reduce the overall overhead of implementing new per-route features we propose to add a generic
 key-value map to the definition of a route across all components. All components handling the map
 SHOULD ignore the contents of the map except gorouter, cloud controller and cf CLI which MUST handle
-the map and its values accordingly. Other components MAY limit the size of the map or size of
-keys / values for technical reasons.
+the map and its values accordingly. Other components MAY limit the size of the map or size of keys /
+values for technical reasons.
 
 The following constraints apply (types are as specified in [RFC 8259](https://rfc-editor.org/rfc/rfc8259)):
 * The map MUST be representable as an object.
@@ -41,11 +40,11 @@ pairs for the `map-route` sub-command.
 
 #### Cloud Controller
 
-The API MUST specify and implement a new field to carry the map inside the route object. The API
-MUST implement per-field validations as features of the map are specified. The route MUST be
+The API MUST specify and implement a new field to carry the map inside the route object. The
+API MUST implement per-field validations as features of the map are specified. The route MUST be
 rejected with an appropriate error message if the provided map is invalid and MUST be passed on
-as-is otherwise. The API also MUST store the map as a generic key-value map to ensure changes to
-the map do not require a change to the database schema.
+as-is otherwise. The API also MUST store the map as a generic key-value map to ensure changes to the
+map do not require a change to the database schema.
 
 Support for a generic map MUST be added to the manifest. The updated routes section in a manifest
 MAY look like this:
@@ -78,25 +77,24 @@ error.
 
 ### Route-Registrar
 
-Route-registrar MUST offer the new features in its config as they are added to the other
-components.
+Route-registrar MUST offer the new features in its config as they are added to the other components.
 
 #### Gorouter
 
-Gorouter MUST accept the new field and parse its contents. If the map cannot be parsed it MUST
-be ignored. If individual key-value pairs are invalid those MUST be ignored and other key-value
-pairs MUST still be parsed and acted upon. For any option which could not be parsed gorouter MUST
-NOT fail but fall back to the value provided in the gorouter config. When encountering an invalid
-option gorouter MUST log the error at least once, the log SHOULD indicate what it tried to parse,
-why it failed and which value will come into effect.
+Gorouter MUST accept the new field and parse its contents. If the map cannot be parsed it MUST be
+ignored. If individual key-value pairs are invalid those MUST be ignored and other key-value pairs
+MUST still be parsed and acted upon. For any option which could not be parsed gorouter MUST NOT
+fail but fall back to the value provided in the gorouter config. When encountering an invalid option
+gorouter MUST log the error at least once, the log SHOULD indicate what it tried to parse, why it
+failed and which value will come into effect.
 
 It MAY be decided to implement one feature as part of this RFC which would be implemented together
 with the generic logic for supporting the new map.
 
 As new features are specified they MUST be implemented in gorouter.
 
-Example `router.register` NATS message containing additional options (field names and values are not
-final):
+Example `router.register` NATS message containing additional options (field names and values are
+not final):
 
 ```json
 {
@@ -131,10 +129,10 @@ To-Do:
 
 ### Specifying Features
 
-It's the responsibility of the App Runtime Platform Working Group (ARP-WG) to specify new
-features based on what is specified in this RFC. When a new feature is proposed the ARP-WG uses
-the process it would use for any new feature to decide whether and how it should be implemented. It
-MAY involve other working groups in the process.
+It's the responsibility of the App Runtime Platform Working Group (ARP-WG) to specify new features
+based on what is specified in this RFC. When a new feature is proposed the ARP-WG uses the process
+it would use for any new feature to decide whether and how it should be implemented. It MAY involve
+other working groups in the process.
 
 ### Features Which Could be Implemented
 
@@ -144,11 +142,13 @@ per-route features:
 - Custom Load-Balancing Algorithm
 - Custom Connection Limits
 - Custom session cookie name (currently set on platform level, mostly to `JSESSIONID`)
-- Option to trim path mapping on request (i.e. an app mapped to `/some-path/` receiving a request `GET /some-path/books` will see the request as `GET /books` if the `trim-path` option is set, instead of the full path)
+- Option to trim path mapping on request (i.e. an app mapped to `/some-path/` receiving a request
+  `GET /some-path/books` will see the request as `GET /books` if the `trim-path` option is set,
+  instead of the full path)
 
 To-Do:
 * Collect more feedback and extend the list.
 
 All of these options are already (or could easily be made) configurable for the entire CF
-installation. Changing them will almost certainly break existing scenarios which is why we
-are looking for a cheap way to gradually allow for more configuration per route.
+installation. Changing them will almost certainly break existing scenarios which is why we are
+looking for a cheap way to gradually allow for more configuration per route.