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

["Drummond Reed" <drummond.reed@cordance.net>]

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