Resumo

  • O RFC 3383 distribuiu valores LDAP entre Standards Action, análise especializada, Specification Required, ordem de chegada, experimento e uso privado conforme o risco de colisão.
  • Um registro demonstrava coordenação, não implementação, segurança ou adoção. Sua força vinha da especificação, do responsável e do caminho de mudança que permaneciam públicos.

Duas equipes podem atribuir o mesmo inteiro a resultados incompatíveis. A mensagem continua bem formada, e justamente por isso o problema é perigoso: cada lado pode aceitar os bytes e executar um significado diferente. Extensibilidade sem coordenação não elimina colisões; apenas as adia.

Publicado em setembro de 2002 como BCP 64, o RFC 3383 organizou a entrada de extensões no Lightweight Directory Access Protocol. LDAP já aceitava novas operações, controles e schema. O desafio era manter nomes públicos inequívocos sem obrigar toda experiência a virar padrão completo.

O documento escolheu políticas diferentes para tipos de mensagem, mecanismos descobertos, códigos de resultado, métodos de autenticação, descritores de OID e opções de AttributeDescription. Esses espaços não produziam o mesmo dano quando colidiam.

Elementos desenvolvidos pela IETF podiam receber um arco OID sob Internet Directory Numbers após Expert Review com Specification Required. IANA atribuía um arco por especificação; o documento podia organizar os OID subordinados sem nova coordenação para cada folha. A fronteira central protegia a árvore, sem centralizar toda decisão interna.

Outros desenvolvedores podiam usar OID devidamente delegados, inclusive sob Private Enterprise Numbers. Trabalhos em andamento eram orientados a usar OID experimentais. A escolha impedia que protótipos ocupassem cedo demais o identificador final; valores experimentais não deviam aparecer em especificações publicadas.

Controles e extensões anunciados no Root DSE seguiam outra combinação. Mecanismos descobertos podiam usar First Come First Served com Specification Required, enquanto mecanismos Standards Track exigiam Standards Action. Publicar uma descrição técnica era necessário, mas não equivalia a padronização.

As políticas não formavam uma escala de qualidade. Ordem de chegada não examinava segurança. Specification Required não provava consenso. Standards Action não provava software implantado. Cada termo definia a evidência mínima para ocupar um espaço específico.

Descritores eram nomes curtos, sem distinção entre maiúsculas e minúsculas, ligados a OID. Um hífen final podia reservar uma família. O prefixo x- ficava para Private Use e não era registrável; e- marcava experimentos com ordem de chegada; os demais descritores passavam por análise especializada.

Opções de AttributeDescription adotavam divisão semelhante. Prefixos comunicavam o alcance da coordenação. Um nome privado podia funcionar localmente, mas não ganhava unicidade global nem documentação pública automática.

Os resultCode dividiam o campo numérico: 0–1023 para Standards Action; 1024–4095 para Expert Review com Specification Required; 4096–16383 para First Come First Served com palavras e-; 16384 em diante e palavras x- para Private Use não registrável.

Métodos de autenticação repetiam os intervalos e declaravam COMMON, LIMITED USE ou OBSOLETE. Sem especificação pública, um método não podia ser COMMON. Uma nova entrada não podia nascer OBSOLETE. A classificação registrava intenção, não uma pesquisa de utilização.

Novos tipos de mensagem precisavam de Standards Action. As mensagens extensíveis reduziam a necessidade de ampliar a escolha principal do protocolo, mas não a eliminavam. Alterar o envelope básico merecia uma barreira maior que uma convenção privada.

O registro antigo de Directory Systems Names deixou de aceitar entradas porque LDAPv3 usava descritores de OID. A lista existente, ligada a LDAPv2, deveria permanecer pública para fins históricos. Encerrar alocações não significava apagar registros.

Na análise especializada, o solicitante publicava um formulário completo por duas semanas. Uma revisão reiniciava o prazo. Participantes podiam apresentar objeções; o especialista aprovava e encaminhava ou recusava, e havia recurso. Pedidos por ordem de chegada iam diretamente a IANA.

A propriedade também seguia a política. IESG controlava valores de Standards Action; solicitantes normalmente controlavam os demais. Atualizações enfrentavam restrições equivalentes às novas inscrições. Se o proprietário não pudesse ou não quisesse corrigir um registro necessário, IESG podia assumir o controle.

Objeções de terceiros podiam ser anexadas como comentários após Expert Review. Isso permitia preservar divergência relevante quando o proprietário não aceitava alteração. O registro não precisava fabricar unanimidade para continuar útil.

Os modelos solicitavam identificador, descrição, especificação, contato, autor ou controlador de mudança, uso e comentários. Um número isolado evita apenas uma duplicação administrativa. Não mostra o significado, a fonte técnica nem quem pode repará-lo.

O RFC 2434 forneceu o vocabulário geral usado em 2002; o RFC 8126 o atualizou depois. As páginas atuais de parâmetros LDAP da IANA demonstram continuidade pública, não imutabilidade de todos os campos nem implementação de cada entrada.

RFC 3377 situou a especificação LDAPv3 de então. RFC 2251, RFC 2252 e RFC 2255 forneceram contexto de protocolo, schema e URL; RFC 4510 descreveu a revisão posterior. Essa genealogia não mede adoção.

O princípio durável foi variar a fricção pelo risco. Exigir padrão completo para toda experiência sufocaria testes. Distribuir valores públicos sem documentação transferiria o custo para colisões futuras. Espaços experimentais e privados mantinham saídas sem prometer sentido mundial.

A especificação inicial mínima de Lu Heng ilumina a escolha: padronizar partições, políticas, formulários, proprietários e reparo, deixando extensões futuras para textos locais. Suas camadas de realidade distinguem alocação, registro, especificação, código, implantação e resultado. Uma entrada no registro prova apenas sua camada.

O RFC 3383 fez da extensibilidade uma responsabilidade de custódia. O identificador oferecia lugar; a política definia o preço de entrar no comum; o registro preservava significado, responsável e caminho de correção depois do momento da alocação.

Fontes