summaryrefslogtreecommitdiff
path: root/bd/eb54d30d7f01855b3d14aa26a4d56d248559a9
blob: 244b52202e5f503e98b9e956c6f862e4e5dfccc2 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
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 <marek@palatinus.cz>) id 1Rbas6-0002VZ-HZ
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Dec 2011 16:42:58 +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 1Rbas2-0005Fo-DU
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Dec 2011 16:42:58 +0000
Received: by eaal1 with SMTP id l1so4458064eaa.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 16 Dec 2011 08:42:48 -0800 (PST)
Received: by 10.204.9.218 with SMTP id m26mr3167053bkm.44.1324053434307; Fri,
	16 Dec 2011 08:37:14 -0800 (PST)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.204.168.15 with HTTP; Fri, 16 Dec 2011 08:36:43 -0800 (PST)
In-Reply-To: <CAJ1JLttMWog=QSLmmM9HiZLQ2UU9sPmwAs2wVQoetW3yjMRPow@mail.gmail.com>
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
	<CABsx9T1wksXjLy=EC6dK1WtVFEayL-HgXWtENgSPXhU6Du2Srg@mail.gmail.com>
	<1323791208.31194.YahooMailNeo@web121013.mail.ne1.yahoo.com>
	<201112131622.08158.andyparkins@gmail.com>
	<CAJna-HiR0qrOp2sG0hb=5bJ2H60y7QwC8BiHDVR9=kiV20W0vA@mail.gmail.com>
	<CAJ1JLttMWog=QSLmmM9HiZLQ2UU9sPmwAs2wVQoetW3yjMRPow@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Fri, 16 Dec 2011 17:36:43 +0100
X-Google-Sender-Auth: 0wc44JkanehdnrcnX-Ol5CwE-eA
Message-ID: <CAJna-HhuoTe3pn_S16UVLErP9iKTod6Jumy-_0cQ0=NqbrAupw@mail.gmail.com>
To: Rick Wesson <rick@support-intelligence.com>
Content-Type: multipart/alternative; boundary=0015175d67ae9d941604b43836ca
X-Spam-Score: 2.3 (++)
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
	1.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rbas2-0005Fo-DU
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2011 16:42:58 -0000

--0015175d67ae9d941604b43836ca
Content-Type: text/plain; charset=ISO-8859-1

OK, I'm ignoring your sarcastic style, I just wanted to support the URL
idea, which is KISS attitude, in the oposite of everything else proposed
here. I'm really affraid of over-engineering the aliases, which will make
it hard to implement in clients. Somebody noticed account implementation in
standard client - yes, it's good example of fail.

I still don't see any serious issue with the URL proposals. And sipa's idea
of posting back the transaction ID is also interesting, prividing yet
another flexibility in implementation and possible usage.

Btw, Rick, feel free to provide me some relevant RFCs which are solving
similar problems like BIP 15. And no, it's not sarcasm, I really want to
learn something new. Until now I just feel we're reinventing wheel or
raping some stuff which we should not touch at all (DNS).

slush

On Fri, Dec 16, 2011 at 4:52 PM, Rick Wesson
<rick@support-intelligence.com>wrote:

> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum.cz> wrote:
> > I really like this proposal with standard URLs. All other proposals like
> DNS
> > mapping or email aliases converted to URLs with some weird logic looks
> > strange to me.
>
> wow, really. Maybe you could review some RFCs, there are thousands of
> examples where some really smart engineers chose the exact opposite
> path which you propose below.
>
> -rick
>
>

--0015175d67ae9d941604b43836ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK, I&#39;m ignoring your sarcastic style, I just wanted to support the URL=
 idea, which is KISS attitude, in the oposite of everything else proposed h=
ere. I&#39;m really affraid of over-engineering the aliases, which will mak=
e it hard to implement in clients. Somebody noticed account implementation =
in standard client - yes, it&#39;s good example of fail.<div>

<br></div><div>I still don&#39;t see any serious issue with the URL proposa=
ls. And sipa&#39;s idea of posting back the transaction ID is also interest=
ing, prividing yet another flexibility in implementation and possible usage=
.<div>

<br></div><div>Btw, Rick, feel free to provide me some relevant RFCs which =
are solving similar problems like BIP 15. And no, it&#39;s not sarcasm, I r=
eally want to learn something new. Until now I just feel we&#39;re reinvent=
ing wheel or raping some stuff which we should not touch at all (DNS).</div=
>

<div><br></div><div>slush<br><div><br></div><div><div><div class=3D"gmail_q=
uote">On Fri, Dec 16, 2011 at 4:52 PM, Rick Wesson <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:rick@support-intelligence.com">rick@support-intelligence.co=
m</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, Dec 15, 2011 at 4:=
07 PM, slush &lt;<a href=3D"mailto:slush@centrum.cz">slush@centrum.cz</a>&g=
t; wrote:<br>


&gt; I really like this proposal with standard URLs. All other proposals li=
ke DNS<br>
&gt; mapping or email aliases converted to URLs with some weird logic looks=
<br>
&gt; strange to me.<br>
<br>
</div>wow, really. Maybe you could review some RFCs, there are thousands of=
<br>
examples where some really smart engineers chose the exact opposite<br>
path which you propose below.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-rick<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blo=
ckquote></div></div></div></div></div>

--0015175d67ae9d941604b43836ca--