GEP-1619: Review Update

- Various typos
- Backend-initiated session rework: change order of approach list,
  mentioned that there are nuances to the approaches such as making it
  transparent, fixed a broken link, and mentioned that inserting a
  cookie is generally a safe approach for implementations.

geps/gep-1619.md

@@ -133,21 +133,25 @@ This could potentially affect frameworks that initiate sessions in the backend.
 and requires careful design, making it suitable for exploration in a separate GEP.
 
 Continuing with the cookie example, when dealing with backend-initiated sessions, the process becomes somewhat more
-complex. For cookie-based session persistence, the gateway needs store a value within a cookie containing a server
+complex. For cookie-based session persistence, the gateway needs to store a value within a cookie containing a backend
 identifier. This identifier can be then used as a reference to maintain a persistent session to a specific backend.
 There are several approaches a gateway could use in this situation to achieve session persistence:
 
-1. Modify the existing cookie's value
-2. Insert an additional cookie
+1. Insert an additional cookie
+2. Modify the existing cookie's value
 3. Prefix the existing cookie
 
+Additionally, there are variations to each of these approaches, such as making new or updated cookies transparent to the
+backend, either by remove an inserted cookie or reversing modifications of the cookie's value.
+
 Alternatively, if the backend is not configured for session persistence, the gateway should refrain from modifying or
 inserting a cookie. In this situation, the gateway should remain passive and simply forward the `set-cookie` header as
 it is.
 
-Refer to the [Cookie Rewriting](#cookie-rewriting) section of the API for implementation guidance.
+Refer to the [Session Initiation Guidelines](#session-initiation-guidelines) section of the API for implementation
+guidance.
 
-Here's an example implementation of a backend initiating a session and the gateway modifies the cookie:
+Here's an example implementation of a backend initiating a session and the gateway modifies the cookie's value:
 ```mermaid
 sequenceDiagram
     actor C as Client
@@ -213,9 +217,9 @@ that certain applications may be designed to function both with and without sess
 importance of Gateway API supporting session persistence remains emphasized because it is frequently seen as a necessary
 feature.
 
-Conversely, apps that have not been designed or tested with session persistence in mind may misbehave when its enabled,
-primarily because of the impacts of load distribution on the app. Apps using session persistence must account for
-aspects like load shedding, draining, and session migration as a part of their application design.
+Conversely, apps that have not been designed or tested with session persistence in mind may misbehave when it is
+enabled, primarily because of the impacts of load distribution on the app. Apps using session persistence must account
+for aspects like load shedding, draining, and session migration as a part of their application design.
 
 ### The Relationship of Session Persistence and Session Affinity
 
@@ -580,8 +584,9 @@ implementations must consider how to manage sessions initiated by other componen
 this GEP does not support configuring backend-initiated persistent sessions. We leave the decision of handling existing
 sessions with each specific implementation. In the case of cookie-based session persistence, an implementation has the
 freedom to either rewrite the cookie or insert an additional cookie, or to do nothing (resulting in the lack of a
-persistent session). However, regardless of the implementation's design choice, the implementation must be able to
-handle multiple cookies.
+persistent session). In general, inserting an additional cookie is a generally safe option, but it's important for
+implementations to exercise their own discretion. However, regardless of the implementation's design choice, the
+implementation must be able to handle multiple cookies.
 
 ### Expected API Behavior