Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rcg79-0002GC-4b for bitcoin-development@lists.sourceforge.net; Mon, 19 Dec 2011 16:30:59 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Rcg73-0000Zt-IS for bitcoin-development@lists.sourceforge.net; Mon, 19 Dec 2011 16:30:59 +0000 Received: from ishibashi.localnet (fl-184-4-160-40.dhcp.embarqhsd.net [184.4.160.40]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 1AF07560005; Mon, 19 Dec 2011 16:30:48 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Mon, 19 Dec 2011 11:30:41 -0500 User-Agent: KMail/1.13.7 (Linux/3.1.4-gentoo; KDE/4.7.3; x86_64; ; ) References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> In-Reply-To: X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583 X-PGP-Key-ID: 665FC11DD53E9583 X-PGP-Keyserver: x-hkp://subkeys.pgp.net MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201112191130.43721.luke@dashjr.org> X-Spam-Score: -2.4 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -2.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Rcg73-0000Zt-IS Subject: Re: [Bitcoin-development] [BIP 15] Aliases 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: Mon, 19 Dec 2011 16:30:59 -0000 On Monday, December 19, 2011 2:56:09 AM Jorge Tim=F3n wrote: > For the "answer format" JSON seems ok, I'd prefer we stick to simple standards. HTTP alone should really be fine to build on... JSON in particular has very poor language support, and cannot reasonably=20 represent binary data (such as a custom output script). The HTTP=20 specification, however, allows binary data in multipart content just fine.