Update 0016_public_key_checksum.md to handle leading 1 in checksum (and pubkey)

rfc/0016_public_key_checksum.md

@@ -7,7 +7,7 @@ Type: Convention
 Status: Proposed Standard
 Author: matograine <matograine@zaclys.net>
 Created: 2021-03-07
-Last edited: 2021-03-07
+Last edited: 2021-04-02
 License: AGPL-3
 ```
 
@@ -20,14 +20,17 @@ For compatibility, clients MAY accept checksum based on this last standard for u
 ## Public key format
 
 A public key is to be understood as an Ed25519 public key.
-It is represented as a Base58 string which length ranges {43,44} characters.
+It SHOULD be represented as a Base58 which length ranges {43,44} characters.
+
+It CAN be represented as a shorter Base58 string so implementation MUST handle it.
+
 
 Example of a public key:
 ```
 J4c8CARmP9vAFNGtHRuzx14zvxojyRWHW2darguVqjtX
 ```
 
-Example of two valid public keys referring to the same  Ed25519 binary public key:
+Example of two valid public keys referring to the same Ed25519 binary public key (first SHOULD be preferred):
 ```
 12BjyvjoAf5qik7R8TKDJAHJugsX23YgJGi2LmBUv2nx
 2BjyvjoAf5qik7R8TKDJAHJugsX23YgJGi2LmBUv2nx
@@ -58,10 +61,10 @@ while len(pubkey_byte) > 32:
 ## Checksum display
 
 The checksum aims at verifying the consistency of the public key.
-It consists in three (3) base58 characters.
+It consists in three (3) base58 characters including leading 1.
 It is displayed after the public key, separated by a colon `:`.
 
-Example of two valid representations of a public key with their checksum:
+Example of two valid representations of a public key with their checksum (first SHOULD be preferred):
 ```
 12BjyvjoAf5qik7R8TKDJAHJugsX23YgJGi2LmBUv2nx:8BD
 2BjyvjoAf5qik7R8TKDJAHJugsX23YgJGi2LmBUv2nx:8BD
@@ -70,6 +73,9 @@ Example of two valid representations of a public key with their checksum:
 This function is used when a public key is typed manually on the keyboard (or issue on QRcode reader)
 to avoid sending coins to the wrong public key. Because no control exist on the Duniter protocol.
 
+Implementation SHOULD accept checksum without leading 1 for compatibility.
+Displayed checksum (and pubkey) MUST include leading 1 when it 32 bytes binary array start with zero-bytes.
+
 This technique is better than adding only some checksum bytes at the end of the key, before the base58.encode because:
 - The public key visible for the user is the same.
 - If the user miss some characters, the software client can detect it.