Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RchnF-0001ON-NC for bitcoin-development@lists.sourceforge.net; Mon, 19 Dec 2011 18:18:33 +0000 X-ACL-Warn: Received: from mail-ey0-f175.google.com ([209.85.215.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RchnE-0000O0-KF for bitcoin-development@lists.sourceforge.net; Mon, 19 Dec 2011 18:18:33 +0000 Received: by eaal1 with SMTP id l1so7256757eaa.34 for ; Mon, 19 Dec 2011 10:18:26 -0800 (PST) Received: by 10.205.132.14 with SMTP id hs14mr2026298bkc.130.1324318706260; Mon, 19 Dec 2011 10:18:26 -0800 (PST) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.204.168.15 with HTTP; Mon, 19 Dec 2011 10:17:55 -0800 (PST) In-Reply-To: <4EEF7EB4.6070800@parhelic.com> References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> <201112191130.43721.luke@dashjr.org> <4EEF6EA2.4060709@parhelic.com> <4EEF7EB4.6070800@parhelic.com> From: slush Date: Mon, 19 Dec 2011 19:17:55 +0100 X-Google-Sender-Auth: pEmj4e_V7S57EqFXQPyGnhP04J0 Message-ID: To: Jordan Mack Content-Type: multipart/alternative; boundary=001517402a800e5ba504b475fa7d X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message 0.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RchnE-0000O0-KF Cc: bitcoin-development@lists.sourceforge.net 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 18:18:33 -0000 --001517402a800e5ba504b475fa7d Content-Type: text/plain; charset=ISO-8859-1 In my opinion, there's not necessary any payload format (json, xml, multipart). In keeping stuff KISS, everything we need is just an address in response + potentially some stuff like HTTP redirects (for providing additional compatibility for proposal of bitcoin URIs with "amount", "label" and other parts). I don't see reason why we need some extra payload yet. slush On Mon, Dec 19, 2011 at 7:13 PM, Jordan Mack wrote: > If the idea is to "KISS", and provide a method that is both quick and > easy to implement for the average developer, then JSON is a stand out > option. Using HTTP for the data interchange will make things difficult > for a lot of developers if multipart responses are used. JSON will be > greeted with open arms. > > --001517402a800e5ba504b475fa7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In my opinion, there's not necessary any payload format (json, xml, mul= tipart). In keeping stuff KISS, everything we need is just an address in re= sponse + potentially some stuff like HTTP redirects (for providing addition= al compatibility for proposal of bitcoin URIs with "amount", &quo= t;label" and other parts). I don't see reason why we need some ext= ra payload yet.

slush

On Mon, Dec 19,= 2011 at 7:13 PM, Jordan Mack <jordanmack@parhelic.com> wrote:
If the idea is to "KISS", and provide a method that is both quick= and
easy to implement for the average developer, then JSON is a stand out
option. Using HTTP for the data interchange will make things difficult
for a lot of developers if multipart responses are used. JSON will be
greeted with open arms.

--001517402a800e5ba504b475fa7d--