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
|
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,