Add in-repo BIP70 extension registration page#36
Conversation
|
Technical ACK -- this is technically true and technically an improvement, but, really this text is talking narrowly about extending the protobufs protocol definition. More widely, any extensions should be documented in a BIP. |
|
Any suggestions on the wording to make that clear? For now it may be best to just add something along the lines of "This page is only to avoid conflicts; you should also write a BIP document describing your extension as well." |
|
ACK. RE: extensions should be documented in a BIP: only if they prove to be useful. I expect there will be "we thought it was a good idea at the time" extensions that never become BIPS. |
|
Idea: add an explicit private/experimental-use-only numbering range. |
|
Good point. Most specs that must allocate number/name-spaces include
|
|
Y'all like making things complicated... RE: experimental use range: NACK on that idea, because then there is pain when a successful experiment "needs" to change numbers to be Officially Supported. See the history of the x-foo "experimental" MIME types for a good example of why not to go that way. RE: vendor-specific range: I don't like that either, for the same reason (successful vendor extensions get used by multiple vendors, then you have pain if you need to support the same feature as both a vendor and a standard extension). |
|
Well the general point is to let people self-organize, rather than centrally administer. |
|
@jgarzik Careful - I'll suggest we use 128-bit UUIDs... |
Add in-repo BIP70 extension registration page
Clarify multiverse documentation
Follow-up to 549afce