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 
they do

*         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
To: '' 
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 
additional fields."

*         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

Reply via email to