Namecoin Forum

biolizard89 wrote:Doesn't BIP just use new BIP numbers for new versions?

Right, but I'm saying that since we have more specifications that naturally go through additional revisions that we should just add versioning. Then we can always refer to the same NEP for a given namespace.

I'm assuming that the d namespace will go through at least 2 or 3 more revisions before it calcifies. Why not just have a single reference point for the latest version? If someone needs to see an older version, the history is right there.

Nor is this a binary situation, we can and should use the depreciation method in parallel.

indolering wrote:

biolizard89 wrote:Doesn't BIP just use new BIP numbers for new versions?

Right, but I'm saying that since we have more specifications that naturally go through additional revisions that we should just add versioning. Then we can always refer to the same NEP for a given namespace.

I'm assuming that the d namespace will go through at least 2 or 3 more revisions before it calcifies. Why not just have a single reference point for the latest version? If someone needs to see an older version, the history is right there.

Nor is this a binary situation, we can and should use the depreciation method in parallel.

I don't think an existing namespace should be a NEP. I think individual significant changes to namespaces should be their own NEP. For example, the "expire" field I proposed a while back would be a NEP; that NEP would only describe the changes introduced by the proposal; it wouldn't restate an entire namespace spec. A proposal like "expire" wouldn't go through many revisions.

Or am I misunderstanding you?

biolizard89 wrote:I don't think an existing namespace should be a NEP.

Why wouldn't we codify existing standards as NEPs? I think I'm misunderstanding what you are saying.

biolizard89 wrote: I think individual significant changes to namespaces should be their own NEP. For example, the "expire" field I proposed a while back would be a NEP; that NEP would only describe the changes introduced by the proposal; it wouldn't restate an entire namespace spec. A proposal like "expire" wouldn't go through many revisions.

That makes a lot of sense, Github PRs are not the place to work on drafts of documents. The workflow would push us towards adding new features via new NEPs.

I also think we should have a mandatory "see also" section at the end that links to related standards and the main discussion threads for the standard.

It would be really cool if we worked out a Github.io page that embedded such discussions ... hmm.

indolering wrote:

biolizard89 wrote:I don't think an existing namespace should be a NEP.

Why wouldn't we codify existing standards as NEPs? I think I'm misunderstanding what you are saying.

For the same reason that HTML 3.2 didn't go through the W3C process after the W3C took over from IETF on the HTML spec. Only new things would be NEP's; specs that we already agreed on unanimously (as the id/ and d/ specs seem to be) wouldn't need to be re-specced.

biolizard89 wrote:

indolering wrote:
Why wouldn't we codify existing standards as NEPs? I think I'm misunderstanding what you are saying.

For the same reason that HTML 3.2 didn't go through the W3C process after the W3C took over from IETF on the HTML spec. Only new things would be NEP's; specs that we already agreed on unanimously (as the id/ and d/ specs seem to be) wouldn't need to be re-specced.

We are trying to reduce effort for outside developers: leaving the most important specs on the wiki would be confusing. It's relatively easy to convert mediawiki-markup to markdown and those articles need to get cleaned up anyway.