AS2 Applicability Statement 2

Toteutettu yhteistyössä Elintarviketeollisuusliitto ry:n ja Päivittäistavarakauppa ry:n kanssa osana maa- ja metsätalousministeriön kansallista elintarviketalouden laatustrategiaa Tiedonsiirtosuositus AS2 Applicability Statement 2 versio 1.0, 2007-03-21

Sisällysluettelo 1 Dokumenttien hallinta... 5 1.1 Päivitykset... 5 2 Yleistä... 6 2.1 Yleiskuvaus... 6 2.2 AS2-sanoman välitys... 6 3 AS2-sanoman rakenne... 7 3.1 HTTP-sanomatyypit... 7 3.2 Otsikkotietojen tyypit ja rakenne... 7 4 Tiedoston siirto AS2-sanomana... 9 4.1 Kuittauspyyntösanoma... 9 4.2 Kuittauspyyntörivi... 9 4.3 MIME-otsikkotiedot... 9 4.3.1 Content-Disposition... 9 4.3.2 Content-Transfer-Encoding... 10 4.3.3 MIME-Version... 10 4.4 Kuittauspyyntösanoman yleiset tiedot... 10 4.4.1 Connection... 10 4.4.2 Date... 11 4.4.3 Via...13 4.5 Kuittauspyyntösanoman kuittauspyyntötiedot... 14 4.5.1 Accept-Encoding... 14 4.5.2 Comment... 15 4.5.3 From... 15 4.5.4 Host... 15 4.5.5 Message-Id... 16 4.5.6 Received... 16 4.5.7 Return-Path... 17 4.5.8 Subject... 17 4.5.9 TE... 17 4.5.10 To... 18 4.5.11 User-Agent... 18 4.6 Kuittauspyyntösanoman entiteettitiedot... 18 4.6.1 Content-Length... 18 4.6.2 Content-Type... 19 4.7 Käsittelyilmoituksen määrittelytiedot... 19 4.7.1 Disposition-Notification-To... 19

4.7.2 Disposition-Notification-Options... 20 4.7.3 Receipt-Delivery-Option... 21 4.8 AS2-ominaiset tiedot... 21 4.8.1 AS2-From... 21 4.8.2 AS2-To... 21 4.8.3 AS2-Version... 22 5 Käsittelyilmoitus... 23 5.1 Yleisiä ohjeita... 23 5.2 Käsittelyilmoitusten tyypit... 24 5.3 Synkroninen AS2-käsittelyilmoitus... 25 5.4 Käsittelyilmoituksen tilarivi... 26 5.5 Käsittelyilmoituksen yleiset tiedot... 29 5.6 Käsittelyilmoituksen vastaustiedot... 29 5.6.1 Location... 29 5.6.2 Retry-After... 29 5.6.3 Server... 29 5.7 Käsittelyilmoituksen entiteettitiedot... 30 5.8 AS2-ominaiset tiedot... 30 5.9 AS2-käsittelyilmoituksen ominaistiedot... 30 5.9.1 Reporting-UA... 30 5.9.2 MDN-Gateway... 31 5.9.3 Original-Recipient... 31 5.9.4 Final-Recipient... 31 5.9.5 Original-Message-ID... 32 5.9.6 Received-Content-MIC... 32 5.9.7 Disposition... 32 5.9.8 Error... 35 5.9.9 Warning... 35 5.9.10 Failure... 35 5.9.11 Esimerkkejä käsittelytilanteisiin liittyvistä ilmoituksista... 36 5.10 Asynkroninen AS2-käsittelyilmoitus... 37 6 Julkisten ja yksityisten avainten käyttö... 38 6.1 Sanoman lähettäjän tehtävät... 38 6.2 Sanoman vastaanottajan tehtävät... 38 7 Esimerkkejä... 39 7.1 Allekirjoitettu AS2-sanoma, johon pyydetään allekirjoitettua synkronista vastaanottoilmoitusta... 39 7.2 Synkroninen AS2-käsittelyilmoitus kappaleen 5.1 sanomaan... 39

7.3 Allekirjoitettu, salakirjoitettu AS2-sanoma, johon pyydetään allekirjoitettua asynkronista vastaanottoilmoitusta... 40 7.4 Asynkroninen AS2-käsittelyilmoitus kappaleen 5.3 sanomaan... 41 8 Lähteet... 43 9 LIITTEET... 44 9.1 Liite 1: Terminologiaa... 44

1 Dokumenttien hallinta Tämä tietoliikennesuositus on tehty Päivittäistavarakauppa ry:n (PTY) ja Elintarviketeollisuusliitto ry:n (ETL) organisoimassa XML-projektissa. Suositus perustuu AS2 (Applicability Statement 2) protokollaan, joka on esitetty dokumentissa RFC 4130 MIME- Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2). Tätä protokollaa ja tämän suosituksen mukaisia määrityksiä on suositeltavaa käyttää välitettäessä hankkeessa määriteltyjä dokumentteja kauppatapahtuman osapuolten välillä. Vaikka hankkeessa määritellyt sanomasuositukset perustuivat XML (extensible Markup language) syntaksiin pohjautuvaan UBL (Universal Business language) esitystapaan, voidaan kyseistä protokollaa käyttää myös muun esitystavan, kuten EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) mukaisen tiedon välittämiseen. 1.1 Päivitykset Versio Pvm/Laatija Muutokset 1.0 2007-03-21 Heikki Laaksamo Ensimmäinen versio 5/46

2 Yleistä 2.1 Yleiskuvaus AS2-protokollaan perustuva sanomanlähetys HTTP POST toimintoon ja sitä käytetään lähettämään sopivasti paketoituja EDI-sanomia, XML-dokumentteja tai muuta kauppatapahtuman aineistoa kauppakumppaneitten välillä. Lähetettyyn sanomaan saadaan vastaanottokuittaus sekä haluttaessa myös käsittelyilmoitus, jossa ilmoitetaan käsittelyn onnistumisesta tai mahdollisista havaituista ongelmista ja virheistä. Tämä kuittauspyyntö/kuittaus-toiminnot sisältävä sanomanvälitys voi sisältää turvallisen, luotettavan ja todennetun EDI-sanoman tai muun kauppatapahtuman tiedon kuljetuksen käyttäen HTTP-tiedonsiirtoprotokollaa ja sen suomia mahdollisuuksia käyttää allekirjoitusta ja sanomatiivisteitä. 2.2 AS2-sanoman välitys Tämä dokumentti sisältää määrittelyt ja ohjeet rakenteellista tietoa sisältämien sanomien siirtämiseksi turvallisesti Internetin HTTP-ympäristössä. Dokumentissa on esitetty yleisimmin siirrossa käytettävät tiedot. Mikäli jollakin suositusta käyttöönottavalla osapuolella on tarpeita käyttää siirrossa muitakin tietoja, löytyvät nämä dokumentista RFC 4229 - HTTP Header Field Registrations. Sanomien turvallisessa siirtosilmukassa organisaatio lähettää allekirjoitetun ja salakirjoitetun lähetyskerran toiselle organisaatiolle ja pyytää allekirjoitettua vastaanottokuittausta. Myöhemmin vastaanottava organisaatio lähettää allekirjoitetun käsittelyilmoituksen alkuperäisen sanoman lähettäjälle. Toisin sanoen tapahtuu seuraavaa: Organisaatio, joka lähettää alkuperäisen sanoman, allekirjoittaa ja salakirjoittaa sanoman käyttäen S/MIME-tekniikkaa. Lisäksi sanoma voi sisältää pyynnön allekirjoitetun käsittelyilmoituksen lähettämisestä alkuperäisen sanoman lähettäjälle. Tukeakseen käsittelyilmoituksen hyväksymistä eli NRRää, alkuperäisen sanoman lähettäjä säilyttää sanoman tunnistetiedot, sanomantunnisteen ja tiivistearvon (MIC). Vastaanottava organisaatio purkaa salakirjoituksen ja tarkistaa allekirjoituksen saadakseen selville sanoman eheyden ja lähettäjän oikeellisuuden. Vastaanottava organisaatio lähettää tämän jälkeen käsittelyilmoituksen alkuperäisen sanoman lähettäneelle organisaatiolle käyttäen HTTP-kuittausta tai erillistä HTTP POST-sanomaa. Tämä allekirjoitettu käsittelyilmoitus sisältää vastaanotetun sanoman tiivisteen antaen alkuperäisen sanoman lähettäjälle varmuuden siitä, että vastaanottaja oli vastaanottanut sanoman varmentaen sen ja purkaen sen salakirjoituksen auki oikein. Edellä esitetty kuvaa toiminnallisesti sen, että jos kaikki edellä esitettyjä piirteitä käytetään, sanoman lähetys täyttää kaikki turvallisuusvaatimukset ja käyttää siirron vastaanoton hyväksymisilmoitusta. Tämä määrittely kuitenkin jättää käyttäjille mahdollisuuden päättää siitä tasosta, jolla he haluavat käyttää turvallisuuspiirteitä kauppakumppaneittensa kanssa. 6/46

3 AS2-sanoman rakenne 3.1 HTTP-sanomatyypit HTTP-sanomia on kahta eri tyyppiä: Request (Kuittauspyyntö) ja Response (Vastaus). Asiakaskone lähettää Request-sanoman palvelimelle ja palvelin lähettää asiakaskoneelle Response-sanoman. Kumpikin näistä sanomista sisältää aloitusrivin (start-line), nolla tai useamman otsikkotiedon (header tai header field) sekä lopuksi tyhjän rivin, jolla ilmaistaan otsikkotietojen loppuminen. Tämän jälkeen seuraa mahdollisesti sanoman runko (message-body). Aloitusrivi voi olla joko kuittauspyyntörivi (request-line) tai tilarivi (status-line). Kuittauspyyntörivillä lähetetään kauppatapahtuman tietoja sisältävä AS2-sanoma. Tilarivillä alkava sanoma on tämän sanoman vastaanottokuittaus, joka synkronisessa tiedonsiirrossa sisältää myös alkupeäisen sanoman käsittelytiedot. Asynkronisessa yhteydessä tilarivillä alkavan vastaussanoman jälkeen lähetetään erillinen kuittauspyyntörivillä alkava käsittelyilmoitus, On kuitenkin huomattava, että jos ennen aloitusriviä (start-line) tulee tyhjärivi, siis pelkkä CRLF, on tällainen tyhjä rivi jätettävä huomioimatta sanoman käsittelyssä. Kuittauspyyntörivillä alkavan sanoman yleinen rakenne on siis muotoa: kuittauspyyntörivi otsikkotiedot tyhjä rivi sanoman runko. Tilarivillä alkavan sanoman yleinen rakenne on puolestaan: tilarivi otsikkotiedot tyhjä rivi sanoman runko. 3.2 Otsikkotietojen tyypit ja rakenne HTTP-sanoman otsikkotiedot jakaantuvat viiteen eri ryhmään: MINE-otsikkotiedot yleiset otsikkotiedot (general-header) kuittauspyynnön otsikkotiedot (request-header) vastauksen otsikkotiedot (response-header) sisällön otsikkotiedot (entity-header). Jokainen otsikkotieto on muotoa: otsikkotiedon nimi: otsikkotiedon arvo Otsikkotiedot ovat merkkisidonnaisia ja otsikkotiedon arvoa voi edeltää yksi tai useampi välilyönti. Kuitenkin ainakin yksi välilyönti on suositeltava. Jos otsikkotiedon arvon merkkimäärä on sellainen, ettei se sovi yhdelle riville, voidaan sitä jatkaa useammalle seuraavalle riville. Tällainen jatkorivi alkaa aina välilyönnillä tai tabulointimerkillä. Otsikkotieto rivi voi olla esimerkiksi: Date: Wed, 14 Mar 2007 12:15:37 GMT missä 7/46

Date Wed, 14 Mar 2007 12:15:37 GMT on otsikkotiedon nimi on otsikkotiedon arvo. Otsikkotietojen keskinäinen järjestys on vapaa, mutta on suositeltavaa, että yleiset otsikkotiedot esitetään ensin. Tämän jälkeen esitetään kuittauspyynnön tai vastauksen otsikkotiedot ja viimeisenä sisällön otsikkotiedot. Samassa sanomassa voi olla useita samannimisiä otsikkotietoja. Tällöin on suositeltavaa, että näiden otsikkotietojen arvot kerätään yhteen ja esitetään yhden ja saman ensimmäisenä sanomassa esiintyvän otsikkotiedon arvona pilkuilla erotettuna. Tällöin otsikkotiedon arvojen järjestys on merkitsevä ja vastaanottavan järjestelmän on säilytettävä tietojen järjestys. 8/46

4 Tiedoston siirto AS2-sanomana Tässä kappaleessa esitetään kuittauspyyntösanoman rakenne sekä sen eri osissa esiintyvät yleisimmin välitettävät tiedot. Harvemmin välitettävät tiedot on esitelty lähdeluettelossa olevissa RFC-dokumenteissa. Dokumentissa RFC 4229 HTTP Header Field Registrations on listattu otsikkotiedot sekä esitetty RFC-dokumentti, josta kyseisen tiedon kuvaus löytyy. Tiedot on esitetty ryhmiteltynä otsikkotietotyypin mukaan aakkosjärjestyksessä. 4.1 Kuittauspyyntösanoma Kuittauspyyntösanoma yleinen muoto on: kuittauspyyntörivi MIME-otsikkotiedot yleiset tiedot kuittauspyyntötiedot entiteettitiedot käsittelyilmoituksen määrittelytiedot AS2-ominaiset tiedot tyhjä rivi sanoman runko 4.2 Kuittauspyyntörivi Kuittauspyyntösanoma ensimmäisellä rivillä, siis kuittauspyyntörivillä, esitetään tiedonsiirtoprotokolla, siis HTTP, ja sen versionumero /-merkillä erotettuna. Rivi on siis muotoa: HTTP/1.1 On huomattava, että versionumero koostuu kahdesta osasta, joissa kumpikin on juokseva. Täten versio 2.4 on aiempi kuin versio 2.13, joka puolestaan on aiempi kuin versio 12.3. AS2-kuittaussanoma alkaa kuittauspyyntörivillä, joka on muotoa: POST Request-URI / HTTP/1.1 Kuittauspyyntösanoman lähettävän osapuolen Internet-osoitetta eli Request-URI-tietoa ei tavallisesti lähetetä AS2-sanomassa, koska se yleensä ilmoitetaan kauppakumppanien välisessä tiedonsiirtosopimuksessa. Rivi on siis tavallisesti muodossa: POST / HTTP/1.1 4.3 MIME-otsikkotiedot 4.3.1 Content-Disposition Tiedolla Content-Disposition esitetään sanoman vastaanottajalle tieto, miten sanoman liitteenä olevat tiedot on käsiteltävä. Tieto on muotoa: Content-Disposition: tyyppi; parametrit Lähetettäessä AS2-sanomia Content-Disposition-tiedon tyyppi-parametri saa aina arvon Attachment. Muista parametriarvoista käytetään AS2-sanomassa yleensä vain arvoa filename, jolloin parametri on muotoa: filename = tiedoston nimi 9/46

Täten tieto Content-Disposition on AS2-sanomassa muotoa: Content-Disposition: Attachment; filename = tiedoston nimi. Parametrin filename arvona sanoman lähettäjä ehdottaa tiedoston nimen, jonka nimisen tiedoston sisällöksi sanoman vastaanottaja tallettaa AS2-sanoman entiteetin sisällön. On kuitenkin huomattava, että sanoman vastaanottajan ei tarvitse käyttää ehdotettua nimeä, sillä nimen on oltava sopusoinnussa vastaanottajan järjestelmien hyväksymien tiedostonimien kanssa muodoltaan, pituudeltaan ja sisällöltään. Tämä tieto voi olla esimerkiksi muotoa: Content-Disposition: Attachment; filename=rfc1767.dat 4.3.2 Content-Transfer-Encoding Tällä tiedolla ilmoitetaan AS2-sanoman sisältökoodaus. Koska HTTP pystyy käsittelemään binäärimuotoista tietoa, tämä tieto ei ole pakollinen, mutta se voidaan välittää. Jos tätä tietoa ei sisälly sanomaan, ei sen puuttuminen saa aiheuttaa vastaanottajan järjestelmissä sanoman hylkäämistä. AS2-sanomissa myös MIME runko-osien koodaus on sallittua. Content-Transfer-Encoding-tieto on muotoa: Content-Transfer-Encoding: mekanismi missä mekanismi saa arvon binary tai 8bit. Tämä tieto voi olla esimerkiksi muodossa: Content-Transfer-Encoding: binary 4.3.3 MIME-Version MIME on lyhenne sanoista Multipurpose Internet Mail Extension. Se on protokolla, joka määrittää, miten viestit lähetetään Internetissä. MIME-protokollaa käytetään esimerkiksi kuvattaessa liitteiden kuvaustapaa ja sitä, millaista tietoa ne sisältävät. Varsinaisista MIME-otsikkotiedoista on esitettävä MIME-Version-tieto, jolla vastaanottavalle järjestelmälle ilmoitetaan Internet-sanoman rungon muotostandardin versio. Tämä tieto on muotoa: MIME-Version: versionumero missä versionumero on muoto N.N, missä N on kokonaisluku. Tämä tieto on esimerkiksi muotoa: MIME-Version: 1.0 4.4 Kuittauspyyntösanoman yleiset tiedot Kuittauspyyntösanoman yleisissä tiedoissa esitetään mm. sanoman luontiajankohta tiedon Date-arvona ja tieto yhteyden ylläpidosta kuittauksen jälkeen Connection-tiedolla. Kuittauspyyntösanoman yleisissä tiedoissa voidaan esittää myös muita tietoja, jotka on esitetty RFC 2616 dokumentin luvussa 4.5. Näiden käyttö kuittauspyyntösanomassa on kuitenkin harvinaista, joten niitä ei esitellä tässä dokumentissa. 4.4.1 Connection Tällä tiedolla kuittauspyynnön lähettäjä esittää tiedon yhteyden jatkumisen laadusta kuittauspyynnön käsittelyn ja kuittauksen lähetyksen jälkeen. Tieto on muotoa: Connection: yhteysmäärittelyt missä yhteysmäärittelyt-parametri sisältää yhden tai useamman määrittelyn yhteyden jatkuvuudelle. On kuitenkin huomattava, että lähetettäessä kuittauspyyntöä proxyn on poistettava kuittauspyyntösanomasta kaikki ne Connection-tietojen toistot, joissa on sama 10/46

yhteysmäärittely, niin ettei lähetettävässä sanomassa esiinny yhteysmäärittelyn toistoja. Yhteysmäärittelyn arvolla close kuittauspyyntösanoman lähettäjä ilmoittaa vastaanottajalle, että yhteys on suljettava kuittauksen lähettämisen jälkeen. Connectiontieto on tällöin muotoa: Connection: close. On huomattava, että sellaisten sovellusten, jotka eivät tue jatkuvaa yhteyttä, on lisättävä edellä esitetty tieto kuittauspyyntösanomaan. 4.4.2 Date Date-tiedon arvo ilmoittaa ajankohdan, jolloin sanoman luoja on päättänyt sanoman muodostuksen siten, että se on valmis lähetettäväksi. Tämä tieto on pakollinen Internetsanomissa. Tämä tieto on muotoa: Date: viikonpäivä päivämäärä kellonaika GTM Jos viikonpäivä on ilmoitettu sen englanninkielisen nimen kolmen ensimmäisen kirjaimen avulla eli muodossa: Viikonpäivän lyhenne Englanninkielinen nimi Suomenkielinen nimi Mon Monday maanantai Tue Tueday tiistai Wed Wednesday keskiviikko Thu Thursday torstai Fri Friday perjantai Sat Saturday lauantai Sun Sunday sunnuntai on päivämäärä muotoa: päivä kuukausi vuosi missä päivä on ilmoitettu kahdella numerolla, siis muodossa 09 tai 21, kuukausi on kuukauden englanninkielisen nimen kolme ensimmäistä kirjainta seuraavasti: Kuukauden lyhenne Englanninkielinen nimi Suomenkielinen nimi Jan January tammikuu Feb February helmikuu 11/46

Mar March maaliskuu Apr April huhtikuu May May toukokuu Jun June kesäkuu Jul July heinäkuu Aug August elokuu Sep September syyskuu Oct October lokakuu Nov November marraskuu Dec December joulukuu vuosi on ilmoitettu joko nelinumeroisena, siis muodossa 2007. Kellonaika esitetään muodossa: tunnit:minuutit:sekunnit missä kaikki tiedot ovat kaksinumeroisia. Aika annetaan aina Greenwichin ajassa, eli aika tiedon jälkeen on merkintä GTM. Aikatieto on tällöin esimerkiksi: Date: Wed, 14 Mar 2007 12:15:37 GMT Jos viikonpäivä on ilmoitettu käyttäen sen englanninkielisiä kokonaisia nimiä eikä lyhenteitä eli muodossa: Englanninkielinen nimi Monday Tueday Suomenkielinen nimi maanantai tiistai Wednesday keskiviikko Thursday Friday Saturday Sunday torstai perjantai lauantai sunnuntai 12/46

on päivämäärä muotoa: päivä-kuukausi-vuosi missä päivä on ilmoitettu kahdella numerolla, siis muodossa 09 tai 21, ja kuukausi on kuukauden englanninkielisen nimen kolme ensimmäistä kirjainta seuraavasti: Kuukauden lyhenne Englanninkielinen nimi Suomenkielinen nimi Jan January tammikuu Feb February helmikuu Mar March maaliskuu Apr April huhtikuu May May toukokuu Jun June kesäkuu Jul July heinäkuu Aug August elokuu Sep September syyskuu Oct October lokakuu Nov November marraskuu Dec December joulukuu Vuosi on ilmoitettu joko kaksinumeroisena, siis muodossa 07. Kellonaika esitetään muodossa: tunnit:minuutit:sekunnit missä kaikki tiedot ovat kaksinumeroisia. Aika annetaan aina Greenwichin ajassa, eli aika tiedon jälkeen on merkintä GTM. Aikatieto on tällöin esimerkiksi: Date: Wednesday, 14-Mar-07 12:15:37 GMT 4.4.3 Via Yhdyskäytävien ja proxeien on käytettävä Via-tietoa ilmaistakseen muuntimien ja palvelimien välillä käytetyt protokollat ja vastaanottajat lähetettäessä kuittauspyyntöä sekä alkuperäisen palvelimen ja asiakaskoneen välillä käytetyt protokollat ja vastaanottajat siirrettäessä käsittelyilmoituksia. Tällä tiedolla voidaan jäljittää eteenpäin toimitettu sanoma, estää silmukoiden muodostuminen sekä määrittelemällä kaikkien lähettäjien protokolla-mahdollisuudet kuittauspyyntö-vastaus-ketjussa. Tieto on muotoa Via: protokolla nimet/protokolla-versio isäntäkone: portti nimimerkki huomautukset 13/46

Protokollan nimellä ja versionumerolla ilmaistaan sanoman protokollan versio, jonka sanoman lähettäjä tai asiakaskone saa jossakin kuittauspyyntö-vastaus-ketjun vaiheessa. Protokollan nimi ja versio liitetään Via-tiedon arvoksi, kun sanoma on toimitettu eteenpäin, niin että tieto käytetyistä protokollista välittyy edelleen ketjun seuraaville osapuolille. Protokollan nimi on valinnainen jos ja vain jos se on HTTP. Isäntäkoneella ja valinnaisella portilla tarkoitetaan vastaanottajan palvelinta tai asiakaskonetta ja sen porttia, jotka toimittivat sanoman eteenpäin. Kuitenkin, jos todellisen isäntäkoneen katsotaan olevan luottamuksellista tietoa, voidaan tästä käyttää myös nimimerkkiä. Jos porttia ei esitetä, oletetaan sen olevan oletusarvoinen. Useat Via-tiedon arvot kertovat reitin, jota pitkin sanomaa on siirretty eteenpäin. Jokaisen vastaanottajan on täten liitettävä tietonsa siten, että lopputuloksena on järjestetty jono sovelluksia, jotka ovat siirtäneet sanomaa eteenpäin. Via-tiedossa voidaan myös esittää vapaavalintaisia huomautuksia määritellen yhdyskäytävän tai proxyn käyttämän sovelluksen. Tällaisen tiedon kuitenkin ketjun seuraava vastaanottaja poistaa sanomasta, ennen kuin hän siirtää sanoman eteenpäin. Oletetaan esimerkiksi, että kuittauspyyntösanoma voidaan lähettää HTTP/1.0-protokollaa käyttävältä palvelimelta sisäiselle proxylle, jonka nimi on matti, joka puolestaan käyttää HTTP/1.1-protokollaa siirtäessään sanomaa edelleen julkiselle proxylle osoitteessa jossain.com. Tämä puolestaan siirtää sanoman edelleen palvelimelle, joka on osoitteessa www.eka.kone.com. Täten www.eka.kone.com saa vastaanottamassaan sanomassa Viatiedon: Via: 1.0 matti, 1.1 jossain.com 4.5 Kuittauspyyntösanoman kuittauspyyntötiedot Kuittauspyyntötiedoilla asiakaskone lähettää kuittauspyyntöön liittyvää lisätietoa kuittauspyynnöstä sekä asiakaskoneesta yleensä. Seuraavassa on esitetty AS2- Kuittauspyyntösanomassa yleisimmin esiintyvät tiedot. Muut tiedot on esitetty RFC 2616 dokumentin luvussa 5.3. Näiden käyttö kuittauspyyntösanomassa on kuitenkin harvinaista, joten niitä ei esitellä tässä dokumentissa. 4.5.1 Accept-Encoding Tiedolla Accept-Encoding alkuperäisen sanoman lähettäjä ilmoittaa vastauksessa käytettävät hyväksyttävät sisältökoodausmenetelmät. Tieto on muotoa: Accept-Encoding: sisältökoodaus;q=q-arvo missä parametripari sisältökoodaus ja q voi esiintyä useita kertoja. Parametrin q q- arvo ilmaisee kyseisen sisältökoodausmenetelmän tärkeyden ja se saa arvoja väliltä [0,1]. Arvo 1 ilmaisee, että kyseinen koodausmenetelmä on mahdollisimman tärkeä ja arvo 0 puolestaan ilmaisee yleensä, ettei asiakaskone hyväksy kyseistä koodausmenetelmää. Tieto voi olla esimerkiksi jokin seuraavista: Accept-Encoding: compress, gzip Accept-Encoding: Accept-Encoding: * Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: gzip;q=1.0, identity;q=0.5, *;q=0 Vastaanottajan palvelin testaa sisällön koodauksen hyväksyttävyyden Accept-Encodingtiedossa esitettyjen vaihtoehtojen mukaan seuraavasti: Jos tietty koodausmenetelmä on esitetty Accept-Encoding-tiedon arvona, se on hyväksyttävä, vaikka sen q-arvo olisikin 0. 14/46

Jos Accept-Encoding-tieto saa arvon *, hyväksyy asiakaskone minkä tahansa koodausmenetelmän. Jos Accept-Encoding-tiedon arvona on useita koodausmenetelmiä, on menetelmä, jonka q-arvo on korkein, suositeltavin. Koodausmenetelmä identity on aina hyväksyttävä, vaikka parametri-listassa se saisikin q-arvon 0. tai vaikka Accept-Encoding-tieto saisi arvon *;q=0 Jos Accept- Encoding-tieto ei saa arvoa eli sanomassa on merkkijono Accept-Encoding: identity on ainoa hyväksyttävä koodausmenetelmä. Jos alkuperäisessä sanomassa esiintyy Accept-Encoding-tiedon arvona koodausmenetelmä, jota vastaanottava palvelin ei voi toteuttaa, on palvelimen lähetettävä käsittelyilmoituksen tilarivillä tilakoodi 406 (Not Acceptable). Jos alkuperäisessä sanomassa ei esiinnyt Accept-Encoding-tietoa, käsittelyilmoituksen lähettävä palvelin voi olettaa, että palvelinkone hyväksyy minkä tahansa koodausmenetelmän. Tällöin palvelimen on käytettävä identity -koodausmenetelmää, jos se on yksi käytössä olevista menetelmistä, vaikkakin palvelimella olisi tietoa siitä, että joku toinen koodausmenetelmä olisi käyttökelpoisempi asiakaskoneen kannalta. 4.5.2 Comment Tiedolla Comment sanoman lähettäjä voi välittää vastaanottajalle vapaamuotoista tekstiä sanomasta, sen sisällöstä, käsittelystä tai muusta sanoman kannalta oleelliseksi katsomastaan asiasta. Tieto on tarkoitettu vastaanottajan luettavaksi ja se esitetään muodossa: Comment: vapaamuotoinen teksti Tämä tieto voi olla esimerkiksi muodossa: Comment: Oletettavasti vastaanottava muunnin ei ole täysin pystynyt käsittelemään sanomaa 4.5.3 From From-tiedolla ilmoitetaan kuittauspyyntösanoman lähettäneen henkilön tai organisaation sähköpostiosoitemuodossa ja se on pakollinen Internet-sanomissa. Tätä tietoa käytetään tiedonkeruutarkoituksissa sekä tunnistettaessa puutteellisen tai epätoivotun kuittauspyynnön lähettäjä. Tämä tieto, joka yleensä lisätään sanomaan automaattisesti, ilmoittaa henkilön, johon ongelmatilanteissa voidaan ottaa yhteys. On kuitenkin huomattava, että tämä tieto ei ole sama kuin kuittauspyyntösanoman lähettävä Internetisäntäkone. On kuitenkin huomattava, ettei kuittauspyyntösanomaan pidä lisätä henkilön sähköpostiosoitetta kysymättä hänen lupaansa. From-tieto on muotoa From: sähköpostiosoite Esimerkiksi: From: milla.malli@example.com 4.5.4 Host Host-tieto on pakollinen tieto ja sillä ilmoitetaan isäntäkoneen osoite ja portti. Tieto on muotoa: Host: isäntäkoneen osoite:portti Portin ilmoittava osa on valinnainen. Jos tätä tietoa ei esitetä, on portin arvona sen oletusarvo. Esimerkiksi: Host: 10.234.160.12:80 15/46

missä 10.234.160.12 on isäntäkoneen IP-osoite 80 on portti. 4.5.5 Message-Id Message-Id-tieto sisältää sanoman yksikäsitteisen tunnisteen, jolla voidaan viitata sanoman tiettyyn versioon. Sanoman jokainen versio saa täten oman tunnuksensa. Sanoman luovan järjestelmän on täten kyettävä muodostamaan sanomille yksikäsitteiset tunnukset. Tämä tunnus on tarkoitettu koneelliseen käsittelyyn eikä tunnuksen tarvitse näin ollen olla henkilön luettavassa muodossa. Message-Id-tiedon maksimipituus on 998 merkkiä. Kuitenkin maksimaalisen takaisinpäin yhteensopivuuden vuoksi pituuden on oltava maksimissaan 255 merkkiä. Tieto on muotoa Message-Id: <vasen-id@oikea-id> Tunnus asetetaan siis kulmasulkujen < ja > väliin. Kulmasulut eivät kuulu varsinaiseen tunnisteeseen. Tieto voi olla esimerkiksi: Message-Id: <200207310834482A70BF63@esimerkki.fi> 4.5.6 Received Received-tieto liitetään mukaan sanomaan, kun sitä siirretään yhdyskäytävien kautta tai sitä toimitetaan edelleen tai kun alkuperäiseen sanomaan lähetetään käsittelyilmoitus. Tätä tietoa voidaan käyttää esimerkiksi sanoman jäljittämisessä. Received-tieto saa erilaisia parametreja, joiden mukaan ilmaistaan sanoman siirtoketjun eri osapuolia ja vastaanottoaika. Tieto on muotoa: Received: rooli tunnus; viikonpäivä päivämäärä kellonaika GTM missä parametripari rooli ja tunnus voi toistua useita kertoja ilmoittaen sanoman reitin. Puolipisteen jälkeen ilmoitetaan sanoman vastaanottoajankohta ja tämä ajanilmaus on Date-tiedon yhteydessä esitetyn määrittelyn mukainen. Parametripari rooli ja tunnus saa seuraavia arvoja: rooli tunnus selite from nimipalvelin lähettävä isäntäkone by nimipalvelin vastaanottava isäntäkone via fyysinen polku sanoman siirtotie with protokolla käytetyt protokollat id sanoman tunnus vastaanottajan sanoman tunnus for sähköpostiosoite vastaanottajan sähköpostiosoite Tämä tieto voi esimerkiksi olla seuraavaa muotoa: Received: from n12c.bullet.sp1.yahoo.com (n12c.bullet.sp1.yahoo.com [69.147.64.111]) by mail1.esimerkki.fi (Postfix) with SMTP id DC94C63AF4 for <mikko.mallikas@esimerkki.fi>; Sun, 18 Mar 2007 21:22:30 +0200 GTM 16/46

4.5.7 Return-Path Järjestelmä, joka toimittaa kuittauspyyntösanoman sen vastaanottajalle, lisää sanomaan tiedon Return-Path. Tämän tiedon tarkoituksena on antaa sanoman vastaanottajalle tarpeellinen tieto sanoman lähettäjästä, kuittaussanoman palautusosoitteestaan ja vastaussanoman reitityksestä. Tieto on muotoa: Return-Path: reititysosoite; palautusosoite Edellä esitetyssä reititysosoite on valinnainen, mutta sen käyttö on suotavaa. Tieto voi olla esimerkiksi muotoa: Return-Path: AS2@example.com 4.5.8 Subject Tieto Subject, jolla ilmoitetaan sanoman aihe tai sisältö, on valinnainen. Tämä tieto on tarkoitettu käyttäjän luettavaksi, joten sen on oltava looginen esittäen sanoman sisältöä tai aihetta käyttäjän luettavassa muodossa. Tieto on muoto: Subject: sisältöä tai aihetta kuvaava teksti Esimerkki: Subject: Asynkroninen käsittelyilmoituspyyntö 4.5.9 TE TE-otsikkotiedolla alkuperäisen sanoman lähettäjä ilmaisee vastauksessa hyväksyttävät siirtokoodausmenetelmät sekä halukkuutensa ottaa vastaa lopuketietoja viipaloidussa siirtokoodauksessa. Tämä tieto on muotoa TE: trailers, siirtokoodusmenetelmä; ;q=q-arvo missä parametripari siirtokoodausmenetelmä ja q voi esiintyä useita kertoja. Parametrin q q-arvo ilmaisee kyseisen siirtokoodausvaihtoehdon tärkeyden ja se saa arvoja väliltä [0,1]. Arvo 1 ilmaisee, että kyseinen koodausmenetelmä on mahdollisimman tärkeä ja arvo 0 puolestaan ilmaisee yleensä, ettei asiakaskone hyväksy kyseistä koodausmenetelmää. Jos tiedon saaman parametrijonon arvojen ensimmäisenä parametrina on trailers, asiakaskone hyväksyy lopukkeet viipaloidussa siirtokoodauksessa. Tieto voi olla esimerkiksi jokin seuraavista: TE: deflate TE: TE: trailers, deflate;q=0.5 TE-otsikkotietoa käytetään ainoastaan jatkuvissa yhteyksissä. Tämän vuoksi ilmoitus TEtiedon esiintymisestä HTTP/1.1-sanomassa on sisällytettävä myös Connection-tiedon arvoksi esimerkiksi seuraavasti: Connection: close, TE TE: trailers, deflate, gzip, compress Palvelin testaa siirtokoodausmenetelmän hyväksyttävyyden TE-tiedon mukaan seuraavasti: Siirtokoodausmenetelmä chunked on aina hyväksyttävä. Jos arvo trailers esiintyy parametrin arvona, palvelinkone ilmaisee, että se on valmis hyväksymään lopuketiedot viipaloidussa vastauksessa itselleen ja kaikille asiakaskoneille, joille se siirtää sanomaa. Vaikka siirtokoodausmenetelmän q-arvo olisi asetettu nollaksi, on se kuitenkin hyväksyttävä siirtokoodausmenetelmäksi, koska se esiintyy TE-tiedon arvona. 17/46

Jos TE-tieto sisältää useita siirtokoodausmenetelmiä, on menetelmä, jonka q-arvo on suurin, suositeltavin. Jos TE-tieto ei saa arvoja tai sitä ei esiinny, ainoa hyväksyttävä siirtokoodausmenetelmä on chunked. Sanoma, jota ei ole siirtokoodattu, on aina hyväksyttävä. 4.5.10 To To-tieto ilmoittaa sanoman pääasiallisen vastaanottajan ja se on muotoa: To: sähköpostiosoite Esimerkiksi: To: mikko.mallikas@esimerkki.fi On huomattava, että sanomaan lähetetyssä vastauksessa To-tiedon arvona on yleensä alkuperäisen sanoman From-tiedon arvo. Dokumentissa RFC 2822 kappaleessa 3.6.3 on esitetty To-tiedon käyttö. 4.5.11 User-Agent User-Agent-tieto ilmaisee selaimen, joka on luonut vastauspyynnön. Tätä tietoa voidaan käyttää hyväksi selvitettäessä sanomassa havaittuja vikoja tai puutteita tai muotoiltaessa vastaussanomaa niin, että se täyttää alkuperäisen lähettäjän sovelluksen vaatimukset. Selaimen on lisättävä pyydettäessä tämä tieto kuittauspyyntösanomaan. Sen rakenne on seuraava: User-Agent: selaimen nimi kommentit missä sovelluksen nimi sisältää sovelluksen nimen, alanimen ja versionumerot sekä muut tuotteen tunnistamiseen tarvittavat tiedot /-merkillä erotettuna. kommentit -osa sisältää selaimen tunnistamiseen liittyvää muuta tietoa. User-Agent-tieto on esimerkiksi seuraavaa muotoa: User-Agent: AS2 Software/Professional/1.01 otettu käyttöön 1.2.2007 Kuittauspyyntösanoman kuittauspyyntötiedoissa voidaan esittää myös muita tietoja, jotka on esitetty RFC 2616 dokumentin luvussa 5.3. Näiden käyttö kuittauspyyntösanomassa on kuitenkin harvinaista, joten niitä ei esitellä tässä dokumentissa. 4.6 Kuittauspyyntösanoman entiteettitiedot Kuittauspyyntösanomalla voidaan välittää entiteetti, jos kuittauspyyntö-mekanismi ei sitä rajoita. Entiteetti koostuu entiteettitiedoista ja varsinaisesta entiteettirungosta. 4.6.1 Content-Length Content-Length tieto ilmaisee entiteettirungon koon. Toisin kuin MIME-määrittelyissä, Content-Length tieto on välitettävä, jos se voidaan laskea ennen sanoman lähettämistä. Tieto on muotoa: Content-Length: entiteettirungon koko missä entiteettirungon koko on kokoa ilmoittava lukuarvo, joka on suurempi tai yhtä suuri kuin nolla. Tieto voi olla esimerkiksi muotoa: Content-Length: 1234 18/46

On kuitenkin huomattava, että Content-Length tieto esittää sekä entiteetin pituutta että sanoman rungon pituuden ilmaisevan siirto-pituuden (transfer-length). Jos nämä kaksi tietoa poikkeavat toisistaan, jätetään Content-Length tieto välittämättä. Jos kuitenkin kuittauspyyntösanoma sisältää sanoman rungon eikä Content-Length tietoa ole annettu, kuittaussanomassa palautetaan virheilmoituskoodi. 4.6.2 Content-Type Entiteettitieto Content-Type ilmaisee entiteettirungon tyypin. Tieto on muotoa: Content-Type: mediatyyppi missä mediatyyppi on muotoa: tyyppi/alatyyppi; parametrit missä parametrit esitetään muodossa: attribuutti= arvo Parametrit tyypit ja alatyypit sekä parametrien attribuuttien nimet eivät ole merkkisidonnaisia, mutta tietyissä tilanteissa parametrien attribuuttien arvot voivat olla merkkisidonnaisia. Tyypin ja alatyypin erottimena on /-merkki ilman välilyöntejä. Parametritiedon mukanaolo riippuu valitusta mediatyypistä ja sen määrittelystä. IANA Internet Assigned Numbers Authority pitää yllä mediatyyppien tyyppi- ja alatyyppirekisteriä. IANAn määrittelemiä mediatyyppien tyyppejä ovat: application, audio, example, image, message, model, multipart, text, video. Jokaiseen tyyppiin liittyy IANAn määrittelemät alatyypit. Tieto voi esimerkiksi olla siis muotoa: Content-Type: multipart/signed; boundary= as2boundary1as2 ; protocol="application/pkcs7-signature"; micalg=sha1 tai Content-Type: application/xml 4.7 Käsittelyilmoituksen määrittelytiedot Jotta sanoman vastaanottaja voisi lähettää käsittelyilmoituksen, on kuittauspyyntösanoman lähettäjän määriteltävä, minne käsittelyilmoitus lähetetään ja minkälaisessa muodossa. Tämä tapahtuu liittämällä kuittauspyyntösanomaan tiedot Disposition-Notification-To ja Disposition-Notification-Options. 4.7.1 Disposition-Notification-To Tiedolla Disposition-Notification-To AS2-sanoman lähettäjä ilmoittaa haluavansa AS2- sanoman käsittelyilmoituksen (MDN). Tämä tieto on muotoa: Disposition-Notification-To: sähköpostiosoite Tieto on esimerkiksi muotoa: Disposition-Notification-To: AS2@example.com On kuitenkin huomattava, ettei käsittelyilmoitusta lähetetä sähköposti-osoitteeseen, joka on esitetty tiedon arvona. Saapuneessa sanomassa oleva tieto ainoastaan käynnistää käsittelyilmoituksen muodostamisen. Lähetettäessä sanomalla tämä tieto, on siinä oltava myös tieto Message-Id. Tätä tietoa tarvitaan lähetettäessä käsittelyilmoitus alkuperäisen sanoman lähettäjälle ja tämän 19/46

verratessa ilmoituksen tietoja alkuperäisen sanoman tietoihin. Lähetettävässä sanomassa on suositeltavaa olla myös tiedot Subject ja Date, jotka sisältävät käyttäjän luettavissa olevaa tietoa. Näiden tietojen perusteella käyttäjä voi liittää saapuneen käsittelyilmoituksen (MDN) tiedot alkuperäiseen sanomaan. On kuitenkin huomattava, että kuittauspyyntösanoman vastaanottajan ei välttämättä tarvitse lähettää käsittelyilmoitusta, vaikka kuittauspyyntö-sanomassa esiintyisikin tieto Disposition-Notification-To. Käsittelyilmoitus ei saa sisältää tietoa Disposition-Notification-To, sillä käsittelyilmoitukseen ei lähetetä enää käsittelyilmoitusta. On huomattava, että jos alkuperäisen sanoman lähettäjän on lähetettävä sama sanoma useammalle osapuolelle ja osalta vastaanottajista halutaan käsittelyilmoitus ja osalta ei haluta, on sanomasta tehtävä kopio, jossa ei esiinny Disposition-Notification-To tietoa. On myös huomattava, että tämän tiedon on oltava sama, kuin Return-Path-tieto. Jos Disposition-Notification-To tieto poikkeaa Return-Path tiedosta, ei käsittelyilmoitusta voida lähettää automaattisesti vaan käsittelyilmoituksen lähettämiseen on saatava käyttäjän vahvistus. 4.7.2 Disposition-Notification-Options Kun alkuperäisen sanoman lähettäjä haluaa asynkronisen käsittelyilmoituksen, on alkuperäisessä sanomassa esiinnyttävä tieto Disposition-Notification-Options. On huomattava, ettei tätä tietoa esitetä, jos alkuperäisen sanoman lähettäjä haluaa synkronisen käsittelyilmoituksen. Tällä tiedolla käsittelyilmoituksen vastaanottaja eli alkuperäisen sanoman lähettäjä esittää myös toiveensa käsittelyilmoituksen muodosta. Tieto on muotoa: Disposition-Notification-Options: palautus-url; attribuutti = pakollisuus; arvo missä parametri palautus-url on Internet-osoite, johon käsittelyilmoitus halutaan lähetettävän. Attribuutin arvo pakollisuus saa arvot: required optional Attribuutti saa arvot: pakollinen valinnainen. signed-receipt-protocol signed-receipt-micalg Näillä attribuuteilla siis ilmoitetaan allekirjoitusprotokolla ja hajakoodaus-algoritmin tyyppi. Kumpikin näistä attribuuteista on valinnaisia, joten pakollisuus saa arvon optional. Tällä attribuutin arvon valinnalla alkuperäisen sanoman vastaanottajalle annetaan mahdollisuus lähettää käsittelyilmoitus, vaikka tämä ei ymmärtäisikään esitettyjä attribuutin arvoja ja siten alkuperäisen sanoman lähettäjän toiveita käsittelyilmoituksen muodosta. Mikäli vastaanottaja ei ymmärrä attribuuttien arvoja, lähettää hän allekirjoittamattoman käsittelyilmoituksen, vaikka alkuperäisessä sanomassa pyydettiinkin allekirjoitettua sanomaa. Tällöin alkuperäisen sanoman vastaanottajan on tehtävä päätös, miten luotettavana hän voi pitää tällaista käsittelyilmoitusta. On kuitenkin huomatta, että haluttaessa allekirjoitettu käsittelyilmoitus, on näiden attribuuttien esiinnyttävä sanomassa. Jos tieto Disposition-Notification-Options puuttuu lähetettävästä sanomasta, halutaan synkroninen vastaanottokuittaus. Attribuutilla signed-receipt-protocol alkuperäisen sanoman lähettäjä ilmoittaa haluavansa allekirjoitetun käsittelyilmoituksen. Attribuutti myös ilmoittaa formaatin, missä 20/46

alkuperäisen sanoman lähettäjä haluaa allekirjoitetun ilmoituksen. Attribuutti saa arvon pkcs7-signiture. Attribuutti signed-receipt-micalg sisältää listan niistä hajakoodaus-algoritmeista, joita alkuperäisen sanoman lähettäjä suosittelee käytettäväksi. Hajakoodausalgoritmit on esitetty attribuutin arvoina suosituimmuus-järjestyksessä. Attribuutti saa arvon md5 ja/tai sha1 käytetystä algoritmista riippuen. Tieto Disposition-Notification-Options voi olla esimerkiksi muotoa: Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional,sha1 4.7.3 Receipt-Delivery-Option Tiedolla Receipt-Deliver-Option ilmaisee alkuperäisen sanoman lähettäjä haluavansa vastaanottaa asynkronisen käsittelyilmoituksen. Tieto on muotoa: Receipt-Delivery-Option: palautusosoite missä palautusosoite on Internet-osoite (URL), johon käsittelyilmoitus on lähetettävä. On huomattava, että haluttaessa sanomaan synkroninen käsittelyilmoitus, ei tätä tietoa pidä esiintyä sanomalla. Tämä tieto voi esiintyä sanomassa esimerkiksi muodossa: Receipt-Delivery-Option: http://www.example.com 4.8 AS2-ominaiset tiedot Tässä kappaleessa esitetyt tiedot esiintyvät ainoastaan AS2-sanomissa. 4.8.1 AS2-From Tiedolla AS2-From ilmoitetaan AS2-sanoman lähettäjä, ja tämän tiedon tarkoituksena on helpottaa vastaanottavaa järjestelmää tunnistamaan lähettäjä. Tämä tieto voi olla esimerkiksi DUNS-koodi tai kauppakumppanit ovat voineet sopia sen keskenään. Suomessa kyseinen tieto voi sisältää esimerkiksi sanoman lähettäjän OVT-tunnuksen. Tieto on muotoa: AS2-From: lähettäjän tunniste missä lähettäjän tunniste on maksimissaan 128 merkkiä. Tieto voi olla esimerkiksi seuraavassa muodossa: AS2-From: 003712345678123 Lähetettäessä kuittaussanoma tai käsittelyilmoitusta on alkuperäisessä sanomassa esiintyvän AS2-From-tiedon arvo AS2-To-tiedon arvona. 4.8.2 AS2-To Tiedolla AS2-To ilmoitetaan AS2-sanoman vastaanottaja. Tämän tiedon tarkoituksena on helpottaa vastaanottavaa järjestelmää tunnistamaan vastaanottaja. Kuten AS2-Fromtiedon arvo tämäkin tieto voi olla esimerkiksi DUNS-koodi tai kauppakumppanit ovat voineet sopia sen keskenään. Suomessa kyseinen tieto voi sisältää esimerkiksi sanoman lähettäjän OVT-tunnuksen. Tieto on muotoa: AS2-To: vastaanottajan tunniste missä vastaanottajan tunniste on maksimissaan 128 merkkiä. Tieto voi olla esimerkiksi seuraavassa muodossa: AS2-To: 00370123412312345 21/46

Lähetettäessä kuittaussanoma tai käsittelyilmoitusta on alkuperäisessä sanomassa esiintyvän AS2-To-tiedon arvo AS2-From-tiedon arvona. 4.8.3 AS2-Version Tiedolla AS2-Version ilmoitetaan käytetyn AS2-protokollan versio. Tieto on muotoa: AS2-Version: versionumero missä versionumero on muotoa N.N, missä N on kokonaisluku. Tällä hetkellä ovat käytössä versiot 1.0 ja 1.1. Tieto on esimerkiksi muotoa: AS2-Version: 1.1 Jos tämä tieto puuttuu kuittauspyyntösanomasta, on sanoman vastaanottavan järjestelmän lähetettävä kuittaussanoma tästä huolimatta. Tällöin kuittaussanoman vastaanottaja olettaa, että kuittauspyyntösanoma on lähetetty järjestelmästä, joka tukee AS2 1.0-versiota. 22/46

5 Käsittelyilmoitus 5.1 Yleisiä ohjeita Saadessaan sanoma vastaanottaja lähettää alkuperäisen sanoman lähettäjälle käsittelyilmoituksen (Message Disposition Notification (MDN)), mikäli sitä pyydetään alkuperäisessä sanomassa. vastaanottokuittauksen sanoman vastaanottaja lähettää automaattisesti ilman erityistä pyyntöä. Sanoman vastaanottajan on kyettävä toteuttamaan seuraavat vaatimukset: Pystyttävä luomaan sanoma, jonka otsikkotieto Content-Type saa arvon multipart/report ja jonka attribuutti report-type saa arvon disposition-notification. Mahdollisuus laskea saapuneesta sanomasta sanoman eheyden tunniste (MIC). Tämä tunniste on lähetettävä alkuperäisen sanoman lähettäjälle käsittelyilmoituksen mukana. Pystyttävä luomaan vastaussanoma, jonka otsikkotieto Content-Type saa arvon multipart/signed sen ensimmäisessä runko-osassa ja jonka toisessa runko-osassa on allekirjoitus. Mahdollisuus palauttaa allekirjoitettu käsittelyilmoitus alkuperäisen sanoman lähettäjälle Mahdollisuus lähettää joko synkrooninen tai asynkrooninen käsittelyilmoitus alkuperäisen sanoman lähettäjän toiveiden mukaan. Allekirjoitettu käsittelyilmoitus lähetetään alkuperäisen sanoman lähettäjälle tämän pyynnöstä osoituksena, että lähetyskerta on vastaanotettu vastaanottaja on todennut lähettäjän oikeutetuksi lähettämään sanomia, jos alkuperäinen sanoma on allekirjoitettu, vastaanottaja voi varmistua sanoman eheydestä, jos alkuperäinen sanoma on allekirjoitettu, Huolimatta siitä, onko alkuperäinen lähetyskerta lähetetty S/MIME-formaatissa, vastaanottajan selainjärjestelmän on pystyttävä suorittamaan seuraavat tehtävät: Jos alkuperäinen sanoma on salakirjoitettu, silloin salakirjoitettu symmetrinen avain ja mahdollisesti lähetetty alustusvektori (initialization vector (IV)) on purettava auki käyttäen vastaanottajan yksityistä avainta. Avattua symmetristä salakirjoitusavainta käytetään lähetyskerran salakirjoituksen purkamiseen. Vastaanottaja varmistaa sanoman allekirjoituksen käyttämällä lähettäjän julkista avainta. Varmistusalgoritmi suorittaa seuraavaa: o Sanoman eheyden tarkistin (MIC) avataan käyttäen lähettäjän julkista avainta. o Sanoman eheyden tunniste lasketaan vastaanotetusta sanomasta käyttäen o samaa tiivistealgoritmia kuin mitä alkuperäisen sanoman lähettäjäkin käytti. Sanoman eheyden tunnistetta (MIC), joka esiintyy lähetetyssä sanomassa, ja sanoman eheyden tunnistetta (MIC), joka on laskettu käyttäen samaa yksisuuntaista hajakoodausalgoritmia, jota alkuperäisen sanoman lähettäjäkin käytti, verrataan keskenään niiden yhtäläisyyden toteamiseksi. Vastaanottaja valmistelee käsittelyilmoituksen ja asettaa lasketun sanoman eheyden tunnisteen (MIC) tiedon Received-Content-MIC arvoksi. Vastaanottaja muodostaan MIME-sanoman, jonka Content-Type tieto saa arvon multipart/signed. Käsittelyilmoitus (MDN) on multipart/signed-tyyppiä olevan sanoman ensimmäinen osa ja digitaalinen allekirjoitus on laskettu tästä käsittelyilmoituksesta sisältäen MIMEsanoman otsikkotiedot. 23/46

Multipart/signed-tyyppiä olevan sanoman toinen osa sisältää digitaalisen allekirjoituksen. Tässä osassa määritellään protokollan tyyppi seuraavasti: S/MIME: protocol = application/pkcs-7-signiture Allekirjoitus muodostetaan S/MIME-määritysten mukaan. Siirrettäessä XML-, EDIFACT- tai muuta rakenteellista tietoa voi näiden sanomien otsikkotiedot olla osa multi-part-muotoisen MIME-sanoman content-type-tietoa. Kun tällainen sanoma on osa multi-part-muotoista MIME-sanoman content-type-tietoa, sanoman eheyden tunniste (MIC) on laskettava koko multi-part-muotoisesta sisällöstä, joka sisältää myös MIME otsikot. Vastaanottaessaan allekirjoitetun käsittelyilmoituksen alkuperäisen sanoman lähettäjä voi käyttää tätä seuraavasti: Sanoman vastaanottajan lähettämänä ilmoituksena alkuperäisen sanoman vastaanotosta. Vastaanottaja tekee tämän palauttamalla alkuperäisen sanoman tunnuksen tiedon original-message-id arvona allekirjoitetun kuittauksen käsittelyilmoitus (MDN) -osassa. Ilmoituksena siitä, että vastaanottaja on todennut alkuperäisen sanoman ehjäksi. Vastaanottaja ilmoittaa tämän lähettämällä lähetyskerrasta laskemansa sanoman eheyden tunnisteen tiedon Received-Content-Mic arvona allekirjoitetussa käsittelyilmoituksessa (MDN). Ilmoituksena, että vastaanottaja on todennut alkuperäisen sanoman lähettäjän oikeutetuksi lähettämään tälle sanomia. Kuittauksena kiistämättömyydestä (non-repudiation), kun alkuperäisen sanoman lähettäjä on onnistuneesti avannut allekirjoitetun käsittelyilmoituksen (MDN) käyttäen vastaanottajan julkista avainta ja palautettu sanoman eheyden tunniste (MIC) on käsittelyilmoituksessa (MDN) sama kuin alkuperäisessä sanomassa. 5.2 Käsittelyilmoitusten tyypit AS2-käsittelyilmoitusta (AS2-MDN) on olemassa kahta eri tyyppiä: synkronista ja asynkronista. Synkroninen käsittelyilmoitus lähetetään HTTP-vastauksena HTTP POST-sanomaan tai HTTPSvastauksena HTTPS POST-sanomaan. Tällaista AS2-käsittelyilmoitusta nimitetään synkroniseksi, koska tällainen AS2-käsittelyilmoitus lähetetään alkuperäisen sanoman lähettäjälle saman TCP/IP-yhteyden aikana. Asynkroninen AS2-käsittelyilmoitus lähetetään HTTP-, HTTPS- tai SMTP-sanomana erillisen TCP/IP-yhteyden aikana. Loogisesti ajatellen, asynkroninen AS2-käsittelyilmoitus on vastaus AS2-sanomaan. Kuitenkin, siirtoprotokolla-kerroksessa, olettaen, että HTTP-pipeliningominaisuutta on hyödynnetty, asynkroninen AS2-vastaanottokuittaus toimitetaan yksittäisen TCP/IP-yhteyden aikana, joka on eri kuin yhteys, jolla alkuperäinen AS2-sanoma toimitettiin. Kun asynkronista kuittauspyyntöä käsitellään, HTTP-vastaanottokuittaus pitää lähettää takaisin ennen kuin käsittelyilmoitus on prosessoitu ja lähetetty erillisen yhteyden aikana. Kun alkuperäisen AS2-sanoman lähettäjä on pyytänyt asynkronisen AS2- käsittelyilmoituksen, synkroninen HTTP- tai HTTPS-vastaanottokuittaus, joka lähetettään alkuperäisen sanoman lähettäjälle ennen kuin yhteys katkaistaan, pitää olla siirtokerroksen vastaus ilmoittaen tiedonsiirron onnistumista tai epäonnistumista. Tällaisen synkronisen vastaanottokuittauksen muoto on sama kuin vastaanottokuittaus, joka lähetetään, kun AS2-käsittelyilmoitusta ei pyydetä. Seuraavissa kuvioissa on esitetty synkronisen ja asynkronisen AS2-käsittelyilmoituksen lähetys. 24/46

Synkronisen AS2-vastaanottoilmoituksen lähetys Lähettäjä Yhteyden muodostus Vastaanottaja Lähettäjä Lähetys Vastaanottaja HTTP kuittauspyyntö AS2-sanoma Lähettäjä Vastaanotto Vastaanottaja HTTP kuittaus AS2-vastaanottoilmoitus Asynkronisen AS2-vastaanottoilmoituksen lähetys Lähettäjä Yhteyden muodostus Vastaanottaja Lähettäjä Lähetys Vastaanottaja HTTP kuittauspyyntö AS2-sanoma Lähettäjä Vastaanotto Vastaanottaja HTTP kuittaus Lähettäjä Yhteyden muodostus Vastaanottaja Lähettäjä Lähetys Vastaanottaja HTTP kuittauspyyntö AS2-vastaanottoilmoitus Lähettäjä Vastaanotto Vastaanottaja HTTP kuittaus On huomattava, että lähetettäessä AS2-käsittelyilmoitusta alkuperäisen sanoman lähettäjälle, ilmoituksen vastaanottava kone voi olla eri kuin alkuperäisen sanoman lähettänyt kone. Se voi myös hyödyntää toista tiedonsiirtoprotokollaa kuin sitä, mitä käytettiin lähetettäessä alkuperäistä sanomaa. Synkronisen käsittelyilmoituksen lähettämisen etuna on, että alkuperäisen sanoman lähettäjä saa välittömästi vahvistuksen sanoman perillemenosta ja prosessoinnin onnistumisesta. Ongelman muodostavat isot lähetettävät AS2-sanomat, joiden vastaanotto, prosessointi ja vastauksen lähettäminen voi ylittää IP-yhteydelle määritellyn TCP/IP-yhteyden maksimipituuden. Asynkronisen käsittelyilmoituksen lähettämisen etuna on, että alkuperäisen sanoman lähettäjä saa välittömästi ilmoituksen tiedonsiirron onnistumisesta. Tällöin TCP/IP-yhteyttä ei tarvitse pitää auki liian kauan. Tällöin kuitenkin AS2-käsittelyilmoitus on varustettava riittävällä määrällä tietoa, jotta alkuperäisen sanoman lähettäjä voi yhdistää saapuneen AS2-käsittelyilmoituksen ja sitä vastaavan alkuperäisen sanoman päivittääkseen alkuperäisen sanoman tiedot oikein. 5.3 Synkroninen AS2-käsittelyilmoitus AS2-käsittelyilmoituksen rakenne riippuu siitä, onko se synkroninen vai asynkroninen. Synkroninen AS2-käsittelyilmoitus on muotoa: tilarivi 25/46

yleiset tiedot vastaustiedot entiteettitiedot AS2-ominaiset tiedot rivin vaihto AS2-käsittelyilmoituksen tiedot 5.4 Käsittelyilmoituksen tilarivi Synkronisen AS2-käsittelyilmoituksen ensimmäisenä rivinä on Tilarivi (status-line), jolla ilmoitetaan protokollaversio, numeerinen tilakoodi ja siihen liittyvä tekstimuotoinen selite. Jokainen näistä tiedoista on erotettu toisistaan välilyönnillä. Tilarivi on siis muotoa: HTTP/versionumero tilakoodi selite Kuten edellä esitetyn kuittauspyyntösanoman yhteydessä mainittiin myös käsittelyilmoituksessa tiedonsiirtoprotokolla, siis HTTP, ja sen versionumero esitetään erotettuna toisistaan /-merkillä. Tilarivi siis alkaa merkkijonolla: HTTP/1.1 On huomattava, että versionumero koostuu kahdesta osasta, joissa kumpikin on juokseva. Täten versio 2.4 on aiempi kuin versio 2.13, joka puolestaan on aiempi kuin versio 12.3. Tilakoodi on kolminumeroinen koodi, jolla ilmoitetaan sanoman vastaanottajan yritysten tulos tulkita sanoman sisältö ja täyttää alkuperäisen sanoman lähettäjän toiveet. Selitteellä pyritään antamaan lyhyt tilakoodia selittävä kuvaus tekstimuodossa. Tilakoodi on itsessään tarkoitettu AS2-käsittelyilmoituksen tiedon koneelliseen käsittelyyn, tilakoodia selittävä teksti on tarkoitettu käyttäjän luettavaksi. Tilakoodin ensimmäinen merkki ilmaisee vastauksen luokan, joita on kaikkiaan viisi. Kahdella jälkimmäisellä numerolla ei sitä vastoin ole tiedon kuvailevaa roolia. Ensimmäisen numeron mukaan koodit jaetaan seuraaviin luokkiin: Luokka Luokan kuvaus Suoritettava toiminto 1XX Informatiivinen Kuittauspyyntö on vastaanotettu, prosessointi jatkuu 2XX Onnistunut Tehtävä on onnistuneesti vastaanotettu, ymmärretty ja hyväksytty 3XX Lisäohje Tehtävän loppuun suorittaminen vaatii lisätoimintoja 4XX Asiakaskoneen virhe Kuittauspyyntösanoma sisältää pahan kieliopillisen virheen tai sitä ei voi toteuttaa 5XX Palvelimen virhe Palvelin ei onnistunut toteuttamaan ilmeisen oikeaoppista kuittauspyyntöä Taulukko: Tilakoodien luokat, niiden kuvaukset ja suoritettavat toiminnot Seuraavassa taulukossa on esitetty tilakoodit sekä suositus vastaavaksi selitteeksi. Selitetekstit ovat kuitenkin vain suosituksia ja ne voidaan korvata vastaavilla paikallisesti, toimialakohtaisesti tai sovelluskohtaisesti käytetyillä selitteillä. 26/46

Tilakoodi Selite Selitteen suomenkielinen vastike Tilakoodia esittelevä dokumentin RFC 2616 kappale 100 Continue Jatkuu 10.1.1 101 Switching Protocols Protokolla muutos 10.1.2 200 OK OK 10.2.1 201 Created Luotu 10.2.2 202 Accepted Hyväksytty 10.2.3 203 Non-Authoritative Information Käytetty eilähettäjän tietoja 10.2.4 204 No Content Ei sisältöä 10.2.5 205 Reset Content Sisällön palautus 10.2.6 206 Partial Content Osittainen sisältö 10.2.7 300 Multiple Choices Useita vaihtoehtoja 10.3.1 301 Moved Permanently Muutettu pysyvästi 10.3.2 302 Found Löydetty 10.3.3 303 See Other Katso muut 10.3.4 304 Not Modified Ei muutettu 10.3.5 305 Use Proxy Käytä proxya 10.3.6 306 (unused) (ei käytössä) 10.3.7 307 Temporary Redirect Tilapäisesti ohjattu muualle 10.3.8 400 Bad Request Huono pyyntö 10.4.1 401 Unauthorized Ei oikeutettu 10.4.2 402 Payment Required Vaaditaan maksua (ei käytössä) 10.4.3 403 Forbidden Kielletty 10.4.4 404 Not Found Ei löydetty 10.4.5 405 Method Not Allowed Menetelmä ei ole sallittu 10.4.6 27/46