Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove legacy-version-string-field-format section #120

Closed
daidoji opened this issue Jan 13, 2024 · 2 comments
Closed

Remove legacy-version-string-field-format section #120

daidoji opened this issue Jan 13, 2024 · 2 comments

Comments

@daidoji
Copy link

daidoji commented Jan 13, 2024

Although entirely appropriate that keripy and associated tools be forced to implement this legacy version string format, for the purpose of this self-contained specification perhaps we ought to remove this section or make it an OPTIONAL or SHOULD for implementers.

If we want to keep it a SHALL, then maybe its better to just spell it out as we have done so noting particularly that sniffing the message at the VVV vs VV parts of the string are appropriate to differentiate the types of message.

Or perhaps, as this spec doesn't necessarily depend on any legacy specifications (although production deployments absolutely do) we should remove it as a requirement entirely anticipating these deployments migrate to the protocol as will be specified.

https://trustoverip.github.io/tswg-keri-specification/#legacy-version-string-field-format

@daidoji
Copy link
Author

daidoji commented Jan 16, 2024

As an addendum to this issue, all of the JSON examples in the spec use the legacy version id in their messages and not the one defined as preferred in the spec. Even if we don't remove the legacy section it may be a good idea to update the versions for all the messages.

@m00sey
Copy link
Contributor

m00sey commented Feb 6, 2024

Legacy format has been moved to the CESR spec

@m00sey m00sey closed this as completed Feb 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants