Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UpZKI-0000Zp-DT for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 07:30:38 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UpZKG-0001f1-Iv for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 07:30:38 +0000 Received: from [37.143.74.116] (helo=[192.168.0.102]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1UpZKA-0005PW-1Q; Thu, 20 Jun 2013 09:30:30 +0200 From: Tamas Blummer Content-Type: multipart/alternative; boundary="Apple-Mail=_82274919-95DF-485D-9943-ED393C3F9E3E" Message-Id: <4DE0E45E-BB48-4DFF-9C86-ACBE312B3049@bitsofproof.com> Date: Thu, 20 Jun 2013 09:30:29 +0200 To: bitcoin-development@lists.sourceforge.net Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1371713436; df345564; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1UpZKG-0001f1-Iv Subject: Re: [Bitcoin-development] Missing fRelayTxes in version 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: Thu, 20 Jun 2013 07:30:38 -0000 --Apple-Mail=_82274919-95DF-485D-9943-ED393C3F9E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Mike, The issue with the current parser is that those fields are conditionally = optional on that there will be no subsequent fields added. If there will be further fields they will become manadory.=20 =20 Why not bump the version and parse the fields as mandatory from then on? = This would be backward compatible and cleaner going forward. Tamas Blummer http://bitsofproof.com --Apple-Mail=_82274919-95DF-485D-9943-ED393C3F9E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Mike,

The issue with the current parser is that those = fields are conditionally optional on that there will be no subsequent = fields added.
If there will be = further fields they will become manadory. 
 
Why not bump the version and parse the fields as = mandatory from then on? This would be backward compatible and = cleaner
going = forward.

Tamas Blummer

= --Apple-Mail=_82274919-95DF-485D-9943-ED393C3F9E3E--