Ve dnech 16. – 21. července 2017 se v Praze bude konat konference IETF 99. O tom, co IETF je a jak funguje, už dřív česky psal můj kolega Ondřej Surý ve svých článcích Cesta do hlubin IETF, Odkud pochází Internetové standardy (aneb bylo jednou jedno RFC) nebo Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF. Ladislav Lhotka zase trefně popsal její neobvyklou geekovskou atmosféru. Proto stačí uvést, že IETF je organizace vydávající internetové standardy. Jejím cílem je vytvářet kvalitní technickou dokumentaci, která ovlivňuje vývoj Internetu a aplikací přes něj provozovaných.
Mezi výsledky práce IETF patří např. standardizace SMTP protokolu pro přenos e-mailu i protokolu HTTPS, přes který nejspíš čtete tento článek. Myšlenkově ale IETF ovlivnilo svět počítačových sítí mnohem více. Uživatel nevědomky ocení, například když jeho webový prohlížeč správně zobrazí i takové HTML stránky, u nichž autor zapomněl uzavřít párový tag jako je např. „<body>“ pomocí uzavíracího „</body>“. Stejně tak poštovní servery běžně doručují e-maily, přestože DNS informace o doručovacím serveru je v rozporu se standardem. Toto je například možné díky široké aplikaci tzv. Postelova principu, jednoho ze základních principů, pomocí kterého se interpretují internetové standardy.
Princip je pojmenován po Jonu Postelovi (1943–1998) a objevil se v roce 1981 ve standardu pro Internet Protocol (to je „ten“ protokol, co dnes všichni bezmyšlenkovitě zkracujeme jako IP). Postelův princip říká: „Implementace musí být konzervativní při odesílání a liberální při příjmu.“ (v originálu: „an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.“).
V roce 1981, když byl Internet ještě v plenkách, bylo cílem Postelova principu usnadnit propojování systémů různých výrobců stanovením odlišných kritérií pro odesílání a příjem paketů. Při odesílání by měl systém produkovat pakety formátované konzervativně, tj. podle standardu. Naopak při příjmu by implementace měla „přimhouřit oko“ a akceptovat i takové pakety, které sice nejsou technicky na 100 % správně, ale je z nich stále zřejmé, co paket znamená.
Tento princip byl ze standardu IP přejat a široce aplikován i na implementace ostatních protokolů, se kterými se každodenně setkáváme. Příkladem jeho aplikace je už zmíněné zobrazení HTML stránky navzdory chybějícímu tagu „</body>“ (důkaz: zde).
Vypadá to jako jasná výhra pro uživatele i Internet jakožto síť sítí: Vše funguje, všichni jsou spokojení. Nebo snad nejsou?
Postelův princip má i odvrácenou stranu, se kterou se setkávají hlavně vývojáři, kteří se snaží držet přikázání a být liberální při příjmu. Potíže pramení z toho, že princip samotný odkazuje na to, „co paket znamená“, bez ohledu na jeho formální správnost. To staví vývojáře před nelehký úkol najít nějaký význam v paketu, jehož formát není popsaný.
Ilustrujme si to na DNS protokolu: jeho standardizovaná verze umožňuje DNS serveru odeslat v odpovědi více informací najednou:
Dotaz klienta může vypadat třeba takhle:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20394
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 6
;; QUESTION SECTION:
nic.cz. MX
Standardní paket s odpovědí serveru vypadá následovně:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 111
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 6
;; QUESTION SECTION:
nic.cz. MX
;; ANSWER SECTION:
nic.cz. 1800 MX 10 mail.nic.cz.
nic.cz. 1800 MX 20 mx.nic.cz.
nic.cz. 1800 MX 30 bh.nic.cz.
;; ADDITIONAL SECTION:
bh.nic.cz. 1800 A 217.31.204.252
mail.nic.cz. 1800 A 217.31.204.67
mail.nic.cz. 1800 AAAA 2001:1488:800:400::400
mx.nic.cz. 1800 A 217.31.58.56
mx.nic.cz. 1800 AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019
Toť standard: jeden dotaz a jedna odpověď s více položkami.
A teď si představme, že program přijme paket s polem „dotaz“ obsahujícím (v rozporu se standardem) dvě položky:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2222
;; flags: rd ad; QUERY: 2, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
www.nic.cz. A
www.nic.cz. AAAA
Co tím odesilatel myslí? Tady začínají problémy, protože dva různí vývojáři si mohou pravidlo „být liberální při příjmu“ snadno vyložit jinak. První vývojář se rozhodne, že program odpoví jen na první ze dvojice dotazů, protože standard neříká, jak se odpovídá na dva dotazy najednou. Druhý si naopak řekne, že standard sice nepředepisuje formát odpovědi na dvě otázky, ale odesilatel dotazu asi chce v poli „odpověď“ mít informace ze všech dotazů, takže naskládá odpovědi za sebe do jednoho paketu. Třetí vývojář problém vyřeší rozdělením odpovědi na každou jednotlivou otázku do samostatného paketu, takže na jeden paket s dotazem pošle dva pakety s odpovědí.
Kdo z nich má pravdu? Vlastně nikdo, protože toto chování standard nedefinuje. Výsledkem je samozřejmě zmatek, protože se různé implementace chovají nekompatibilně.
Problém se vystupňuje, když se příslušná pracovní skupina pokusí rozšířit původní standard o podporu pro „více dotazů najednou“, kterou ale mezitím vývojáři naimplementovali každý jinak. Žádná z implementací se nechce vzdát svého chování, typicky s odkazem na to, že „naši uživatelé jsou závislí na chování naší implementace, a proto ho nemůžeme změnit“. Takže úplně na konec buď vznikne standard, který ale téměř nikdo nedodržuje (protože se všichni drží vlastního vynálezu), nebo nový standard nevznikne vůbec, protože není možné dosáhnout ani hrubého konsenzu o jeho podobě.
Tímto způsobem „liberální” část Postelova principu vede k vytváření vzájemně nekompatibilních rozšíření, která znesnadňují další vývoj protokolu a v důsledku tak způsobují „zkostnatění“ prostředí na Internetu.
Rychlý vývoj Internetu a aplikací přes něj provozovaných zároveň vede k potřebě přizpůsobovat existující standardy a vytvářet nové. Aplikace Postelova principu na konkrétní problém je proto otázkou, které se žádná pracovní skupina v rámci IETF nemůže vyhnout. Vždy je nutné zvážit pro a proti: Má být konkrétní vlastnost protokolu pevně daná a striktně vyžadovaná, což může zpomalit či znemožnit jeho další vývoj? Nebo má určitá část protokolu záměrně zůstat volnější, otevřít dveře aplikaci Postelova principu a umožnit překotný vývoj za cenu rizika nekompatibilních rozšíření?
IETF má v současnosti 126 pracovních skupin a pole jejich působnosti je opravdu široké. Seznam a agendu všech pracovních skupin je možné najít zde, kde je také možné se zaregistrovat do e-mailové konference libovolné pracovní skupiny a přečíst si nejen, co se bude probírat na letošním, pražském IETF, ale také jak bude práce pokračovat dál. Tímto způsobem jsou pracovní skupiny otevřené komukoliv, kdo se v dané problematice vyzná a je ochoten jí věnovat čas.