Network Working Group A. Bhushan Request for Comments: 475 MIT-DMCG NIC: 14919 6 Mart 1973

FTP VE AĞ POSTA SİSTEMİ

Bu makale, 23 Şubat 1973 tarihinde SRI-ARC'de yapılan Ağ Posta Sistemi toplantısının sonuçlarına ilişkin anlayışımı ve FTP (Dosya Aktarım Protokolü) açısından ortaya çıkan etkileri açıklamaktadır. Toplantıda, ağ posta işlevinin FTP kapsamında yer alması gerektiği konusunda genel bir görüş birliği vardı.

FTP şu anda postanın işlenmesi için iki komut sağlamaktadır. MAIL komutu, bir kullanıcının TELNET bağlantısı üzerinden posta göndermesine olanak tanır (sunucu, postayı toplar ve "CRLF.CRLF" karakter dizisini arayarak bitişini belirler). MLFL (mail file) komutu ise bir kullanıcının veri bağlantısı üzerinden posta göndermesine olanak tanır (komutun işlenmesi için bir kullanıcı-FTP gerektirir, ancak sunucunun özel bir karakter dizisi araması gerekmediğinden aktarım daha verimlidir). Bu komutlar ağ üzerinden posta gönderme olanakları sağlamak için kullanılmaktadır. Yerel posta ve SNDMSG programları, birçok sitede ağ üzerinden posta göndermeyi içerecek şekilde değiştirilmiştir (örneğin, BBN_TENEX'te USER@HOST ve MIT-DMCG'de MAIL host user).

Ağ posta sistemi, kullanıcıların bir veya daha fazla ana makinede "posta kutuları" bulunan diğer ağ kullanıcılarına kolayca mesaj gönderebilmelerini sağlayan bir olanak sunmalıdır. Mesajların ya da postanın gerçek zamanlı olarak teslim edilmesi gerekli değildir. Ağ posta sistemi, etkileşimli bir konsollar arası iletişim olanağı değildir; ancak bazı sitelerin "acil" postayı gerçek zamanlı olarak kullanıcılara iletmesi mümkün olabilir (örneğin, kullanıcı o anda oturum açmışsa postanın kullanıcı konsolunda yazdırılması). Posta sistemi ayrıca genel bir süreçler arası iletişim olanağı da sağlamaz; bununla birlikte, posta kutusu adresleri olan programlara mesaj iletmek mümkün olabilir. Süreçler arası ve varlıklar arası iletişim olanakları son derece arzu edilir olmakla birlikte, ağ posta sisteminin kapsamı dışındadır.

"Posta kutusu" ve "posta kutusu adresleri" kavramları, ağ posta sistemine ilişkin bu tartışmanın merkezinde yer almaktadır. Posta kutusu, bir kullanıcının postayı alıp okumadan önce saklandığı yerdir. Kullanıcının dizinindeki bir dosya olabileceği gibi, basılı kopyalar için bir kutu da olabilir. Posta kutusu adresi, gönderenin postayı hedef posta kutusuna gönderebilmesi için gerekli olan adrestir. "Çevrim içi" bir ağ posta kutusu bulunan kullanıcılar için posta kutusu adresi, Ana Makine adresini ve o Ana Makinedeki kullanıcının posta kutusu kimliğini içerir. Posta kutusu kimliği, bir FTP sunucusunun postayı istenen posta kutusuna koyabilmesi için gerekli olan bilgidir. Posta kutusu adresi terimi, çevrim içi ağ posta kutusu adresini ifade etmek için kullanılacaktır.

AĞ POSTA SİSTEMİ İŞLEVLERİ

Ağ posta sistemi aşağıdaki altı işlevi sağlamalıdır:

1. OLUŞTURMA

Bu, kullanıcının mesajını hangi şekilde oluşturduğu ya da kaleme aldığı ile ilgilidir. FTP sunucuları açıkça herhangi bir mesaj düzenleme yeteneği sağlamaz (MAIL komutu durumunda sunucunun düzenleme kuralları uygulanabilir). Karakter silme ve satır iptali gibi düzenleme kuralları ağ genelinde büyük ölçüde farklılık gösterir. Kullanıcı, kendi yerel Ana Makinesinin kurallarına en aşinadır ve ağ postası düzenlemesi için bunlar kullanılmalıdır. Kullanıcının ayrıca mesaj dosyalarını hazırlamak için kullanılabilecek yerel düzenleme sistemlerine erişimi vardır. Mesaj dosyası daha sonra MAIL veya MLFL komutları aracılığıyla iletilebilir (MLFL tercih edilir). Mesajların oluşturulmasının gönderenin sorumluluğu olduğu varsayımına dayanan mevcut FTP yaklaşımı yeterli görünmektedir. TIP kullanıcıları, düzenleme olanakları istiyorlarsa, mesajları oluşturmak ve göndermek için ara Ana Makineleri kullanmalıdır.

2. BULMA

Gönderenin alıcının adresini nasıl belirlediği. FTP, gönderenin alıcının doğru adresini bildiğini varsayar. Yayınlanmış ya da "çevrim içi" bir posta kutusu adresleri listesi yoktur. Bununla birlikte, SRI-ARC'deki Ağ Bilgi Merkezi (NIC) tarafından tutulan (çevrim içi) ve yayımlanan bir ağ katılımcıları listesi vardır. Ağ kullanıcılarına NIC tarafından benzersiz bir "NIC Ident" ve Ana Makine sitesi atanmıştır. Bu nedenle FTP'de, FTP sunucularının NIC Ident'leri posta kutusu kimliklerine eşleyen bir tablo tutması belirtilmiştir. NIC, ağ katılımcıları için yerel posta kutusu adresi bilgilerini çevrim içi olarak tutacak ve yayımlayacaktır. Kullanıcıların yayımlanmış bir listeye bakarak ya da NIC'i çevrim içi olarak sorgulayarak hedef adresleri bulmaları mümkün olacaktır. NIC ayrıca, adres bilgilerini almak için programlar tarafından kullanılabilecek (FTP'ye benzer) bir çevrim içi olanak da sağlayacaktır. Adreslerin NIC tarafından tutulmasına yönelik bu son yaklaşımın birçok avantajı vardır. Kullanıcı, bir grup için birden fazla adres edinebilir ve bunları postayı iletmek için kullanabilir. FTP sunucularının NIC Ident tabloları tutmasına gerek kalmaz ve NIC, soyadlarından, NIC Ident'lerden ya da hatta belirsiz bilgilerden adres bulmak için iyi bir olanak sağlayabilir. Yine de FTP sunucularının NIC Ident'leri, soyadlarını ve diğer standart biçimleri posta kutusu tanımlayıcıları olarak kabul etmesi arzu edilebilir.

3. GÖNDERME

Mesajın hedef posta kutusuna nasıl gönderildiği. Mesajlar doğrudan hedef posta kutusuna (TELNET veya veri bağlantıları üzerinden) ya da NIC gibi bir ara Ana Makine üzerinden gönderilebilir. FTP, ara Ana Makineler tarafından posta yönlendirilmesini açıkça sağlamaz; ancak FTP sunucuları adreslerin yerel olmadığını tanıyabilir ve postayı yönlendirebilir. Postanın yönlendirilmesi durumunda, ara sitenin, posta teslim edildiğinde ya da belirli bir süre içinde teslim başarısız olursa (istek üzerine) bir onay göndermesi arzu edilen bir olanaktır. Mevcut FTP belirtimleri, FTP sunucularının birden fazla adresi kabul etmesini önermektedir ancak bunu zorunlu kılmaz.

4. SAKLAMA

Postanın okunmadan önce nerede saklandığı ve daha sonra başvuru veya geri alma için bilgi bulunup bulunmadığı. FTP, gönderenin postayı saklamasını ya da kopyalarını tutmasını gerektirmez. Okuma, başvuru veya geri alma için bilgiyi saklamak alıcının sorumluluğundadır. Alıcı, postayı bir veri dosyası olarak saklamak zorunda değildir; doğrudan bir kullanıcı konsolunda ya da satır yazıcısında yazdırabilir. FTP, ara siteler tarafından yapılan saklama işlemlerine ilişkin yordamları belirtmez. Bir ara site, posta nihai hedefine teslim edilene kadar yönlendirme için kullanılabilir. Posta teslim edilemezse, ara site teslim edilemeyen bilgileri gönderen tarafa geri göndermelidir. Benzer bir durum, postanın gönderici site tarafından ertelenmesi halinde ortaya çıkar (hedef ana makine çalışmıyor olabilir). Bu durumda gönderici site, kullanıcı açısından bir ara yönlendirici gibi davranır.

5. KAYDETME

Postanın daha sonra başvuru ve geri alma için kataloglanıp kaydedilip kaydedilmeyeceği. FTP şu anda alıcının postayı kaydetmesi için açık bir mekanizma sağlamaz. Posta dağıtımı için bir ara site (NIC) kullanılıyorsa, böyle bir sitenin işlevlerinden biri, istek üzerine postayı kaydetmek olabilir. NIC, postayı kaydetmek için ideal bir yerdir, ancak diğer siteler de postayı kaydetmek isteyebilir. Posta kaydediliyorsa, postanın tüm içeriğini göndermek gerekli değildir. Bunun yerine, belge için yalnızca bir atıf gönderilebilir ve alıcı, postayı yalnızca isterse geri alabilir. Bu durum, NWG/RFC'ler gibi bir gruba dağıtılan büyük belgeler için özellikle yararlıdır. Atıf; yazar, başlık, geri alma yol adı ve belki bir özet içerebilir.

6. OKUMA

Postanın son olarak kullanıcıya nasıl sunulduğu ve kullanıcı tarafından nasıl okunduğu. FTP şu anda posta okumanın tamamen alıcı sitenin işlevi olduğunu varsayar. Bununla birlikte, gönderenin alıcının daha iyi posta okuma olanakları sağlamasına yardımcı olabileceği yollar vardır. Örneğin, alıcı sistem bir mesajın acil olduğunu biliyorsa, bunu hemen bir kullanıcı konsoluna iletebilir. Uzun mesajlar, kullanıcının normal postasında bir bildirimle birlikte ayrı dosyalara konulabilir. Alternatif olarak, posta, okuma programının kullanıcı isteği üzerine geri alabileceği bir atıf olabilir. Farklı posta sınıflarının seçici olarak ele alınması, geliştirilmiş bir ağ posta sistemi için önemlidir.

POSTA SİSTEMİ KULLANIM MODELLERİ

Bir posta sistemi kullanıcısı, adresleri bulmak, postayı kaydetmek ve/veya dağıtmak ve postayı oluşturmak ile okumak için bir ara site kullanabilir. Bu nedenle, posta sistemi kullanımı için aşağıdaki modellere sahibiz:

Kullanıcı, doğrudan hedef FTP sunucusuna bağlanır ve MAIL komutunu kullanarak posta gönderir. Yerel düzenleme işlevleri, karakter silme ve satır iptali ile sınırlıdır (kullanıcının satır satır modda olduğu varsayılarak) ve sunucu kuralları da uygulanabilir. Kullanıcının kendi sitesinde yalnızca bir kullanıcı-TELNET programına ihtiyacı vardır, ancak hedef adresi bilmesi gerekir. Bu model, özellikle kullanıcı-FTP veya kullanıcı-Posta programları olmayan TIP ve diğer mini-Ana Makine kullanıcıları için uygundur.
Kullanıcı, postayı yerel bir düzenleyici (veya posta sistemi) kullanarak hazırlar ve ardından kullanıcı-FTP ya da posta programından FTP MAIL veya MLFL komutları aracılığıyla postayı doğrudan hedefe göndermesini ister. Kullanıcının hedef adresi bilmesi gerekir. Hedef Ana Makine çalışmıyorsa, gönderme işlemi gönderici program tarafından ertelenebilir. TIP kullanıcıları, bir "ana üs" Ana Makinenin olanaklarını kullanarak bu modeli uygulayabilir.
Kullanıcı, posta dağıtımı için NIC gibi bir ara siteyi (diğer siteler de yönlendirme hizmetleri sağlayabilir) kullanır. Kullanıcının hedef adresleri bilmesi gerekmez; bireyler ve birey grupları için NIC Ident'leri kullanabilir. Posta istek üzerine kaydedilebilir ve gönderimi ertelenebilir (hedef Ana Makine çalışmıyor olabilir ya da postayı ertelemek daha ekonomik olabilir). Gönderilecek mesaj, yerel düzenleme olanakları kullanılarak yerel sitede hazırlanabilir ya da doğrudan ara sitede hazırlanabilir.
Kullanıcı, postanın tamamı yerine bir atıf gönderebilir. Atıf, çevrim içi olarak geri alınabilen mevcut bir belgeye gönderme yapar (örneğin, bir NIC dergi iletişiminin NIC numarası).

TIP KULLANICILARINA POSTA GÖNDERME

TIP şu anda bir FTP sunucusu ya da posta kutusu olanakları sağlamamaktadır. TIP terminallerine (satır yazıcıları gibi) posta göndermek mümkün olmakla birlikte, postanın kaybolma olasılığı, gizlilik eksikliği ve kullanıcının TIP'in bulunduğu yerden birkaç (ya da birkaç yüz) mil uzakta olabilmesi nedeniyle bunun istenmeyen bir durum olduğu görülmektedir. TIP kullanıcılarının genellikle hesaplama çalışmalarının çoğunu yaptıkları bir "ana üs" bilgisayarı vardır. TIP kullanıcıları sorunu, TIP kullanıcılarının "ana üs" Ana Makinede posta kutuları kiralamalarının zorunlu kılınmasıyla en iyi şekilde çözülebilir. Böyle bir Ana Makine, iyi posta okuma ve sorgulama olanakları sağlayabilir. Bir TIP kullanıcısı, "ev" Ana Makinesinden bir TIP terminalinde kendisine posta bildirimi göndermesini isteyebilir. RDML komutu (NWG/RFC 458) FTP'de kabul edilirse, TIP kullanıcıları böyle bir komutu kullanabilir. Daha da önemlisi, kullanıcının farklı Ana Makinelerde birden fazla posta kutusu varsa, RDML (veya RDMF) komutu, posta kutusu bulunan tüm sitelerdeki postalarını okumak için kullanılabilir.

POSTA SİSTEMİNDE ERİŞİM DENETİMİ

FTP belirtiminin, posta işlevinin (posta alma için) "ücretsiz" olmasını, yani FTP sunucularının kullanıcının "oturum açmasını" (USER, PASS ve ACCT komutlarını göndermesini) gerektirmemesini zorunlu kılması gerektiği önerilmiştir. Erişim denetimi komutlarının yokluğunda, FTP sunucusu posta alma maliyetini bir genel gider ya da göz atma hesabına yüklemelidir. Varsayılan bir USER hesabı kullanan bu "ücretsiz" posta işlevinin, yeniden başlatma yapılmadan posta ile ilgili olmayan komutlara izin vermeyebileceği unutulmamalıdır. Bu gereksinim, ağ kullanıcıları arasındaki iletişimi iyileştirecektir.

Multics gibi bazı sistemlerde, posta alımında erişim denetimi için mekanizmalar vardır. Yani, bir kullanıcı kendisine kimlerin posta göndermeye yetkili olduğunu belirleyebilir (normalde kullanıcılar "...*." erişimini verir, yani herkes posta gönderebilir). Ayrıcalıklı erişim elde etmek için erişim denetimi komutları gerekli olacaktır. USER komutu, postanın gönderenini tanımlamak için en iyi yol gibi görünmemektedir. GUEST, ICCC, NETWORK, MIT-DMCG ve NETWORK-USER olarak oturum açmış kullanıcıları düşünün. Ayrı bir FROM komutu arzu edilir görünmektedir. Böyle bir komut, göndereni tanımlamak ve ayrıca onaylar ile yanıtlar göndermek için kullanılabilir. Alıcı site, postayı şu şekilde etiketleyebilir: FROM AKB at MIT-DMCG, GUEST olarak oturum açılmış. Alıcı daha sonra AKB at Host 70 posta kutusu adresine bir yanıt gönderebilir (SNDMSG AKB@DMCG veya MAIL DMCG AKB).

AĞ BİLGİ MERKEZİ İŞLEVLERİ

NIC, postayı işlemek için çok özel bir olanaktır. Bireylere ve birey gruplarına postayı kaydetme ve dağıtma ile kullanıcı adreslerini bulma olanakları sağlar. NIC ayrıca kaydedilmemiş postanın dağıtımını da sağlamayı üstlenecektir. Şu anda NIC, kullanıcıların NIC'e oturum açmasını ve postayı hazırlamak ve dağıtmak için NLS kullanmasını gerektirmektedir. NLS kullanarak posta hazırlamak, farklı düzenleme sistemlerine alışkın olan birçok kişi için hayal kırıklığı oluşturan bir deneyim olmuştur. Son zamanlarda, NIC'in günün çoğu saatinde aşırı yüklü olması gibi bir sorun yaşanmaktadır ve bir "ağ terminali" elde edilip oturum açılsa bile etkileşim oldukça yavaştır. NIC (veya NLS), uzak yankı ile karakter başına etkileşim için tasarlandığından, kullanım verimsizdir. Kullanıcı, yankıda bir satırın tamamı kadar geride kaldığında NIC'i kullanmak özellikle katlanılmaz hale gelmektedir.

NIC'in doğrudan kullanımına bir alternatif, NIC'i FTP ve kullanıcının sitesindeki programlar aracılığıyla kullanmaktır. Kullanıcı, kendi yerel düzenleme sistemiyle dergi belgeleri hazırlayabilir ve ardından bunları FTP aracılığıyla NIC'e aktarabilir. Öğenin kaydedilecek olması durumunda, yazar, başlık, onayın nereye gönderileceği ve dergi numarası gibi bilgilerin belirtilmesi gerekebilir. Kullanıcıların sıralı dosyaları NIC'e göndermesi ve bunların "input sequential" yapılmadan NLS biçimine dönüştürülmesi de mümkün olmalıdır (bir öneri, dosya adının .NLS ile bitmesi durumunda dosyanın "NLS" yapılmasıdır). Alternatif olarak, kullanıcıların daha önce bir "output sequential" yapmak zorunda kalmadan dergi belgelerini ve diğer sıralı dosyaları geri alabilmeleri mümkün olmalıdır.

NIC şu anda postayı basılı kopya ve/veya çevrim içi olarak teslim etmektedir. Çevrim içi teslimat, şu anda kullanıcının NIC'e oturum açmasını, mesajı olup olmadığını kontrol etmesini ve "print branch" ile okumasını gerektirmektedir. Mesajlar hedef kullanıcılara birkaç gün boyunca ulaşmamakta ve birçok kullanıcı, çevrim içi NIC postasını inceleme fırsatı bulamadan basılı kopyasını almaktadır. NIC, postayı ağ kullanıcılarına FTP aracılığıyla teslim ederse, posta dönüş süresi büyük ölçüde hızlanacak ve kullanıcıların NIC'e oturum açması gerekmeyecektir. Büyük belgelerin tamamının kullanıcıya gönderilmesi gerekmez; yalnızca bir atıf gönderilmesi yeterlidir. NIC, özellikle birçok FTP sunucusunun NIC Ident'lere "saygı göstermediği" görüldüğünden, postanın teslimi için ağ katılımcılarının posta kutusu adresleriyle ilgili bilgileri toplamak zorunda kalacaktır. Bir kullanıcının bu adreslerden yalnızca birine (en çok kullanılanına) sahip olabileceği kabul edilmektedir.

NIC kimlik tanımlama alt sistemi (şu anda yalnızca NLS üzerinden erişilebilir), kullanıcılar (kurum bilgisi, ABD Posta adresi, telefon numaraları vb.) ve gruplar (üyeler vb.) hakkında bilgiler içerir. Çevrimiçi posta kutusu adres bilgileri buraya eklenebilir. NIC, kimlik tanımlama alt sisteminin programlar tarafından sorgulanabilmesine olanak tanıyan bir olanak sağlamayı üstlenecektir; böylece posta programları adresleri otomatik olarak alabilecektir. Bu olanak FTP’den ayrı olacaktır.

FTP Değişiklikleri

FTP şu anda postanın kaydedilmesi, gönderenin adresinin iletilmesi, program tarafından okunabilir atıfların gönderilmesi, belgeler için yazar ve başlık belirtilmesi, alındı istenmesi ve ileti türünün (acil, normal ve uzun) belirtilmesi için açık olanaklar sağlamamaktadır. Bu eksikliklerin üstesinden gelmek için aşağıdaki yaklaşımlardan herhangi birini benimseyebiliriz:

İstenen özellikleri MAIL ve MLFL komutlarının yol adı sözdizimine yamamak; bu yamayı, işlevlerin çoğunun yalnızca NIC tarafından kullanılacağı gerekçesiyle savunmak.
İstenen işlevler için yeni komutlar eklemek ve MAIL ile MLFL komutlarını, yeni komutların varlığını tanıyacak şekilde bir miktar değiştirmek.
Eksik işlevleri içeren yeni bir posta komutu tanımlamak (bu süreçte istenen işlevler için yeni komutlar tanımlanacaktır). MAIL ve MLFL komutları mevcut biçimleriyle kullanılabilir ancak zamanla kademeli olarak devreden çıkarılabilir.

Birinci yaklaşım bana arzu edilir görünmemektedir; çünkü eksik işlevlerin birçoğu diğer siteler tarafından da kullanılabilir. Ayrıca, karmaşık bir sözdizimi yerine komutlarla çalışacak programlar yazmak daha kolay olacaktır. İkinci ve üçüncü yaklaşımlar birbirinden çok da farklı değildir. Üçüncü yaklaşım, mevcut posta programlarının mevcut biçimleriyle çalışmaya devam etmesine olanak tanıyacağı için tercih edilir görünmektedir. Üçüncü yaklaşımı kullanarak aşağıdaki yeni FTP komutlarını göz önünde bulundurun:

MLTO (mail to): Argüman, "," (virgül) ile ayrılmış bir veya daha fazla posta kutusu tanımlayıcısıdır. Argüman yoksa, postanın sorumlu bir kullanıcıya gönderilmesi veya bir yazıcıda basılması önerilir. Bu komut, aşağıda açıklanan isteğe bağlı FTP posta ile ilgili komutlar dizisini başlatır. Dizi, TEXT, FILE veya CITA (atıf) komutlarıyla sona erer.
FROM: Argüman, gönderenin veya gönderenlerin adresidir. Programlar tarafından olduğu kadar insan kullanıcılar tarafından da yorumlanabilen standart bir biçimdedir. Bu bilgi, gönderen(ler)i tanımlamak, yanıt göndermek ve alıcı bir ara yönlendirme sitesi ise alındı göndermek için kullanılacaktır.
MTYP (mail type): Posta türünü U (acil), O (normal) ve L (uzun) olarak tanımlar. Alıcı sistem bu bilgiden uygun eylemleri çıkarabilir. Varsayılan kabul normal postadır.
RECO (record the mail): Argüman varsa, kayıt için tanımlayıcı bilgidir (NIC Journal numarası gibi). Argüman yoksa, sunucu kayıt bilgisini atayacak ve uygun bir yanıt gönderecektir (gerçek zamanlı veya ertelenmiş).
AUTH (author): Belgenin yazarını, sunucu tarafından kabul edilebilir bir biçimde tanımlar (NIC için NIC kimliği gerekebilir).
TITL (title): Belgenin başlığını tanımlar. Argüman, "CRLF.CRLF" dizisiyle sonlanan bir ASCII dizgesidir.
ACKN (acknowledge): Ara yönlendirme siteleri için geçerlidir. Sunucudan, teslimat üzerine veya belirli bir süre içinde teslimat başarısız olursa alındı göndermesini ister.
TEXT: Argüman yoktur. TELNET bağlantısı üzerinden postanın, MAIL ile tamamen aynı şekilde aktarılmasını başlatır.
FILE: Argüman yoktur. Veri bağlantısı üzerinden postanın, MLFL ile tamamen aynı şekilde aktarılmasını başlatır.
CITA (citation): Argüman, alınabilir dosyanın yol adıdır.

Postanın ele alınması için yeni yanıt kodları da tanımlamamız gerekir. Bazı siteler, "yalnızca X bayt posta gönder" gibi yanıtların gereksinimini dile getirmiştir. Diğer yanıtlar, ayrıcalıklı posta gönderimi için USER/PASS/ACCT, posta yönlendirme için FROM/ACKN ve kayıtlı posta için AUTH/TITL gibi ek komutları özellikle isteyebilir. Dikkate alınabilecek bir başka öneri, FILE komutu için A/8 dışında TYPE/BYTE kullanımına izin verilmesidir. PDP-10’lar gibi benzer makineler arasında büyük dosyaların postalanması I/36’da daha verimlidir. Bressler ve Thomas tarafından önerilen RDML ve RDMF komutları (NWG/RFC 458) da, farklı Host’larda posta kutuları olan kullanıcılar için postanın ele alınmasına yardımcı olacakları için değerlendirmeye değerdir.

Bu RFC, çevrimiçi RFC arşivlerine girmek üzere makine tarafından okunabilir biçime Kelly Tardif, Viagenie tarafından 10/99 tarihinde dönüştürülmüştür.