Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.175 as permitted sender)
	client-ip=209.85.161.175; envelope-from=jordanmack1981@gmail.com;
	helo=mail-gx0-f175.google.com; 
Sender: Jordan Mack <jordanmack1981@gmail.com>
Message-ID: <4EEF8F13.70508@parhelic.com>
Date: Mon, 19 Dec 2011 11:22:59 -0800
From: Jordan Mack <jordanmack@parhelic.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
	<CAJna-HjyZv2y9grNdnKKG8k6tn7jdW=zL=vtrALpeW8jkuzV6Q@mail.gmail.com>
	<CAGQP0AEEzOjc2ayOJYgs_oh4RG91Dp4JSHUjyPX=qdp+ri6oSg@mail.gmail.com>
	<201112191130.43721.luke@dashjr.org>
	<4EEF6EA2.4060709@parhelic.com>
	<CAJna-HgjkC95pt+REmLi2tUh7MVmP-nYwLgzCzrK78qBmEcE_Q@mail.gmail.com>
	<4EEF7EB4.6070800@parhelic.com>
	<CAJna-Hgq2CLq+bKxHweGtH4ujjYoNtbBY25XwdQXOd4GNdEnyg@mail.gmail.com>
In-Reply-To: <CAJna-Hgq2CLq+bKxHweGtH4ujjYoNtbBY25XwdQXOd4GNdEnyg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list

If alias resolution was guaranteed to always be just the address, then 
yes, I would opt for no serialization at all. A simple plain text 
response of an address is about as simple as it can get.

There are already a lot of good ideas floating around about how the 
alias protocol could be extended. Is it really going to stay that simple 
for long? I would personally much just have a serialized response 
upfront, rather than having to worry about backward compatibility in the 
future.

On 12/19/2011 10:17 AM, slush wrote:
> 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.