Update EIP-5267: Move to Last Call

[frangio]

No description provided.

[eth-bot]

All tests passed; auto-merging...

(pass) eip-5267.md

classification
updateEIP

• passed!

[github-actions]

The commit 9060947 (as a parent of c693f67) contains errors.
Please inspect the Run Summary for details.

[xinbenlv]

Congrats on moving to last call. This is an long awaited improvement~

Cross posting some editorial questions hoping to get @frangio 's clarification I left on FEM

---

Discussion: can you share the rationale of extensions being format as uint256 instead of bytes32 ?

Extensions are described by their EIP numbers because EIP-712 states: “Future extensions to this standard can add new fields […] new fields should be proposed through the EIP process.”

Here EIP-712 didn't specify what format of fields will be, so it's open to future designer to design, EIP-5267 is one of such future design.

Q1. Could author share your thoughts into why choose the format of extensions an uint256[] vs bytes32[] or generally bytes? This is one of the problem that EIP-5750 is trying to address and thus when EIP-5267 made a design choice that's different, I'd love to learn the rationale and understand it better. When using uint256[] and describe in EIP-5267 as it needs to be a EIP number, does it mean only EIP number will be allowed in the extension as a way to provide extending information? Will EIP number be sufficient? Do you anticipate some of these elements could be re-purposed in the future?

Q2. In the reference implementation,

    return (
          hex"0d", // 01101
          "Example",
          "",
          block.chainid,
          address(this),
          bytes32(0),
          new uint256[](0)
      );

and also in javascript

  if (extensions.length > 0) {
    throw Error("Extensions not implemented");
  }

Is it intentional that in author's perspective the extension shall at least have one element?

[frangio]

Is it intentional that in author's perspective the extension shall at least have one element?

No. This is clear in the specification. There are no constraints on the length of the extensions array. Additionally the Solidity reference implementation returns an empty array.

Will reply to the other questions in the discussions thread as I don't think they are editorial.

[xinbenlv]

Will reply to the other questions in the discussions thread as I don't think they are editorial.

Sure. Some questions are in editorial nature (meaning non-technical) e.g. we suggest spell out / clarify some rationale in some design choices that the author made. But those editorial questions are not merge-blocking and can be addressed in the followup PRs.