• Typy popisujúce typ prenášaných dát:
  

  :: text

  Tento typ je určený pre posielanie textových informácií. Text je kódovaný v niektorej z podporovaných znakových sád; znakovú sadu určuje parameter charset. Jednotlivé znakové sady sú uverejnené na: http://www.iana.org/assignments/character-sets. Primárny podtyp je plain a označuje neformátovaný text.

  
  :: application

  Binárne dáta pochádzajúce z rôznych aplikačných programov (databáz, textových procesorov, tabuľkových kalkulátorov, kompresných programov a pod.). Primárnym typom je neutrálny octet-stream, ďalšou možnosťou je napríklad postscript.

  
  :: image

  Dáta reprezentujúce (statický) obrázok. RFC 1521 definuje dva základné podtypy - gif a jpeg. Ďalšie typy sú uverejnené na: http://www.isi.edu/in-notes/iana/assignments/media-types/media-types.

  
  :: audio

  Telo správy obsahuje zvuk. Primárnym podtypom je basic (mono so vzorkovacím kmitočtom 8 kHz).

  
  :: video

  Obsahom tela správy je video, primárny podtyp je mpeg.

  
  :: model

  Modelom sa rozumie reprezentácia troch a viac dimenzionálnych systémov, v ktorých je možné zaviesť pravouhlú súradnicovú sústavu. Model sa skladá z jedného alebo viacerých objektov, medzi ktorými je definovaný vzťah typu master/slave. Objekt sa skladá z elementov, ktoré majú medzi sebou definované vzťahy. Model môže zahŕňať faktory ako je sila, rýchlosť, zrýchlenie, hybnosť, čas atď. Primárnym podtypom je iges, ďalšou možnosťou je napr.: vrml. Popisom tohoto typ sa podrobnejšie zaoberá dokument RFC 2077.

  
  
• Typy špecifikujúce, že správa sa skladá z niekoľkých častí:
  

  :: message

  Tento typ umožňuje odoslať e-mailovú správu ako telo inej správy (rfc822), dlhú správu odoslať ako niekoľko kratších (partial) alebo namiesto tela správy odoslať informácie, že správa sa nachádza na danom serveri (external-body).
  
  Definované podtypy sú:

  • Message/rfc822 špecifikuje, že telo obsahuje vnorenú správu, ktorá má syntax podľa RFC 822. Často je potrebné poslať e-mailovú správu ako telo inej správy. Práve pre tento účel je definovaný typ message. Na rozdiel od RFC 822 nie je potrebné, aby každé telo správy typu message/rfc822 obsahovalo hlavičkové polia From, To a Subject.
    
    
  • Message/Partial je definovaný preto, aby bolo možné posielať dlhé správy ako niekoľko kratších a príjemcov software ich mohol automaticky zobraziť ako jednu správu.
    
    
  • Message/External-Body špecifikuje informácie o správe, ktorá je uložená na určitom serveri. Parameter acces-type obsahuje typ servera (protokolu). Najčastejšie typy serverov sú: ftp, anon-ftp (anonymný FTP server), mail-server a local-file (súbor na lokálnom počítači). Ďalšie typy je možné nájsť na adrese: ftp://ftp.isi.edu/in-notes/iana/assignments/access-types. Parameter name - určuje meno súboru, parameter site - meno počítača, parameter directory - adresár, v ktorom sa nachádza daný súbor a parameter expiration - špecifikuje čas, dokedy bude súbor aktuálny.

  :: multipart

  Telo správy tohto typu obsahuje niekoľko rôznych častí. Každá časť tela správy začína reťazcom, ktorý je definovaný v parametre boundary (v hlavičkovom poli Content-Type). Potom nasledujú hlavičkové polia tejto časti, prázdny riadok a vlastné telo správy. Posledná časť je zakončená koncovým reťazcom (napríklad: ------------D32C428032D08B1A1736CED2).
  
  Reťazec definovaný v parametre boundary je špeciálna množina znakov, ktorá sa nesmie vyskytnúť vo vnútri žiadnej časti správy. Maximálna dĺžka tohto reťazca je 70 znakov.
  
  Jednotlivé čiastkové správy nie sú interpretované podľa RFC 822. Môžu, ale nemusia obsahovať hlavičkové polia (prázdny riadok za záhlavím však musí byť uvedený vždy). Pokiaľ nie sú hlavičkové polia u čiastkových správ uvedené, uplatňujú sa implicitné hlavičkové polia zo záhlavia celej správy.
  
  Definované podtypy sú:

  • Multipart/Mixed je primárnym podtypom. Je určený pre správy, ktoré obsahujú nezávislé časti, ktoré je potrebné zviazať v danom konkrétnom poradí. Klasickým prípadom podtypu Multipart/Mixed je správa elektronickej pošty obsahujúca jednu alebo viacej príloh.
    
    
  • Multipart/Alternative - správa tohto typu obsahuje niekoľko častí, pričom všetky časti obsahujú rovnaké informácie, ale majú odlišný formát. Tá istá správa môže byť raz napísaná v US-ASCII, potom v ISO-8859-2 a nakoniec napríklad nahovorená, t.j. audio. Príjemcov software musí rozpoznať, ktoré formy je schopný zobraziť a vybrať z nich tú najlepšiu. Software vytvárajúci takúto správu musí usporiadať jednotlivé časti podľa vzrastajúcej kvality.
    
    
  • Multipart/Digest umožňuje, aby jedna alebo viacej správ boli tvorené postupnosťou správ. V praxi sa môžeme stretnúť s prípadom, že správa je tvorená pomocou multipart/mixed dvomi čiastkovými správami. Prvá čiastková správa tvorí obsah a druhá pomocou multipart/digest sa skladá z jednotlivých kapitol.
    
    
  • Multipart/Parallel pri tomto podtype nezáleží na poradí častí správy. Poštový software všetky tieto časti prezentuje užívateľovi súčasne.
    
    
  • Multipart/Signed špecifikuje správu, ktorá sa skladá z dvoch častí:

    • zo správy,
      
    • z elektronického podpisu tejto správy.

  • Multipart/Encrypted špecifikuje šifrovanú správu, ktorá sa skladá z dvoch častí:

    • z informácií o použitom spôsobe šifrovania,
      
    • zo šifrovanej správy.

  Subtypy Multipart/Signed a Multipart/Encrypted predstavujú cestu k použitiu tzv. bezpečného e-mailu a sú definovné v dokumente RFC 1847. V súčasnosti existujú štyri nezávislé štandardy pre bezpečný e-mail:

  • PGP (RFC 1991),
    
  • PEM (RFC 1421 až 1424),
    
  • MOSS (RFC 1848),
    
  • S/MIME (Secure/MIME).

7-bit
Ide o implicitnú metódu kódovania, ktorá sa predpokladá, pokiaľ nie je hlavičkové pole Content-Transfer-Encoding uvedené. Dáta takto spracované nie sú vôbec kódované, sú iba rozdelené do krátkych riadkov, ktoré obsahujú len znaky us-ascii, t.j. znaky zo základného rozsahu 32 až 126.

8-bit
Dáta transformované týmto algoritmom nie sú opäť kódované, sú iba rozdelené do krátkych riadkov. Môžu sa tu vyskytnúť aj znaky mimo základný rozsah 32 až 126.

binary
Okrem možného výskytu znakov mimo rozsahu 32 až 126 nie je zaručená ani dĺžka riadkov. Tento algoritmus nepredstavuje žiadne kódovanie.

quoted-printable
Tento typ kódovania je vhodný pre dáta, ktoré z väčšej časti obsahujú ASCII znaky zo základného rozsahu (32 až 126), no len malý počet z nich treba kódovať. Výsledkom kódovania je teda ASCII text, ktorý je aj bez dekódovania relatívne čitateľný. Kódovaný môže byť aj text, ktorý obsahuje len ASCII znaky. Robí sa to z dôvodu zabezpečenia integrity dát (napr. ak dáta prechádzajú cez bránu (gateway), ktorá vykonáva náhradu znakov alebo zarovnávanie riadkov).

Pravidlá kódovania:

• Ľubovolný znak (okrem znaku konca riadku) je nahradený znakom '=', za ktorým nasleduje hexadecimálna hodnota znaku.
  
  
• Znaky s desiatkovou hodnotou od 33 do 60 a od 62 do 126 vrátane sú nahradené ASCII znakmi (od '!' do '<' a od '>' do '~').
  
  
• Znaky s hodnotou 9 a 32 sú nahradené znakmi TAB a SPACE. Tieto znaky sa nesmú vyskytnúť na konci riadku.
  
  
• Koniec riadku je vyjadrený znakom CRLF.
  
  
• Zakódovaný riadok môže mať maximálne 76 znakov. Pokiaľ je riadok dlhší, vloží sa na jeho koniec znak '='.

base64
Tento algoritmus (obr. 1) je pravdepodobne najvhodnejším pre kódovanie binárnych súborov. Kódované dáta sú iba o tretinu dlhšie než dáta pôvodné. Kódovací algoritmus je jednoduchý. Používa tabuľku base64, ktorá obsahuje 64 znakov a znak "=". Znak "=" sa používa pre špeciálne účely. Na začiatku kódovania sa binárne dáta rozdelia na skupiny po troch bajtoch a 24 bitov každej trojice sa prerozdelí na štyri bloky po 6 bitov. Každých 6 bitov je potom nahradených zodpovedajúcim znakom z tabuľky base64 (tab. 1). Takto zakódovaný binárny súbor sa musí usporiadať do riadkov, ktorých maximálna dĺžka je 76 znakov. Pokiaľ nie je dĺžka pôvodného súboru deliteľná tromi, zostane nám na konci kódovania menej než 24 bitov, teda 8 alebo 16. V prvom prípade sa počet bitov doplní sprava nulami na 12, teda dva bloky, ktoré sa zakódujú pomocou dvoch znakov. Za týmito znakmi sa ešte vloží dvakrát znak "=". V druhom prípade sa počet bitov doplní sprava nulami na 18, z toho dostaneme tri znaky, ktoré sa ešte doplnia znakom "=". Dĺžka výsledného kódovaného binárneho súboru je vždy deliteľná štyrmi.


Obr. 1: Princíp kódovania binárnych súborov algoritmom base64

radix-64
Ide o rozšírenie kódovania base64 o kontrolný súčet. Data v správe sú kódované algoritmom base64, za nimi však nasleduje nový riadok (CRLF), znak "=" a 24 bitov dlhý kontrolný súčet z pôvodných, nekódovaných dát. Tento súčet je vypočítaný algoritmom CRC-24 a je zakódovaný do formátu base64. Zdrojový kód algoritmu CRC-24 ako i popis kódovania radix-64 nájdete v dokumente RFC 2440.

Príklad:

  -----BEGIN PGP MESSAGE-----
  Version: OpenPrivacy 0.99

  yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
  vBSFjNSiVHsuAA==
  =njUN
  -----END PGP MESSAGE-----

V prípade, že váš softvér nepodporuje kódovanie radix-64, stačí ak odstránite posledný riadok kódovanej správy a na dekódovanie použijete softvér, ktorý podporuje algoritmus base64.

x- anything
Štandard RFC 1521 [13] umožňuje použiť aj ďalšie typy kódovania. Ich označenie v hlavičkovom poli Content-Transfer-Encoding musí začínať prefixom x-. Tieto nové typy kódovania môžu byť použité pre experimenty. Ak byť majú používané v praxi, musia byť podľa RFC 2048 registrované odoslaním príslušného dokumentu na adresu: ietf-types@iana.org. Registrované algoritmy sú uverejnené na adrese: http://www.iana.org/assignments/transfer-encodings.