[mdx] url-encoding a basic identifier

Ian Young ian at iay.org.uk
Mon Aug 4 10:27:49 PDT 2014


On 4 Aug 2014, at 14:41, Cantor, Scott <cantor.2 at osu.edu> wrote:

> As a practical matter, they're interchangeable and it's pretty much a
> requirement that servers be able to handle both. We probably should be
> explicit about that.

If what you mean is "we should treat '/entities/a+b' as the same as '/entities/a%20b', then I'm going to
provisionally disagree with that. Unless you can find an obligation somewhere that forces the path component "a+b" to be URL-encoded as "a%2bb" then this would break identifiers containing '+' characters.

In RFC 3986, '+' is a sub-delim, unlike things like '/' and '?' which are gen-delims. These classes appear to be distinguished (section 2.2) in that %-encoding is essentially mandatory for gen-delims when building a URI (so, to make a path component with '/' or '?' in it requires %-encoding) but whether to %-encode is scheme-specific for sub-delims. I can't find anything requiring %-encoding of '+' in http URLs.

> As far as what to send, if we say "URL-encode", that's %20, and if we
> formally call out use of the MIME type used by browsers for form
> submission, it would be '+'.

We definitely don't refer to that MIME type. The intention was to use URL encoding, so that the intention was for the answer to Tom's question to be "%20". If people can re-read the current draft, we can figure out whether that's sufficiently clear. 

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20140804/070aae87/attachment.bin>


More information about the mdx mailing list