We should be able to split the parameters in an HXRI into pieces,
extract the resolution input parameters for processing, and leave the
rest in tact. Since the W3C recommends ';' as a delimiter in addition to
'&', we have to escape it. I think that's fine.
Other than the requirement to be able to split the query parameters, the
resolver MUST NOT interpret non-resolution query parameters, i.e. they
should be left as-is.
For resolution parameters, I think we can say that other than '&' and
';', everything else should not be unescaped in any way while
interpreting the HXRI. An important consequence of this is that any %
encoding will stay.
For example, in order to place http://example.com/test%20type/?a=1&b=2&x=a+b
into the _xrd_t parameter of the following HXRI:
http://xri.example.com/=example/path
It becomes:
http://xri.example.com/=example/path?_xrd_t=http://example.com/test%20type/?a=1%3Bb=1%3Bx=a+b
Implementations should be able to reverse this to the original value;
i.e. %20 should not become a space character (which makes the URI
illegal), nor should it be misinterpreted as '+'. And, of course %3B
gets turned into '+'.
This usually means re-implementing the URL parser because in many CGI
environments/implementation, the parameters are escaped in a "standard"
manner, which conflicts with the way we have specified.
So, that's a long-winded form of saying that '+' should not be escaped
when it appears in the resolution input parameters.
Thoughts?
=wil
Drummond Reed wrote:
>
> In his feedback on ED06, Gabe suggested we add an example of HXRI
> query parameter encoding rules. To do so I broke the encoding rules
> into a separate subsection in ED07. That entire subsection is included
> below for reference.
>
> The issue that came up doing this, however, is that in rule #3 below,
> while we give unambiguous instructions that the character + and the
> percent-encoded sequence %2B MUST be interpreted as the same
> character, we don’t currently say anything about whether the +
> character SHOULD or SHOULD NOT be encoded as %2B.
>
> And thus it is not clear what to do with the + characters that appear
> in the example.
>
> So the open issue is: what additional instructions about + character
> encoding, if any, should we put in rule #3 below?
>
> =Drummond
>
>
> */HXRI Query Parameter Encoding Rules/*
>
> To conform with the requirements of HTTP(S) URI processors, the
> following rules MUST be applied to encode HXRI query parameters prior
> to input and decode them prior to output. Decoding MUST be performed
> prior any comparison operation defined in this specification.
>
> 1. Any occurrences of the character & within an input parameter
> (specifically the Service Type value) MUST be percent encoded using
> the sequence %26.
>
> 2. If an HXRI query parameter includes one of the media type
> parameters defined in Table 6, it MUST be delimited from the HXRI
> query parameter with a semicolon, and this semicolon MUST be
> percent-encoded using the sequence %3B. This prevents
> misinterpretation of the semicolon character by a proxy resolver.
>
> 3. In an HXRI query parameter, the character + and the percent-encoded
> sequence %2B MUST be interpreted as the same character, therefore
> spaces in an HXRI query parameter MUST NOT be encoded as + signs.
>
> 4. Any XRIs or IRIs used as values of HXRI query parameters MUST be in
> URI-normal form as defined in *[XRISyntax]*.
>
> Following is an example HXRI before application of these encoding
> rules, with the characters requiring encoding highlighted in *red*.
>
> https://xri.example.com/=example*name/path?query&_xrd_r=application/
> xrds+xml*;*https=true*;*sep=true*;*refs=true&_xrd_t=http://example.org/
> test?a=1*&*b=2*&*string=hello%20plan*è*te&_xrd_m=application/atom+xml
>
> Here is the HXRI after application of the encoding rules, with the
> encoding highlighted in *red*.
>
> https://xri.example.com/=example*name/path?query&_xrd_r=application/
> xrds+xml*%3B*https=true*%3B*sep=true*%3B*refs=true&_xrd_t=http://example.org/test?a=1*%26*b=2*%26*string=hello%20plan*%E9*te&_xrd_m=application/atom+xml
>
> ------------------------------------------------------------------------
