Resumo

  • O perfil RAW da RFC 3195 transporta mensagens syslog conhecidas por BEEP, que garante entrega confiável e ordenada em cada canal; COOKED acrescenta entradas estruturadas com resposta positiva ou negativa para cada uma.
  • São recibos de escopo diferente: um quadro entregue ou um <ok/> não prova, sozinho, a origem do evento, seu armazenamento durável, sua indexação ou uma resposta operacional.

A palavra “confiável” pode sugerir mais do que a garantia realmente especificada. Publicada em novembro de 2001 como documento da trilha Standards Track, a RFC 3195 associa syslog ao BEEP, uma estrutura orientada à conexão. Seus dois perfis tornam visível uma escolha de engenharia. RAW prioriza implementação simples, baixo custo e compatibilidade: mantém a forma histórica da mensagem syslog, enquanto o BEEP fornece entrega confiável e em ordem dentro de cada canal. COOKED usa operações estruturadas e permite que cada entry receba um ok ou um error. Essa resposta trata da troca no protocolo, não de todos os estágios posteriores de um sistema de logs. (RFC 3195 §§1, 3.1, 4.4.2)

É preciso separar os recibos. Um emissor transmite um evento; um par BEEP recebe a mensagem completa; um ouvinte COOKED pode aceitar ou rejeitar uma entrada; então um coletor pode analisá-la, gravá-la, indexá-la, replicá-la ou disparar um alerta. São mudanças de estado distintas. A RFC 3195 define o transporte e as trocas dos perfis, não uma transação universal de armazenamento. Nem <ok/> especifica se o coletor sincronizou os dados em mídia durável ou se consumidores posteriores receberam o registro. Um error pode representar recusa administrativa: comprova uma decisão de política, não que o evento jamais tenha existido.

RAW deixa o limite evidente. No BEEP, a marca final delimita a mensagem e o transporte garante confiabilidade e ordem em um canal individual. Mas a mensagem inicial do ouvinte RAW não tem semântica de entrada syslog; as respostas do iniciador carregam as entradas. O perfil também limita o corpo de cada evento RAW a 1.024 bytes, sem incluir a sobrecarga de enquadramento BEEP. É um limite de carga útil, não uma promessa de retenção duradoura. Ele difere do teto de pacote e da possível truncagem em retransmissores descritos pela RFC 3164, outro mecanismo. (RFC 3195 §3.3; RFC 3164)

A RFC 3195 também distingue comunicação protegida de integridade do objeto. Sua seção de segurança diz que um dispositivo comprometido pode gerar mensagens incorretas e que retransmissores ou coletores podem modificá-las, inseri-las ou apagá-las sem detecção, a menos que outras técnicas sejam usadas. O documento trata autenticação, resistência a repetição, integridade e confidencialidade como serviços que precisam ser configurados separadamente. Um canal protegido pode autenticar o par de um salto; essa identidade não é necessariamente o hostname escrito no evento nem uma assinatura de ponta a ponta sobre o conteúdo. (RFC 3195 §§5, 10; RFC 5425 §4)

Trabalhos posteriores de syslog tornam a diferença mais explícita. A RFC 5848 define blocos assinados que podem sustentar autenticação de origem, integridade, resistência a repetição, sequenciamento e detecção de mensagens ausentes. Separadamente, alerta que transporte confiável não impede perda na camada de aplicação — por exemplo, quando o receptor fecha uma sessão TCP ou TLS. Isso não demonstra adoção ampla da RFC 3195 nem que assinaturas resolvam toda questão de retenção. Demonstra que entrega, autenticidade e completude exigem evidências diferentes. (RFC 5848 §§1, 8.3–8.7)

O valor duradouro da RFC 3195 está na precisão do escopo. RAW pode responder: “este canal BEEP entregou a mensagem em ordem?” COOKED acrescenta: “o ouvinte respondeu positiva ou negativamente a esta entrada?” Sem outros controles, nenhum deles responde se o evento é autêntico, sobreviveu a uma falha de armazenamento ou provocou uma intervenção. Uma investigação deve guardar separadamente o estado da sessão, as respostas por entrada, a validação de assinaturas, a persistência do coletor e o processamento posterior.

A RFC especifica comportamento de protocolo; as fontes disponíveis não estabelecem sua prevalência atual nem seu desempenho operacional.

Fontes: RFC 3195; registro atual da RFC 3195 no RFC Editor; texto da RFC 3195 no IETF Datatracker; RFC 3080, núcleo do BEEP; RFC 3081, BEEP sobre TCP; RFC 3164, protocolo BSD Syslog; RFC 5424, protocolo Syslog; RFC 5425, transporte TLS para Syslog; RFC 5426, transporte UDP para Syslog; RFC 5848, mensagens Syslog assinadas; RFC 6587, Syslog sobre TCP; RFC 2782, DNS SRV; RFC 2119, níveis de requisito.