KERI verion 1.XX version string

[SmithSamuelM]

KERI version 2.00 has a new version string field format. This is meant to document the version 1.XX format.
A compliant regex parser can recognize both formats, and new KELs for version 1.XX can be created using the new format while
old KELs created using the old format.

Version 1. XX version string

The format of the version string is KERIvvSSSShhhhhh_. The first four characters KERI indicate the protocol. The CESR encoding standard supports multiple protocols, KERI being one of them. The next two characters, vv provide the lowercase hexadecimal notation for the major and minor version numbers of the version of the KERI protocol specification. The first v provides the major version number and the second v provides the minor version number. For example, 01 indicates major version 0 and minor version 1 or in dotted-decimal notation 0.1. Likewise 1c indicates major version 1 and minor version decimal 12 or in dotted-decimal notation 1.12. The next four characters SSSS indicate the serialization kind in uppercase. The four supported serialization kinds are JSON, CBOR, MGPK, and CESR for the JSON, CBOR, MessagePack, and CESR serialization standards, respectively [[spec: RFC4627]] [[spec: RFC4627]] [[ref: CBOR]] [[ref: RFC8949]] [[ref: MGPK]] [[ref: CESR]]. The next six characters provide in lowercase hexadecimal notation the total length of the serialization inclusive of the version string an any prefixed characters or bytes. This length is total number of characters in the serialization of the KERI message body. The maximum length of a given KERI message body is thereby constrained to be 2²⁴ = 16,777,216 characters in length. The final character _ is the version string terminator. This enables later versions of KERI to change the total version string size and thereby enable versioned changes to the composition of the fields in the version string while preserving deterministic regular expression extractability of the version string.

Although a given KERI message body serialization kind may have characters or bytes such as field map delimiters or framing codes that appear before i.e., prefix the version string field in a serialization, the set of possible prefixes for each of the supported serialization kinds is sufficiently constrained by the allowed serialization protocols to guarantee that a regular expression can determine unambiguously the start of any ordered field map serialization that includes the version string as the first field value. Given the length from the version string, a parser may then determine the end of the serialization so that it can extract the full KERI message body from the stream without first deserializing it. This enables performant stream parsing and off-loading of KERI streams that include any or all of the supported serialization types.