OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Encoding plus (+) sign


We never closed this thread regarding whether or not we need to specify that the + sign (or other symbols) require encoding when used in HXRI query parameters during XRI proxy resolution.

 

A recent email to me from Wil Tan summarizes his view:

 

**** START  ****

 

I would like to re-state my arguments for percent encoding the + sign, but if the TC decide otherwise it is fine by me:

  1. It may break round trip conversion; if the URL is deconstructed and reconstructed, the ‘+’ sign could become ‘%20’ because ‘+’ => ‘ ‘ => ‘+’ or ‘%20’ depending on implementation.
  2. It is a non-standard query syntax. Gabe has a point that the query component is rarely standardized anyway, and he’s right. But URL has standardized ‘&’ or ‘;’ delimited query parameters that works across all HTTP applications. And we are standardizing the HXRI format that is meant to work with HTTP, why make it non-standard?
  3. It is non-consistent. Certainly, _xrd_r may be ASCII only but _xrd_t isn’t and would require percent encoding anyway.
  4. Implementation-wise, it adds more work to the server builder because on almost all programming platforms, a re-implementation of the query parser is necessary. For java, it is this file: http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr154/src/share/javax/servlet/http/HttpUtils.java (look under parseName, called by the parseQueryString method)

 

**** END ******

 

So the decision before the TC appears to be this:

 

1) Should we specify that specific characters in HXRI query parameters must be percent-encoded?

 

2) If so, which characters?

 

This is a vital issue for Working Draft 11 and is included on the list of Working Draft 11 open issues at http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11.

 

I encourage all TC members with an opinion on this to post it. If we can’t close it on the list we’ll make it an agenda item on next Thursday’s TC call (4pm Pacific).

 

=Drummond

 

 

 


From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Wednesday, May 10, 2006 11:24 AM
To: Tan, William; Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Encoding plus (+) sign

 

I don't think they have to be encoded.

 

The query part of a URI has relatively few requirements for escaping/encoding relative to the rest of the URI.

 

We should consult the RFC 3986 spec to answer this question - we should require no more encoding/escaping than is required by that spec.

 

   -Gabe

 


From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Wednesday, May 10, 2006 11:13 AM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Encoding plus (+) sign

What about non-ASCII characters in the resolution parameter? They would have to be % encoded in IRI style anyway, right? I doubt these parameters would be intelligible to the layperson by any standard anyway, why not just specify that they be URL encoded (rfc1738), which includes encoding % to %25?

 

=wil (http://xri.net/=wil)

 

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wednesday, May 10, 2006 3:04 PM
To: Tan, William; xri@lists.oasis-open.org
Subject: RE: [xri] Encoding plus (+) sign

 

So, Wil, are you thinking that we should only specify percent-encoding of the plus sign? While that’s simple, it seems a little bit of an odd rule. Since this only applies to XRI proxy servers, wouldn’t it be easier for proxy server implementers to just make sure their code leaves the plus sign alone?

 

That way we wouldn’t need any special encoding of the resolution parameters at all.

 

Thoughts?

 

=Drummond

 


From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Monday, May 08, 2006 6:50 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Encoding plus (+) sign

 

No, slashes are fine.

I don’t know of any other strange character other than the plus sign.

 

=wil (http://xri.net/=wil)

 

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Tuesday, May 09, 2006 11:20 AM
To: Tan, William; xri@lists.oasis-open.org
Subject: RE: [xri] Encoding plus (+) sign

 

I was offline at the Internet Identity Workshop last week so I just got to this.

 

This seems like it is hugely important from an interoperability standpoint. Either we need to require all proxy HXRI parameters to use percent-encoding for all XRI reserved characters (which is a big deal) or we need some other solution.

 

How do others feel?

 

Wil, would this also extend to forward slash characters?

 

=Drummond

 


From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Monday, May 01, 2006 3:25 AM
To: xri@lists.oasis-open.org
Subject: [xri] Encoding plus (+) sign

 

Hi XRItes,

 

The resolution specification does not say that we have to URL-escape the query parameters before merging it into the proxy URI. However, our most important MIME type “application/xrds+xml” contains a plus sign which has special legacy meaning which gets decoded as a space character on the server side. The parameter values could get corrupted if we don’t escape it, especially when merging with existing QXRI query string. So, my argument is to require that the query parameter values be URL-encoded (by that I mean percent encoding any symbol in the “iquery” production).

 

=wil (http://xri.net/=wil)

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]