Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 173.246.101.161 as permitted sender)
	client-ip=173.246.101.161;
	envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; 
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <CAKm8k+0o0fBcBgRMOEc3nycGaLN7EEvfQ5wrZN4XwO5Gk2Pk5w@mail.gmail.com>
References: <1328020046.70720.YahooMailNeo@web121002.mail.ne1.yahoo.com>
	<1328025899.2832.5.camel@BMThinkPad.lan.bluematt.me>
	<1328034145.2832.11.camel@BMThinkPad.lan.bluematt.me>
	<jg9p4a$c90$1@dough.gmane.org>
	<CAKm8k+0o0fBcBgRMOEc3nycGaLN7EEvfQ5wrZN4XwO5Gk2Pk5w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 31 Jan 2012 17:47:57 -0500
Message-ID: <1328050077.2891.4.camel@BMThinkPad.lan.bluematt.me>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
Precedence: list

Odd, here I was thinking I checked that.  Just goes to show how useful
sources other than the rfc itself are... Anyway, Ill change it to a
hyphen.

Matt

On Tue, 2012-01-31 at 22:37 +0000, Gary Rowe wrote:
> Andreas has a good point. See RFC 3986 on URI
> schemes: http://tools.ietf.org/html/rfc3986#page-12
> 
> 
> The colon is a reserved general delimiter (similar in use to the / in
> a typical URL, but applies to URNs etc). As suggested, we get
> req:something being changed to one of the unreserved characters that
> do not have to be URL encoded. Again, from the RFC these are
> 
> 
> * Option A: req_something (underscore)
> * Option B: req-something (hyphen)
> * Option C: req~something (tilde)
> * Option D: req.something (period)
> 
> 
> Personally, my eye likes Option B, the hyphen. 
> 
> On 31 January 2012 22:14, Andreas Schildbach <andreas@schildbach.de>
> wrote:
>         On 01/31/2012 07:22 PM, Matt Corallo wrote:
>         
>         > that "It is recommended that additional variables prefixed
>         with
>         > mustimplement: not be used in a mission-critical way until a
>         grace
>         
>         
>         Is the ':' sign actually allowed in URL parameter names
>         (unescaped/unencoded)? If not, I'd propose an unrestricted
>         char instead,
>         maybe '_'.