Názvy internetových specifikací sestávají ze zkratky RFC a pořadového čísla specifikace, např. „RFC 822“. Obsah jednou vydané specifikace se již nemění (neopravují se ani překlepy), pouze se může změnit celkový stav platnosti. Dokumenty RFC tak představují spojitou vzestupnou sérii, přičemž čísla nemají žádný vztah k obsahu. Referenční formát je stále prosté ASCII.
RFC (Request for Comment) je v překladu „žádost o komentář“, smířlivý název motivující k diskuzi a aktivitě. Pro RFC používám slovo specifikace, jelikož se skoro vždy jedná o technické specifikace, ale jen malé procento z nich dospěje do stavu oficiálního internetového standardu, závazného pro uživatele. Některé RFC pak ani nejsou zamýšleny jako standard vůbec, ale jako pomocné informační dokumenty (podrobněji níže). Posláním procesu jako celku ovšem je vytvořit ideální standard:
Internetový standard je specifikace, která je stabilní a dobře pochopena, je technicky kompetentní, má více nezávislých a interoperujících implementací se značnou zkušeností z provozu, těší se významné podpoře veřejnosti a je znatelně užitečná v některé části nebo v celém Internetu.
Standardizační proces tvorby RFC
Navrhnout dokument pro vydání formou specifikace RFC může kdokoliv i bez předchozí aktivity v internetové komunitě (IETF). Většina internetových specifikací ovšem vzniká jako výsledek činnosti pracovních skupin WG pod dohledem ředitele oblasti AD. Schválení provádí řídící skupina IESG, v závěrečné fázi se uplatní i role editora. Proces přijímání RFC je pečlivě „specifikován“ v RFC 2026, vznikl a je rozvíjen z živé zkušenosti s přijímáním specifikací.
Varianty standardizačního procesu a možné typy/stavy specifikací RFC
Specifikaci lze navrhnout pro schválení a publikaci třemi různými způsoby:
- podáním na dráhu standardů (standards track),
- podáním pro informační nebo experimentální účely (informational, experimental),
- podáním specifikace jako vyjasnění nejlepší současné praktiky (best current practice).
Způsob schvalování se liší podle druhu podání. Možné průběhy a stavy zachycuje obrázek. Ve všech případech, než se dokument stane specifikací RFC, musí být vždy nejprve vystaven jako návrh I-D (Internet Draft). Smyslem je, aby komunita i IESG měla přehled o všech (i externích) podaných návrzích a tyto mohly být přiřazeny k posouzení či začlenění vhodným dotčeným skupinám. Návrhy mohou být následně ještě různě upravovány a měněny. Vývojový diagram schvalování jedné specifikace naleznete na stránkách editora.
Hlavním druhem specifikací jsou ty, které jsou podány do dráhy standardů. Těmito specifikacemi se intenzívně zabývají pracovní skupiny, jejich zpracování podléhá rigidním a čas vyžadujícím pravidlům. Jejich vydání jako specifikace RFC musí vždy schválit IESG.
V určitých případech je třeba pohotově vydat pomocné specifikace (informational, experimental). Jejich vydání je ponecháno v pravomoci editora a může trvat jen několik týdnů. Editor se sice i v těchto případech koordinuje s IESG, ale vzácně může vydat i něco, s čím IESG není zcela srozuměna.
Specifikace přijaté do dráhy standardů mají obecně za cíl zrát. První vydané RFC standardu nese označení „proposed standard“. Po jeho vydání probíhá dospívání tím, že se vyvíjejí implementace, sbírají se zkušenosti jak z nich, tak i ze schopnosti jednoznačně porozumět specifikaci. Specifikace se může doplnit a vydat jako nové RFC s visačkou „draft standard“. Každé nové vydání opět schvaluje IESG. Do finále třetího vydání RFC ve stavu „Internet standard“ většina specifikací nikdy nedospěje, aniž by to vážně vadilo jejich úspěšnému využívání.
Pokud je specifikace přetvořena zásadně, vstupuje znovu do dráhy standardů od počátku. Specifikace v dráze standardů nesmí záviset na jiných standardech z dráhy standardů, které jsou na nižší úrovni dospělosti, nebo na jiných specifikacích, pocházejících od jiných standardizačních organizací. Příliš zastaralé specifikace mohou být převedeny do stavu „historic“. Některé dávné specifikace jsou natolik odtažité, že nesou stav „unknown“ (neznámý). Občas je potřeba ujednotit způsob využívání některých již publikovaných specifikací, což se činí pomocí publikace typu „Nejlepší současná praktika“ (Best Current Practice). Pro tyto specifikace se systém zrání pochopitelně nehodí, takže bývají přijímány jako samostatná kategorie.
Přehled typů specifikací RFC
Typy/stavy specifikací ve standardizačním procesu jsou:
- „Internet draft“ je návrh internetové specifikace. Návrhy se vystavují v adresáři návrhů IETF pro možnost zkoumání a připomínkování veřejností. Rovněž je zpracovávají pracovní skupiny. Pokud se o návrh nikdo dlouho nezajímá ani jej IESG neschválila pro vydání, je stažen. Draft ještě není formální specifikací Internetu, nemá RFC číslo, a může být předmětem libovolných změn, úprav, či úplného odmítnutí. Nesmí se na něj odkazovat jinak než jako „ve vývoji“, ani vykazovat kompatibilita produktu.
- „Proposed standard“ je dobře srozumitelná, stabilní specifikace, jejíž tvůrci zvážili a rozhodli možné varianty provedení, byla dostatečně prozkoumána a těší se zájmu komunity. Z hlediska implementace to je nedospělá specifikace, jež se ještě může měnit.
- „Draft standard“: existují již alespoň dvě nezávislé interoperující implementace. Specifikace je považována za velmi dobře srozumitelnou a výrobci ji mohou brát za poměrně neproměnlivý základ pro své implementace i do prostředí, kde by budoucí změny jinak mohly vadit.
- „Internet standard“ je specifikace s vysokým stupněm technické dospělosti, specifikovaný protokol nebo služba poskytuje důležité výhody pro komunitu Internetu.
- „Experimental“ je specifikace, jež je součástí výzkumu či vývoje. Slouží pro obecnou informovanost internetové technické komunity.
-
„Informational“ slouží pro obecnou informovanost internetové komunity, nepředstavuje však konsensus nebo doporučení komunity. Jako informační se často vydávají specifikace vytvořené mimo Internet, s dovolením vlastníka. Slouží např. pro odkazování z jiných RFC a dostupnost odkazované informace komunitě.
Publikování specifikací „experimental“ a „informational“ je v pravomoci editora. Ten u nich dbá kromě obecné vhodnosti a technické úrovně i na to, aby v této kategorii nebyly publikovány specifikace, na jejichž vývoji se pracuje v dráze standardů, a nedošlo tak k jejich obejití.
- „Historic“ je specifikace, jež byla nahrazena čerstvější specifikací, která dosáhla úrovně „standard“. Nebo je z jiných důvodů považována za zastaralou. Změnou stavu na „historic“ se nemění číslo RFC.
- „Best current practice“ (BCP) je specifikace popisující nejlepší současné praktiky. Mohou ovšem existovat specifikace, jež popisují současnou nejlepší používanou praktiku, aniž by byly označeny BCP.
Specifikace „Internet standard“ obdrží kromě přiděleného čísla RFC ještě označení STD a pořadové číslo v sérii STD. Specifikace „best current practice“ obdrží kromě svého přiděleného čísla RFC ještě označení BCP a pořadové číslo v sérii BCP. Pro usnadnění orientace ve specifikacích STD a BCP publikuje IESG s intervalem cca čtyři měsíce až jeden rok specifikaci RFC (např. RFC 3700) nazvanou vždy „Internet Official Protocol Standards“.
Práva duševního vlastnictví (IPR)
Zkušenější uživatelé IT vědí, že konkurenční boj se v branži vede i tvrdým zápolením za scénou o prosazení svých standardů. Obecnou snahou IESG je, aby standardizační proces nebyl k něčemu takovému zneužit, aby se uživatelé Internetu mohli těšit z volné konkurence implementací, nesvazované patenty, autorskými, značkovými aj. podobnými právy.
Otázka IPR se v poslední době přiostřila, standardizační proces byl čerstvě doplněn o zásady „IPR v příspěvcích“ RFC 3978, jimiž se rozumí i veřejná vystoupení v IETF a mailing-listech, a o „IPR v implementacích“ RFC 3979. První zajišťuje veřejnost a volnou šířitelnost příspěvků i výsledných specifikací RFC. Druhý se snaží o svobodu implementací, stanoví zásady typu, že osoba vytvářející specifikaci má povinnost informovat o všech právních nárocích, kterých si je vědoma apod.
Pokud již se specifikaci kryté právními nároky nelze vyhnout, pak se IESG snaží být neutrální k držitelům práv, mj. jejich práva nepotvrzovat ani nevyvracet. Známé nároky se jednotlivě do specifikací RFC neuvádí, neboť by se tím nepřímo potvrzovaly, a zároveň nelze vyloučit pozdější vznesení obdobných nároků někým jiným. Stav vznesených nároků k technologiím popsaným ve specifikacích RFC je třeba kontrolovat průběžně na URL:
Pokud si je IESG vědoma vznesených nároků, uvede do specifikace obecné upozornění na možnost jejich existence. IESG se také ještě před vydáním snaží přimět vlastníka práv k vyjádření typu:
„Každý bude schopen získat právo implementace, používání a šíření technologie či díla, při implementaci, používání nebo šíření technologie na základě určené specifikace (v RFC), za otevřeně určených, přiměřených a nediskriminačních podmínek.“
Takové vyjádření prohlašujícího přitom neznamená, že by IESG potvrzovala oprávněnost jeho nároků.
I bez vlivu IPR je tvorba specifikací vždy náročnou činností, je třeba řešit kolize zájmů různých stran, dosáhnout širokého konsensu a specifikace vyzkoušet v realitě.
Navigace ve specifikacích RFC
Přijatý vzestupný způsob číslování specifikací určuje jednoznačně pouze pořadí a přibližný čas verze. Pro orientaci ve čtyřech tisících dokumentů je jinak značně nepřehledný. K hledání relevantní specifikace vám mohou pomoci:
- udržované řady STD a BCP, poslední vydání je RFC 3700,
- seznam všech specifikací RFC – textové vyhledávání v něm (pozor na zkratky!), poznámky o stavu specifikace, o číslech nahrazených specifikací nebo o nahrazujících specifikacích a rozšířeních,
- hledání přes seznamy pracovních skupin WG, jsou udržovány i seznamy uzavřených WG,
- jinak získané úvodní odkazy (z literatury, ze stránek skupin mimo IETF, přes Google apod.).
Nalezené specifikace budete muset rešeršovat, abyste zjistili, zda skutečně pokrývají hledanou oblast a jsou aktuální. Moderní RFC mají přehlednější strukturu, hlavičky obsahují zařazovací informace (pracovní skupina apod.), odkazy na staré nahrazované dokumenty, krátký abstrakt atd.
Sekce odkazů literatury vás však mohou zavést do houští jiných internetových specifikací, ale to je úděl všech složitých systémů. Můžete také zjistit, že IETF se vaší oblastí vůbec nezabývá a přenechává její rozvoj někomu kompetentnějšímu (např. W3C).
