What:
Currently, schemas have "additionalProperties": false at the top-level. This ensures that the ETSI part of the message is compliant with ETSI and does not contain data that could not be converted to an ASN.1 message.
However, the top-level is not part of the ETSI, and is an ad-hoc container specific to our JSON encapsulation. As such it does not need to be as strict as the ETSI part.
Some applications may want to add extra fields in that top-level container (and some already do!). This works because we do not yet enforce the schemas when receivening/emitting messages. But once we do enforce the schemas, those applications will break.
Expected:
The "additionalProperties": false is removed from the top-level object, and moved into the "message" object, that encapsulates the ETSI message. This will keep the guarantee that the ETSI part of the message can still be converted to an ETSI ASN.1 message, while allowing additional (e.g. debug, application-specific data) to be added to the top-level object.
What:
Currently, schemas have
"additionalProperties": falseat the top-level. This ensures that the ETSI part of the message is compliant with ETSI and does not contain data that could not be converted to an ASN.1 message.However, the top-level is not part of the ETSI, and is an ad-hoc container specific to our JSON encapsulation. As such it does not need to be as strict as the ETSI part.
Some applications may want to add extra fields in that top-level container (and some already do!). This works because we do not yet enforce the schemas when receivening/emitting messages. But once we do enforce the schemas, those applications will break.
Expected:
The
"additionalProperties": falseis removed from the top-level object, and moved into the"message"object, that encapsulates the ETSI message. This will keep the guarantee that the ETSI part of the message can still be converted to an ETSI ASN.1 message, while allowing additional (e.g. debug, application-specific data) to be added to the top-level object.