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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1Wznz9-0004fP-Ae
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 14:15:39 +0000
X-ACL-Warn:
Received: from mail-ve0-f170.google.com ([209.85.128.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wznz7-0005Vo-Le
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 14:15:39 +0000
Received: by mail-ve0-f170.google.com with SMTP id i13so2051782veh.15
for <bitcoin-development@lists.sourceforge.net>;
Wed, 25 Jun 2014 07:15:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc:content-type;
bh=CQNiXRHZMkERERSA2oARhKbNVWsbWp9HXJTMkGoreRY=;
b=hfLA0NHOsFGKAUeLemSDE+4fAM7xQ8X0CUJs6wB/8eWAVwsm9J+SUFwWBt2JQWTgjV
wOQSzJAylJx3/DOTRaFvM7FapWbozXr06n9VW4eFekGGOsBql0k6Pw5poK/hKLZb+iUB
m8QU3y4kGlBBwTOzyv1Ekc4CtRChi1OJH7eNuRWR+P8ndfw0/LSzA/3apAZGXHsdCpQk
CGB0POUwwf8VW163dqnooqfKA81B0LDFw8tMz/wtUHUu0AhsEJzvsErc/vX0WYNuGAMa
BYMmLAXlk5sQ5ZPzKkXS6taHJLzLKZba0j0njEOGsnE/FUks6mz4tTgpMgBgwcpeit7P
22Dw==
X-Gm-Message-State: ALoCoQmzQ7Pb1070OB6xIs8neQvOp9YDaooCN8Xot0PvyJogvNlcn5Vmvo5dKn0S0q9v9oaAAiqf
X-Received: by 10.52.92.12 with SMTP id ci12mr436663vdb.90.1403705731860; Wed,
25 Jun 2014 07:15:31 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.58.198.69 with HTTP; Wed, 25 Jun 2014 07:15:01 -0700 (PDT)
In-Reply-To: <CANEZrP0ce4MMX2hOhcGVWt23L_CMn6Cmj9_Okqd0BR9seQXJew@mail.gmail.com>
References: <CANEZrP3iyQ9zQ+hDnooxrjdBO+_Fj+nAkK1Skgk+Gb4gkidPhQ@mail.gmail.com>
<CAJHLa0Omiz+UhGjSKgYU7+b2YY7aN23w7o8CQntqMePFs7LkjA@mail.gmail.com>
<CANEZrP06gk-JhKaNpvYUTfjFq9AGnCay9=pjUGpVMjMSuX3_ew@mail.gmail.com>
<CAJna-HhX8HOci0KMe4ZScr4QW792S3n5twvU0QhbQe1N_3q7_w@mail.gmail.com>
<6E6F88E9-5698-419B-927C-F65A5FCABBE9@gmail.com>
<CAJHLa0PYfuJg3daPvzPFZpFz7ezH2RHpJ8zyz2g1NDKppM7rWA@mail.gmail.com>
<BBF86C9B-6B3D-4A03-AC7B-35619C47091F@gmail.com>
<CABsx9T13yksenx5aYd4HVqTyVjARx9aTHy=Neu64p6k9FnRRVw@mail.gmail.com>
<C95DB811-9E6A-4EA2-AE8F-83595C3AC817@gmail.com>
<CANEZrP0ce4MMX2hOhcGVWt23L_CMn6Cmj9_Okqd0BR9seQXJew@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Wed, 25 Jun 2014 16:15:01 +0200
X-Google-Sender-Auth: hkT6AAYpizSQS1v1J21BuGIpIV4
Message-ID: <CAJna-HiRChr4M9QL_7ZeKQeV7m5M4-ysnERB1DmK1itJMaGucQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=20cf3071c6c684741704fca9b566
X-Spam-Score: 1.0 (+)
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
X-Headers-End: 1Wznz7-0005Vo-Le
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed BIP 70 extension
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: Wed, 25 Jun 2014 14:15:39 -0000
--20cf3071c6c684741704fca9b566
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn <mike@plan99.net> wrote:
>
> The protocol is there to contain features! There is zero benefit to
> slavishly following some religious notion of purity or minimalism here.
>
Good standard must be explicit as much as possible. Having million optional
fields with ambiguous meaning is even worse than not having these fields.
HTTP status codes are good example. There are hundreds of them, still
applications understands just few of them, because other have ambiguous
meaning and software don't know how to handle them.
Good example of such over-engineering is also XMPP. XMPP has milions
extensions and features, but look at Jabber clients; call yourself lucky
when you can send messages and files, although there're various extensions
like searching for contacts (something which has be working in ICQ decade
ago), voice support, end to end encryption or alerting users. These
features are defined, but not widely implemented, because its definition is
vague or the feature is abused because of poor design.
Please don't over-engineer payment protocol.
Thank you for your attention.
slush
--20cf3071c6c684741704fca9b566
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 25, 2014 at 10:25 AM, Mike Hearn <span dir=3D"ltr"><<a href=3D"m=
ailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>The protocol is there to contain features! There is zero benefit to slavis=
hly following some religious notion of purity or minimalism here.</div></di=
v>
</div></div></blockquote><div><br></div><div>Good standard must be explicit=
as much as possible. Having million optional fields with ambiguous meaning=
is even worse than not having these fields.</div><div><br></div><div>
HTTP status codes are good example. There are hundreds of them, still appli=
cations understands just few of them, because other have ambiguous meaning =
and software don't know how to handle them.</div>
<div><br></div><div>Good example of such over-engineering is also XMPP. XMP=
P has milions extensions and features, but look at Jabber clients; call you=
rself lucky when you can send messages and files, although there're var=
ious extensions like searching for contacts (something which has be working=
in ICQ decade ago), voice support, end to end encryption or alerting users=
. These features are defined, but not widely implemented, because its defin=
ition is vague or the feature is abused because of poor design.</div>
<div><br></div><div>Please don't over-engineer payment protocol.</div><=
div><br></div><div>Thank you for your attention.</div><div><br></div><div>s=
lush</div><div><br></div><div><br></div></div></div></div>
--20cf3071c6c684741704fca9b566--
|
