<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn <span dir="ltr"><<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The protocol is there to contain features! There is zero benefit to slavishly following some religious notion of purity or minimalism here.</div></div>
</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 applications 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. 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.</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>slush</div><div><br></div><div><br></div></div></div></div>