Original text:
Clients encapsulate a request "request" using values from a key configuration: <del> the key identifier from the configuration, "keyID", with the corresponding KEM identified by "kemID", </del>  the public key from the configuration, "pkR", and <del> a selected combination of KDF, identified by "kdfID", and AEAD, identified by "aeadID". </del>  The client then constructs an Encapsulated Request, "enc_request", from a binary encoded HTTP request, "request", as follows: Construct a message header, "hdr", by concatenating the values of <del> "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </del>  Build "info" by concatenating the ASCII-encoded string "message/ bhttp request", a zero byte, and the header. Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server: <del> Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID", </del>  "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private <del> key, "skR", corresponding to "keyID". </del>  <del> a.  If "keyID" does not identify a key matching the type of "kemID", the server returns an error. </del>  <del> b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns an error. </del>  Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, "keyID" as an 8-bit integer, plus "kemID", "kdfID", and "aeadID" as three 16-bit integers. </del>  Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt".

Reviewer comments:
RFC 9180 does use skR/pkR/skS/skR, so I didn't change everything to use snake_case, but this is more consistent with how we identify things in other places. Also, it reads better and we don't have to grapple with whether it should be keyId or keyID.

Revised text:
Clients encapsulate a request "request" using values from a key configuration:  <ins> the key identifier from the configuration, "key_id", with the corresponding KEM identified by "kem_id", </ins> the public key from the configuration, "pkR", and  <ins> a selected combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id". </ins> The client then constructs an Encapsulated Request, "enc_request", from a binary encoded HTTP request, "request", as follows: Construct a message header, "hdr", by concatenating the values of  <ins> "key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </ins> Build "info" by concatenating the ASCII-encoded string "message/ bhttp request", a zero byte, and the header. Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server:  <ins> Parses "enc_request" into "key_id", "kem_id", "kdf_id", "aead_id", </ins> "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private  <ins> key, "skR", corresponding to "key_id". </ins>  <ins> a.  If "key_id" does not identify a key matching the type of "kem_id", the server returns an error. </ins>  <ins> b.  If "kdf_id" and "aead_id" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns an error. </ins> Build "info" by concatenating the ASCII-encoded string "message/  <ins> bhttp request", a zero byte, "key_id" as an 8-bit integer, plus "kem_id", "kdf_id", and "aead_id" as three 16-bit integers. </ins> Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt".