13. Приложение А. Руководство для реализации протокола
Информация в этом разделе подана в виде рекомендаций разработчикам. Авторы полагают, что они полезны, хотя и не являются нормативными. Реализациям НЕ ТРЕБУЕТСЯ жестко следовать им, чтобы соответствовать данной спецификации.
13.1. Приложение А.1. Совместимость с BSD Syslog
Хотя BSD Syslog широко используется в настоящее время, его формат никогда не был формально стандартизирован. В RFC 3164 описываются распространённые существующие форматы. Этот информационный RFC практически показал как много существует различных реализаций. Исследование, проведенное во время создания этого документа, показало, что есть очень мало общего между различными реализациями Syslog на различных платформах. Единственная вещь, в которой все они согласуются, состоит в том, что сообщения начинаются с последовательности <
PRIVAL >
. Всё остальное содержимое сообщений Syslog не отформатировано непротиворечивым способом. И RFC 3164, соответственно, не описывает определенных элементов в сообщении Syslog. Это подтверждается тем, что любой пакет, предназначенный для порта UDP Syslog, должен быть обработан как сообщение Syslog, независимо от того, каковы его формат или содержимое.
Настоящий документ сохраняет синтаксис значения PRI и его семантику. Это позволяет унаследованным реализациям серверов Syslog правильно обрабатывать сообщения, сгенерированные приложениями Syslog, поддерживающими настоящую спецификацию.
Большинство существующих реализаций поддерживает UDP в качестве транспортного протокола для Syslog. Данная спецификация также поддерживает транспорт UDP, но не рекомендует его. Рекомендуется развертывание требуемой поддержки TLS. Также могут использоваться дополнительные транспортные протоколы.
RFC 3164 описывает поведение ретрансляторов сообщений. Настоящий документ не определяет поведение ретрансляторов. Это могло бы быть сделано в отдельном документе.
Поле TIMESTAMP, описанное в RFC 3164, предполагает меньшую точность, чем метка времени, определенная в настоящем документе. Также в этом поле отсутствуют год и информация о часовом поясе. Если сформированное согласно настоящему документу сообщение должно быть преобразовано в формат RFC 3164, то предлагается использовать местное поясное время источника сообщения, а информацию о часовом поясе и годе отбрасывать. Если полученное в формате RFC 3164 сообщение должно быть преобразовано так, чтобы соответствовать настоящей спецификации, то при добавлении информации о годе и часовом поясе МОЖЕТ использоваться текущий год и часовой пояс ретранслятора или коллектора.
Поле HOSTNAME в RFC 3164 менее представительно, но такой формат все ещё поддерживается в настоящей спецификации, как одно из альтернативных представлений имени узла.
Часть сообщения, обозначаемая MSG, согласно RFC 3164, состоит из полей TAG и CONTENT. В настоящей редакции, MSG — это то, что называлось CONTENT в RFC 3164. Теперь TAG — это часть заголовка и если раньше он был простым полем, то теперь TAG разделен на поля APP-NAME, PROCID и MSGID. Это не полностью напоминает использование TAG, но обеспечивает ту же самую функциональность для большинства случаев.
Поле STRUCTURED-DATA не было описано в RFC 3164. Если сформированное согласно настоящему документу сообщение содержит STRUCTURED-DATA и должно быть преобразовано в формат RFC 3164, то STRUCTURED-DATA просто становятся частью поля CONTENT RFC 3164, содержащим данные в свободной форме.
В целом этот документ пытается обеспечить легко анализируемый заголовок с четким разделением полей, тогда как традиционный BSD Syslog страдает от некоторых исторически разработанных, трудно анализируемых правил разделения полей.