Resumo

  • RFC 5284 recomenda registrar a organização, a suborganização, o valor e a descrição de um USER_ERROR_SPEC; interpretar esse conjunto e agir sobre ele são etapas posteriores.
  • Um estado único como tratado apaga a diferença entre mensagem válida, significado resolvido, ação autorizada, execução bem-sucedida e recuperação observada.

O painel mostra tratado. O que aconteceu de fato? O receptor gravou o objeto no log. Um serviço de automação encontrou o número da empresa. Outro componente tentou reduzir uma reserva. O comando retornou sucesso. Minutos depois, o mesmo erro apareceu novamente porque a condição original nunca mudou.

Cada frase descreve uma evidência diferente. O selo verde não descreve nenhuma delas com precisão.

RFC 5284 foi criado para transportar erros definidos por usuários no RSVP sem transformar cada necessidade de desenvolvimento em um novo código global. A especificação oferece uma estrutura clara: um objeto de erro padrão mantém o contexto RSVP; um objeto adicional carrega uma identificação privada; implementações antigas podem encaminhá-lo sem entender; receptores capazes podem registrar, interpretar e tomar medidas. Em nenhum ponto o recebimento equivale automaticamente à reparação.

O recibo inicial é a validade da mensagem

PathErr e ResvErr já exigem ERROR_SPEC no RSVP, e Notify o exige nas extensões RSVP-TE. USER_ERROR_SPEC é adicionado a esse objeto obrigatório, não o substitui. A mensagem mantém um código padrão e ganha um detalhe com escopo próprio.

Se um código existente serve, o detalhe privado pode acompanhá-lo. Na ausência de outro código aplicável, usa-se o Error Code 33, User Error Spec, com o subcódigo 0 indicando que há mais detalhes no objeto adicional. Código 33 sem USER_ERROR_SPEC é uma mensagem malformada.

O objeto adicional também só é válido em PathErr, ResvErr ou Notify. Em outro tipo de mensagem, deve ser tratado como malformado. ResvConf não entra nesse mecanismo, embora carregue ERROR_SPEC, porque ali códigos e valores não têm o mesmo uso significativo.

Antes de qualquer interpretação, portanto, existe um teste estrutural. O objeto padrão está presente? O código é coerente? O companheiro exigido chegou? O tipo de mensagem é permitido? Um painel que pula essas perguntas pode acionar uma resposta a dados que a própria norma manda rejeitar.

O identificador completo é um triplo

Dentro de USER_ERROR_SPEC, o primeiro campo é um Private Enterprise Number de 32 bits atribuído pela IANA. Depois vem Sub Org, com 8 bits, que permite a uma organização separar espaços de valores para equipes ou esforços paralelos. Quando a separação não é necessária, o valor recomendado é zero. Só então aparece o User Error Value, com 16 bits.

O valor isolado não possui significado global. O número 6 de uma organização pode descrever uma condição que não tem qualquer relação com o número 6 de outra. Até duas suborganizações podem reutilizá-lo. Agregadores precisam usar empresa, suborganização e valor como uma chave indivisível.

O registro da IANA distingue o proprietário do espaço superior. Ele não publica automaticamente cada dicionário interno, não autentica a origem de uma mensagem concreta e não autoriza uma ação. Proteção da mensagem, resolução do dicionário e decisão operacional continuam separadas.

Um recibo de interpretação deve incluir a versão do mapa privado. Se o significado muda entre versões, aplicar o mapa atual a um evento antigo reescreve a história. Preservar os bytes originais, o triplo, a versão, o componente que decodificou e o horário torna a interpretação reproduzível.

Encaminhar é uma capacidade deliberadamente menor

O objeto recebeu Class 194 e C-Type 1. A classe fica na faixa 192–247 do RSVP, na qual uma implementação que não entende o objeto o encaminha sem modificação. Equipamentos antigos podem manter a continuidade do dado sem receber antecipadamente todos os dicionários privados.

Esse comportamento comprova transporte. Não comprova que o nó reconheceu a empresa, mostrou a descrição, armazenou o valor ou concordou com uma resposta. Um objeto intacto no destino pode ter atravessado uma sequência inteira de elementos semanticamente alheios.

A regra para repetições também limita inferências. Implementações devem ignorar ocorrências repetidas e encaminhá-las sem alteração quando repassam a mensagem. Repetição não é quorum, gravidade acumulada nem confirmação independente. É uma característica da entrada que merece registro.

Separar transporte e entendimento permite evoluir com segurança. A rede pode primeiro preservar o objeto. Receptores passam a registrá-lo. Um subconjunto instala o dicionário. Só depois políticas específicas autorizam respostas. Cada etapa pode ser revertida sem destruir as anteriores.

A descrição não é a interface da automação

O campo de descrição usa UTF-8/Net-Unicode, recebe preenchimento nulo até um múltiplo de quatro bytes e pode ter comprimento zero. A recomendação de usar uma linha de US-ASCII imprimível quando possível aumenta a chance de exibição, mas não muda o requisito de codificação.

RFC 5284 explica que nem toda implementação conseguirá mostrar a descrição. Ela deve conter apenas informação suplementar; a informação crítica para operar a rede fica no valor numérico. Um receptor sem suporte a UTF-8 deve escapar caracteres segundo RFC 5137.

Isso impede que uma frase de diagnóstico vire uma API informal. Textos mudam por idioma, versão e estilo. A automação deve consultar o triplo com uma versão de mapa aprovada, enquanto a pessoa recebe uma explicação legível.

Há ainda uma fronteira de segurança. Strings exibidas ou registradas podem conter caracteres de controle ou explorar tratamento inadequado de tamanho. O sistema precisa guardar o original como evidência e produzir uma representação segura para telas e logs. Sanitizar a visualização não deve alterar a prova; preservar a prova não exige expor bytes não confiáveis ao terminal.

Subobjetos têm contorno comum e conteúdo privado

A extensão admite subobjetos definidos pelo usuário. Cada um segue um formato TLV. Type e Length ocupam 8 bits; o comprimento total inclui esses campos, deve ser pelo menos quatro e múltiplo de quatro. Um parser genérico consegue atravessar a estrutura sem conhecer todos os tipos.

O número do tipo e o conteúdo do valor, porém, são definidos pela empresa e pela suborganização. A sintaxe compartilhada permite contenção e encaminhamento. O significado depende de documentação privada e de uma versão concreta.

O limite evita uma conclusão perigosa: estar dentro de uma moldura padronizada não torna o conteúdo uma ordem padronizada. A organização nomeia; o receptor decide se confia; a política local autoriza; o resultado precisa ser observado.

Um fluxo operacional precisa de estados que não se sobrescrevem

RFC 5284 recomenda que o receptor registre, no mínimo, empresa, suborganização, valor e descrição. Implementações capazes de interpretar o conteúdo devem tomar outras medidas com base no erro. A segunda ação não apaga a primeira.

Um modelo de estado útil conserva etapas cumulativas:

  1. mensagem aceita como estruturalmente válida;
  2. objeto e chave completa preservados;
  3. significado resolvido com um mapa identificado;
  4. resposta escolhida por uma política autorizada;
  5. ação submetida e resultado do executor recebido;
  6. condição técnica observada novamente;
  7. efeito sobre o serviço confirmado por uma fonte independente.

Falhar no quinto passo não invalida o terceiro. Sucesso no quinto não prova o sexto. Uma melhora no sexto pode não representar o sétimo. Estados separados permitem localizar a ruptura e tentar uma correção limitada.

O rótulo tratado deveria desaparecer ou ser acompanhado de uma fase precisa. A pergunta operacional não é “o sistema viu o erro?”, mas “qual foi o último recibo verificável e qual componente deve produzir o próximo?”.