Since this RFC is still in review, I'd skip the "Errata" mode of writing in favor of having just the latest process described in the document (which is way more convenient to use as a reference document).

Maybe we should exceptionally allow for amending this RFC in the future as well, as it is more about the process (meta-rfc?) than the common public API of our SDKs.

I can see why true RFCs pertaining to the common public APIs of the SDKs would be considered "immutable" once Accepted (meaning a change to the API would involve both a new MAJOR - or is it MINOR? - version as per semver, but also a new RFC)...

But "meta-rfc" could maybe be less strict, autorizing modifications as long as there is an History section at the end that points to commits for the old versions of the meta-rfc?

I see what you're saying @simonbasle, but I don't think it matters that much.

Out of curiosity, I checked to see what IETF does. They track errata but they seem to update the document. I don't think we need to track errata as formally as they do, but maybe it'd be better to have a section on errata and just have updates on the document (since git will remember the changes).

In other words, errata would state:
Errata:
01: Missing formal definitions on states and transitions. Added 20150120.
02: Clarification on process needed. Added 20150120.

This makes it easy on the casual reader, but easy to track.

Or we could use issues and labels with errata, but that just seems like it's a step too far.

Example from IETF on the JSON RFC: http://www.rfc-editor.org/errata_search.php?rfc=7159

if you mean just an errata/history of changes with 1 line per change (bonus point if link to commit id), then I totally agree.

What I think is far less useful is having the whole original content, then an errata which is the whole content again but with updates inline

Updated with the changes now inline, only one errata line stating that something has changed. WDYT?

this looks, good minus the code block formatting typo (see inline comment)

@ingenthr is that what you had in mind? If so we should do a final round of vote here and get the updated merged in, since technically we are already using that method.

It's close, but not exactly there. The challenge for me is that it inline mentions things that are in effect deprecated. Since we're treating it as errata, I'd generally expect the main body of the document to be clean (not mention the errata) and just have a note in there at the end. Does that make sense?

@ingenthr okay I'll give it another pass

@ingenthr I'll update this one with the latest changes too.