Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.41 as permitted sender)
	client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f41.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <lc3tm6$9ko$1@ger.gmane.org>
References: <lc3tm6$9ko$1@ger.gmane.org>
Date: Sun, 26 Jan 2014 22:24:35 +0100
Message-ID: <CANEZrP2F-1aqzBfUB82riWOwTABf1arbx70FdQ-XndQ91m_QqA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=001a11c30600c1925904f0e6374b
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70/71 issue, RFD
Precedence: list

--001a11c30600c1925904f0e6374b
Content-Type: text/plain; charset=UTF-8

Which medium is this an issue for? As you note, for files and HTTP
responses it's not a problem in practice. i'd guess nor for NFC tags nor QR
codes.


On Sun, Jan 26, 2014 at 10:11 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> I'm experimenting with BIP70/71 (payment protocol) usage in face to face
> payments (more on that soon).
>
> I've excountered an issue with the protobuf format. Protobufs are not
> self-delimiting. That means if you're reading from an undelimited
> stream, you will read endlessly because you don't know how much to read.
>
> The current BIP70 implementations probably work because they're reading
> either from a file or from an HTTP resource which sets the
> Content-Length header. Trouble is the Content-Length header is optional,
> and also there are many kinds of streams that don't have this built-in
> delimiting mechanism.
>
> The Java protobuf API solves this by offering delimited I/O, like
>
> payment.writeDelimitedTo(os);
>
> This writes the size of the message as a varint before writing the data.
> I don't know about protobuf implementations for other languages but I'd
> expect them to offer something compatible.
>
> However, this leading varint is an incompatible change and would need to
> be added to the spec.
>
> I specifically encountered this with PaymentMessage and PaymentACK, but
> it might be a good idea to apply this to all messages if any. Open for
> discussion.
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a11c30600c1925904f0e6374b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Which medium is this an issue for? As you note, for files =
and HTTP responses it&#39;s not a problem in practice. i&#39;d guess nor fo=
r NFC tags nor QR codes.</div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">
On Sun, Jan 26, 2014 at 10:11 PM, Andreas Schildbach <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildba=
ch.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m experimenting with BIP70/71 (payment protocol) usage in face to fac=
e<br>
payments (more on that soon).<br>
<br>
I&#39;ve excountered an issue with the protobuf format. Protobufs are not<b=
r>
self-delimiting. That means if you&#39;re reading from an undelimited<br>
stream, you will read endlessly because you don&#39;t know how much to read=
.<br>
<br>
The current BIP70 implementations probably work because they&#39;re reading=
<br>
either from a file or from an HTTP resource which sets the<br>
Content-Length header. Trouble is the Content-Length header is optional,<br=
>
and also there are many kinds of streams that don&#39;t have this built-in<=
br>
delimiting mechanism.<br>
<br>
The Java protobuf API solves this by offering delimited I/O, like<br>
<br>
payment.writeDelimitedTo(os);<br>
<br>
This writes the size of the message as a varint before writing the data.<br=
>
I don&#39;t know about protobuf implementations for other languages but I&#=
39;d<br>
expect them to offer something compatible.<br>
<br>
However, this leading varint is an incompatible change and would need to<br=
>
be added to the spec.<br>
<br>
I specifically encountered this with PaymentMessage and PaymentACK, but<br>
it might be a good idea to apply this to all messages if any. Open for<br>
discussion.<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
CenturyLink Cloud: The Leader in Enterprise Cloud Services.<br>
Learn Why More Businesses Are Choosing CenturyLink Cloud For<br>
Critical Workloads, Development Environments &amp; Everything In Between.<b=
r>
Get a Quote or Start a Free Trial Today.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D119420431&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D119420431&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>

--001a11c30600c1925904f0e6374b--