You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be easier and cleaner to do this in v2.0 instead of v1.4 due to SemVer policy.
RFC 7049bis indicates additional considerations for encoding not mentioned in 7049, so future protocols are likely to use new encoding modes.
One way to handle options would be to use some integer "enums" to specify different aspects of encoding modes. So 6-7+ of these aspects can combine to specify any current or future mode. And each is an integer so they can have new values made available as needed.
Something like the following (with better names than this rough draft):
As discussed, maybe a v1.4 before 2.0 can have this baby step before merging in CBOR tags.
deprecate but still support boolean encoding modes in v1.4
add SortMode (int) and ShortestFloat (int) as encoding options to replace encoding mode booleans.
The combination of SortMode and ShortestFloat can be used to specify these modes in v1:
default
Canonical
CTAP2
Core Deterministic Encoding Rule 2 (7049bis)
and modes that don't have a name yet
type SortMode int
const (
SortNone SortMode = 0 // no sorting
SortLengthFirst SortMode = 1 // Old Canonical
SortBytewiseLexical SortMode = 2 // Bytewise Lexicographic
SortCanonical SortMode = SortLengthFirst
SortCTAP2 SortMode = SortBytewiseLex
SortCoreDeterministic SortMode = SortBytewiseLex
)
type ShortestFloat int
const (
ShortestFloatNone ShortestFloat = 0 // no change
ShortestFloat16 ShortestFloat = 1 // float16 as shortest form of float that preserves value
ShortestFloat32 ShortestFloat = 2 // float32 as shortest form of float that preserves value
ShortestFloat64 ShortestFloat = 3 // float64 as shortest form of float (this may convert from float32 to float64, etc.)
)
It would be easier and cleaner to do this in v2.0 instead of v1.4 due to SemVer policy.
RFC 7049bis indicates additional considerations for encoding not mentioned in 7049, so future protocols are likely to use new encoding modes.
One way to handle options would be to use some integer "enums" to specify different aspects of encoding modes. So 6-7+ of these aspects can combine to specify any current or future mode. And each is an integer so they can have new values made available as needed.
Something like the following (with better names than this rough draft):
And one or more aspects for each of these:
So a combination of these options can handle all existing CBOR modes plus some future modes that don't exist yet.
The text was updated successfully, but these errors were encountered: