Skip to content
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

Merged
merged 1 commit into from
Apr 24, 2014

Conversation

petertodd
Copy link
Contributor

Follow-up to 549afce

@jgarzik
Copy link
Contributor

jgarzik commented Mar 17, 2014

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.

@petertodd
Copy link
Contributor Author

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."

@gavinandresen
Copy link
Contributor

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.

@petertodd
Copy link
Contributor Author

Idea: add an explicit private/experimental-use-only numbering range.

@jgarzik
Copy link
Contributor

jgarzik commented Mar 18, 2014

Good point. Most specs that must allocate number/name-spaces include

  • An experimental range. Anybody is free to use these without a BIP for experiments etc. If you get clobbered and break something, you get to keep both pieces.
  • A vendor-specific range. Any vendor rolling out vendor-specific extensions uses this range.

@gavinandresen
Copy link
Contributor

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).

@jgarzik
Copy link
Contributor

jgarzik commented Mar 18, 2014

Well the general point is to let people self-organize, rather than centrally administer.

@petertodd
Copy link
Contributor Author

@jgarzik Careful - I'll suggest we use 128-bit UUIDs...

gmaxwell added a commit that referenced this pull request Apr 24, 2014
Add in-repo BIP70 extension registration page
@gmaxwell gmaxwell merged commit 856bb84 into bitcoin:master Apr 24, 2014
real-or-random added a commit to real-or-random/bips that referenced this pull request Aug 10, 2022
guggero pushed a commit to guggero/bips that referenced this pull request Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants