This occurred to me while reviewing section 7 but it seems to be problematic across the spec. The value NULL is used in many places throughout the text without definition as to its wire format specification.
Its probably clear that there many ways to serialize a NULL value (for example CESR has a single code) to anyone reviewing this issue but I think its probably also a trap for the unwary implementer.
There are two ways null seems to be used (9 times by my count) in the spec at present:
For the first case, I think it entirely reasonable to come up with a reserved placeholder (say the string VID_ANY) or change the usage to require a LIST or whatever the context requires (say a reply message should contain the VID the sender is replying to) rather than relying on some NULL placeholder to signify that the message isn't routed.
For the second case, we should explicitly require some serialization that's equivalent to NULL across all wire transports (in CESR this would be specifying the particular null that can exist in the supported JSON/MGPK/CBOR/CESR formats). Either in a list of null representations in these formats or just using say empty string/byte array where a true null is indicated.
This occurred to me while reviewing section 7 but it seems to be problematic across the spec. The value
NULLis used in many places throughout the text without definition as to its wire format specification.Its probably clear that there many ways to serialize a
NULLvalue (for example CESR has a single code) to anyone reviewing this issue but I think its probably also a trap for the unwary implementer.There are two ways null seems to be used (9 times by my count) in the spec at present:
TSP_Envelope = {TSP_Tag, TSP_Version, VID_sndr, VID_rcvr | NULL}from https://trustoverip.github.io/tswg-tsp-specification/#tsp-envelope or- Payload fields = {VID_b1, VID_List|NULL}https://trustoverip.github.io/tswg-tsp-specification/#parallel-relationship-forminginfo = NULLfrom https://trustoverip.github.io/tswg-tsp-specification/#hpke-auth-modeFor the first case, I think it entirely reasonable to come up with a reserved placeholder (say the string
VID_ANY) or change the usage to require a LIST or whatever the context requires (say a reply message should contain the VID the sender is replying to) rather than relying on some NULL placeholder to signify that the message isn't routed.For the second case, we should explicitly require some serialization that's equivalent to NULL across all wire transports (in CESR this would be specifying the particular null that can exist in the supported JSON/MGPK/CBOR/CESR formats). Either in a list of null representations in these formats or just using say empty string/byte array where a true null is indicated.