Re: Encoding the form-urlencoded Media Type

Larry Masinter (masinter@parc.xerox.com)
Wed, 23 Aug 1995 00:00:28 PDT


To: dwm@shell.portal.com
Cc: html-wg@oclc.org, uri@bunyip.com
In-Reply-To: David Morris's message of Tue, 22 Aug 1995 22:43:03 -0700 <Pine.SUN.3.90.950822223958.27143C-100000@jobe.shell.portal.com>
Subject: Re: Encoding the form-urlencoded Media Type 
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <95Aug23.000043pdt.2763@golden.parc.xerox.com>
Date: Wed, 23 Aug 1995 00:00:28 PDT

[This is a followup to a note on html-wg about URL encoding of spaces  ]
[in arguments and whether, if spaces are turned into +, then +'s should]
[be encoded. I think we may want to (need to?) change the URL proposed ]
[standards to properly deal with this, though. Followup to uri list.   ]

If + is used as a delimiter between arguments, then it is should be
listed in the set of 'reserved' characters, not the 'unsafe' ones.
(Reserved characters have semantics and should be encoded if used for
anything other than its reserved purpose.) Unfortunately, '+' isn't
listed as a (potentially) reserved character. We had a good reason at
the time for limiting the set of reserved characters to a 'known set'.

Perhaps if RFC1738 (and 1808) get updated, + should get moved from
'safe' to 'reserved', or maybe the whole distinction of between the
two is bogus. At this point, there are only "$-_.+" that are listed as
'safe', so perhaps they're all reservable by *some* URL scheme.