Fix all KERI implementations generating v1 CESR to encapsulate all CESR and ACDC messages, with attachments, in a generic group code.

[kentbull]

Feature request description/rationale

From today's call we need to fix all KERI CESR v1 generators to properly wrap all KEL and TEL messages, along with their attachments, in group codes.

This completes what is necessary for both forward and backward compatibility.

[daidoji]

What does that mean? Json field maps are already top-level cesr codes and the attachments follow in order. Is this dialect going to change?

[kentbull]

Right now KEL and tell messages have been occurring as a combination of

• CESR Message followed by
• CESR Attachments.

This change would wrap those in a generic group code so that all CESR messages are uniform in the sense that they are all wrapped in group codes. This allows CESR 2.0 parsers to pull the right number of bytes off the stream for CESR 1.0 without having to interrogate the attachment groups where the count codes count number of primitives and not number of bytes.

[kentbull]

So it would change to:

• Generic Group Code
  • (nested) CESR Message
  • (nested) CESR Attachments

[SmithSamuelM]

The generic group code is

GenericGroup: str = '-W' # Generic Material Quadlets BigGenericGroup: str = '-0W' # Big Generic Material Quadlets

This was added in a recent pull request to keripy main

[SmithSamuelM]

@daidoji @kentbull @m00sey @pfeairheller

In order for CESR 2.0 parsers and CESR 1.0 parsers to be able to parse CESR streams that interleave at the top level CESR 1.0 and CESR 2.0 we have to make some accomodations for different cases.

All versions of CESR parsers must now support the ProtocolGenusVersion Group Code. This code specifies what version of CESR the following elements of the stream are encoded with. Going forward all streams must start the stream with this code. Everytime the connection restarts it must restart with this code. If it switches to a different version of CESR then it injects this code before any elements that use a different version.

There is a not so nice and a nice way for a parser to handle streams that include a version of CESR that parser does not understand. A. The not so nice way is to drop the connection. Since the parser does not know how to parse that version the only thing it can do is drop the connection

B. The nice way is for a parser to recognize at least the top level generic group code or codes for a given version. This way the parser can just drop those groups without having to drop the connection and then when a protocolgenusversion code is seen that the parser supports it can resume parsing. The nice way means that all messages at the top level have to be wrapped in group codes.

This codes include the number of quadlets/triplets of bytes in that group. So the parser doesn't have to descend into the group and parse its contents it just drops that many quadlets/triplets of bytes from the stream and then looks at the next group until it gets a protocolgenusversion code it supports.

For CESR 1.0 this is the Generic Group code -W or -0W.
For CESR 2.0 these are either the universal group codes generic -A, and big -0A, or message+attachment -B, and big -0B

1. CESR 1.0 parser that does not support parsing CESR 2.0. must be able to parse at least the universal group codes from CESR2.0 so it can drop those groups.

2. CESR 2.0 parser that does not support parsing CESR 1.0 must be able to parse at least the generic group code from CESR 1.0 so it can drop those groups.

Going forward the changes to CESR 1.0 are

1. support for generating and parsing the protocolgenus group code
2. wrapping all messages + attachments in the generic group code when generating a stream
3. parsing generic group codes to extract the embedded message plus attachments
4. parsing generic group codes from CESR 2.0 to drop those groups