VyÜlo v t²denφku:	COMPUTERWORLD
╚φslo:	11/95
RoΦnφk:	1995
Rubrika/kategorie:	TΘma t²dne, ╚lßnky o Internetu

zp∞t do archivu Φlßnk∙ | rejst°φk | p°edchozφ Φlßnek

Ji°φ Peterka

Standardizace v Internetu

Tento Φlßnek vyÜel v poΦφtaΦov²ch novinßch Computerworld Φ. 11/95, v rßmci tzv. tΘmatu t²dne, jako souΦßst sΘrie Φlßnk∙ v∞novan²ch problematice Internetu.

Jednφm z velmi d∙le₧it²ch moment∙, kterΘ p°isp∞ly k dneÜnφ popularit∞ a obrovsk²m rozm∞r∙m Internetu, je existence dob°e propracovanΘho a efektivn∞ fungujφcφho mechanismu tvorby standard∙ a doporuΦenφ, definujφcφch fungovßnφ Internetu.

Mechanismus, prost°ednictvφm kterΘho Internet vypracovßvß, schvaluje, vydßvß a distribuuje svΘ standardy, normy a doporuΦenφ, se samoz°ejm∞ vyvφjel. V tomto Φlßnku si jej budeme popisovat v takovΘ podob∞, jakou mß dnes, a kterß je ji₧ delÜφ dobu ustßlena. SouΦßstφ celΘho mechanismu p°itom jsou jak r∙znΘ organizaΦnφ subjekty, kterΘ se p°φpravou a schvalovßnφm standard∙ a doporuΦenφ zab²vajφ, tak i p°esn∞ definovanß pravidla jejich fungovßnφ, a pravidla tvorby a postupu p°ijφmßnφ standard∙ a doporuΦenφ r∙zn²ch typ∙ a r∙znΘho urΦenφ.

ZaΦn∞me nejprve organizaΦnφmi subjekty, jejich postavenφm a poslßnφm.

ISOC, IAB, IETF, IRTF a dalÜφ

Jak jsme si ji₧ uvedli v tΘmatu t²dne v CW 4/95, je nejvyÜÜφ odbornou autoritou v Internetu spoleΦnost Internet Society (ISOC), jako profesnφ sdru₧enφ jednotlivc∙ i organizacφ, usilujφcφ o rozvoj "sφ¥ovßnφ" prost°ednictvφm Internetu a jeho technologiφ. SpoleΦnost ISOC jako takovß vÜak ₧ßdnΘ standardy, normy Φi doporuΦenφ nevypracovßvß ani formßln∞ neschvaluje - je spφÜe zast°eÜujφcφm orgßnem, kter² koordinuje veÜkerΘ koncepΦnφ otßzky kolem Internetu a jeho dalÜφho rozvoje (ani₧ by si p°itom Φinila nßrok na jakΘkoli "vlastnictvφ" Internetu, viz ji₧ zmφn∞nΘ CW 4/95). V Φele spoleΦnosti ISOC stojφ jejφ p°edsednictvo (Board of Trustees).

Pokud jde o technickΘ otßzky, t²kajφcφ se architektury Internetu obecn∞ a protokol∙ TCP/IP konkrΘtn∞, pak ty mß v Internet Society na starosti "dce°inn²" subjekt se statutem technickΘho poradnφho orgßnu, kter²m je Internet Architecture Board (IAB). Jeho ·kolem je koordinovat a zast°eÜovat vÜechny zmφn∞nΘ aktivity (tj. aktivity na poli architektury Internetu a protokol∙ TCP/IP). Vlastnφm °eÜenφm technick²ch otßzek se vÜak IAB samo nezab²vß, a p°enechßvß je dalÜφm odborn²m orgßn∙m, jejich₧ Φinnost pouze koordinuje. Je to vÜak prßv∞ IAB, kdo fomßln∞ vydßvß jednotlivΘ standardy a doporuΦenφ Internetu - ovÜem bez toho, ₧e by kohokoli k Φemukoli nutila. Dodr₧ovßnφ p°φsluÜn²ch standard∙ a doporuΦenφ je tedy Φist∞ dobrovolnΘ, v praxi ale mnohdy d∙sledn∞jÜφ, ne₧ dodr₧ovßnφ r∙zn²ch prßvn∞ zßvazn²ch standard∙ de jure.

Vlastnφ technickß prßce probφhß na p∙d∞ dalÜφho organizaΦnφho subjektu, kter²m je IETF (Internet Engineering Task Force). Ten si vytvß°φ jednotlivΘ pracovnφ skupiny (Working Groups), kterΘ se podle svΘho tematickΘho zam∞°enφ sdru₧ujφ do v∞tÜφch skupin, oznaΦovan²ch jako Areas (doslova: oblasti). Kdy₧ se nap°φklad p°ed Φasem ukßzalo, ₧e souΦasn² zp∙sob adresovßnφ v rßmci protokolu IP je dlouhodob∞ neudr₧iteln² (viz tΘ₧ Φlßnek "Adresovßnφ v TCP/IP sφtφch), bylo v rßmci IETF vytvo°eno n∞kolik pracovnφch skupin, zb²vajφcφch se jednotliv²mi aspekty tΘto problematiky, a byly sdru₧eny do jednΘ zast°eÜujφcφ "oblasti" (IPnG Area), kterß jejich Φinnost koordinuje.

Zajφmavou je i otßzka Φlenstvφ v jednotliv²ch pracovnφch skupinßch IETF: to je otev°enΘ a ryze dobrovolnΘ - staΦφ ·Φastnit se zasedßnφ IETF a jejφch pracovnφch skupin, nebo se na jejich prßci podφlet alespo≥ on-line formou, prost°ednictvφm sφt∞ (zejmΘna elektronickou poÜtou). P°itom se oΦekßvß, ₧e Φleny budou spφÜe zainteresovanφ a odborn∞ fundovanφ jednotlivci, ne₧ formßln∞ delegovanφ zßstupci r∙zn²ch organizacφ. Pravidla Φlenstvφ jsou skuteΦn∞ natolik otev°enß, ₧e s trochou nadsßzky je mo₧nΘ definovat Φlenstvφ v IETF jako "duÜevnφ rozpolo₧enφ".

Tak voln∞ organizovan² orgßn, jak²m je IETF, je ale dosti obtφ₧nΘ °φdit a koordinovat. Proto nad nφm existuje jeÜt∞ jeden zast°eÜujφcφ orgßn charakteru "dozorΦφ rady", kter²m je tzv. Internet Engineering Steering Group (IESG). Jeho Φleny jsou °editelΘ jednotliv²ch oblasti (Area directors), a dßle volen² p°edseda IETF, kter² je souΦasn∞ i p°edsedou IESG. ┌kolem IESG je praktickΘ a bezprost°ednφ °φzenφ aktivit IETF, a napl≥ovßnφ pravidel pro vypracovßvßnφ, schvalovßnφ a Üφ°enφ standard∙ Internetu. Na rozdφl od samotnΘho IETF je IESG formßln∞ souΦßstφ Internet Society (ISOC).

Za zmφnku stojφ jeÜt∞ dalÜφ orgßn, zast°eÜen² spoleΦnostφ ISOC a jejφ radou IAB: Internet Research Task Force (IRTF). Tento orgßn je v jistΘm smyslu paralelnφ k IETF, nebo¥ takΘ provßdφ vlastnφ "technickou" prßci a je Φlen∞n na r∙zn∞ tematicky zam∞°enΘ oblasti (Areas). Zab²vß se vÜak takovou problematikou, kterou bychom mohli za°adit spφÜe do kategorie "zßkladnφho v²zkumu", a kterß v∞tÜinou jeÜt∞ nemß bezprost°ednφ vyu₧itφ v rßmci Internetu (a pokud se takovou stane, IRTF ji p°edßvß do kompetence IETF). TakΘ IRTF, podobn∞ jako IETF, mß nad sebou svou "dozorΦφ radu" - IRSG (Internet Research Steering Group). Ani IRTF, ani IRSG vÜak dφky svΘmu odbornΘmu zam∞°enφ nejsou pova₧ovßny za souΦßst standardizaΦnφ "maÜinΘrie" Internetu.

Ne vÜechno je standard

Pro rozumnΘ a efektivnφ fungovßnφ Internetu jsou samoz°ejm∞ zapot°ebφ takovΘ standardy, kterΘ musφ ve vlastnφm zßjmu dodr₧ovat vÜichni, a vÜichni je takΘ stejn²m zp∙sobem implementovat. Vedle nich ale bude v₧dy existovat celß °ada dalÜφch pravidel, doporuΦenφ Φi technik, kterΘ se t²kajφ jen urΦitΘho okruhu u₧ivatel∙, dßle celß °ada doporuΦenφ, kterΘ jsou nepovinnΘ, resp. volitelnΘ, kterΘ majφ pouze experimentßlnφ nebo informativnφ charakter apod. P°esto je ale vhodnΘ, aby i takovΘto materißly podlΘhaly jednotn²m pravidl∙m, jednotnΘ koordinaci, zp∙sobu dostribuce atd.

StandardizaΦnφ "maÜinΘrii" Internetu proto musφme chßpat pon∞kud Üφ°eji v tom smyslu, ₧e vedle skuteΦn²ch standard∙ (zßvazn²ch na dobrovolnΘ bßzi, viz v²Üe) jsou jejφmi v²stupy i dalÜφ doporuΦenφ, normy a jinΘ druhy materißl∙, kterΘ mohou mφt pon∞kud odliÜn² charakter, zßb∞r i zßm∞r. Pro sna₧Üφ vyjad°ovßnφ budeme vÜechny tyto v²stupy oznaΦovat jednotn∞ jako dokumenty (resp. dokumenty Internetu), proto₧e majφ v₧dy psanou formu (a teprve pozd∞ji si °ekneme, jak²m zp∙sobem a v jakΘm tvaru jsou vydßvßny a Üφ°eny).

V prvnφm p°iblφ₧enφ si m∙₧eme vÜechny dokumenty Internetu rozd∞lit na dv∞ hlavnφ kategorie, na standardy a ostatnφ materißly. Prvnφ z obou kategoriφ je v p∙vodnφ terminologii Internetu oznaΦovßna jako "track" (doslova "cesta", "trasa"), resp. jako "standards track", co₧ dob°e vystihuje skuteΦnou podstatu v∞ci: p°φsluÜnΘ dokumenty, kterΘ se majφ stßt standardy, toti₧ postupn∞ prochßzφ n∞kolika stßdii, a teprve na konci celΘ tΘto p°edem nalinkovanΘ "cesty" se stßvajφ skuteΦn²mi standardy Internetu. Naproti tomu u druhΘ kategorie (Off-track) se obdobn² pohyb (s drobn²mi v²jimkami) nep°edpoklßdß.

Off-Track

Podφvejme se nynφ podrobn∞ji na tu z obou kategoriφ, jejφ₧ v²stupy nejsou zam²Üleny jako zßvaznΘ standardy - nebo alespo≥ ne v danΘ chvφli. JednotlivΘ dokumenty jsou zde °azeny do Φty° ·rovnφ, oznaΦovan²ch jako tzv. maturity levels (doslova: "·rovn∞ vyzrßlosti"):

Informational: do tΘto ·rovn∞ pat°φ dokumenty, vydßvanΘ pro pot°eby vÜeobecnΘ informovanost celΘ komunity u₧ivatel∙ Internetu. Jde p°edevÜφm o dokumenty, kterΘ popisujφ zßm∞ry, zkuÜenosti, nßvody, perspektivy apod. P°itom nemusφ p°inßÜet ani ₧ßdnΘ doporuΦenφ, ani nemusφ vyjad°ovat ₧ßdn² vÜeobecn² konsensus v urΦitΘ otßzce. Jako dokumenty tohoto typu mohou b²t vydßvßny i specifikace, vypracovanΘ mimo rßmec Internetu, a o kter²ch se nep°edpoklßdß ₧e by se standardy Internetu n∞kdy staly.
Experimental: sem pat°φ dokumenty, p°edstavujφcφ specifikace takovΘho °eÜenφ, kterΘ je souΦßstφ experimentu, v²voje Φi v²zkumu. Jsou vydßvßny jednak kv∙li vÜeobecnΘ informovanosti InternetovskΘ komunity, tak p°edevÜφm jako formßlnφ zachycenφ postupu pracφ a p°φpadn²ch v²sledk∙.
Prototype: tato ·rove≥ byla zavedena pro pot°eby vΦasnΘho zve°ejn∞nφ nßvrh∙ nov²ch protokol∙, kterΘ by m∞ly b²t v budoucnu °ßdn∞ standardizovßny. OvÜem ne₧ budou moci nastoupit p°edepsanou cestu standardizace ("Standards Track"), musφ b²t nejprve shromß₧d∞ny pot°ebnΘ zkuÜenosti s jejich praktickou implementacφ a provozem. Prßv∞ k tomuto ·Φelu slou₧φ publikovßnφ jejich specifikacφ coby "prototyp∙".
Historical: r∙znΘ dokumenty mohou Φasem zastarat, a b²t nahrazeny nov∞jÜφmi verzemi Φi variantami, nebo b²t jednoduÜe prohlßÜeny za p°e₧itΘ. V takovΘm p°φpad∞ jsou tyto dokumenty p°esunuty do ·rovn∞ "historick²ch".
Standards Track

Podobn∞ jako v p°φpad∞ p°edchßzejφcφ kategorie, existujφ i zde r∙znΘ "·rovn∞ vyzrßlosti" (maturity levels) - tentokrßte jen t°i, ale zato jde ji₧ o skuteΦnΘ ·rovn∞, kterΘ jsou hierarchicky uspo°ßdßny, a mezi kter²mi jednotlivΘ dokumenty postupn∞ p°echßzφ sm∞rem vzh∙ru, podle p°edem p°esn∞ stanoven²ch pravidel:

Proposed Standard (doslova: "navhovan² standard") je poΦßteΦnφ ·rovnφ, na kterΘ nov∞ p°edklßdanΘ standardy zaΦφnajφ svou ₧ivotnφ drßhu. Specifikace, p°edklßdanß jako navrhovan² standard, by m∞la kodifikovat takovΘ °eÜenφ, kterΘ je ji₧ dostateΦn∞ ustßlenΘ, kterΘ ji₧ mß vy°eÜeny vÜechny zßkladnφ koncepΦnφ otßzky, je pova₧ovßno za dostateΦn∞ zvlßdnutΘ a propracovanΘ, a kterΘmu se ji₧ dostalo takovΘ pozornosti ze strany ÜirÜφ InternetovskΘ komunity, ₧e je mo₧nΘ jej pova₧ovat za p°φnosnΘ. P°esto se ale p°ipouÜtφ, ₧e na zßklad∞ dalÜφch praktick²ch zkuÜenostφ m∙₧e v nßvrhu dojφt k urΦit²m zm∞nßm, nebo dokonce ke sta₧enφ celΘho nßvrhu jako takovΘho. Pro p°edlo₧enφ novΘho nßvrhu standardu nenφ formßln∞ po₧adovßna ani praktickß implementace ani existence provoznφch zkuÜenostφ - tyto jsou ale velmi ₧ßdoucφ, a mohou b²t rozhodujφcφm argumentem pro prosazenφ nßvrhu a jeho postup na vyÜÜφ ·rove≥. V²robci sφ¥ov²ch komponent by m∞li pova₧ovat nßvrhy tΘto ·rovn∞ za jeÜt∞ nevyzrßlΘ. Na jednΘ stran∞ je jist∞ vhodnΘ, aby s nimi experimentovali a zφskßvali zkuÜenosti, ale na druhΘ stran∞ by se praktickΘ implementace takov²chto nßvrh∙ nem∞ly dostßvat voln∞ na trh a mezi b∞₧nΘ zßkaznφky. P°echod dokumentu z tΘto ·rovn∞ na vyÜÜφ ·rove≥ je mo₧n² nejd°φve za 6 m∞sφc∙.
Draft Standard ("p°edb∞₧n² standard") je ·rovnφ, pro jejφ₧ dosa₧enφ je ji₧ vy₧adovßna existence nejmΘn∞ dvou nezßvisl²ch a vzßjemn∞ interoperabilnφch implementacφ, a takΘ existence urΦit²ch zkuÜenostφ s praktick²m provoozem. P°echod dokumentu z ·rovn∞ "Proposed Standard" na ·rove≥ "Draft Standard" je pak vyjßd°enφm vφry ve vyzrßlost, u₧iteΦnost a takΘ realizovatelnost navrhovanΘho °eÜenφ. Standard, kter² dosßhl tΘto ·rovn∞, je ji₧ pova₧ovßn vφcemΘn∞ za definitivnφ, a p°φpadnΘ zm∞ny v n∞m by m∞ly odrß₧et jen °eÜenφ konkrΘtnφch problΘm∙, kterΘ se objevily a₧ p°i masov∞jÜφm vyu₧itφ. Pro v²robce sφ¥ov²ch komponent ji₧ v∞tÜinou mß smysl implementovat °eÜenφ na tΘto ·rovni standardizace ve sv²ch produktech, a uvßd∞t je b∞₧n∞ na trh. P°echod na vyÜÜφ ·rove≥ je mo₧n² nejd°φve za 4 m∞sφce.
Internet Standard (tΘ₧ jen: Standard) je nejvyÜÜφ ·rovnφ, pro jejφ₧ dosa₧enφ jsou zapot°ebφ rozsßhlΘ praktickΘ zkuÜenosti s provozem. ╪eÜenφ, kterΘ se dostalo a₧ na tuto ·rove≥ standardizace, je vÜeobecn∞ pova₧ovßno za vyzrßlΘ, ustßlenΘ, a p°inßÜejφcφ v²znamn² efekt pro celou komunitu u₧ivatel∙ Internetu. Setrvßnφ standardu na tΘto ·rovni nenφ nijak Φasov∞ omezeno, ani nenφ podmφn∞no ₧ßdn²mi pravideln²mi Φi nepravideln²mi revizemi.

P°echod kterΘhokoli dokumentu z jednΘ ·rovn∞ na druhou je obvykle iniciovßn nßvrhem ze strany IESG, a podlΘhß schvßlenφ ze strany IAB.

┌rovn∞ zßvaznosti

Pro vyjßd°enφ mφry zßvaznosti jednotliv²ch dokument∙, a hlavn∞ pro vyjßd°enφ okruhu u₧ivatel∙ a provozovatel∙, kter²ch se t²kajφ, jsou jednotlivΘ dokumenty °azeny do p∞ti ·rovnφ zßvaznosti (requirements levels):

Required (doslova: "po₧adovßno"): do tΘto ·rovnΘ jsou za°azeny dokumenty se specifikacemi takov²ch protokol∙ a °eÜenφ, jejich₧ implementace je povinnß. P°φkladem mohou b²t protokoly IP a ICMP na ·rovni sφ¥ovΘ vrstvy, kterΘ jsou pro fungovßnφ sφt∞ a jejφ p°ipojenφ k Internetu naprosto nezbytnΘ.
Recommended (doslova: "doporuΦenΘ"): implementace °eÜenφ, definovan²ch dokumenty na tΘto ·rovni zßvaznosti, sice nenφ nezbytn∞ nutnß pro dosa₧enφ minimßlnφ po₧adovanΘ funkΦnosti, ale je velmi ₧ßdoucφ. V²robci sφ¥ov²ch komponent by tato °eÜenφ m∞li zakomponovßvat do sv²ch v²robk∙, a vynechßvat by je m∞li jen ve zvlßÜ¥ od∙vodn∞n²ch p°φpadech.
Elective (nejspφÜe: "volitelnΘ"): sem pat°φ dokumenty, popisujφcφ takovß °eÜenφ, pro kterß neexistuje ₧ßdnß explicitnφ povinnost je implementovat. V²robci i koncovφ u₧ivatelΘ se pro n∞ mohou rozhodovat podle vlastnφho uvß₧enφ a podle vlastnφch pot°eb.
Limited Use (doslova: "omezenΘ vyu₧itφ"): jde o dokumenty popisujφcφ takß °eÜenφ, jejich₧ p∙sobnost je n∞jak²m zp∙sobem omezena. Typick²m p°φkladem mohou b²t °eÜenφ, kodifikovanß dokumenty z ·rovn∞ Experimental - jejich nasazenφ by m∞lo b²t omezeno jen na subjekty, kterΘ se na p°φsluÜnΘm experimentu podφlφ.
Not Recommended (doslova: "nedoporuΦenΘ"): na tuto ·rove≥ zßvaznosti se dostßvajφ dokumenty popisujφcφ takovΘ protokoly Φi takovß °eÜenφ, kterß jsou pova₧ovßna za neevhodnß pro vÜeobecnΘ pou₧itφ - a¥ ji₧ z d∙vodu svΘ omezenΘ funkΦnosti, svΘ ·zce specializovanΘ povahy, Φi zastaralosti.

Zajφmavou je na t∞chto ·rovnφch zßvaznosti takΘ skuteΦnost, ₧e d°φve si ji jednotlivΘ dokumenty nesly p°φmo v sob∞ (resp. ·rove≥ zßvaznosti t∞chto dokument∙ byla vyjßd°ena p°φmo v jejich textu). Vzhledem k obΦasn²m zm∞nßm ·rovn∞ zßvaznosti jednotliv²ch dokument∙ (mj. i p°echodu do ·rovn∞ "Not Recommended" z d∙vodu zastaralosti) se ale toto °eÜenφ ukßzalo jako nep°φliÜ vhodnΘ. Proto se dnes informace o za°azenφ jednotliv²ch dokument∙ do konkrΘtnφch ·rovnφ zßvaznosti vydßvajφ ve form∞ samostatnΘho dokumentu.

Dokumenty RFC

Zßkladnφm mechanismem zp°φstupn∞nφ dokument∙ Internet∙ co nejÜirÜφmu spektru zainteresovanΘ odbornΘ ve°ejnosti je jejich vydßnφ ve form∞ tzv. dokument∙ RFC. Jak jsme si ji₧ uvedli v tΘmatu t²dne v CW 4/95, jde v jistΘm smyslu o tradici vzniklou roku 1969 - kdy tehdejÜφ posgradußlnφ studenti, pozd∞jÜφ auto°i protokol∙ TCP/IP, cht∞li vhodn∞ prezentovat svoje myÜlenky, nßzory a nßvrhy, ale nemohli (a nejspφÜe ani necht∞li) se op°φt o ₧ßdnou formßlnφ autoritu, ktreß by je vydßvala. Proto sv²m dokument∙m dali p°φznaΦn² nßzev "Request For Comment", doslova: "₧ßdost o komentß°".

Tradice pokraΦovala, a dalÜφ dokumenty byly oznaΦovßny takΘ jako RFC. Aby se nepletly, ka₧d² z nich dostal do nßzvu svΘ po°adovΘ Φφslo: historicky prvnφm dokumenten RFC byl dokument RFC-1, pak nßsledoval RFC-2 atd. V dob∞ psanφ tohoto Φlßnku jich vyÜlo p°es 1700. S postupem Φasu se ale obsahovß nßpl≥ dokument∙ RFC pon∞kud m∞nila. Jestli₧e zpoΦßtku mohly tyto dokumenty obsahovat v podstat∞ cokoli, vΦetn∞ bßsnφ a pozvßnek na r∙znß zasedßnφ, pozd∞ji se ji₧ zam∞°ujφcφ jen na odbornΘ otßzky. Jak by ji₧ m∞lo vypl²vat z d°φve uvedenΘho textu, zdaleka ne vÜechny dokumenty RFC p°edstavujφ standardy. Pokud bychom sledovali jejich Φetnost, pak by zdaleka nejpoΦetn∞jÜφmi byly dokumenty ·rovn∞ "Informational". NicmΘn∞ ka₧d² odborn² "dokument Internetu" ve vydßn touto formou.

Podstatnou vlastnostφ vÜech dokument∙ RFC je skuteΦnost, ₧e jsou voln∞ Üi°itelnΘ (public domain), a to v on-line form∞. VÜechny musφ existovat ve form∞ ΦistΘho ASCII textu - co₧ samoz°ejm∞ nebrßnφ jejich kvalitn∞jÜφmi naformßtovßnφ, p°evodu do jin²ch textov²ch formßt∙ a Üφ°enφ i v textovΘ podob∞. Sm∞rodatn² je vÜak v₧dy jejich Φist² ASCII tvar.

DalÜφ d∙le₧itou vlastnostφ dokument∙ RFC je skuteΦnost, ₧e se nikdy nem∞nφ. Dojde-li k pot°eb∞ zm∞nit obsah ji₧ publikovanΘho dokumentu RFC, je mφsto toho vydßn nov² dokument RFC - s nov²m po°adov²m Φφslem - kter² ji₧ ve svΘm zßhlavφ nese ·daj o tom, ₧e nahrazuje jin² dokument RFC (doslova: Obsoletes RFC-xxxx, neboli: "Φinφ RFC-xxxx zastaral²m"). Tato vlastnost je velmi v²hodnß pro Üφ°enφ dokument∙ RFC prost°ednictvφm samotnΘho Internetu - nikdy se toti₧ nem∙₧e stßt, ₧e by v n∞jakΘm archivu bylo t°eba obm∞≥ovat starΘ verze dokument∙ RFC verzemi nov²mi. Stejn∞ tak se nikomu nem∙₧e stßt, ₧e by si z n∞jakΘho archivu v Internetu "stßhnul" neaktußlnφ verzi - m∙₧e se mu ale stßt to, ₧e nemß jin² dokument RFC, s vyÜÜφm po°adovßm Φφslem, kter² dan² dokument nahrazuje.

Dokumenty STD

V n∞kter²ch situacφch vÜak m∙₧e b²t "nem∞nnost" dokument∙ RFC spφÜe na obtφ₧ - zvlßÜt∞ je-li pot°eba vyhledat nejaktußln∞jÜφ verzi n∞kterΘho standardu. Proto byla vedle dokument∙ RFC zavedena jeÜt∞ dalÜφ °ada (Φi spφÜe sub-sΘrie), a to STD. JednotlivΘ dokumenty tΘto °ady vÜak nejsou ₧ßdn²mi nov²mi dokumenty - vÜechny jsou souΦasn∞ vydßvßny i jako dokumenty RFC. Jde tedy jen o nov² druh Φφslovßnφ a °azenφ dokument∙: nap°φklad dokumentem STD-1 je dokument RFC-1280, ale stejn∞ tak budou dokumentem STD-1 i budoucφ aktualizace RFC-1280, kterΘ toto RFC nahradφ. U dokument∙ STD tedy ji₧ nebude platit to, co u dokument∙ RFC - bude nutnΘ shßn∞t jejich nejaktußln∞jÜφ verze. Na druhΘ stran∞ aktußlnφ verze urΦitΘho dokumentu STD bude v₧dy p°edstavovat aktußlnφ stav urΦitΘho standardu, co₧ v p°φpad∞ dokument∙ RFC neplatφ.

Dokumenty FYI

JeÜt∞ dalÜφ zajφmavou °adou dokument∙, kterß je op∞t jen sub-sΘriφ dokument∙ RFC, resp. nov²m druhem jejich Φφslovßnφ, je °ada FYI (od anglickΘho: For Your Information). Jejφm smyslem je zv²raznit existenci dokument∙ vysloven∞ informativnφho charakteru, zam∞°en²ch na nejr∙zn∞jÜφ skupiny u₧ivatel∙ Internetu, a zavΘst lepÜφ p°ehled do jejich Φφslovßnφ. Nap°φklad oznaΦenφ FYI-18 je p°eci jen snßze zapamatovatelnΘ, ne₧ RFC-1392 (ve skuteΦnosti jde o v²kladov² slovnφk nejΦast∞ji pou₧φvan²ch termφn∙).