The HXRI below should be:
http://xri.example.com/=example/path?_xrd_t=http://example.com/test%20type/?a=1%26b=2%26x=a+b
Thanks to John for the correction!
=wil
Tan, William wrote:
> 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
>>
>>
>> ------------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
