• 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: http://www.iana.org/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.