Resumo

  • Um processador conhecedor de DTD ou esquema pode inserir um atributo padrão que não viajou na rede; captura e aplicativo então observam dados diferentes.
  • Validação é um recibo estrutural com versão e proveniência próprias, não prova de verdade, autorização, assinatura integral ou conclusão da operação.

O analista abriu a captura e não encontrou o atributo. O serviço abriu seu log e mostrou o mesmo atributo com um valor perfeitamente válido. Nenhum dos dois registros havia sido adulterado.

O valor veio do ambiente de validação. Uma DTD ou um esquema pode declarar padrões que o processador acrescenta à visão entregue ao aplicativo. O pacote prova o que o remetente enviou; a árvore prova o que aquela configuração produziu. Tratar os dois como a mesma mensagem apaga o autor da transformação.

Publicado em janeiro de 2003 como Best Current Practice 70, o RFC 3470 não escolhe XML para todos os protocolos. Ele estabelece disciplina para quem já fez essa escolha. A recomendação contra valores padrão em atributos é um caso particular de uma ideia mais ampla: a interpretação precisa de proveniência.

A boa formação protege a fronteira sintática

Um documento bem formado respeita a gramática básica de XML. O RFC 3470 exige que um documento malformado não seja interpretado parcialmente. O protocolo pode abortar ou pedir retransmissão, mas não deve escolher os trechos convenientes e avançar o estado.

Quando a análise tem sucesso, o resultado é um XML Information Set. Ele representa elementos, atributos, caracteres e propriedades de namespace, não uma fotografia dos octetos. Codificação, fins de linha, entidades e normalizações já participaram do caminho.

O primeiro recibo deve guardar bytes, hash, envelope, tipo de mídia, horário e codificação. O segundo identifica o analisador, a versão, a configuração e a política de acesso externo. Só depois aparece o infoset.

Uma declaração XML deve ser aceita. Se o protocolo permitir codificações além de UTF-8 ou UTF-16, a declaração se torna necessária. A árvore não permite adivinhar com segurança todos os detalhes do fluxo original.

O padrão inserido tem um autor operacional

Esquemas têm valor real: detectam filhos ausentes, estruturas inesperadas e tipos fora do contrato. Mas uma validação sempre responde com relação a um perfil, uma versão e um modo de resolução.

Quando o esquema fornece um atributo padrão, ele introduz informação na visão do aplicativo. Um monitor que não carrega o mesmo esquema verá outra coisa. Uma assinatura pode ter sido calculada antes ou depois da inserção, conforme o modelo utilizado. Uma troca de versão pode mudar o valor sem alterar a mensagem.

Por isso o RFC 3470 desaconselha depender de valores padrão em protocolos. Não é porque todo padrão seja incorreto, mas porque produtores, validadores, rastreadores e verificadores podem operar com conjuntos diferentes de informação.

O recibo de validação precisa guardar o perfil exato, a origem, o conteúdo ou hash, a versão, as opções e uma lista das inserções. “Passou no XSD” não é reproduzível quando XSD significa um URL mutável.

A linguagem do esquema não contém o negócio inteiro

DTD, XML Schema e outras linguagens expressam conjuntos diferentes de restrições. O RFC 3470 reconhece que requisitos adicionais, inclusive semânticos, inevitavelmente permanecem na especificação em prosa e no código.

Um identificador pode cumprir o tipo e apontar para um objeto inexistente. Uma data pode estar no formato correto e fora do prazo. Uma operação pode ser estruturalmente válida e proibida no estado atual. O esquema não autentica a origem nem concede permissão.

Assim, validação, verificação semântica, autorização e commit precisam de resultados separados. O aplicativo deve registrar o estado anterior e a regra aplicada, não apenas o objeto já normalizado.

O resultado percebido pelo usuário vem depois. Uma resposta positiva do validador não demonstra que a transação persistiu nem que um sistema a jusante a aceitou.

Namespace organiza vocabulário, não cadeia de comando

Nomes de namespace têm forma de URI e separam vocabulários. Eles não precisam ser consultados na rede e não provam que o remetente representa a organização sugerida pelo domínio.

Há uma diferença propensa a erro: o namespace padrão vale para elementos sem prefixo, mas não para atributos sem prefixo. O aplicativo deve usar nomes expandidos e regras explícitas, não a proximidade visual.

Extensões desconhecidas também exigem política. Ignorar, preservar, encaminhar, rejeitar ou falhar por obrigação de entendimento são decisões do protocolo. O XML apenas confirma que a construção é legal.

Instruções de processamento e comentários não devem esconder estruturas normativas. O processamento comum precisa poder ignorá-los sem perder o contrato.

Dependências externas podem recriar a árvore

Entidades externas, esquemas remotos e referências relativas acrescentam entradas que não estão no pacote. Um objeto pode mudar entre recepção e repetição. O analisador também pode fazer uma chamada de rede a partir de um local privilegiado.

O RFC 3470 recomenda evitar declarações de entidades em protocolos e impedir acesso arbitrário por referências externas em XML não confiável. As cinco entidades predefinidas e referências numéricas continuam sendo recursos locais normais.

xml:base exige uma regra de precedência quando transporte, contêiner e documento oferecem bases. Sem ela, implementações compatíveis com XML podem buscar objetos diferentes.

Para repetir a decisão, registre a política externa, cada URI resolvido, os bytes obtidos ou a prova de rede desativada. Consultar o mesmo endereço hoje é uma nova execução, não uma restauração do passado.

Canonização e assinatura precisam mostrar o alcance

Canonical XML, no RFC 3076, cria uma serialização reprodutível de um conjunto de nós. XML Signature, no RFC 3275, define referências e transformações. Ambas exigem que o objeto de entrada seja nomeado.

Uma assinatura válida cobre os nós selecionados depois das transformações. Não cobre automaticamente um atributo padrão inserido em outra fase, um irmão sem assinatura ou um recurso externo usado pelo aplicativo.

O recibo deve conservar referências, resoluções, transformações, algoritmo canônico, chave e identidade. Depois é preciso comparar esse alcance com os dados realmente usados na decisão.

Integridade e identidade também não são autorização. Uma ordem pode ser autêntica e ainda contrariar prazo, limite, função ou estado.

Espaço e ordem não seguem a intuição visual

Caracteres de espaço podem fazer parte dos dados se o protocolo não declarar outro tratamento. Reformatar um documento pode alterar texto ou entrada de assinatura.

Já a ordem dos atributos não tem significado em XML, e valores podem ser normalizados. Um consumidor que exige a ordem produzida por seu gerador cria um subconjunto privado. O RFC 3470 recomenda evitar essas restrições improvisadas e usar mecanismos comuns quando uma forma estável é necessária.

O contrato precisa definir espaço, conteúdo misto, ordem de elementos, uso de atributos e preservação de extensões. “Parece igual” não é critério de interoperabilidade.

O código do analisador é outra superfície

XML não incorpora confidencialidade, integridade, autenticação ou autorização. O analisador executa sobre estrutura controlada por terceiros e pode sofrer expansão abusiva, consumo de CPU e memória ou falhas de implementação.

Registre limites de tamanho, profundidade, expansão, tempo, memória e rede, além do comportamento de erro. Uma entrada pode ser legal pela gramática e inaceitável pela carga.

O RFC 8996 atualizou o contexto de transporte ao descontinuar TLS 1.0 e 1.1. TLS atual protege o canal conforme sua configuração, mas não indica de onde veio o atributo padrão nem se a operação foi autorizada.

Quatorze recibos para saber de onde veio um valor

Comece com octetos e codificação. Registre analisador e configuração, boa formação e falha integral. Preserve entidades, base, recursos externos e infoset. Nomeie esquema, versão, validação e padrões inseridos.

Depois registre namespaces, extensões, canonização, referências de assinatura e identidade autenticada. Em seguida vêm regras semânticas, autorização, estado anterior, commit e resultado autenticado.

Se a alegação for interoperabilidade, repita com recursos externos bloqueados e outro processador compatível. Compare a captura e a árvore, em vez de escolher uma como verdade universal.

Limite da evidência

Este artigo não acusa produto, analisador ou incidente. Não afirma que todo esquema insere padrões nem que validação seja inútil. Define o que cada resultado prova.

Também não repete a análise YANG/XML já publicada pela BTW, que trata de árvore YANG efetiva, defaults, revisões, mount, datastore e efeito de rede. Aqui, o foco é a autoria genérica de dados acrescentados entre pacote e aplicativo.

Os princípios de especificação inicial mínima e primazia do código em execução, de Heng Lu, são lentes editoriais declaradas. Eles favorecem invariantes comuns estritos e evidência do caminho real, sem impor uma biblioteca. Não são medições de implantação.

A conclusão é operacional: se o aplicativo usa um valor que não estava no pacote, o sistema precisa dizer quem o adicionou, segundo qual versão e sob qual autoridade.

Sources