summaryrefslogtreecommitdiff
path: root/37/836c069e615321bd9b3879692f1dd3b43cb82c
blob: e25d6afb34a2d00747e4fafd4309a3bb8917d5a1 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <walter.stanish@gmail.com>) id 1TdCcB-0000D4-El
	for bitcoin-development@lists.sourceforge.net;
	Tue, 27 Nov 2012 04:17:43 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.47 as permitted sender)
	client-ip=209.85.214.47; envelope-from=walter.stanish@gmail.com;
	helo=mail-bk0-f47.google.com; 
Received: from mail-bk0-f47.google.com ([209.85.214.47])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1TdCcA-0002vf-DD
	for bitcoin-development@lists.sourceforge.net;
	Tue, 27 Nov 2012 04:17:43 +0000
Received: by mail-bk0-f47.google.com with SMTP id j4so3478445bkw.34
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 26 Nov 2012 20:17:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.13.28 with SMTP id z28mr4115445bkz.113.1353989856036; Mon,
	26 Nov 2012 20:17:36 -0800 (PST)
Sender: walter.stanish@gmail.com
Received: by 10.204.49.133 with HTTP; Mon, 26 Nov 2012 20:17:35 -0800 (PST)
In-Reply-To: <CAJ1JLttTPi9XNwCGyvbvx8TXqbLyk0KxFRHxv_8UB+tEQrKvvA@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<CACwuEiP7CGeZZGW=mXwrFAAqbbwbrPXTPb8vOEDuO9_96hqBGg@mail.gmail.com>
	<CAAS2fgSY8hHiCJYEDv=y48hYRJJtB-R5EBX8JLz6NivBm+Z9PQ@mail.gmail.com>
	<CACwuEiMjf8WYOpfmzHUHMa-sy2VsJHaUNj1cj722Y=P_sosbvw@mail.gmail.com>
	<CAJ1JLtuJ8HQri7++2bodc2ACRrE7Y48oy0HkPR8d400MooHaqA@mail.gmail.com>
	<CACwuEiMgcv09U2P9dD58x-oMXMSg==fPYo0yRLsqzyuax96Eqw@mail.gmail.com>
	<CAJ1JLttTPi9XNwCGyvbvx8TXqbLyk0KxFRHxv_8UB+tEQrKvvA@mail.gmail.com>
Date: Tue, 27 Nov 2012 12:17:35 +0800
X-Google-Sender-Auth: Vvw6SZjMKhjl3FQlPqZeZEvWe90
Message-ID: <CACwuEiNZobcpR4g=1AH=JReZFzHmH=6exNGTaPBBjm+q5eR9vg@mail.gmail.com>
From: Walter Stanish <walter@stani.sh>
To: Rick Wesson <rick@support-intelligence.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(walter.stanish[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1TdCcA-0002vf-DD
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
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: Tue, 27 Nov 2012 04:17:43 -0000

>> We are not establishing an IETF working group, which is an option that
>> was explored prior to the Paris meeting and has been sidelined at
>> present for depth-of-bureaucracy by the backing commercial entities.
>> Rather, we are establishing a top-level IANA registry group. This is
>> not anticipated by the IETF old-guard working with us to be either (a)
>> controversial or (b) possible to block.
>
> My last note in this sub-thread.

Mine too!

> There are no IANA registry groups, there is no such thing, and no way
> to form one.

Reading between the lines, I believe this phrase, which is not my own
but that of experienced IETF staff, refers to the groups visible at
http://www.iana.org/protocols/ (which you yourself cited). Whether it
is formally used or not is unknown to me.

> The IETF can ask the IANA to form a registry but these
> things take lots of support and take a long time,

Expert opinion estimates six weeks, and by current estimates, we
should have an arrival circa February.

> and these are only
> created through standards track RFC. ICANN runs the IANA and there is
> no such framework that you elude to. Review
> http://www.iana.org/protocols/

I would like to suggest that perhaps exactly this sort of banter is an
excellent illustration for the Bitcoin community of what we have been
up against in this (conceivable simple an public benefit oriented)
endeavour. If you also look at the fact that the ISO4217 registry (to
take currency/commodity codes as just one example) there is apparently
not even a public list of requirements for codepoint issue.  This sort
of thing is *exactly* why the internet community appears to
desperately need an open registry - allowing public internet bodies
(IANA) to function to support innovation and interconnectivity for all
sectors of the internet's various financial communities so that
anyone, including innovators, can obtain interoperability via simple,
hassle-free paths, without encountering self-important bureaucrats.

We anticipate victory circa February.

- Walter