Resumo

  • RFC 822, de agosto de 1982, separava extensões formais do correio de campos definidos por usuários. As primeiras jamais começariam com X-, deixando essa grafia como espaço protegido para os segundos.
  • A proteção teve custo. RFC 2068, de janeiro de 1997, orientou aplicações HTTP a tratar x-gzip/x-compress como equivalentes de gzip/compress. RFC 5064, de dezembro de 2007, padronizou Archived-At e também descreveu e registrou seu precursor X-Archived-At.
  • RFC 6648, de junho de 2012, desaconselhou o prefixo para novos parâmetros textuais de protocolos de aplicação. O nome não deveria atestar padronização ou segurança; registros acessíveis deveriam documentar o estado do parâmetro.

O espaço reservado para tentar

Um campo de mensagem tem nome e valor. O programa que recebe a mensagem procura o nome para saber como tratar o valor. Se comunidades diferentes atribuírem sentidos diferentes ao mesmo nome, a colisão aparece quando as mensagens circulam entre elas. Reservar uma faixa de nomes para usos locais pareceu uma solução simples: laboratórios poderiam testar ideias sem pedir licença, e os futuros padrões teriam um estoque separado.

Foi o arranjo de RFC 822, publicado em agosto de 1982. O documento distinguia campos de extensão formalmente publicados de campos definidos pelos usuários. As extensões oficiais jamais começariam por X-. Os usuários ganhavam uma faixa protegida. Uma organização podia colocar informações adicionais em suas mensagens enquanto ainda não havia motivo para procurar uma especificação comum.

A marca, porém, era parte do próprio identificador lido pelo computador. Para a pessoa, X- dizia “uso privado por enquanto”. Para o programa, X-Exemplo e Exemplo são nomes diferentes. A aprovação posterior de um deles não atualiza automaticamente o código escrito para o outro. O status social da ideia e os caracteres que viajam na rede passaram a depender de dois relógios distintos.

Renomear é barato antes da primeira implementação. Depois que programas enviam, recebem e arquivam uma grafia, ela ganha usuários. Publicar um nome oficial pode então acrescentar mais uma obrigação, em vez de retirar a anterior. O experimento bem-sucedido deixa sua etiqueta presa nas cópias antigas.

A conta apareceu no HTTP

RFC 2068, publicado em janeiro de 1997, mostra a despesa em uma instrução curta. Para compatibilidade com implementações anteriores, aplicações HTTP deveriam considerar x-gzip equivalente a gzip e x-compress equivalente a compress. O texto não pôde simplesmente escolher a forma mais limpa e descartar a outra. A grafia com prefixo já era uma entrada reconhecida por software existente.

Isso afeta o processamento. Um emissor pode anunciar uma codificação sob uma das formas. Um receptor que conheça apenas a outra pode tratar o corpo incorretamente. Intermediários que repassam ou arquivam respostas também precisam conhecer a relação. A etiqueta provisória virou parte do que o padrão ensinava a ler.

No correio, RFC 2822, de abril de 2001, substituiu RFC 822 e descreveu campos opcionais sem preservar a antiga divisão gramatical entre extensão formal e campo do usuário. Alterar a gramática de um documento não reescreve as mensagens guardadas nem os aplicativos que já aprendiam os nomes anteriores.

A demonstração mais concreta veio em RFC 5064, de dezembro de 2007. O padrão definiu Archived-At, campo que aponta para uma cópia arquivada da mensagem. Também precisou descrever seu antecessor X-Archived-At por compatibilidade. Leitores podiam analisar o velho campo; novos emissores eram aconselhados a não gerá-lo. O nome anterior foi registrado como obsoleto ao lado do sucessor. A promoção oficial produziu duas entradas, uma para usar e outra para continuar lendo.

Os exemplos têm regras distintas. HTTP declara equivalência para dois pares de codificações. O padrão de arquivo de correio aceita uma entrada antiga e prefere uma saída nova. Nenhum deles mede quantos sistemas usavam cada nome em certa data. Isso exigiria versões de software documentadas ou amostras de mensagens. A obrigação de manter a ponte já aparece nas fontes originais.

O prefixo perde o direito de dar carteira de identidade

RFC 6648, aprovado como Best Current Practice da IETF em junho de 2012, descreveu o problema recorrente. Um nome não padronizado pode se espalhar. Ao criar outro para a versão oficial, implementações antigas conhecem apenas o nome com prefixo, enquanto novas talvez conheçam apenas o recém-publicado. Para preservar a comunicação, os programas novos acabam aceitando o antigo por tempo indefinido. A faixa supostamente privada transforma-se em padrão de fato.

A recomendação passou a ser evitar X- ao criar novos parâmetros textuais de protocolos de aplicação. RFC 6648 não ordenou apagar os campos já existentes; seus responsáveis decidem o destino deles. Tampouco proibiu experiências privadas ou revogou automaticamente regras especiais de um protocolo. Retirou a ideia de que o status atual da experiência deve fazer parte do nome transmitido.

Os leitores receberam outra regra: não devem decidir se um parâmetro é padronizado apenas pela presença ou ausência do prefixo. Também não devem supor que uma grafia sem X- é segura e outra com X- é insegura. Um nome identifica dados; não certifica revisão técnica, registro ou segurança.

A alternativa eram registros com espaço para crescer e procedimentos simples, possivelmente com inscrições provisórias e permanentes. RFC 6648 não proibiu registrar nomes prefixados. Pediu que a inscrição, e não a aparência, carregasse a informação de status. Uma organização pode atualizar o registro quando o parâmetro amadurece sem mandar todos os participantes aprenderem uma segunda grafia.

Há ainda um risco na troca automática de nome. Uma versão padronizada pode alterar o comportamento depois de revisão de segurança ou interoperabilidade. Nesse caso, cortar X- e tratar as formas como idênticas cria um erro novo. A equivalência de x-gzip em RFC 2068 vale para aqueles nomes e aquela codificação; não é uma ferramenta universal para reescrever qualquer campo.

Um experimento que funciona deixa herdeiros

A divisão de 1982 deu liberdade para testar. A revisão de 2012 registrou o outro lado do sucesso: software lê o nome, arquivos o preservam e outros sistemas passam a depender dele. Quando chega a cerimônia de padronização, o nome provisório já pode ter uma comunidade de usuários que a cerimônia não consegue mover de uma vez.

Nos documentos, o custo é verificável. HTTP carregou dois nomes para uma codificação em 1997. O correio registrou um precursor obsoleto em 2007. Uma contagem de adoção requer outros registros, com datas e implementações identificáveis. Mas as normas já mostram quem tinha o poder prático de impedir a retirada imediata: não era a letra na frente do nome, e sim o software que continuava a reconhecê-lo.

RFC 6648 não esvaziou a velha gaveta. Pediu aos próximos autores que deixassem o estado da experiência no registro, onde ele pode mudar, e mantivessem o identificador estável. Um experimento poderia virar padrão sem nascer com uma segunda grafia como dívida futura.