...

The motivation behind extending the schema to include dataType of the configuration entry is to enable the client to provide better validation to the user. In the absence of dataType the only way to know if the user specified value is correct is to make an `alter` call and check if there is no error, which is a suboptimal experience.  Including the dataType could open up potentially other use cases as well.

By including Including documentation would enable the client to provide better latest information about the config to the user and would also act as a single source of truth.

By including Including validator would enable the client to further improve upon the validation provided by dataType. Validator here is the serialized version of Range, ValidList, ValidString, CaseInsensitiveValidString, NonNullValidator, NonEmptyString to name a few.

...

{
  "name": "offsets.topic.num.partitions",
  "value": "50",
  "source": "DEFAULT_CONFIG",
  "type": "INT",   // New
  "synonyms": [
    {
      "name": "offsets.topic.num.partitions",
      "value": "50",
      "source": "DEFAULT_CONFIG"
    }
  ],
  "documentation": "The number of partitions for the offset commit topic (should not change after deployment)", // New
  "isReadOnly": true,
  "isSensitive": false,
  "validValues": { . // New
    "min": 1.0,
    "max": null
  }
}

...

{
  "name": "log.message.timestamp.type",
  "value": "CreateTime",
  "source": "DEFAULT_CONFIG",
  "type": "STRING", // New
  "synonyms": [
    {
      "name": "log.message.timestamp.type",
      "value": "CreateTime",
      "source": "DEFAULT_CONFIG"
    }
  ],
  "documentation": "Define whether the timestamp in the message is message create time or log append time. The value should be either `CreateTime` or `LogAppendTime`", // New
  "isReadOnly": false,
  "isSensitive": false,
  "validValues": { . // New
    "caseSensitive": false,
    "values": [
      "CreateTime",
      "LogAppendTime"
    ]
  }
},

...

Instead of serializing the Validator, we could leverage Recommender in org.apache.kafka.common.config.ConfigDef.ConfigKey. Few reason for not doing that

1. Recommender is not used in by any of the KafkaConfig today. 

2. Recommender.validValues() which returns valid set of values has limited expressiveness when it comes to defining Range, nullability, case sensitiveness that comes with Validator

...

The proposed change is backward compatible in a sense that for same version of Kafka server and client response would include type fieldadditional fields

replication.quota.window.num=11 type=INT sensitive=false synonyms={}

...

And for server version > client version type would will be ignored

Rejected Alternatives

...