Pular para o conteúdo principal

Horizonte temporal

Plurianual

Na faceta Horizonte temporal, a inteligência de horizonte temporal Plurianual organiza os artigos pelo período durante o qual se espera que um sinal seja relevante. A página ajuda os leitores a distinguir mudanças operacionais imediatas de mudanças de ciclo mais longo em governança, investimento, padrões e infraestrutura, que podem se desenrolar ao longo de trimestres ou anos. Ela conecta premissas de tempo com evidências públicas, atores relacionados, contexto de mercado, exposição de clientes, pressão de políticas públicas e planejamento de infraestrutura, para que os leitores possam avaliar se um desdobramento é urgente, estratégico ou ainda aguarda evidências de confirmação. A página também explica como o horizonte temporal altera o significado de um sinal, quais organizações podem estar expostas e quais decisões de infraestrutura exigem ação de curto prazo ou monitoramento de ciclo longo.

O byte que dizia “comece de novo”: SLIP, RFC 1055 e o custo de recuperar uma moldura serial

História

O byte que dizia “comece de novo”: SLIP, RFC 1055 e o custo de recuperar uma moldura serial

Uma linha serial não entrega datagramas prontos; ela entrega uma sequência de bytes e, às vezes, deixa no receptor uma sobra do ruído da linha. RFC 1055 sugeriu uma resposta muito econômica: mandar `END` no início do próximo pacote, além de mandá-lo no fim. Esse primeiro byte não…

31 de ago. de 2026
Mike McBride e o registro multicast que impediu um tipo de colisão

IETF

Mike McBride e o registro multicast que impediu um tipo de colisão

O erro estava na planta do condomínio: dois mecanismos diferentes tinham autorização para escolher endereços no mesmo lote. A RFC 10028 redesenhou os limites. O registro passou a evitar uma colisão por construção, mas não instalou a nova planta nos equipamentos antigos.

31 de ago. de 2026
A virada não foi uma só: como a RFC 897 separou renomeação de resolução DNS

História

A virada não foi uma só: como a RFC 897 separou renomeação de resolução DNS

Em março de 1984, DHOSTS.TXT virou HOSTS.TXT. A troca é pequena no nome do arquivo e enorme como evidência: os nomes em estilo de domínio podiam tornar-se oficiais dentro da própria tabela antiga, antes de os programas passarem a consultar servidores. O novo vocabulário chegou…

31 de ago. de 2026
As LANs que o host não deveria ver: RFC 925 e o custo de esconder a topologia

História

As LANs que o host não deveria ver: RFC 925 e o custo de esconder a topologia

Um site da Internet inicial podia mostrar cada cabo ao restante da rede ou fazer vários LANs parecerem uma única rede local aos seus hosts. RFC 925 escolheu a segunda ilusão: preservou o ARP comum do host e transferiu para um intermediário a descoberta, a memória e, por vezes, a…

31 de ago. de 2026
O portador não era a conexão: como a RFC 892 separou o estado de transporte do caminho de rede

História

O portador não era a conexão: como a RFC 892 separou o estado de transporte do caminho de rede

O registro atual ainda reserva `iso-tsap` na porta 102, mas essa linha não conta a história inteira. Antes de o ISO transport ser colocado sobre TCP, a RFC 892 já separava o contrato de transporte da conexão de rede usada para carregá-lo. O número coordenava uma entrada…

31 de ago. de 2026
Gavin Brown e o create bem-sucedido que ainda não havia registrado o domínio

IETF

Gavin Brown e o create bem-sucedido que ainda não havia registrado o domínio

Um protocolo pode confirmar o recebimento de uma intenção com absoluta precisão e continuar sem resposta sobre quem ficará com o nome. Na RFC 8334, o código 1001 não é uma contradição: é a fronteira entre aceitar a aplicação e alocar o domínio.

31 de ago. de 2026
Russ Housley e o endereço MAC que o certificado podia nomear, mas não tornar único

IETF

Russ Housley e o endereço MAC que o certificado podia nomear, mas não tornar único

Uma assinatura consegue preservar seis ou oito octetos com precisão. Ela não consegue, sozinha, dizer onde esses octetos estão em uso agora, quem os observou nem qual regra local permite uma consequência.

31 de ago. de 2026
O caminho mais rápido levava a hora, mas não escolhia o relógio mestre: a RFC 891

História

O caminho mais rápido levava a hora, mas não escolhia o relógio mestre: a RFC 891

No DCN, o mesmo HELLO ajudava um Fuzzball a escolher a saída de pacotes e a estimar a diferença entre relógios. A combinação era econômica, não absoluta: a rota aceitava uma medida, a configuração apontava o mestre e o relógio local ainda podia adiar, graduar ou recusar a…

31 de ago. de 2026
O quadro era mais longo que o datagrama: como a RFC 894 manteve o preenchimento Ethernet fora do IP

História

O quadro era mais longo que o datagrama: como a RFC 894 manteve o preenchimento Ethernet fora do IP

Em abril de 1984, dois Ethernets receberam dois limites diferentes: 1.500 octetos na rede de 10 Mb/s e 1.536 na Experimental Ethernet de 3 Mb/s. A regra importante, porém, não era nenhum desses números. Nos dois casos, o enlace podia completar uma trama curta, mas os octetos…

31 de ago. de 2026
Benoît Claise e o augment que o módulo-base não conseguia nomear

IETF

Benoît Claise e o augment que o módulo-base não conseguia nomear

Há dependências que deixam sua assinatura no arquivo que as usa. E há dependências que chegam de fora e mudam o que o arquivo significa sem aparecer nele. É nesse segundo grupo que a RFC 10035 intervém.

31 de ago. de 2026
Descobrir quem dizia oferecer não era confirmar o serviço: a lição da RFC 887

História

Descobrir quem dizia oferecer não era confirmar o serviço: a lição da RFC 887

Uma consulta por broadcast podia trazer o endereço de um candidato, mas a RFC 887 ainda mandava perguntar diretamente a ele. A arquitetura tratava memória de terceiros, afirmação do servidor e resultado da aplicação como etapas diferentes.

31 de ago. de 2026
Kazuho Oku e o campo que torna a recusa visível sem prometer streaming

IETF

Kazuho Oku e o campo que torna a recusa visível sem prometer streaming

Uma resposta pode terminar com sucesso e ainda fracassar no que mais importava: entregar o primeiro byte a tempo. A RFC 10036 dá nome e consequência a uma decisão de intermediários HTTP, mas não transforma uma cadeia desconhecida em garantia de ponta a ponta.

31 de ago. de 2026
A lista chamou de oficial, não de implementado: como a RFC 880 separou status de código em execução

História

A lista chamou de oficial, não de implementado: como a RFC 880 separou status de código em execução

O Stream Protocol tinha uma implementação real, mas a própria lista advertia que ela havia evoluído e talvez já não correspondesse à especificação. A RFC 880 não deixou o código falar em nome do documento, nem o documento falar em nome do código.

31 de ago. de 2026
Aaron Parecki e o BFF que impede o roubo de tokens, mas não o sequestro do cliente

IETF

Aaron Parecki e o BFF que impede o roubo de tokens, mas não o sequestro do cliente

O Backend for Frontend muda o lugar onde a autoridade OAuth reside: o token deixa o JavaScript e passa ao servidor. A RFC 10017 mostra o ganho e o limite dessa mudança. Um código hostil pode não conseguir levar a credencial embora e ainda assim pedir ao BFF que aja enquanto a…

31 de ago. de 2026
A porta dos fundos não era uma rota: como a RFC 831 alcançava uma SATNET particionada

História

A porta dos fundos não era uma rota: como a RFC 831 alcançava uma SATNET particionada

Quem fazia a chamada X.25 pagava a conta. Por isso, até a direção de abertura do túnel fazia parte da engenharia de contingência. A RFC 831 combinou essa restrição física com uma regra de controle ainda mais importante: o host de recuperação poderia reescrever um fluxo de…

31 de ago. de 2026
O gateway levou os bytes, mas não inventou o significado: como a RFC 875 desafiou a tradução de protocolos

História

O gateway levou os bytes, mas não inventou o significado: como a RFC 875 desafiou a tradução de protocolos

O problema apareceu quando a palavra “pronto” cruzou a fronteira. Pronto para quem: para o IMP ao lado do gateway, para o transporte remoto ou para a aplicação final? A RFC 875 mostrou que traduzir esse sinal exigia escolher um fato que os dois protocolos não descreviam da mesma…

31 de ago. de 2026
Hannes Tschofenig e o identificador de autoridade que não assinou o token

IETF

Hannes Tschofenig e o identificador de autoridade que não assinou o token

Uma chave pode ter assinado o componente instalado; outra, a evidência EAT sobre o estado observado. A RFC 10013 impede que o sistema use a validade das duas assinaturas para inventar uma identidade única ou uma autorização que nenhuma delas concedeu.

31 de ago. de 2026
O arquivo mestre podia estar em dia e a rede não: como a RFC 849 dividiu push e consulta

História

O arquivo mestre podia estar em dia e a rede não: como a RFC 849 dividiu push e consulta

Em 1983, o problema não era apenas manter HOSTS.TXT correto no SRI-NIC. Era fazer uma máquina que perdera o aviso descobrir a mudança sem baixar novamente um arquivo idêntico. A RFC 849 distribuiu essa tarefa entre versão, entrega, integridade, instalação e recuperação local.

30 de ago. de 2026
Corey Bonnell e a assinatura de CRL feita por uma chave sem autorização

IETF

Corey Bonnell e a assinatura de CRL feita por uma chave sem autorização

O verificador pode provar que uma chave assinou uma lista de revogação e ainda não provar que aquela chave foi certificada para esse trabalho. A RFC 10007 fecha essa distância: em certificado v3 do emissor de CRL, `keyUsage` precisa existir e `cRLSign` precisa estar marcado.

30 de ago. de 2026
Kireeti Kompella e a resposta Echo que não comprovou o serviço

IETF

Kireeti Kompella e a resposta Echo que não comprovou o serviço

Uma resposta MPLS Echo pode mostrar que uma sonda definida chegou a um roteador capaz de explicar um FEC específico. Ela não comprova todos os caminhos ECMP, a prontidão do backup ocioso, a simetria da volta, o payload do cliente nem a conclusão da aplicação. Em LSP Ping, a…

30 de ago. de 2026