Carsten Bormann <[email protected]> wrote: > Answer: > No. Thank you for your well reasoned reply. I have also been thinking that future 8366 extensions should be done via a mechanism similiar or identical to what 8520 does:
https://www.rfc-editor.org/rfc/rfc8520.html#section-3.9 3.9. extensions This optional leaf-list names MUD extensions that are used in the MUD file. Note that MUD extensions MUST NOT be used in a MUD file without the extensions being declared. Implementations MUST ignore any node in this file that they do not understand. Note that extensions can either extend the MUD file as described in the previous paragraph or reference other work. An extension example can be found in Appendix B. I didn't cotton on to this until I was looking at the licensing term extension. This mechanism exploits the fact that XML and JSON dict keys are strings, and do not need to be allocated or registered. That makes serialization to CBOR/SID problematic, but there are some possible answers. Specifically, a Tag <47> with the root SID value, and then a sub-dict with SIDs allocated for/by the extension itself. I feel sad that I didn't think of this two years ago and start work to make this happen. Now I feel that I want this, but don't want to wait for it. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
