I'm using an API which requires a certain query parameter (whose value is a complex object) to be encoded in a proprietary JSON-like syntax which uses colons as a delimiter. Rather than quoting the string values in the object, these strings are meant to be %-encoded as necessary. Any colons inside the string values are required to be encoded. Any colons part of the structure must not be encoded. This seemed fishy to me, and led me to dive into the RFC3986 to find out exactly how %-encoding is meant to work.
Consider the following paragraph in the RFC:
6.2.2.2. Percent-Encoding Normalization
The percent-encoding mechanism (Section 2.1) is a frequent source of variance among otherwise identical URIs. In addition to the case normalization issue noted above, some URI producers percent-encode octets that do not require percent-encoding, resulting in URIs that are equivalent to their non-encoded counterparts. These URIs should be normalized by decoding any percent-encoded octet that corresponds to an unreserved character, as described in Section 2.3.
From this, I've cooked up two possible interpretations.
Whenever a character that doesn't need to be encoded is encoded, it's equivalent to the original. This is based on the sentence "[...] some URI producers percent-encode octets that do not require percent-encoding, resulting in URIs that are equivalent to their non-encoded counterparts".
It's only equivalent if the character in question is unreserved. Characters which are reserved but permitted locally, such as a colon within the querystring, don't fall into this category. this is based on "These URIs should be normalized by decoding any percent-encoded octet that corresponds to an unreserved character."
The issue is that "unreserved characters" and "octets that do not need to be encoded" are two distinct categories. My guess is that #2 is the correct interpretation, but the preceding sentence seems to contradict it. Can anyone with more knowledge confirm that interpretation?
