This was discussed in the Core WG meeting today. The answers are as follows
(copied from Marcello's slide edited in real-time during the meeting):
* About data could include vendor extensions
o Josh pointed out that there was a discussion in the context of the IRB mail
? Consensus was that was the intent
* Config map contains at least one field that is also in About info
o If something is in the config map does it need to be in the About data also?
? Given it may be a vendor extension, it should really be up to vendor what
* Names of Vendor extensible fields: is there a naming convention?
o Consensus is that the naming convention for extensions (vendor in
particular) should use the reverse DNS convention like interface names
From: Dave Thaler
Sent: Tuesday, October 11, 2016 12:55 PM
Subject: Additional fields in About/Configuration data
Use case: a vendor or a spec for a gateway to another protocol that provides
more info wants to provide additional metadata fields that are standard in
About & Configuration.
The 14.12 About interface spec
does not say whether the metadata fields in About can be extended or must be
only the set in the spec.
The 14.12 Configuration interface spec
on the other hand explicitly states "The OEM or application developer can add
* Does this mean that it is NOT legal for OEM or app developer to add
additional fields to the About data?
* If an additional field is read-only, should it be added to aboutData,
or configMap, or both?
* If an additional field is read-write, should it be added to
aboutData, or configMap, or both?
* Is there any expected naming convention for the names of the
additional fields? (e.g., to avoid future conflicts with anything that might
be a standard)
* Is it possible for a client app to reliably know the semantics of an
additional field? (e.g., if the field name is unique enough? Or some other
Allseen-core mailing list