Specify lexicographical order for fragment params

The rationale for this change is that since `-` instead of `+` breaks
compatibility anyway, the marginal cost of removing this
unusual/surprising requirement for reverse lexicographical ordering is
zero.

Author: nothingmuch

bip-0077.md

@@ -234,26 +234,30 @@ These session-specific parameters use a bech32-inspired encoding.
 The HRP is used as the parameter key, followed by the '1' separator,
 followed by the parameter value encoded using the bech32 character set in
 [uppercase](#uppercase-url). No checksum is used. Parameters are separated
-by a `-` character (previously a `+` separator [was specified](#bip-77)).
+by a `-` character.
 
-The following parameters are defined, and must be provided in reverse
-lexicographical order:
+The following parameters are defined, and must be provided in lexicographical
+order:
 
-- `RK`: encodes the *receiver key* as a 33-byte compressed public key.
-  Senders will initiate HPKE with the receiver using this key.
+- `EX`: specifies a [session
+  expiration](#session-expiration) in [unix
+  time](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16).
 - `OH`: encodes an alternate format of the OHTTP Key Configuration of
   the directory. It consists of a 33-byte compressed public key of the
   directory's OHTTP Gateway, prefixed by the 2-byte Key Identifier. A [
   RFC 9458 Key
   Configuration](https://www.ietf.org/rfc/rfc9458.html#section-3.1)
   is reconstructed by assuming the HPKE KEM ID and Symmetric Algorithms
   are [fixed](#secp256k1-hybrid-public-key-encryption).
-- `EX`: specifies a [session
-  expiration](#session-expiration) in [unix
-  time](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16).
+- `RK`: encodes the *receiver key* as a 33-byte compressed public key.
+  Senders will initiate HPKE with the receiver using this key.
 
 For example, a properly encoded endpoint Bitcoin URI looks like this
-`bitcoin:tb1q6q6de88mj8qkg0q5lupmpfexwnqjsr4d2gvx2p?amount=0.00666666&pjos=0&pj=HTTPS://PAYJO.IN/TXJCGKTKXLUUZ%23RK1Q0DJS3VVDXWQQTLQ8022QGXSX7ML9PHZ6EDSF6AKEWQG758JPS2EV-OH1QYPM59NK2LXXS4890SUAXXYT25Z2VAPHP0X7YEYCJXGWAG6UG9ZU6NQ-EX1WKV8CEC`
+`bitcoin:tb1q6q6de88mj8qkg0q5lupmpfexwnqjsr4d2gvx2p?amount=0.00666666&pjos=0&pj=HTTPS://PAYJO.IN/TXJCGKTKXLUUZ%23EX1WKV8CEC-OH1QYPM59NK2LXXS4890SUAXXYT25Z2VAPHP0X7YEYCJXGWAG6UG9ZU6NQ-RK1Q0DJS3VVDXWQQTLQ8022QGXSX7ML9PHZ6EDSF6AKEWQG758JPS2EV`
+
+Until 2026 implementations SHOULD also accept `+` as a fragment parameter
+separator and not enforce parameter ordering requirements, for compatibility
+with the [previous version of this document](#changelog).
 
 ### Sender Original PSBT Messaging
 
@@ -711,8 +715,6 @@ receiver also specifies the directory.
 
 ## Backwards compatibility
 
-### BIP 78
-
 Senders not supporting Payjoin will just ignore the `pj` parameter and
 proceed to typical address-based transaction flows.
 
@@ -728,18 +730,6 @@ seconds or else the directory should respond with an `unavailable` JSON
 error code as [defined in BIP
 78](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-well-known-errors).
 
-### BIP 77
-
-A previous version of this document specified `+` as the fragment parameter
-separator. This can cause issues due to a common convention (not specified in
-RFC 3986, but in RFC 1866 in relation to HTML form submission and query
-parameters, not URI fragments) of representing ` ` with `+` in URI query
-parameters.
-
-As a result of this change implementations are encouraged to still accept `+`
-delimited fragment parameters for during 2026 (a grace period of just under 6
-months).
-
 ## Reference implementation
 
 A production reference implementation client can be found at
@@ -748,3 +738,15 @@ directory, and development kit may be found here:
 <https://github.com/payjoin/rust-payjoin>. Source code for an Oblivious
 HTTP relay implementation may be found here:
 <https://github.com/payjoin/ohttp-relay>.
+
+## Changelog
+
+- 0.2.0 2025-07-08
+    - Change fragment parameter delimiter from `+` to `-` to improve
+      compatibility with generic URI parsing libraries, and order them
+      lexicographically. `+` can cause issues due to a common convention (not
+      specified in RFC 3986, but in RFC 1866, in relation to HTML form
+      submission and query parameters) of interpreting `+` as ` ` when decoding
+      URIs.
+- 0.1.0 2025-05-28
+    - First merged Draft version of BIP 77