Say what the payload version does not protect - #28
Conversation
A reader of the merged page took the version bits to be what stops a terms table entry being redefined under an identifier already issued. They do not, and cannot. The version says where the fields sit, so redefining a row moves nothing, the bits stay 0, every reader accepts the payload and every one answers with the new meaning. The rule that an index is never reused or repointed is the only thing standing in the way, and the page already states it in the Terms section. What it did not say is that no mechanism enforces it, which is what let a careful reader believe the format had them covered. Says so in the Version section, where the misreading happens, rather than repeating the rule in the Terms section, where it is already stated once in the place it governs.
The paragraph ended by saying what the rule against reusing or repointing a Terms index is, which this document already says as a MUST in the Terms section, and it said it at more length and less plainly than the original. A specification that states one rule twice invites the two statements to drift apart, and a reader who finds the weaker one first has no way to know there is a stronger one. The new point the paragraph makes is worth keeping, which is that the version protects the layout rather than the meaning, so a redefinition would pass every check the format can make. That stays. The restatement becomes a pointer to where the rule is actually written. The closing clause is gone with it. It read as an aphorism rather than a specification, and what it asserted about people keeping rules is not something this document is in a position to say.
Revised, per James Rosewell's instruction to change the wording before mergingHe did not say what to change, so rather than guess I read the rest of the document and found something concrete. The last three sentences restated a rule this specification already carries. Under Terms it already says:
That is the same rule, written as a MUST, and written better. The paragraph here restated it at more length and less plainly, and ended on a clause about people keeping rules that is not something a specification is in a position to assert. A specification that states one rule twice invites the two statements to drift apart, and a reader who finds the weaker statement first has no way to know a stronger one exists. What changedThe new point stays, which is that the version protects the layout rather than the meaning, so redefining a row would move nothing, the version would stay 0, and every reader would accept the payload and answer with the new meaning for an identifier issued under the old one. Nothing in the format catches that. The restatement becomes a pointer to where the rule is written:
Three sentences replace four, no rule is stated twice, and the aphorism is gone. If this was not what was meantSay so and I will change it again. This is a reading of the document rather than a reading of what James wanted, and the subject of the paragraph is what a guarantee does not cover, so wording is the whole substance of it. Written with AI assistance and needs human review. |
One paragraph in the Version section of the 51Did identifier layout.
A reader of the merged page took the version bits in flags 4 and 5 to be what stops a row of the Terms table being redefined under an identifier already issued. They are not, and cannot be. The version says where the fields sit. Redefining a row moves nothing, so the bits stay 0, every reader accepts the payload, and every one of them answers with the new meaning for an identifier issued under the old one.
The rule that an index is never reused or repointed is the only thing standing in the way, and the page already states it in the Terms section at the point it governs. What the page did not say is that nothing enforces it, which is precisely what let a careful reader conclude the format had them covered.
The note goes in the Version section rather than the Terms section, because that is where the misreading happens. The existing rule stays where it is and is not repeated.
This came from a real misreading rather than a hypothetical one. Someone implementing against the merged specification reached the wrong conclusion and said so, which is the only evidence that a sentence is missing.