+Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]

+ helo=mx.sourceforge.net)

+ by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)

+ (envelope-from <gcbd-bitcoin-development@m.gmane.org>)

+ id 1WR0nh-0007qD-CO for bitcoin-development@lists.sourceforge.net;

+ Fri, 21 Mar 2014 14:52:01 +0000

+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;

+Received: from plane.gmane.org ([80.91.229.3])

+ by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)

+ (Exim 4.76) id 1WR0nf-0008Tt-El

+ for bitcoin-development@lists.sourceforge.net;

+ Fri, 21 Mar 2014 14:52:01 +0000

+Received: from list by plane.gmane.org with local (Exim 4.69)

+ (envelope-from <gcbd-bitcoin-development@m.gmane.org>)

+ id 1WR0nY-0006xV-Hp for bitcoin-development@lists.sourceforge.net;

+ Fri, 21 Mar 2014 15:51:52 +0100

+Received: from e179064016.adsl.alicedsl.de ([85.179.64.16])

+ by main.gmane.org with esmtp (Gmexim 0.1 (Debian))

+ id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;

+ Fri, 21 Mar 2014 15:51:52 +0100

+Received: from andreas by e179064016.adsl.alicedsl.de with local (Gmexim 0.1

+ (Debian)) id 1AlnuQ-0007hv-00

+ for <bitcoin-development@lists.sourceforge.net>;

+ Fri, 21 Mar 2014 15:51:52 +0100

+X-Injected-Via-Gmane: http://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

+X-Complaints-To: usenet@ger.gmane.org

+X-Gmane-NNTP-Posting-Host: e179064016.adsl.alicedsl.de

+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>

+X-Enigmail-Version: 1.5.2

+X-Spam-Score: -0.4 (/)

+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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,

+ no trust [80.91.229.3 listed in list.dnswl.org]

+ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record

+ 1.1 DKIM_ADSP_ALL No valid author signature,

+ domain signs all mail

+ -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay

+ domain

+ -0.0 SPF_PASS SPF: sender matches SPF record

+X-Headers-End: 1WR0nf-0008Tt-El

+Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

+X-BeenThere: bitcoin-development@lists.sourceforge.net

+X-Mailman-Version: 2.1.9

+Precedence: list

+List-Id: <bitcoin-development.lists.sourceforge.net>

+List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,

+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>

+List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>

+List-Post: <mailto:bitcoin-development@lists.sourceforge.net>

+List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>

+List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,

+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>

+X-List-Received-Date: Fri, 21 Mar 2014 14:52:01 -0000

+

+> > 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?

+

+

+