RFC 822:n on korvannut RFC 2822. Muutokset ovat suhteellisen pieni�, mutta en ole viel� tarkistanut, vaikuttavatko ne t�m�n dokumentin sis�lt��n.
RFC 822,
Standard for the format of ARPA Internet text messages
on Internetin vanhimpia ja keskeisimpi�
standardeja.
Se m��rittelee viestien (messages) yleisen muodon, ja t�h�n
muotoon perustuvat mm. meiliss� ("s�hk�postissa") ja
nyyseiss� (Usenet news,
"keskusteluryhm�t", "uutisryhm�t") k�ytetyt viestien muodot samoin
kuin Web-palvelimien ja Web-selainten v�linen viestint� (HTTP).
Asemaltaan se on yksi harvoja
"oikeita" Internet-standardeja, STD 11.
Se on huomattavan vanha; DRUMS-ty�ryhm�ss� on k�ynniss� ty� standardin uusimiseksi
(josta on olemassa luonnos
draft-ietf-drums-msg-fmt-09.txt).
T�m� dokumentti kuvaa lyhyesti RFC 822:n p��piirteet sek� siihen tehdyt muutokset (jotka eiv�t ilmene itse RFC 822:sta).
Alun perin RFC 822 m��riteltiin ihmisten v�list� viestint�� varten, tarkemmin sanoen meilin ("s�hk�postin", electronic mail) viestien muodoksi. Sit� on kuitenkin k�ytetty perustana m��ritelt�ess� lukuisia muita viestint�tapoja, joissa voi olla kyse my�s ihmisen ja tietokoneen v�lisest� taikka tietokoneiden keskin�isest� viestinn�st�. Luonnollinen tausta t�lle on, ett� RFC 822 m��riteltiin tietokoneen avulla tapahtuvan viestinn�n tarpeisiin, ja t�ll�in on otettava huomioon se, ett� viestej� l�hett�v�t, kuljettavat ja vastaanottavat tietokoneohjelmat.
Koska RFC 822 alkuper�isess� muodossaan (pelkk�� teksti�) on melko raskas referenssin� k�ytett�v�ksi, kannattaa k�ytt�� Freesoftin Internet-ensyklopediaan sis�ltyv�ss� RFC-kokoelmassa olevaa RFC 822:n hypertekstiversiota.
RFC jakautuu seitsem��n osaan, kun liitteit� ei oteta huomioon:
Seuraavassa on lyhyit� tiivistelmi� osien sis�ll�st�; otsikot ovat linkkej� em. hypertekstiversion vastaaviin kohtiin.
Standardi m��rittelee sellaisten viestien syntaksin, joita tietokoneiden k�ytt�j�t l�hett�v�t toisilleen meilin (electronic mail) puitteissa. (Kuten edell� todettiin, t�m� on nykyisin vain erikoistapaus, ja RFC 822:ta noudatetaan soveltuvin osin muussakin viestinn�ss�.)
Viestill� on kuori (envelope) ja sis�lt� (contents) eli runko (body). Kuori sis�lt�� (kirjekuoren tavoin) informaatiota, joka on tarpeen viestin kuljettamiseen ja toimittamiseen perille. Sis�lt��n standardi ei yleens� puutu mitenk��n. Kun siis sanotaan, ett� RFC 822 m��rittelee viestien muodon, niin kyse on nimenomaan kuoresta, ei varsinaisesta viestist�.
Viesti koostuu tekstiriveist�. T�t� alkuper�ist� ajatusta on sittemmin laajennettu etenkin MIME-m��rittelyill� niin, ett� viestin sis�lt� voi olla muutakin (esim. grafiikkaa), mutta itse RFC 822 k�sittelee vain tekstimuotoista viestint��.
My�s kuori koostuu tekstiriveist�, otsakkeista (headers).
Yhdess� otsakkeessa voi olla vastaanottajan osoite, toisessa l�hetysaika,
kolmannessa viestin aihetta kuvaava Subject-otsake jne.
T�m� luku kuvaa my�s standardissa k�ytetyt muodolliset merkint�tavat. Ne perustuvat Backus-Naur-muotoon (Backus-Naur Form, BNF), joka on alkujaan ohjelmointikielten kuvaamiseen kehitetty v�line mutta laajassa k�yt�ss� muutenkin ATK-alalla.
Viesti koostuu otsakekentist� ja rungosta, joka voi puuttua. Runko on jono rivej�, jotka koostuvat Ascii-merkeist�. (Edell� mainittu MIME on lis�nnyt mahdollisuuden k�ytt�� muutakin merkist��.)
Rivinvaihdon esitykseksi RFC 822 edellytt�� ns. CRLF:n, joka tarkoittaa kontrollikoodeja CR ja LF per�kk�in. (T�m� hyvin usein poikkeaa siit�, mik� on rivinvaihtojen "normaali" sis�inen esitysmuoto l�hett�j�n tai vastaanottajan koneessa - joissa muodot voivat olla kesken��n erilaiset. Ongelmia ei synny, kunhan ohjelmat suorittavat tarvittavat muunnokset automaattisesti. Ks. kirjoitustani Rivinvaihdot ja kappaleet datan k�sittelyss�.)
Keskeinen muotos��nt� RFC:ss� on, ett� otsakkeet ja rungon erottaa toisistaan tyhj� rivi (null line). T�m�n rivin tulee todella olla tyhj� eli siin� ei saa olla edes yht� v�lily�nti� rivinlopun (CRLF) edell�.
Otsakkeiden yleinen muoto on
nimi: arvo
miss� nimi on otsakekent�n nimi (esim. From, 'l�hett�j�')
ja arvo on kent�n sis�lt� (esim. l�hett�j�n meiliosoite
jukkakk@gmail.com), jonka muoto ja merkitys riippuu kent�st�.
Kukin otsake on loogisesti yksi rivi, mutta se voidaan k�yt�nn�n
syist� jakaa usealle riville; t�t� koskevat ns.
folding-s��nn�t ovat melko mutkikkaat,
mutta yksinkertaistaen sanottuna: jos otsakkeen ensimm�ist� rivi� seuraavan
rivin alussa on v�hint��n yksi v�lily�nti, niin se on jatkorivi.
Otsakkeissa voi esiinty� my�s
kommentteja, joiden syntaksi on luonnollisempi kuin
esim. ohjelmointikieliss� tyypillisesti: kommentti kirjoitetaan tavallisiin
sulkumerkkeihin. Esimerkiksi tyypillisess� From-kent�ss�
kuten
From: jkorpela@beta.hut.fi (Jukka Korpela)
on suluissa oleva osa periaatteessa vain
kommentti (mutta ks.
kohtaa 6 Osoitteet).
Kenttien nimiss� voi k�ytt�� isoja tai pieni� kirjaimia vapaasti,
esim. from tai FROM. Yleinen k�yt�nt� on kuitenkin
kirjoittaa sanat isoilla alkukirjaimilla mutta muuten pienill� kirjaimilla.
T�m� luku m��rittelee viestien pakolliset ja vapaaehtoiset kent�t sek� sen, miten kenttien valikoimaa voidaan laajentaa. T�lt� osin RFC 822 koskee muuta kuin meiliviestint�� vain soveltuvin osin. Esimerkiksi HTTP-protokollan viestien muoto noudattaa RFC 822:n yleisi� periaatteita mutta kenttien valikoima on suurimmaksi osaksi toinen.
Tavat, joilla otsakekenttien valikoimaa voidaan RFC 822:n mukaan laajentaa,
ovat toisaalta erillisten spesifikaatioiden tekeminen
(k�yt�nn�ss� RFC:in�),
toisaalta ns. user defined fields. J�lkimm�isi� voidaan
k�ytt�� kahdenkeskisen sopimuksen perusteella tai laajemman mutta vahvistamattoman
k�yt�nn�n mukaan, ja niiden nimien tulee alkaa X-, siis
esim. X-mun-ikkari-otsake.
RFC 822:ssa m��ritellyt otsakekent�t ovat seuraavat. Otsakkeiden j�rjestyksen ei tarvitse olla t�m�n mukainen.
| Kent�n nimi | Kent�n merkitys |
|---|---|
Return-Path
| sis�lt�� "polun" takaisin l�hett�j�lle, k�yt�nn�ss� usein vain meiliosoitteen; ei pakollinen, mutta voimakas suositus on, ett� ao. ohjelmat automaattisesti lis�isiv�t t�m�n kent�n |
Received
| tietoa viestin kulusta koneesta toiseen |
From
| ilmaisee henkil�n, joka halusi t�m�n viestin l�hetett�v�ksi; kent�n sis�lt�n� on meiliosoite (johon voi liitty� kommentissa erillinen tieto nimest�) |
Sender
| ilmaisee "agentin" (ihmisen, j�rjestelm�n tai prosessin), joka l�hetti viestin; tarkoitettu k�ytett�v�ksi silloin, kun "agentti" ei ole viestin alkuper�inen laatija |
Reply-To
| meiliosoite, johon vastaukset tulisi l�hett��; tarpeen silloin, kun t�m�n
halutaan olevan eri kuin From-kent�ss� oleva osoite
|
To
| viestin ensisijaiset vastaanottajat (heid�n meiliosoitteensa) |
Cc
| viestin toissijaiset vastaanottajat ("tiedoksi kopio n�ille"; "carbon copy") |
Bcc
| viestin muut vastaanottajat; poikkeaa Cc:st� siten, ett�
t�m� kentt� j�� pois niist� kopioista, ett� ensi- ja toissijaiset vastaanottajat
saavat eli n�m� eiv�t n�e, ketk� ovat Bcc-jakelussa ("blind carbon copy")
|
Date
| viestin luomisen ajankohta |
Message-ID
| viestin yksik�sitteinen tunniste, jonka l�hett�v� j�rjestelm� generoi; tarkoitettu tietokoneiden luettavaksi, ei niink��n ihmisten |
In-Reply-To
| vastausviestiss� kentt�, joka ilmaisee, mihin aiempaan viestiin t�m� viesti vastaa |
References
| viittaa muihin viesteihin, joihin t�m� viesti jotenkin liittyy (vastauksena, vastauksen vastauksena tms.) |
Keywords
| sis�lt�� avainsanoja tai avainilmaisuja; erottimena pilkku |
Subject
| ilmaisee tiivistelm�n viestist� tai kertoo, mit� se koskee |
Comments
| viestiin liittyvi� kommentteja (joita ei ole haluttu kirjoittaa viestin runkoon) |
Encrypted
| tieto siit�, ett� viestin sis�lt� on salakirjoitettu |
Lis�ksi on m��ritelty kent�t Resent-From, ...,
Resent-Message-ID, jotka ovat analogisia
kenttien From, ....,
Message-ID kanssa
mutta on tarkoitettu k�ytett�viksi
uudelleenl�hetysten yhteydess� eli
kun alkuper�isen viestin saaja on l�hett�nyt sen eteenp�in (ks. standardin kohtaan
Forwarding).
T�ll�in esimerkiksi Resent-From-otsake
ilmaisee edelleenl�hett�j�n ja
From-otsake ilmoittaa alkuper�isen l�hett�j�n.
Ks. esimerkkej� t�llaisista tilanteista
standardin liitteess� A.2.
Pakolliset kent�t ovat From, To
ja
Date. (T�m� on standardin vaatimus; se ei tarkoita, ettei
viesti, joka on t�ss� suhteessa viallinen, koskaan voisi kulkea minnek��n.)
Standardin liite A.3 sis�lt�� esimerkkej� viestien "kuorista" eli viestin kaikkien otsakkeiden kokoelmista, yksinkertaisimmista varsin laajoihin.
Lukuisissa muissa protokollissa on m��ritelty muita otsakekentti�. Ks. Jacob Palmen kirjoittamaa RFC 2076:ta ja uudempaa koostetta Common Internet Message Header Fields.
RFC 822 m��rittelee er��n aikojen (p�iv�m��rien ja kellonaikojen)
ilmaisemisen muodon, josta on muodostunut laajasti k�ytetty joskaan
ei suinkaan ainoa Internetiss�. Alkuper�isess� muodossa
piti (!) vuosiluku ilmaista kahdella numerolla.
Vuonna 1989 t�t� kuitenkin muutettiin (ks. tietoja muutoksista j�ljemp�n�) niin, ett� vuosiluvussa on
kahdesta nelj��n numeroa, ja suositus on k�ytt�� nelj�� numeroa.
(Mutta viel�kin on ohjelmia, jotka l�hett�v�t
Date-kentti�, joissa vuosiluku on kaksinumeroinen.)
Ajanilmaisujen rakenne selvi�� parhaiten esimerkist�:
Fri, 4 Mar 2000 08:52:26 +0200
T�ss�
Fri, ilmaisee viikonp�iv�n; t�m� osa voi puuttua,
mutta jos se on mukana, siin� tulee olla viikonp�iv�n
englanninkielisen nimen kolmikirjaiminen lyhenne, jota seuraa pilkku
4 ilmaisee kuukaudenp�iv�n (yksi tai kaksi numeroa;
my�s 04 olisi sallittu)
Mar ilmaisee kuukauden sen
englanninkielisen nimen kolmikirjaimisella lyhenteell�
2000 on vuosiluku, jonka on siis syyt� olla
nelinumeroinen
08:52:26 kertoo kellonajan; huomaa, ett�
tunnit, minuutit ja sekunnit pit�� ilmaista kaksinumeroisina
ja ett� erottimena on kaksoispiste; sekunnit ilmaiseva
loppuosa, esimerkiss�mme :26, saa puuttua
+0200 ilmaisee aikavy�hykkeen; t�m� osa on
pakollinen, mutta sallittuja muotoja on useita:
UT tai GMT tai Z, jotka
tarkoittavat
yleisaikaa,
Universal Coordinated Time;
huomaa, ett� yleisajan nykyisin tavallinen lyhenne UTC ei
ole sallittu RFC 822:n aikaformaatissa
EST;
n�it� RFC 822 m��rittelee vain muutamia - USA:n
aikavy�hykkeille; muut ovat siis periaatteessa standardin
vastaisia ja k�yt�nn�ss� ne tulkitaan miten sattuu
+0200,
joka ilmaisee eron yleisaikaan n�hden; esimerkiss�mme
ollaan 2 tuntia edell� yleisajasta; t�ss� ei
k�ytet� mit��n erotinta tuntien ja minuuttien v�lill�,
ja molempien pit�� olla mukana ja kaksinumeroisina.
T�t� esitysmuotoa ei saa lokalisoida esimerkiksi korvaamalla viikonp�ivien ja kuukausien nimet vaikkapa suomenkielisill�. Kyse on tietokoneiden k�sitelt�v�ksi tarkoitetusta datasta, jossa jokaisella kent�ll� on sille m��ritelty merkitys; on sin�ns� yhdentekev��, onko jotkin merkkijonot alun perin otettu englannista vai volapükist�. Kokonaan eri asia sitten on, ett� ohjelma voi n�ytt�� ajan ilmaisun k�ytt�j�lle miten vain, vaikkapa normaalia suomen kielt� taikka kalenteria ja kellotaulua k�ytt�en.
Ajanilmaisut ovat yleens� ohjelmien tuottamia, ei "k�sin" kirjoitettuja. Edell� oleva selitys on tarkoitettu auttamaan ilmaisujen tulkinnassa sek� toisaalta arvioimaan ohjelmia silt� kannalta, miten hyvin ne noudattavat t�t� standardia.
Jos ajanilmaisu esiintyy otsakkeessa niin, ett�
sit� seuraa esim. (EET), niin se on t�ysin sallittua -
mutta kyseess� on pelkk� kommentti.
Huomattakoon, ett� RFC 822 poikkeaa merkitt�v�sti yleisest� kansainv�lisest� aikojen ilmaisemista koskevasta standardista ISO 8601:st�.
Standardi m��rittelee
k�sitteet mailbox ja
address periaatteessa eri asioita tarkoittaviksi: address
voi olla mailbox tai group, joka koostuu erityisell� tavalla
muodostetusta, puolipisteeseen (;) p��ttyv�st�
osoitelistasta.
K�yt�nn�ss� group-vaihtoehtoa ei yleens� k�ytet�, joten
mailbox ja address tarkoittavat samaa.
Huomattakoon, ett� sanaa mailbox k�ytet��n (RFC 822:n ulkopuolella)
yleisesti tarkoittamaan tiedostoa, johon k�ytt�j�lle saapunut meili menee;
nimitys perustuu analogiaan postilaatikon kanssa.
Osoitteen (mailbox) perusmuoto koostuu
paikallisosasta (local-part) ja
alueesta (domain), joiden v�liss� on erottimena
�t-merkki @:
paikallisosa@alue
Vaihtoehtoisena muotona on sallittu mm. seuraava:
fraasi <paikallisosa@alue>
miss� fraasi on samassa asemassa kuin
kommentti. T�st� seuraa, ett� on kaksi
vaihtoehtoista tapaa liitt�� osoitteen yhteyteen selitys,
esim. nimi,
joka on tarkoitettu informaatioksi ihmisille mutta joka
ei vaikuta viestin kulkuun, t.s. ohjelmat j�tt�v�t sen huomiotta:
jkorpela@beta.hut.fi (Jukka Korpela)
Jukka Korpela <jkorpela@beta.hut.fi>
Huomaa kuitenkin, ett� nyysien osalta RFC 1036 m��rittelee (kohdassa 2.1.1), ett� kyseist� osaa ei pidet� kommenttina vaan osoitteen osana (joka voi puuttua) ja ett� se ilmoittaa k�ytt�j�n koko nimen (full name of the user).
T�ss� on k�sitelty vain muutamaa t�rke�� yksityiskohtaa
osoitteista. Itse standardissa on niit� kuvattu paljon laajemmin; ks. my�s
selityst�ni
Internet E-mail address format (RFC 822) explained.
Mainittakoon kuitenkin viel�, ett� pisteell� on
osoitteissa aivan eri merkitys sen mukaan, esiintyyk� se
paikallisosassa vai alueessa eli onko se @-merkin
vasemmalla vai oikealla puolella. Alueessa se on monitasoisen
(hierarkkisen) nimen osien erotin. Sen sijaan paikallisosassa
se on vain merkkijonon osa, jolla ei sin�ns� ole sen kummempaa
erillist� merkityst� kuin vaikkapa i-kirjaimella.
Sellaiset osoitteet kuin Jukka.Korpela@hut.fi ovat
tulleet k�ytt��n, koska on haluttu itse osoitteiden olevan
havainnollisempia ihmisille ja koska toisaalta paikallisosassa
v�lily�nti ei normaalisti ole sallittu.
Tosin v�lily�nti olisi standardin
mukaan sallittu lainausmerkkien sis�ll�. Esimerkiksi
"Jukka Korpela"@hut.fi olisi muotos��nt�jen mukainen
osoite (ei kuitenkaan toimiva osoite!).
Sellaisia ei kuitenkaan yleens� ole haluttu ottaa k�ytt��n
mm. siksi, ett� lainausmerkit aiheuttavat sekaannuksia.
Kohdassa 6.1 standardi vaatii, ett� jokaisessa alueessa
on osoite Postmaster@alue,
jonka kautta tavoittaa meilij�rjestelm�n yll�pit�j�n
("a person responsible for the site's mail system or to a person with
responsibility for general site operation").
Lis�ksi kohta 3.4.7 vaatii, ett�
j�rjestelm�n tulee ymm�rt�� tunnus Postmaster siit�
riippumatta, miten siin� on k�ytetty isoja ja pieni� kirjaimia
(esim. my�s kirjoitusasujen postmaster ja
POSTMASTER tulee kelvata).
Vaikka standardi mainitsee vaatimuksen perusteluksi my�s sen, ett�
k�ytt�j� voisi haluta saada selville jonkun ihmisen oikean osoitteen,
t�t� on pidett�v� vanhentuneena; se kuuluu aikaan, jolloin meilin
k�ytt� oli paljon v�h�isemp�� kuin nykyisin. Osoitteet on syyt� etsi�
muilla keinoin; ks. dokumenttia
Meiliosoitteiden ("s�hk�postiosoitteiden") etsiminen erityisesti kansallisista osoitehakemistoista,
etenkin siin� olevaa kuvausta er�ist� postmasterille kuuluvista teht�vist�.
Standardin liite A.1 sis�lt�� esimerkkej� osoitteista ja osoitelistoista.
T�m� on l�hinn� kai vain historiallisesti mielenkiintoinen. Historiasta kiinnostuneille mainittakoon, ett� RFC 822:n edelt�j� RFC 733 puolestaan perustui aiemmille ehdotuksille ja k�yt�nn�ille. Er�s niist� on RFC 561 vuodelta 1973. Siin� on nasevasti sanottu, miksi hommaan ryhdyttiin (viittaus "FTP mailiin" kannattaa ymm�rt�� yleiseksi viittaukseksi sen ajan alkeellisiin viestinv�lityskeinoihin):
One of the deficiences of the current FTP mail protocol is that it makes no provision for the explicit specification of such header information as author, title, and date. Many systems send that information, but each in a different format. One fairly serious result of this lack of standardization is that it's next to impossible for a system or user program to intelligently process incoming mail.
RFC Editorin hakulomakesivulla RFC 822:sta saatavien tietojen mukaan se on "Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156" (tilanne 2000-03-22). Niist� RFC 1138, RFC 1148 ja RFC 1327 ovat "obsoleted by RFC2156", joten relevantteja ovat:
Asiallisesti varsin merkitt�v�� laajennusta merkitsee mediatyyppien (Mime-tyyppien) j�rjestelm� ja siihen liittyv� viestien muodon laajennus. Siin� ei kuitenkaan ole kyse RFC 822:n muuttamisesta vaan sen pohjalle rakennetusta uudesta viestimuodosta.
Viimeisimm�n p�ivityksen ajankohta: 2001-10-15. V�h�isi� teknisi� korjauksia 2004-11-19.
Jukka Korpela,