>>>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.
>> Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи
>> и нет никакой проблемы перегнать с одного формата в другой.
>>>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
>> Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ?
> Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий):

Сам MSG не структурирован. Как по вашему задаются обязательные и дополнительные поля для MSG? никак. в этом и проблема, которую хотят вылечить.

Дальше дыры в безопасности: наличие в теле сообщения APP-NAME, PROCID, TIMESTAMP (возможно и других подобных полей). Приложение не должно иметь API для того чтобы выдать себя за другое или использовать другое время.

API должен быть подобный (псевдо код):
спикокПолейИЗначений = {
"поле1":"значение поля 1",
"IP":127.0.0.1,
};
LOG.debug("сообщение для человека без данных", списокПолейИЗначений);

И нигде не должно запрашиваться у приложения его ИМЯ, procid и дата записи. ДАТА - по факту логирования, ИМЯ и procid - по факту того кто вызвал запись. И т.п. иначе запись что приложение Маша с хоста Вася является скомпрометированной поскольку приложение может подменить и хост и собственное имя.

PS спасибо, что подтвердили мои догадки, что RFC не описывает структуру самого сообщения. Ваша цитата наглядно это показывает )))))