Re: [xri] ED07 Issue #1: Encoding of + in query parameters

["Tan, William" <William.Tan@neustar.biz>]

The problem is not just spaces.

I will rephrase what I said, if we are going to allow ANY URIs to be 
used in _xrd_t parameter with only '&' and ';' escaped, implementations 
MUST be able to reproduce the original URI after extracting it. The 
problem of %20 being decoded to ' ' applies to any other %-encoded 
sequences in the original URI, i.e. it will be decoded.

So, I think there's another option:
#4. Require any % character to be escaped. This is just a generalization 
of #3.

=wil

Drummond Reed wrote:
> I agree with Victor about the first two choices -- to paraphrase him:
>
> #1. Require the + to be escaped, as in "_xrd_r=application/xrds%2Bxml"
>
> #2. Not require the + to be escaped, and recommend against using SPACE in
> any form in a QXRI query string due to the likelihood that it will be
> misunderstood by many implementations.
>
> However there is a third choice that solves the %20 problem:
>
> #3: Require double-percent-encoding of SPACE (or any other characters for
> which you want to preserve the percent-encoding) in an HXRI.
>
> This is the same approach we took in conversion of XRI-normal form to
> IRI-normal form: require that a character like SPACE that is already
> percent-encoded go through a second round of encoding on the percent sign.
> For example, if you wanted to turn the following into an HXRI:
>
> 	http://xri.net/=vg?_xrd_r=application/xrds+xml
> 	&_xrd_t=http://example.com/a%20b?a=1&b=2
>
> ...the actual fully-encoded HXRI would be:
>
> 	http://xri.net/=vg?_xrd_r=application/xrds+xml
> 	&_xrd_t=http://example.com/a%2520b?a=1%26b=2
>
> Following the same rule as IRI-normal form-to-XRI-normal form conversion,
> after its received by the proxy resolver, you simply do one level of
> unescaping (un-percent-encoding). That would convert the "%25" back into "%"
> and the "%26" back into "&", and you end up with the first string above.
>
> It seems like this would cleanly solve the entire problem, and not require
> that + be escape encoded.
>
> I'm putting this on the "final closure" list for tomorrow's telecon (agenda
> coming out shortly in between World Series innings ;-)
>
> =Drummond 
>
>
>   
>> -----Original Message-----
>> From: Victor Grey [mailto:victor@idcommons.org]
>> Sent: Wednesday, October 24, 2007 4:46 PM
>> To: OASIS XRI TC
>> Subject: Re: [xri] ED07 Issue #1: Encoding of + in query parameters
>>
>> Gabe Wachob wrote:
>>     
>>> Python RULEZ!!!
>>>       
>> Was that Python RULEZ or
>> Python
>> 	RULEZ
>> ;-)
>>
>> Tan, William wrote:
>>     
>>> Then we can't disallow %20, because who knows that %20 meant a
>>> SPACE character (character semantics) or just byte value \x20 (byte
>>> semantics). After all, it is a URI, and if we specified that no
>>> escaping other than ';' and '&' is necessary, we need to be able to
>>> extract that URI without changing anything.
>>>       
>> The issue is that + and %20 are both standard encodings for the SPACE
>> character in query strings.
>>
>> So we have to either:
>> 1. require the + to be escaped, as in "_xrd_r=application/xrds%2Bxml"
>> 2. not disallow but just recommend against using SPACE in any form in
>> a QXRI query string due to the likelihood that it will be
>> misunderstood by many implementations.
>>
>> (1) hurts the eyes, which is not a small thing when you've been up
>> all night debugging, and (2) is pedantically incorrect but unlikely
>> to be problematic in any application I can imagine (but maybe Wil
>> imagines differently than I do).
>>
>> I prefer (2) but I'm OK with either. It does imho have to be one or
>> the other.
>>
>> =vg
>>
>> P.S.
>> If you hand "http://xri.net/=vg?_xrd_r=application/xrds%20xml"; to
>> xri.net, it behaves exactly as if you had handed it
>> "_xrd_r=application/xrds%2Bxml" or "_xrd_r=application/xrds+xml". So
>> the misunderstanding that I'm predicting to be likely in many apps is
>> happening there too.
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>     
>
>
>
> ---------------------------------------------------------------------
> 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 
>
>