Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Fri, 21 Mar 2014 15:51:42 +0100
Message-ID: <lghjle$2er$1@ger.gmane.org>
References: <lc5hmg$1jh$1@ger.gmane.org>
	<leuunm$tjk$1@ger.gmane.org>	<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>	<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>	<lge7lv$3mf$1@ger.gmane.org>	<CALDj+BZRsXnU5w=1B+01PDfMPY-7zqU3GP_52vr9wknEdTJ59Q@mail.gmail.com>	<lgh1q8$1dc$1@ger.gmane.org>
	<CALDj+Bb=CR1pL0Ze1M6k22wfQM1bL6-w+EyipJQWc1OHhAY0rg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.3.0
In-Reply-To: <CALDj+Bb=CR1pL0Ze1M6k22wfQM1bL6-w+EyipJQWc1OHhAY0rg@mail.gmail.com>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Precedence: list

>     > Hmm, if we're inventing an URI for bluetooth, I'd rather follow
>     existing
>     > URI's patterns. BT is strictly point-to-point connection, so BT MAC
>     > should be considered as server address, and payment request ID
can be
>     > considered as request path. Probably "bt:<bt-mac>/​
>     > <random_id_of_payment_request>" would be more usual and easily
>     > understandable.
>
>     Agreed. I used the dash because I feared a slash would need to be
>     escaped if used in an URL parameter.
>
> ​It will need to be ​escaped, but HTTP URLs used in BIP72 have it
> already, so don't see why we should bother.

Quoting from RFC 3986, Section 3.4. Query:  "The characters slash ("/")
and question mark ("?") may represent data within the query component."

> Ok. Btw, I've tested ​QR possibilities on my PoS screen, in binary mode
> it's limited to about 600 chars, so really I can include only unsigned
> and rather short payment request. Signed requests longer than few
> hundred bytes will not work.

Thanks for testing this. It would be interesting to know what device and
software you used for scanning. But anyway, it falls into the same
ballpark as my tests.

> I probably will skip this anyway and go with bluetooth
> URI scheme we've just agreed + old style payments over p2p network as
> fallback. So no payment requests in QR codes at all from my side.

So BIP72 with a BT URI in the 'r' parameter?