Resumo

  • A RFC 8174 reserva os significados especiais da BCP 14 às palavras grafadas integralmente em maiúsculas sob a convenção declarada. Em minúsculas, elas mantêm o sentido normal do inglês.
  • A regra não faz da tipografia um teste completo de normatividade. Texto normativo pode existir sem palavras-chave, e a força delas também depende do nível do documento.
  • Uma prova de conformidade precisa guardar versão e status, convenção, frase inteira, sujeito, condição, exceção, teste e resultado observado; uma contagem de maiúsculas serve apenas para localizar candidatos.

O relatório encontrou uma palavra antes de encontrar uma obrigação

Transformar cada MUST de um RFC em item de planilha dá a sensação de controle. Mas a mesma grafia pode estar numa citação, num exemplo ou numa discussão sobre a regra de outro documento. A busca ainda não sabe se a BCP 14 foi declarada.

Mesmo quando a frase é normativa, faltam perguntas operacionais. Qual componente é o sujeito? Qual evento aciona a ação? Uma definição referenciada restringe o alcance? Que observação separa implementação correta de mera configuração?

A RFC 8174 elimina uma ambiguidade que podia eliminar. Ao não prometer mais, ela também estabelece o ponto em que uma ferramenta deve devolver o caso ao contexto.

“Frequentemente em maiúsculas” abria duas leituras

A RFC 2119 de Scott Bradner definiu uma linguagem comum. MUST é exigência absoluta da especificação; MUST NOT, proibição absoluta. SHOULD aceita desvio por razões válidas depois de compreender as consequências. MAY oferece escolha real, preservando interoperabilidade entre implementações que escolhem ramos diferentes.

O documento original dizia que essas palavras eram “frequentemente” capitalizadas. Um must minúsculo podia ser o termo definido com estilo descuidado ou apenas uma palavra comum. Autor, revisor e máquina podiam aplicar gramáticas distintas à mesma linha.

Leiba fechou a bifurcação: somente a forma toda em maiúsculas recebe o sentido especial da BCP 14. Fora dela, vale o inglês normal. O novo texto padrão faz o próprio documento declarar essa convenção.

Texto normativo não depende de uma palavra em caixa alta

A simplificação mais atraente seria “maiúscula é normativo, minúscula não é”. A RFC 8174 a rejeita: usar as palavras-chave não é obrigatório, e muito texto normativo não as contém.

Há dois testes separados. A caixa informa se a palavra invoca a definição BCP 14. O status do documento, a estrutura e o contexto informam se a frase tem força normativa, de onde ela vem e quem alcança.

Uma expressão regular usada para responder às duas perguntas perde regras em prosa comum e transforma citações em controles locais. A automação não remove a ambiguidade; apenas produz erros com formato uniforme.

É o documento que empresta força ao termo

A RFC 2119 observa que a força das palavras é modificada pelo nível de exigência do documento. Tipografia não transforma Internet-Draft em padrão, RFC Informacional em obrigação universal nem política privada em consenso da IETF.

O autor escolhe a frase; grupo de trabalho e aprovador do fluxo estabelecem processo e status; o RFC Editor preserva o sentido aprovado; o implementador converte a norma em comportamento; o laboratório observa o resultado.

As maiúsculas melhoram o recibo entre essas funções. Não substituem nenhuma delas. Por isso o boilerplate e as referências são parte da proveniência do requisito.

SHOULD contém uma política de exceção

Colocar MUST, SHOULD e MAY numa escala simples de intensidade esconde três controles diferentes. MUST fecha uma escolha. SHOULD mantém uma saída que exige motivo e avaliação das consequências. MAY abre uma escolha e pede que o ecossistema tolere os dois caminhos.

A orientação atual da IETF trata SHOULD como especialmente difícil. O texto precisa explicar por que não usa MUST e o que acontece quando há desvio. Marcar a linha como “opcional” apaga justamente a informação decisória.

Um requisito implementável inclui ator, ação, condição, exceção e impacto de interoperabilidade. A palavra destacada aponta para o registro; não é o registro inteiro.

O guia de estilo declara uma gramática diferente

A RFC 7322 afirma que não usa a terminologia da RFC 2119. Depois emprega must e should em minúsculas com sentidos editoriais locais: mudanças aplicadas automaticamente pelo RFC Editor e recomendações que podem ser questionadas.

O exemplo não enfraquece a BCP 14. Ele mostra como uma declaração evita que o leitor confunda minúsculas intencionais com capitalização defeituosa.

O mesmo guia exige referência normativa à RFC 2119 quando sua interpretação for usada; caso contrário, a interpretação correta deve ser definida. Aparência familiar não substitui essa origem.

A marcação identifica a expressão, não a regra completa

O vocabulário RFCXML oferece o elemento opcional <bcp14> para envolver a expressão definida, como MUST ou SHOULD NOT. A documentação manda não envolver toda a exigência.

O limite do esquema é informativo. O objeto legível pela máquina é menor que a obrigação. Sujeito, ação, condição, exceção e referências continuam no restante do documento.

Uma ferramenta pode usar a marca como sinal de alta qualidade. Convertê-la diretamente em teste atribui ao XML uma decisão que ele não registra.

Caixa alta é recibo de vocabulário, não delegação de poder

Barry Leiba não tornou as maiúsculas mais autoritárias. Tornou verificável o momento em que uma palavra assume a definição da BCP 14.

Consenso, fluxo e status fornecem autoridade. A frase e suas referências dão alcance. Implementação e ensaio fornecem evidência de conformidade. A caixa da palavra não reconstrói sozinha nenhuma dessas camadas.

Automação prudente encontra o termo e mantém o documento ligado a ele. Pergunta quem está obrigado, segundo qual versão, com que exceção e por qual observação. As maiúsculas cumprem sua tarefa ao abrir essa investigação.

Fontes