Domínio principal
Infraestrutura de Internet
Na faceta Domínio principal, Infraestrutura de Internet grupos de inteligência são organizados por domínio principal para que os leitores possam acompanhar uma área de foco em infraestrutura da internet, governança, mercados de conectividade ou capital digital. A página reúne artigos relacionados, evidências públicas, instituições, empresas, pessoas, exposição regional, dependências operacionais e contexto de mercado que, de outra forma, poderiam estar espalhados por páginas de categorias separadas. Ela explica o domínio, a provável classe de atores, o contexto de mercado ou de governança e o material de origem que os leitores devem usar ao comparar sinais. Operadores, analistas e leitores de governança podem ver como o mesmo domínio aparece em eventos, perfis, mudanças de mercado, evidências de fontes públicas, dependências regionais e decisões de infraestrutura de ciclos mais longos ao longo do tempo.
História
Control-S só era comando enquanto a opção valia: a fronteira Telnet do RFC 1080
Um terminal interrompe a rolagem ao receber Control-S; um editor espera que a mesma tecla atravesse a sessão como entrada. O RFC 1080 não resolveu a disputa escolhendo um uso permanente. Ele definiu um consentimento de sessão, um pedido remoto e um ponto de decisão que continuava…
História
O NIC parecia contínuo. As escritas do registro tinham parado: RFC 1261
Uma migração pode preservar a relação do usuário com um serviço e, ao mesmo tempo, interromper de propósito a única operação que transforma um pedido em registro oficial. Esse é o ponto cuidadoso de RFC 1261. Em 1991, a transição do Network Information Center prometia manter vias…
História
A fibra era rápida. O serviço ainda era um sistema: RFC 1077
Em 1988, a fibra óptica já permitia imaginar uma reserva colossal de capacidade bruta. O RFC 1077 recusou o atalho de chamar essa capacidade de serviço: entre a luz e o usuário havia comutação, hosts, alocação, gestão e medição.
Arquivo de Caso
O token nomeou o chip. Não decidiu a porta: RFC 9783 e a autoridade da atestação PSA
Há uma diferença decisiva entre receber um token tecnicamente bem formado e receber uma autorização. Um relatório pode trazer nonce correspondente, client ID esperado, uma instância, uma implementação, estado de ciclo de vida e componentes de software. Esse conjunto dá segurança…
História
A fila aceitou o trabalho. Não tinha impresso uma página: as duas confirmações da RFC 1179
Em impressão em rede, “aceito” costuma soar como a última palavra, embora seja apenas uma passagem do percurso. O cliente apontou uma fila, transmitiu arquivos e recebeu respostas positivas do daemon. Isso é evidência útil. Não é evidência de que uma página foi composta, que uma…
História
O HEMS saiu da disputa de protocolos; seu modelo de dados ficou na sala: RFC 1076
O episódio mais importante do HEMS não aconteceu entre dois agentes. Aconteceu na escolha coletiva de 1988: um de seus autores recomendou retirar o sistema para que a Internet chegasse a um acordo rápido sobre SNMP. A saída, porém, não levou embora o catálogo de informação que o…
História
O anel podia compartilhar um filtro. Não podia provar um grupo: a fronteira multicast da RFC 1469
No início dos anos 1990, o multicast IP precisou caber em uma mídia local de opções físicas estreitas. Um adaptador Token Ring podia decidir quais destinos de hardware receber, mas os poucos endereços funcionais disponíveis não podiam reservar uma etiqueta física para cada grupo…
Arquivo de Caso
O contato perdeu o UID. Não perdeu seus limites: RFC 9982 e a autoridade da identidade de registro
Um job de sincronização pode terminar sem erro, copiar todos os campos visíveis e ainda assim não ter recebido o direito de dizer que duas fichas são a mesma pessoa. Essa diferença aparece no centro da RFC 9982. Ao tornar `uid` opcional em JSContact 2.0 e proibir sua invenção…
História
A NSFNET pôs IP dentro de um endereço OSI; a política ainda escolhia a rota: RFC 1074
Treze pontos ligados em T1 precisavam concordar sobre topologia sem obrigar cada rede regional a adotar o mesmo protocolo interno. A solução de 1988 não foi elegante por pureza. Ela foi disciplinada na mistura: IP carregava os controles, campos de formato NSAP recebiam fatos da…
Arquivo de Caso
O modelo nomeou o endpoint. Não iniciou o serviço: RFC 10009 e a autoridade da configuração HTTP
Um painel pode ficar verde muito antes de um serviço existir. A URI já está na árvore de gestão, as versões permitidas foram escolhidas, os parâmetros TLS e o proxy foram preenchidos, o servidor ganhou um nome. São decisões úteis e auditáveis. A RFC 10009 torna possível…
História
A janela era do cliente; a reação era do servidor: RFC 1073 e Telnet NAWS
Uma conexão Telnet não precisava recomeçar quando a janela mudava. O cliente podia trocar 24 linhas por 64 e enviar outra medida. O servidor, porém, não prometia fazer nada com ela. A RFC 1073 transformou essa assimetria em uma interface explícita: quem possuía a janela declarava…
História
O nome era local. O número ainda precisava de registro: a fronteira de mapeamento DNS da RFC 1101
Em 1989, o DNS já distribuía informações de hosts, mas ainda não oferecia um modo padronizado de perguntar como uma rede era chamada a partir de seu número. A RFC 1101 sugeriu uma resposta feita de PTRs, nomes de host-zero em `IN-ADDR.ARPA` e máscaras. A lição não é que uma…
Arquivo de Caso
A chamada conectou. A identidade ainda precisava ser comprovada: RFC 9970 e o limite da autoridade local
Uma chamada atendida é um acontecimento de rede; não é, por si só, a confirmação de que o interlocutor esperado foi alcançado. RFC 9970 oferece evidência de identidade da parte conectada no retorno de uma conversa SIP. Esse avanço não deve ser usado para transferir ao protocolo a…
História
A Internet era o enlace, não a rede: a fronteira experimental da RFC 1070
Uma tabela antiga podia fazer um roteador novo parecer ausente, embora seu endereço IP continuasse plenamente alcançável. Esse descompasso estava previsto na RFC 1070. O experimento usava a Internet como caminho físico para outra camada de rede, mas deixava a identidade dos…
História
O pedido entrou na fila. O arquivo ainda precisava se mover: RFC 1068 e BFTP
Uma pessoa podia fechar a sessão; a intenção de transferir continuava no computador de controle. Essa foi a promessa prática do BFTP em 1988. A fila devolvia tempo ao operador, mas não encurtava a distância lógica entre aceitar um pedido, abrir duas sessões FTP e comprovar o…
Arquivo de Caso
A preferência foi publicada. Não era controle de IA: RFC 9969
A RFC 9969 expõe uma diferença que nenhuma declaração pública resolve sozinha: manifestar uma preferência sobre uso por IA não é controlar a coleta, o armazenamento, o treinamento, a inferência ou a reparação. O sinal pode ser necessário; não é a evidência de que alguém o recebeu…
Arquivo de Caso
Um identificador de provisionamento não era acesso à rede: RFC 9965
A RFC 9965 dá a um par EAP sem credenciais um modo disciplinado de solicitar um caminho de provisionamento. O domínio `eap.arpa` e seu identificador tornam o pedido compreensível; não autenticam o par, não provam uma rota, não emitem credenciais e não concedem acesso geral à…
História
A trama FDDI carregava IP, não identidade: o limite de encapsulamento da RFC 1188
Uma rede local pode reconhecer uma trama e ainda não saber quem a enviou, se o emissor tinha permissão ou se o conteúdo produziu efeito no outro extremo. A RFC 1188 foi valiosa porque não fingiu resolver tudo isso. Ela especificou como IP e ARP seriam carregados em FDDI e deixou…
História
Para esperar menos, o pacote ganhou uma fila menor: a troca proposta pela RFC 1046
Uma fila curta reduz a espera de quem consegue entrar. Também deixa o excesso do lado de fora. A RFC 1046 transformou essa obviedade em uma proposta para o Type of Service do IPv4: baixa latência vinha com menos espaço de buffer, descarte antecipado e uma fatia limitada do…
Arquivo de Caso
A troca híbrida protege a sessão, mas não escolhe quem é o host: RFC 10042
RFC 10042 combina ML-KEM e ECDH no estabelecimento de chaves do SSH. Essa combinação pode proteger a confidencialidade de uma sessão sob condições definidas; ela não decide qual chave de host o cliente aceita, quem é o usuário nem o que a política local permite fazer.