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

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

+1 to what Wil says here -- the rule has to be "double-escaping" of all
escaped characters, i.e., escaping of any % sign in the "pre-encoded HXRI".

Note that just like in XRI-normal form-to-IRI-normal form transformations,
the rule is NOT idempotent, so you must do double-escaping once to encode
the HXRI, and proxy resolvers must undo it exactly once to decode the HXRI.

Luckily we can just use the text we already wrote in XRI Syntax 2.0 ;-)

=Drummond 

> -----Original Message-----
> From: Tan, William [mailto:William.Tan@neustar.biz]
> Sent: Wednesday, October 24, 2007 11:30 PM
> To: Drummond Reed
> Cc: 'Victor Grey'; 'OASIS XRI TC'
> Subject: Re: [xri] ED07 Issue #1: Encoding of + in query parameters
> 
> 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
> >
> >
> 
> 
> ---------------------------------------------------------------------
> 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