update ref links

This commit is contained in:
brent saner
2024-07-10 01:17:03 -04:00
parent 4e317bd8d2
commit fe2a32e55c
2 changed files with 6 additions and 6 deletions

View File

@@ -52,7 +52,7 @@ NOTE: In the event of the embedded text in this document differing from the onli
[id="proto"]
== Protocol
The WireProto data packing API is a custom wire protocol//message format designed for incredibly performant, unambiguous, predictable, platform-agnostic, implementation-agnostic communication. It is based heavily on the https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.key[OpenSSH "v1" key format^] https://git.r00t2.io/r00t2/go_sshkeys/src/branch/master/_ref/KEY_GUIDE.html#v1_plain_2[(example/details)] packing method.
The WireProto data packing API is a custom wire protocol//message format designed for incredibly performant, unambiguous, predictable, platform-agnostic, implementation-agnostic communication. It is based heavily on the https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.key[OpenSSH "v1" key format^] https://sshref.dev[(example/details via sshref.dev)^] packing method.
It supports arbitrary binary values, which means they can be anything according to the implementation-specific details; a common practice is to encode ("marshal") a Go struct to JSON bytes, and set that as a WireProto field's value.
@@ -120,7 +120,7 @@ Throughout this document, you may see references to things like `LF`, `SOH`, and
These refer to _ASCII control characters_. You will also see many values represented in hex.
You can find more details about this (along with a full ASCII reference) https://square-r00t.net/ascii.html[here^]. Note that the specification fully supports UTF-8 (or any other arbitrary encoding) -- just be sure that your <<alloc_size, size allocators>> are aligned to the *byte count* and not *character count* (as these may not be equal depending on encoding).
You can find more details about this (along with a full ASCII reference) at https://asciiref.dev/[asciiref.dev^]. Note that the specification fully supports UTF-8 (or any other arbitrary encoding) -- just be sure that your <<alloc_size, size allocators>> are aligned to the *byte count* and not *character count* (as these may not be equal depending on encoding).
====
Each *message* is composed of: