Tiivistelmä RFC 822:sta muutoksineen

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 822:n sisältö pääkohdittain

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.

1 Johdanto

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.

2 Merkintäsopimukset

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.

3 Viestien leksikaalinen rakenne

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.

4 Viestien muoto

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.

5 Ajan ilmaisut

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ä

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ä.

6 Osoitteet

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.

7 Kirjallisuusluettelo

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.

Muutokset

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,