To: email@example.com Cc: firstname.lastname@example.org, email@example.com In-Reply-To: David Morris's message of Tue, 22 Aug 1995 22:43:03 -0700 <Pine.SUN.3.90.950822223958.27143Cfirstname.lastname@example.org> Subject: Re: Encoding the form-urlencoded Media Type From: Larry Masinter <email@example.com> Message-Id: <95Aug23.firstname.lastname@example.org> 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.