Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RsMKs-000209-B9 for bitcoin-development@lists.sourceforge.net; Tue, 31 Jan 2012 22:37:58 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.47 as permitted sender) client-ip=209.85.213.47; envelope-from=g.rowe.froot@gmail.com; helo=mail-yw0-f47.google.com; Received: from mail-yw0-f47.google.com ([209.85.213.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RsMKr-0004oB-6g for bitcoin-development@lists.sourceforge.net; Tue, 31 Jan 2012 22:37:58 +0000 Received: by yhfq46 with SMTP id q46so317749yhf.34 for ; Tue, 31 Jan 2012 14:37:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.139.234 with SMTP id c70mr38363845yhj.33.1328049470070; Tue, 31 Jan 2012 14:37:50 -0800 (PST) Sender: g.rowe.froot@gmail.com Received: by 10.236.195.99 with HTTP; Tue, 31 Jan 2012 14:37:50 -0800 (PST) In-Reply-To: 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> Date: Tue, 31 Jan 2012 22:37:50 +0000 X-Google-Sender-Auth: P5buBuV5zpsuYAsz3KcJFucAXBc Message-ID: From: Gary Rowe To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=485b397dceabe8605b04b7da9c25 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (g.rowe.froot[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RsMKr-0004oB-6g Subject: Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 22:37:58 -0000 --485b397dceabe8605b04b7da9c25 Content-Type: text/plain; charset=UTF-8 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 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 '_'. > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --485b397dceabe8605b04b7da9c25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andreas has a good point. See RFC 3986 on URI schemes:=C2=A0http://tools.ietf.org/html/rfc3986#= page-12

The colon is a reserved general delimiter (s= imilar in use to the / in a typical URL, but applies to URNs etc). As sugge= sted, we get req:something being changed to one of the unreserved character= s that do not have to be URL encoded. Again, from the RFC these are

* Option A: req_something (underscore)
* Opti= on B: req-something (hyphen)
* Option C: req~something (tilde)
* Option D: req.something (period)

Personally, my eye likes Option B, the hyphen.=C2=A0
=

On 31 January 2012 22:14, Andreas Schil= dbach <andrea= s@schildbach.de> wrote:
On 01/31/2012 07:22 PM, Ma= tt 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 '_'.



---------------------------------------------------------------------------= ---
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now!
http://p.= sf.net/sfu/learndevnow-d2d
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--485b397dceabe8605b04b7da9c25--