-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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