Okuma
☕ 9 dk
Konular
Ağlar · Yapay zekâ araçları
Rev
15 Kas 2026

İçine düştüğüm graph

RFC, Request for Comments’in kısaltması. İnternetin gönüllü standartlarını yapan kurum IETF,1 Internet Engineering Task Force. Kendi tanımıyla internet kullanıcılarının, ağ operatörlerinin ve donanım üreticilerinin çoğu zaman benimsediği gönüllü standartları yapıyor. Misyon belgesi RFC 3935’e göre amacı interneti daha iyi çalıştırmak. Kapısı da açık: ilgilenen herkes çalışmaya katılabiliyor. RFC’ler hakkındaki sayfasında bunu açık açık söylüyor: RFC’ler IETF’in asıl ürünü ve internetin teknik temellerini anlatıyor, adresleme, yönlendirme ve taşıma gibi. 1969’daki RFC 1’den başlayarak sırayla numaralanıyorlar, herkes ücretsiz okuyabiliyor ve bir RFC yayımlandıktan sonra bir daha hiç değişmiyor. Düzeltme, eskisini gösteren yeni bir RFC olarak geliyor. Bir tanesini okumanın seni bir graph’ın içine çekmesi de tam bu son kural yüzünden.

TL;DR: Uzun bir hikâye bu, RFC 1’den Lynx’e, oradan bugüne. Asıl varmak istediğim yer, bir RFC’yi okurken içine düştüğüm o graph ve onu çizen küçük oyuncak. Bunalırım diyorsan doğrudan oraya atla, kimse kızmaz :)

2017-2018 yıllarında EMVCo’nun 3-D Secure 2.0 entegrasyonu üzerinde çalışıyordum2 EMVCo’nun kendi tanımıyla EMV 3-D Secure, kartın fiziken sunulmadığı (card-not-present) e-ticaret alışverişlerinde tüketicinin pürüzsüzce doğrulanmasını sağlayan bir mesajlaşma protokolü. EMVCo da kendini, güvenli ödeme işlemlerinin dünya çapında birlikte çalışmasını ve kabul edilmesini sağlayan küresel teknik kurum olarak tanıtıyor. 2.0.0 spesifikasyonunu Ekim 2016’da, 2.1.0’ı da 31 Ekim 2017’de yayımladı. ve iş beni sürekli üç dokümana götürüyordu: RFC 7515 (JWS), RFC 7516 (JWE) ve RFC 7519 (JWT). Çıktılarını almıştım. Kâğıt üzerinde, elimde kalemle satır satır anlamaya çalıştığımı hatırlıyorum: bir imza neden böyle diziliyor, şu alan neden orada.

Spesifikasyonda mesajların nasıl işlendiğini ve doğrulandığını anlatan bölümlerde JWS ve JWE sürekli geçiyordu. Mesela uygulama tabanlı akışta SDK’nın, ACS’nin imzaladığı içerikteki JWS imzasını doğrulaması gerekiyordu,3 ACS, Access Control Server. Spesifikasyonun sözlüğüne göre kartı veren tarafta (Issuer Domain) çalışan, bir kart numarası ve cihaz tipi için doğrulamanın mümkün olup olmadığına bakan ve kart sahibini doğrulayan bileşen. ACS’ye giden challenge mesajları da JWE nesnesi olarak gidiyordu. Ben de o iki kısaltmayı anlamaya çalışıyordum.

Bu arada Go’da ya da Node.js’te kullandığın JWT kütüphanesinin, daha doğrusu auth paketinin, aslında tam bu RFC’lerin bir implementasyonu olduğunu biliyor muydun? Go’daki golang-jwt README’sine kendini “implementation of JSON Web Tokens” diye tanıtarak başlıyor ve bu ifadeyi RFC 7519’a linkliyor, Node.js’teki jsonwebtoken da “An implementation of JSON Web Tokens” diye açılıyor, linki yine aynı RFC’ye.

RFC’leri bilerek okuduğum ilk zaman oydu. Ama ayağımın altında oldukları ilk zaman değildi.

Her gün kullanıyoruz

HTTP, TCP, TLS, DNS, login cookie’ndeki JWT: bu adları her gün ağzımıza alıyoruz ama çoğumuz arkalarındaki dokümanı hiç açmadık. Ben de açmamıştım, denk gelip okuyana kadar. Bu adların her biri bir RFC. IP RFC 791, 1981’den. TCP artık 2022’de baştan yazılan RFC 9293, HTTP’nin anlamı da RFC 9110’da duruyor.

Bu arada şu an da senin için çalışıyorlar. DNS (RFC 1035) hayatibis.dev’i bir adrese çevirdi, byte’ları TCP taşıdı (tarayıcın HTTP/3 seçtiyse onun küçük kuzeni QUIC, RFC 9000), yol boyunca TLS 1.3 kimse okumasın diye kilitledi, bu sayfayı da HTTP istedi. Yani RFC’ler hakkındaki bir yazıyı bir yığın RFC sayesinde okuyorsun :)

Bir pazar günü aktivite olarak Ben Eater’ın Networking tutorial serisini izlemiştim. On üç video, ilkinin adı “Sending digital information over a wire”, yani bir kablo üzerinden dijital bilgi göndermek. Adım adım anladıkça çok etkilendiğimi hatırlıyorum. Bugünlerde biraz nostaljik aktiviteler bunlar bizim için, ama RFC’ler ve böylesi deep dive’lar benim için hep önemliydi.

Lynx, Netscape’ten bile öncesi

Aslında daha önce başlamıştı. Üniversitedeyken web programlamanın temelleri dersimizde kıymetli Gönenç hocamız Lynx’ten bahsetmişti: terminalde çalışan, web’i düz metin olarak gösteren bir tarayıcı. Onunla web’in temellerine doğru bir yolculuğa çıktım ve altını kurcalamaya başladım. Düşün ki daha Netscape bile ortada yok :) Lynx 1992’de Kansas Üniversitesi’nde başladı, Netscape Navigator 1994’te çıktı.

Lynx çalışan bir terminal penceresi, RFC 1'in ilk sayfasını gösteriyor: Network Working Group, Request for Comments 1, Steve Crocker, UCLA, 7 April 1969, Host Software, altında içindekiler ve en altta Lynx'in tuş yardımı.
Lynx 2.9.3'te RFC 1: 1969'dan bir not, 1992'den bir tarayıcıda, hâlâ rahat okunuyor. Terminalden alınmış gerçek bir Lynx ekranı.

Bu yazıyı yazarken bulduğum bir bağ var. Lynx’in üç yazarından biri olan Lou Montulli, 1994’te Netscape’in kurucu mühendislerinden biri oldu ve HTTP cookie’sini orada ortaya çıkardı.4 <blink> etiketi de ondan. 1994’ten kalan her şey cookie kadar iyi yaşlanmadı. Cookie 1997’de RFC 2109 oldu ve üzerinde onun adı var, bugün kullandığımız hali RFC 6265. Üniversitede tanıdığım metin tarayıcısı ile bugün her tarayıcıdaki cookie aynı graph’ta iki düğüm ötede duruyor.

Bu yolculuk bana herhangi bir protokolden daha fazlasını verdi aslında: içinde olmadığım bir dünyayı bugünden izleyebilmeyi. 1969’da da 1992’de de orada değildim. Notları okurken o dünyayı karar karar takip edebildim.

RFC 1

Bu hikâyeyi Steve Crocker kendisi RFC 8700’de, Fifty Years of RFCs’te anlatıyor ve hikâye henüz var olmayan bir ağla başlıyor.

ARPANET bir devlet alımıydı. Advanced Research Projects Agency, yani ARPA (1972’de adı Defense Advanced Research Projects Agency, DARPA oldu) onu 1968 yazında satın almaya başladı. Crocker dönemi “remember Vietnam, flower children, etc.?” diye hatırlatıyor :) Crocker’ın anlatımıyla packet switching’i iletişim stratejisinin temel bir parçası olarak deneyen ilk girişimdi. Crocker’a göre internet de başlangıcını ARPANET’e borçlu. Plan, ABD’nin batısında, her birinde farklı bir bilgisayar çalışan dört yeri birbirine bağlamaktı: UCLA, Menlo Park’taki SRI, UC Santa Barbara ve Utah Üniversitesi.

Devletin teklif talebi her yer için bir tane olmak üzere dört packet switching cihazı istiyordu, adları Interface Message Processor’dı, kısaca IMP. Onları yapmak BBN’in işiydi. Massachusetts’in Cambridge şehrindeki Bolt Beranek and Newman ihaleyi 1968’in sonunda kazandı, Ocak 1969’da işe başladı ve ilk IMP’yi Eylül başında UCLA’ya teslim etmesi gerekiyordu.

Yani 1969’un başında ARPANET henüz yoktu. BBN IMP’leri yapıyordu, bilgisayarların birbiriyle nasıl konuşacağı ise dört yerden gelen küçük bir lisansüstü öğrenci ve çalışan grubuna kalmıştı. Notlarını Crocker toparlıyordu. Notların, grubun sahip olmadığı bir yetkiyi iddia ediyormuş gibi görüneceğinden çekiniyordu. Sonunda uykusu kaçtığı bir gece birkaç alçakgönüllü cümle yazdı. Kural basitti: herkes her şeyi söyleyebilirdi ve hiçbir şey resmî değildi. Adını da Bill Duvall önerdi: Request for Comments.

RFC 1, “Host Software”, 7 Nisan 1969 tarihli ve giriş bölümü şöyle bitiyor: buradakilerin çok azı kesin, tepki bekleniyor. RFC 3 çıtayı olabildiğince alçak tuttu: notların cilalı olmasındansa zamanında olması tercih edilir. Bir notun en kısa uzunluğu tek cümleydi.

En sevdiğim kısım bu. İnterneti ayakta tutan dokümanlar, gece yazılmış, herkesi cevap vermeye çağıran alçakgönüllü notlar olarak başladı.

İçine düştüğüm graph

Tek bir şeye bakmak için bir RFC açıyorsun, seni başka birine gönderiyor. Sadece RFC 9110’da 83 kaynak var, çoğu başka RFC. Üstelik dokuz RFC’yi geçersiz kılıyor, yani eski bir link seni artık geçerli olmayan bir metne bırakabiliyor. RFC Editor’ın indeksinde5 RFC Editor kendini, RFC’leri düzenlemek, yayımlamak ve arşivlemek için birlikte çalışan birkaç gruptan oluşan bir yapı olarak tanıtıyor. 6 Kasım 2026’da 9.854 RFC vardı ve numaralar beş haneye geçti: o gün en yenisi RFC 10080’di.

Yıllardır aklımın bir köşesinde bir fikir duruyordu: bir RFC’yi bütün o graph gözünün önündeyken okumak, nerede olduğunu ve neyi atladığını görebilmek. Fikir olarak kaldı, hani akşamı hiç bulunamayan hobi projelerinden. AI ile geliştirme yaptığımız bu dönemde proje bir saatten kısa sürede çıktı.

Adı rfc-graph (kaynak kod). RFC 1’den başlıyor ve her RFC’nin referanslarını IETF Datatracker’dan ve RFC Editor’dan canlı çekiyor.6 IETF Datatracker, kendi tanımıyla IETF standartları üzerinde çalışanların her gün kullandığı, IETF veritabanının ön yüzü. Her RFC yayımlandığı yılın rengiyle bir yıldız, ışık da bir RFC’den onun üstüne kurulanlara doğru akıyor. Metni graph’ın yanında okuyabiliyorsun, içindeki her “RFC nnnn” de içeri açılan bir kapı.7 Eski RFC’lerin neredeyse hiç kayıtlı referansı yok, o yüzden metinlerindeki “RFC nnnn” adları da kenar olarak çiziliyor. RFC 1 hiçbir şeye referans vermiyor; başlattığı şeyler öbür tarafta görünüyor.

Gece gökyüzü gibi koyu bir graph: ortada parlak nane yeşili bir yıldız olarak RFC 9110, ondan onlarca çizgi başka RFC'lere uzanıyor; eskiler amber, yeniler nane yeşili, bazılarının üstü geçersiz diye çizili. Yan panelde HTTP Semantics başlığı, yazarları ve geçersiz kıldığı RFC'ler.
rfc-graph'ta RFC 9110: referans verdiği 64 RFC, yıllarına göre renkli, geçersiz kılınanların üstü çizili.

Madem Lynx’le başladık, aynı oyuncak orada nasıl görünüyor ona da bakalım. Gökyüzünü çizmek için JavaScript gerekiyor, Lynx’e de butonlar ve beş yalnız yıldız kalıyor :)

rfc-graph.hayatibis.dev'i açmış Lynx: bir sıra BUTTON yer tutucusu, 1969 ve 2026 yılları, lejanttaki çizgilerin yerinde beş yıldız işareti.
Lynx'te rfc-graph: JavaScript yok, gökyüzü de yok. Gerçek bir Lynx ekranı.

RFC’ler bugün neyle uğraşıyor

MCP’nin de RAG’in de bir RFC’si yok.8 MCP kendi dokümanında, AI uygulamalarını dış sistemlere bağlamak için açık kaynaklı bir standart olarak tanımlanıyor. RAG, yani retrieval-augmented generation, önceden eğitilmiş parametrik ve parametrik olmayan belleği dil üretiminde birleştiren modelleri anlatan bir 2020 makalesinden geliyor. MCP’nin kendi süreci var (birazdan geliyorum), ama o da RFC’lerin üstüne kurulu: authorization spec’i dayandığı standartları tek tek sayıyor, on maddenin altısı RFC. 2026’da Kasım’a kadar çıkan 152 RFC’nin 44’ü güvenlik alanından ve içlerinden belirgin bir tema geçiyor: kuantum bilgisayarlara hazırlık, TLS 1.3 ve SSH için post-kuantum anahtar değişimi. Bunları okuyup anlamaya çalışıyoruz. Geçmişi okumak keyifli ama geleceği görmeye, anlamaya çalışmak da bir hayli zor :) HTTP’ye yeni bir metot geldi, QUERY: gövde taşıyabilen ama güvenle tekrarlanabilen bir istek. Yapay zekâyla ilgili tek RFC şimdilik bir rapor: IAB’in AI-CONTROL çalıştayından çıkan RFC 9969,9 Internet Architecture Board. Charter’ı RFC 2850’ye göre hem IETF’in bir komitesi hem de Internet Society’nin danışma organı; ana rollerinden biri IETF’in farklı alanları arasında uzun vadeli planlama ve koordinasyon. bir sitenin AI crawler’larına pratik olarak nasıl “hayır” diyebileceği üzerine.10 RFC 9405’i saymazsak: “AI Sarcasm Detection: Insult Your AI without Offending It”, 1 Nisan 2023. İlk 1 Nisan RFC’si 1978’deki RFC 748, “Telnet randomly-lose option”, RFC 8700’e göre de bu RFC’lerin geniş bir hayran kitlesi var.

Agent’lar için yeni bir döngü mü?

Dönüp dolaşıp geldiğim soru bu. Açık, numaralı notlar kültürü bugünkü agent’ları mı doğurdu, AI devrimiyle yeni bir RFC döngüsü kurulabilir mi?

Bir kısmı zaten oluyor. IETF Ekim 2026’da Agent Communication Protocols adında bir çalışma grubu kurdu, amacı agent’lar arası diyaloğu yönetecek ortak bir temel protokol tanımlamak. Oraya giden draft’lardan biri, Framework, Use Cases and Requirements for AI Agent Protocols (Ekim 2025), hâlâ “Network Working Group” diye açılıyor, RFC 1’in en üstündeki kelimelerle aynı. Bir başka grup, AI Preferences, içeriğin AI için nasıl kullanılabileceğini söylemeye yarayan bir sözlük yazıyor.

Agent kimliği de aynı yoldan gidiyor. IETF’in WIMSE (Workload Identity in Multi-System Environments) grubundan 2 Kasım 2026 tarihli bir draft, AI Identity Management System, bir bölümüne “Agents are workloads” başlığını koymuş. Ne yapmayacağını da baştan söylüyor: yeni protokol tanımlamıyor. Zaten yaygın kullanılan standartlar agent’ların authentication’ı ve authorization’ı için nasıl uygulanır, nasıl genişletilir, onu anlatıyor. Bu yazının çıktığı hafta da IETF San Francisco’da toplanıyor: IETF 127 14 Kasım Cumartesi başlıyor, 20 Kasım Cuma öğleden sonra bitiyor.

IETF’in dışında da alışkanlık kopyalanıyor. Model Context Protocol, Specification Enhancement Proposal denen önerilerle değişiyor: bir önerinin resmî incelemeden önce onu sahiplenecek bir working group bulması gerekiyor, “Final” olması için de spesifikasyon metni, referans implementasyonu ve conformance testi tamam olmalı. Açıkta yaz, çalıştığını göster. Yeni bir okurla 1969 aslında.

Çıktılara dönersek

Kâğıt üzerinde okuduğum JWS, JWE ve JWT 2015 dokümanları ve hâlâ graph’ın içindeler: RFC 9964 bu yıl JOSE’ye post-kuantum bir imza getirdi. O agent kimliği draft’ı da aynı yere çıkıyor: agent’ın sunduğu access token birçok kurulumda JWT, diyor. Gerçi agent harness11 Anthropic, Claude Agent SDK’yı kodlamada ve modelin araçları kullanarak bağlam toplaması, plan yapması ve uygulaması gereken başka işlerde de iyi, güçlü ve genel amaçlı bir agent harness olarak tanımlıyor. Claude Code da bu harness üzerinde çalışıyor. gibi kavramları sindirip uygulamaya koyulduğumuz bu günlerde kâğıda çıktı almak artık pek iyi bir fikir değil. Crocker 1969’da tepki bekliyordu. Bugün o referansları takip eden okur çoğu zaman bir agent, bazen de bir pazar günü elinde kalemle hâlâ birimiz.

Senin her gün kullanıp hiç açmadığın RFC hangisi :)

Ayrıca DEV