Resumo

  • RFC 3969 reservou cada nome de parâmetro URI em SIP e SIPS para impedir dois significados incompatíveis; a especificação de origem, não a reserva dupla, decidia onde o parâmetro se aplicava.
  • O documento escreveu “Specification Required” e também exigiu RFC de padrões. RFC 5727 reconheceu a contradição e esclareceu que a intenção era Standards Action.

RFC 3969 tomou uma decisão que parece redundante: todo nome iria para SIP e SIPS, ainda que o parâmetro não se aplicasse a um deles. O segundo registro não dizia “funciona aqui”. Dizia “ninguém pode usar esta mesma palavra aqui com outro sentido”. Era uma reserva preventiva de identidade.

A lacuna vinha de RFC 3261, que permitia novos parâmetros e valores sem criar seu registro IANA. Extensões independentes poderiam escolher a mesma palavra curta para funções distintas e manter mensagens sintaticamente válidas, porém semanticamente incompatíveis. Em dezembro de 2004, RFC 3969 construiu o ponto de coordenação ausente.

Duas vagas, uma definição

A tabela inicial trazia comp, lr, maddr, method, transport, ttl e user. comp remetia a RFC 3486; as demais entradas iniciais, a RFC 3261. Cada linha guardava o nome, um indicador de valores predefinidos e referências.

Essa estrutura exige leitura cautelosa. Predefined Values: Yes não contém a lista inteira: o implementador precisa seguir todas as referências. No registro IANA de parâmetros SIP, transport hoje aponta para RFC 3261 e RFC 7118. A linha é um índice vivo; uma cópia antiga pode continuar historicamente fiel e já não bastar para um analisador atual.

Os nomes registrados eram palavras reservadas. Um nome local não registrado podia funcionar, mas corria risco de colisão futura. O registro não oferecia árvore para extensões de fornecedores. RFC 3427 havia alertado que extensões SIP poderiam ampliar muito a complexidade ou prejudicar a segurança, justificando a exigência de documentação em RFC.

Ainda assim, autoridade de nome não era autoridade de execução. RFC 5630 esclareceu depois o tratamento de SIPS e suas expectativas de segurança; RFC 3263 tratou de descoberta de servidores e transporte. A reserva em dois esquemas não incorpora essas condições e não prova que um produto as implementou.

O rótulo de política precisou de uma segunda leitura

Na seção 4.2, RFC 3969 usou “Specification Required”, categoria de RFC 2434. Logo depois, exigiu que o parâmetro fosse definido por RFC da trilha de padrões. Os dois filtros distribuem decisão e revisão de modo diferente.

RFC 5727 registrou a falha explicitamente: a contradição vinha de uma compreensão incorreta das categorias, e a política pretendida era Standards Action. É o que a página atual da IANA mostra. RFC 8126 atualizou mais tarde o vocabulário de políticas e ajuda a ler esses termos como regras de autoridade, não simples etiquetas.

O presente não apaga essa proveniência. O registro do RFC Editor, a consulta de erratas e o Datatracker documentam estado, correções e história. RFC 3986 oferece a arquitetura geral de URI; RFC 6648 reforçou depois que grafia e prefixos não certificam maturidade ou segurança.

Ao investigar um parâmetro, registre esquema, nome e momento. Consulte a linha daquele momento, siga todas as RFCs e leia aplicabilidade e segurança. Só então verifique versão do software, configuração, processamento e resultado. Uma chamada bem-sucedida pode ter ignorado o parâmetro; um nome registrado pode chegar a um terminal que nunca o implementou.

RFC 3969 reservou de modo amplo para permitir conclusões estreitas e confiáveis. Duas posições preservaram uma identidade. Elas nunca foram dois recibos de capacidade.

Fontes