Ačkoliv se tedy jedná o počítačovou úlohu popisu struktur dat (disciplína IT, popř. computer science), tato notace pochází z telekomunikační instituce (z let, kdy její hlavní náplní ještě byla hlasová telefonie). Na některých výsledných vlastnostech notace je tento původ mírně znát, i když přiznám, že návrh specifikačního jazyka dat ze zelené louky by se dokonale nepovedl asi nikomu. Z počítačových instrumentů má k ASN.1 asi nejblíže BNF (Backus-Naurova Forma), která ji však nahradit nemůže.
ASN.1 pak byla v ITU-T použita pro datové definice celých rodin doporučení, např. v X.400 a v X.500. Z nich se značně ujala část doporučení X.509 (certifikáty). Dále bylo ASN.1 využito v kryptografických specifikacích řady PKCS # firmy RSA Security, Inc., protože začátkem 90. let zkrátka stále nic lepšího a přesnějšího nebylo k dispozici. S těmito úspěchy se data zapsaná v ASN.1 následně dostala do značného počtu internetových specifikací, zejména v rámci skupin PKIX a S/MIME. Jejich praktická rozšířenost je taková, že ani nedávný nástup XML nemá šanci ASN.1 v dohledné době vyhubit.
ASN.1 není kryptografický (např. šifrovací algoritmus) nebo obsahový standard (např. formát internetové pošty), ale obecný nástroj sloužící pro definici dat takových standardů. ASN.1 je zhruba to, co jsou noty pro hudbu, tedy prostředek zápisu různých hudebních skladeb a nikoliv skladby samé.
Motivace vzniku
Motivace vzniku obecné standardizace je nasnadě. Představme si N různých zařízení (mohou být i od N různých výrobců), která spolu mají komunikovat.
Obr. 1: interoperabilita bez komunikačních standardů
Jestliže byly navrženy bez ohledu na možnost existence zařízení jiných výrobců, lze vzájemné komunikace nyní dosáhnout pouze přídavným doděláním (N-1) bran pro každé zařízení (celkem je třeba zhruba N*(N-1)/2 bran).
Pozn: ačkoliv se zdá, že takový nesmysl by nikoho nenapadl, není tomu tak. V 80. letech se např. doslova roztrhl pytel s různými proprietárními systémy elektronické pošty pro lokální sítě (LAN). Na potřebě jejich vzájemného propojení pak dobře vydělávalo několik třetích firem, které nabízely brány, spojující vždy pouze jednu dvojici systémů mezi sebou.
Situaci by zjevně pomohlo, kdyby všechna zařízení spolu komunikovala pomocí jednotícího modelu a protokolů výměny dat. Takové modely již vznikaly, např. sedmivrstvý ISO/OSI nebo čtyřvrstvý TCP/IP (Internet). Ačkoliv by bylo záhodno striktně definovat data protokolů i síťových a nižších vrstev, v praxi existovala především značná potřeba zformalizovat datové definice vrstev a aplikací, pracujících nad nimi. Vznik ASN.1 byl specificky motivován především potřebami rozhraní mezi šestou (prezentační) a sedmou vrstvou (aplikační) ISO/OSI. Zatímco u síťových a nižších vrstev byla prioritou efektivnost protokolů a s tím související relativní jednoduchost datových definic, aplikace vyžadovaly rozsáhlé datové definice, kterým metody záznamů nižších vrstev již nemohly stačit.
Zkusme si představit jednoduchou úlohu, spočívající ve výměně datového záznamu obsahu:
- jméno (jméno a příjmení jako řetězec znaků),
- výška (v cm zaokrouhlená na celé číslo),
- stav (svobodný, ženatý, rozvedený, vdovec).
Realizační potíž spočívá v tom, že základy konstrukce komunikačních (či komunikujících) zařízení bývají naprosto odlišné. Vyrábí je různí výrobci, spravují různí operátoři či vlastníci, pro vývoj se používají různé programovací jazyky s různými způsoby konverzí typů do strojové reprezentace, pracují na procesorech s různou délkou slova (8, 16, 32, 64 bitů), s různým způsobem reprezentace bitů (malý vs. velký indián), s různými konvencemi předávání parametrů (C, Pascal apod.), s různým kódováním znaků a řetězců (ASCII, EBCDIC, ISO 8859–2, UTF-8, …), atd. Výše uvedený datový záznam vytvořený optimálním způsobem na jednom zařízení bude bez dalšího s největší pravděpodobností naprosto nesrozumitelný na zařízení jiném, pokud se jej vůbec podaří přenést. Ambicí ASN.1 je být na všech výše uvedených vlastnostech i subjektech nezávislá a přitom poskytnout přesné datové definice.
Je možné i vhodné ponechat zařízení, aby pro své vlastní potřeby použilo takovou reprezentaci záznamu, která mu je vlastní. Jakmile však chce komunikovat s jiným zařízením, musí záznam napřed převést do standardizované transportní podoby. Každému zařízení pak dostačuje provedení jediné konverze do/z „společného jmenovatele“, přes který se dorozumí s každým jiným podobným zařízením. Viz následující obrázek.
Obr. 2: interoperabilita pomocí datových struktur definovaných v ASN.1
Na obrázku 2 je zaznamenáníhodné to, že společný jmenovatel je rozdělen do dvou částí, označených zde jako ASN.1 a BER. K primární formální definici struktury přenášených dat slouží ASN.1, s jejíž pomocí vzniká lidsky srozumitelný zápis, obdobně jako je srozumitelný zdrojový zápisu programu v některém programovacím jazyku. Definice v ASN.1 jsou zapsány i ve zveřejněném dokumentu standardu nebo specifikace. Konkrétní zařízení ovšem budou pracovat s reálnými daty. Je zapotřebí, aby reprezentace byla pokud možno efektivní a zároveň aspoň nějak určená do běžné binární podoby, jako je na obrázku uvedené kódování BER (více k němu níže). To je analogií vykonatelné strojové podoby programů.
V praxi je často prostředkujícím standardem úspěšný průmyslový standard některého výrobce. Má-li dobře sloužit k vzájemné výměně dat, musí být nejen otevřený, ale jeho datové definice musí být jasné a formálně přesné. K otevřenosti a interplatformnosti nestačí jen dobrá vůle autora, ale je zapotřebí i vhodný nástroj. Takovým jakým je např. i ASN.1.
Syntaxová triáda
Jak je uvedeno již výše, tvůrci standardů potřebují vytvořit:
- Systém na zápis struktur dat, jenž by byl jednoznačně srozumitelný a vyložitelný člověkem (tj. abstraktní syntaxe).
-
Pravidla kódování, s jejichž pomocí lze reálné hodnoty vytvořené podle typů (tj. „šablon“ definovaných v abstraktní notaci) reprezentovat ve strojově vyměnitelném formátu (tj. v přenosové syntaxi).
Pro první úkol byla v organizaci a standardech ITU-T navržena abstraktní syntaxová notace ASN.1, pro druhý pravidla kódování (např. BER). V jazyku ASN.1 lze výše požadovaný záznam zapsat např. takto:
Zaznam ::= SEQUENCE { jmeno PrintableString (SIZE (1..30) ) vyska INTEGER stav ENUMERATED { svobodny (0), zenaty(1), rozvedeny(2), vdovec (3) } }Výše uvedený zápis postihuje strukturu záznamu Zaznam a definuje ji v abstraktní rovině jazyka ASN.1. Syntaktická pravidla jazyka ASN.1 zaručí, že zápisy (určené pro popis syntaxe dat) jsou jednoznačně vyložitelné. ASN.1 lze též zjednodušeně považovat za „programovací jazyk“, který je zcela koncentrován na datové definice.
Pro jakýkoliv případ použití této datové struktury, mimo abstraktní rovinu, musí pochopitelně existovat přesně definovaná pravidla, dle nichž se navržený formát přetransformuje do strojové podoby (typicky bitové nebo bytové = oktetové, obecně binární). Tato pravidla ITU-T rovněž definoval a jejich první navrženou variantu nazval BER (Basic Encoding Rules – Základní kódovací pravidla).
Výhoda této koncepce oddělení abstrakce a kódování spočívá i v tom, že pro různá technická přenosová prostředí lze definovat různá kódovací pravidla, přičemž původní abstraktní zápis zůstává nezměněn.
V současnosti již existuje široká škála kódovacích pravidel: BER, DER, CER, PER, XER, … Příliš mnoho typů kódování může být pochopitelně obtížné současně implementačně podporovat. Implementátoři se naštěstí zpravidla drží jen těch kódování, jež jsou vhodná pro daný typ standardu, prostředí a použití. Konverze do přenosových syntaxí může být rovněž do značné míry automatizována!
Kromě dvou výše uvedených notací se ještě využije:
- Nativní implementace v zařízení pomocí konkrétní syntaxe.
Pokud by se standardizátoři např. pokusili definovat strukturu abstraktně v některém programovacím jazyku – jako je třeba „C“ – přímo, narazí na několik potíží. Především implementace „C“ je závislá na platformě, např. typ integer bývá implementován v délce a přesnosti přirozené délky slova procesoru počítače, tj. může být 16bitový, 32bitový apod. Jinak řečeno – kódovací pravidla jsou u různých implementací „céčka“ proměnná a mimo kontrolu standardizátora.
S jinými jazyky je tomu podobně, nebo se svými vlastnostmi plně nehodí pro všechny nároky zápisu datových struktur. Další nevýhodou může být i to, že formování a vývoj jazyka nejsou spolehlivě v rukou standardizátora. V případě použití ASN.1 pak celý systém vypadá dle následujícího obrázku.
Obr. 3: syntaxová triáda: abstraktní + konkrétní + přenosová syntaxe
Reálná implementace zařízení se nakonec pochopitelně provádí v některém skutečném programovacím jazyku (jako jsou C nebo Pascal) a nikoliv v ASN.1. Tato skutečná implementace musí vyjadřovacími prostředky (konkrétní syntaxe) svého programovacího jazyka rovněž popisovat potřebný záznam a být dostatečná pro zpracování datových struktur, jež jsou pro aplikaci v ASN.1 definovány.
Vývoj zařízení, vycházejícího z definice v ASN.1, v současnosti může efektivně probíhat takto:
- Specifikátor zapíše datové struktury protokolu v ASN.1.
- Zápis ASN.1 se zkontroluje parserem ASN.1 na správnost zápisu.
- Vývojář použije kompilátor ASN.1, jenž provede kontrolu správnosti zápisu a zkonvertuje definice do cílového programovacího jazyka (např. C nebo Pascal) do souborů dvojího typu:
- definice typů v cílovém jazyku (s nimiž se dobře pracuje v cílovém jazyku a prostředí);
- konverzní funkce, jež překládají definované typy v cílovém jazyku do přenosové syntaxe (mohou mít též formu knihovny).
- Vývojář používá v cílovém jazyku datové typy a funkce vytvořené kompilátorem ASN.1 v kroku 3.
Výhodou opět je, že v případě použití jiných kódovacích pravidel (např.XER místo BER, viz níže) se soubory dle 3a) nemusí měnit, pouze se mění generované funkce 3b) a jen mírně práce s nimi v kroku 4.
Pokud vývojář kompilátor ASN.1 k dispozici nemá, musí si vhodné typy cílového jazyka a jejich konverzi do přenosové syntaxe (krok 3) navrhnout sám.
V praxi tvorby na obecných platformách je situace mnohem horší. Jen málokterý programátor je zde ochoten sáhnout na data v úrovni jejich přenosového kódování a kontroly jejich obsahu vůči definicím v ASN.1 ve standardech. Místo toho se většinou používají knihovní funkce vyšší úrovně, které mu jsou předpřipraveny v operačním systému, v operačním prostředí, v aplikaci nebo jiném typu middleware. Na jednu stranu takový vývoj ušetří čas i peníze, na druhou stranu má vývojář často jen omezenou jistotu, že ve „wrapperech“ nejsou chyby, zadní vrátka apod. Takové knihovny též mohou významně omezovat funkční pestrost, kterou poskytuje originální standard.
Další příklady ASN.1, jeho základy a podrobnosti o metodách kódování, si vyložíme příště.
