Consider allowing implementation-specific string map keys

[banburybill]

• Section 7.1: Negative integer map keys are concise, but they come with
  the potential for interoperability-hostile collisions. I think the
  document should encourage restricting their use to tightly-controlled
  closed systems, and then additionally propose a particular namespacing
  pattern (e.g., "{namespaceName}-{keyName}") for use of
  implementation-specific /string/ keys in other cases.

https://mailarchive.ietf.org/arch/msg/dnsop/OADqnhAq-Q3GA9JVde1JDmvLNwo

[banburybill]

We understand the intention to reduce the chances of implementations attempting to read implementation-dependent items that they believe are items they know, but which in fact belong to a different implementation.

However:

• we're concerned that string keys pull in the opposite direction to the concision of the rest of the format.
• as we noted on the list, we intended the negative integer map keys for closed systems. One problem with introducing a generic extension mechanism for open systems is that it potentially complicates implementation. Implementations would need to be able to correctly parse any form of valid CBOR to safely skip over an unknown key, while currently they only need to parse the subset of CBOR constructions used by C-DNS. For example, at present, implementations do not need to parse FLOAT or SIMPLE items and do not need to handle fields having or not having tags.
• we feel that a such a generic extension mechanism is beyond our current aims for this format. Implementors are, of course, free to experiment with this.

We had no other feedback on this suggestion following our comments on the list or the WG at IETF101. We've therefore not attempted to incorporate this into the latest draft.