Add in-repo BIP70 extension registration page #36

Follow-up to 549afce2ee1339370dec52787548645ab1f8c3c5

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

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

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