e-gov / dhx Goto Github PK

Protokoll ei keela seda. Küll aga tekib küsimus, mis oleks mitme vahendaja mõte? DHX ei paku saatjale teavet, millega too saaks otsustada, kummale dokument saata. Üheaegselt mitme vahendaja olemasolu võib viidata sellele, et vahendaja vahetamisega on midagi sassi läinud - asutus on lisatud uue vahendaja vahendusnimekirja, vana ei ole aga asutust eemaldanud. Siiski ei saa seda alati käsitada veaolukorrana.

Kuidas ministeerium saaks saata kirja kõigile valitsemisala asutustele?

Praegune vaade on, et see oluline vajadus peaks jääma DHS-de endi kanda. Leviedastus eeldab kataloogiteenuse (directory service) olemaolu. Teiste sõnadega, peab olema võimalus adressaatide rühmi moodustada ja hallata. Tõenäoliselt on mõned laiemat huvi pakkuvad rühmad. Nende haldamiseks võiks koht olla. Kui, siis aga pigem RKOARRi (Riigi ja kohaliku omavalitsuse asutuste riikliku registri) juures. Kindlasti on asutusespetsiifilisi rühmi. Nende haldamine peaks jääma asutuse DHS-i pädevusse.

MÄRKUS. Praegune DVK pakub "adressaatide DVK serveris automaatse lisamise" teenust [DVK spetsifikatsioon 1.6.0-1, lk 56]:

DVK serverit on võimalik seadistada nii, et kui saadetav dokumendikonteiner vastab etteantud tingimustele, siis lisatakse dokumendi adressaatide hulka üks või mitu täiendavat adressaati. Nimetatud lahendus on vajalik näiteks selleks, et garanteerida mingi projektiga seotud dokumentide jõudmine kõigile asjassepuutuvatele osapooltele.
Automaatse adressaatide lisamise korral muudab DVK server saadetava dokumendikonteineri XML andmeid, s.t. lisatud adressaadid on nähtavad ka kõigile teistele adressaatidele ja dokumendi esialgsele saatjale.

Analüüsimist vajab olukord, kus DHS teenindab hulka asutusi, nendele asutustele saadetakse regulaarselt group mail-i ja kirjad on suured. Sellistel juhtudel oleks hea vältida sama kirja mitu korda samasse DHS-i (kuigi erinevatele adressaatidele) saatmist.

Laiendatavus on oluline. Vrdl ühe protokolli kriitika:

"a protocol design that sets the clock back at least 20 years, while the rest of the distributed systems community has made extensibility and Postel's robustness principle driving considerations for practically all modern protocol designs.

"Custom message metadata extensibility".

Sõnumivorming ei tohiks olla "non-extensible locked box".

Vajab mõtlemist, kas testimisteenus võiks olla X-tee arendus- või testkeskkonnas (ja kes seda teenust osutaks)?

Vrdl vastavustestimine EL dokumendivahetuslahenduses e-Delivery: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+Conformance+testing.

DHX töötoas arendajatega 9.02.2017
Tõnu: "Testitud ja töötab 200 Mb faili saatmine DHX-ga."
Arendaja: "See on suur samm edasi. Varem tekkisid probleemid 30-40 Mb failidega. Vaja oleks 600 Mb."

Priit: DHX on algselt mõeldud dokumentide edastamiseks. "Dokumendi tekst peab olema [..] võimalikult lühike." Asjaajamiskorra ühtsed alused § 10, lg 2.
Suurte failide saatmine on kahtlemata vajadus, aga kas see on DHX-i eesmärk? Võib-olla vajame vooedastus- (ingl Streaming) protokolli? Fragmentedastus oli DHX-i puhul kaalumisel, kuid sellest loobusime.

"Laoteenuse" osutamine oli aktuaalne kümme aastat tagasi.
Tänapäeval oleks ehk õigem, kui asutuse dokumente hoitaks asutuse DHS-is.

Rakendamise motivaatorid (deployment incentives) ja demotivaatorid (disincentives) on üldjoontes selged, kuid vajavad veel täiendat analüüsimist.

Kirjandus: Thaler D (2016). Out With the Old and In With the New: Planning for Protocol Transitions.

DVK korral võis Kapsel sisaldada mitu adressaati. Iga adressaat käis DVK-st eraldi receiveDocuments teenusega küsimas.

DHX korral kaob keskne postkast. Seega peab muutuma ka mitmele adresaadile saatmise loogika.
Ilmselt saatja peab ise sama Kapsli igale adressaadile eraldi saatma. Saatja peab arvestama et mõni adressaat võib tagastada vea. Seega saatja (kasutajaliidese) realisatsioon võiks olla selline et saadetud dokumendi iga adressaadi korral oleks näha kas dokument võeti vastu või tagastati viga.

Uus UK võiks mitmele adresaadile saatmist lihtsustada, niimoodi et võtab DHS-ilt vastu kapsli üks kord ja teostab ise edasi saatmised mitmele adressaadile.

Seda näitab protokolli täiendav analüüs ja verifitseerimine. Kavandatud funktsionaalsus katab dokumendivahetuse põhivajaduse. Täiendavate omaduste lisamisel peab vaatama, millisesse kihti omadus läheb.

X-tee mõttes on piisavaks ja pidavaks kinnituseks dokumendi kättesaamise kohta X-tee päringu vastus (Response message). Kui soovitakse "kõrgema taseme" s.t äritaseme kinnitust, siis see saab tulla ainult DHS-st. Äritaseme kinnituse võib teostada DHX dokumendina. Sellise käitumismustri võib vormistada eraldi kihina; ei pea tingimata olema DHX-i osa.

RFC 3552 Guidelines for Writing RFC Text on Security Considerations

AK:
Tere. Veel üks asi. Hakkasin nüüd mõtlema et milleks on protokollis kirjas et PEAB mõne aja pärast saatmist uuesti üritama. Mulle tundub et seda kas on vaja uuesti saatma või mitte võiks igaüks ise otsustama. Meil on sünkroonne suhtlus DHS-de vahel, aga kui teeme korduvsaatmist siis see ei ole lõpuks kasutaja jaoks sünkroonne, sest kasutajale ei saa kohe öelda kas saatmine ebaõnnestus. Kui keegi teab et ta saadab ainult väiksed dokumendid ja tahab kohe teada kas dokument jõudis kohale, siis miks mitte anda sellist võimalust?

TP:
Minu arvates võiks seal olla VÕIB proovida uuesti saatmist (ja se on ka mõtekas ainult teatud tüüpi tehniliste vigade korral vist)
Lisaks tundub et DHS süsteemid realiseerivad siiski enda sisemiselt saatmise asünkroonselt paljud. Nagu koosolekutest selgus
St et kasutajale ütlevad saatmisel "Läks teele" aga saadavad asünkroonselt ja on eraldi vaade kus on näga dokumentide saatmise staatused

TP:
Intervjuudes on selgunud, et mitmes asutuses on 2 või enam infosüsteemi mis kasutavad DVK-d eraldi kausta alusel. Registirkood on neil üks, aga kaust on erinev. Ja preagu nii saatmine (sendDocuments) kui ka vastuvõtmine (receiveDocuments) käib vist registrikood+kaust alusel.

Kuidas me DHX korral selle ära lahendame?
Vahendamine siin ka ei aita, kui vahendamist teeme registrikoodi alusel (esialgse plaani järgi).
Kas peaks juurde tooma mingi uue mõõtme "kaust" vms ka DHX korral?
[9:04:41] Tõnu Põld: Tene variant on ka et ühel asutusel on mitu DHX alamsüsteemi:
EE/GOV/12345/DHX1/sendDocuments
EE/GOV/12345/DHX2/sendDocuments
Aga see ajab ka asja segaseks vist

Luua tööriist, mille abil hajusale dokumendihaldusele ülemineku erinevad osapooled saavad ülevaate kes on juba DHX-i võimekuse loonud.

VAJADUS
Avaliku sektori üleminek detsentraliseeritud dokumendivahetusele algab plaanide kohaselt 2017. a. Erinevad sihtrühmad (asutused, arendajad, teenusepakkujad, ITAO) hakkavad meie poole pöörduma küsimustega:

• kes on DHX-i vahendajad?
• millised asutused on DHX-i vahendajate kliendid?
• kes asutustest on DHX-ile juba üle läinud?

Vajame jooksvat ülevaadet ülemineku seisust.
Vajalik teave sisaldub mitmes allikas: X-tee globaalses konfiguratsioonis, DHX-i vahendajate poolt X-teel publitseeritavates vahendusnimekirjades ja osalt ka RIHAst. Puudub lihtne viis selle teave kiireks kokkusaamiseks ja inimesele esitamiseks.

ETTEPANEK
Luua lihtne tööriist, mis pöörduks X-tee globaalse konfiguratsiooni ja X-teel publitseeritavate DHX-i vahendusnimekirjade poole, koguks sealt teabe ülalnimetatud kolmele küsimusele vastamiseks ning esitaks veebiliidese kaudu inimkasutajale. Tööriista põhikasutajaks oleksid RIA teenusehaldurid ja ülemineku koordinaator, kes kasutavad teavet erinevate sihtrühmade nõustamiseks, probleemide lahendamiseks, üleminekuprotsessi seireks ja statistika andmiseks dokumendihaldust koordineerivale üksusele ITAO-le. Tööriist peaks olema konfigureeritav nii, et teenuse saaks avalikult avada. (X-tee globaalne konfiguratsioon on tehniliselt avalik, DHX-i vahendusnimekirjade avalikkuse kohta tuleb seisukoht kujundada.)
Terminoloogia: Tööriista abil esitatav nimistu on sisuliselt DHX-i „aadressiraamat“.

EI OLE SKOOBIS
DHX-i „aadressiraamatut“ ei pakuta masinloetavalt. DHX-i rakendav infosüsteem peab, DHX protokolli kohaselt, dokumendiedastuseks vajaliku aadressiotsingu teostama lokaalselt (https://e-gov.github.io/DHX/#74-lokaalne-aadressiraamat).
Tööriist pakuks ainult hetkeseisu teavet. Ajalugu võib olla vajalik, eelkõige DHX-i vahendajatega seotud probleemide ja järelevalve teostamiseks. Seda oleks siiski tunduvalt raskem teostada, vajadusel saab pöörduda X-tee logide poole.

TEOSTUS
Teenus on suunatud inimkasutajale (DHX-i planeerijale, arendajale, haldajale, dokumendihalduse koordinaatorile). Käideldavusnõue on madal.
Tööriista programmeerimiseks vajalikud tarkvarakomponendid on DHX etalonteostuse käigus juba loodud. Kokkupanemise maht on väike.
Tööriistaga ei looda uusi andmeid, andmebaasi ei vaja.
Analüüsi vajab küsimus, kas DHX-i aadressiraamat peaks tervikuna või osaliselt olema avalik. Kui mitte, siis on vaja autentimist ja pääsuhaldust.

Tere

Mul on mõned küsimused viimase sendDocument speki[1] kohta.

1. päringu väljudi dokis on fault elemendid faultcode, faultstring. äriloogilise vea näites on faultCode, faultString. vist peaks mõlemas suur täht olema?
2. päringu sisendi dokis on documentAttachment tüüp swaRef. kuskil väga ei viidata, mis see tähendab. võiks viidata http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html peale? selle järgi peaks väärtus olema xsd:anyURI, nt cid: protokolliga. näidispäringutes pole cid: prefixi kasutatud, aga peaks? kui cid: prefix on puudu, siis kas peaks ikkagi eeldama, et tegu on cid: protokolliga ja proovima content-id järgi otsida?
3. näidispäringutes on palju imelikku whitespace, nt documentAttachment elemendi väärtus sisaldab reavahetust. osad xml parserid (nt .net XmlReader) ei ignoreeri seda, reavahetus loetakse väärtuse osaks. dhx adapteri testlood selliseid reavahetusi ei sisalda. kas need näited on korrektne sisend, mida peaks toetama?

Lisaks üldise DHX speki[2] otsevõimekuse osa on ebaselge. See ei paista eriti alamsüsteemide olemasolu arvestavat.

1. Asutuse ainus DHX alamsüsteem võib olla nimega DHX*, kus * ei ole tühi. Võib ka olla mitu DHX* alamsüsteemi. Spekk lubab otsevõimekust kontrollida otsese saatmisüritusega "DHX" alamsüsteemile, aga see võib üsna ettearvamatu tulemuse anda.
2. Asutusel võib olla mitu alamorganisatsiooni või infosüsteemi, millest ühel on otsevõimekus ja teine sooviks kasutada vahendamist. Kas see on lubatud? Spekk ütleb, et kui mingi otsevõimekus on olemas, siis ei tohi üldse vahendamist kontrollida. Samas tehniliselt oleks see võimalik, kui vahendatava ja otsevõimekusega osadel on erinev alamsüsteemi nimi.

[1] https://github.com/e-gov/DHX/blob/646aa1d7ca0f2ddc1e9ed60308f494cdff5c745c/docs/sendDocument.md
[2] https://github.com/e-gov/DHX/blob/616c62147f20d3d63619e31ff9471508cf759cef/docs/index.html

(küsitud kohtumisel arendajatega 17.03.2016)

See on huvitav mõte, mis vajab kaalumist.

Käesolev issue on mõeldud e-arvetega seonduva arutamiseks. Hoiame arutelu siin, siis jääb jälg kõigile huvilistele nähtavaks! RIA poolt oleme koostanud juhendi E-arved DVK-s üleminekuperioodil. Juhend on praegu veel kavandi seisuses, kuid valmides peaks andma ammendavad vastused kõigile osapooltele, kelle e-arvemajandust DHX-ile üleminek ja DVK sulgemine puudutab. Palume arutelus osalejatel sellega tutvuda. Kõik küsimused, arvamused ja ettepanekud on teretulnud. Aitäh!

DVK pakub võimalust edastada dokumente fragmentidena. (DVK spetsifikatsioon, jaotis "Dokumentide edastamine fragmentidena"). Kas DHX peaks nõudma sama?

Kõigepealt tuleb välja selgitada, kas selle järele on reaalset vajadust. Asjaajamise kord nõuab, et "Dokumendi tekst peab olema [..] võimalikult lühike." Dokument võib sisaldada rasterjooniseid, samuti võib dokumenti edastada pildistusena. Need suurendavad faili. Kuid dokumentivahetuse skoobis ei tohiks olla gigabaidiste kettatõmmiste jms väga suurte failide edastamine.

Fragmentedastuste standardimisel - kui selleks on ärivajadus - võib aluseks võtta senise DVK lahenduse, kus sendDocument päringus edastatakse:

• fragmente_kokku - edastatavate fragmentide hulk (s.t. mitmeks tükiks dokument on jagatud)
• fragment_nr - edastatava fragmendi järjekorranumber alates 0-st (s.t. 0, 1, 2, jne.)
• edastus_id - edastussessiooni ID. Saatja poolt vabalt valitav võimalikult unikaalne string, mis on ühiseks nimetajaks kõigile edastatavatele tükkidele.

Edastatav dokument peab olema esmalt GZIP-ga kokku pakitud.

Fragmentedastuse toe nõuet on võimalik püstitada, kuid ilmaasjata seda teha ei tuleks.

EK:
Kui nüüd saatmine muutub hajusaks ja keegi tahab saata 500 le adressaadile 50 megast dokki, see tähendab siis ju 500 x-tee päringut järjest.
Aeglaseks ei jää ?
Voi kas sealt ei teki mingit riskikohta ?

Mis moodi DHX puhul käib selle teenuse avamine asutusel asutustele? Kas iga asutus peab seda ise iga kontakti puhul eraldi tegema? Nö. andma loa oma teenusele?

X-teel on võimalus avada teenus kõigile. Praegu on nii mõeldud.

AGA - vt issue #16

Vaikimisi kõigile avamine eeldab, et X-tee liikmeid saab üldjuhul usaldada.

Võimalik on teha ka "ukse" ja doorkeeper-iga lahendus. Tehniliselt X-tee nn grupi - DHX kasutajate gruppi - loomise kaudu. Menetlus oleks:

1. RIA kui X-tee haldaja loob X-tee liikmegrupi "DHX kasutajad"
2. Asutus, kes on valmis DHX-i kasutusele võtma, esitab taotluse (ITAO - Liivi ja/või RIA)
3. <võimalikud tehnilised vm kontrollid>
4. RIA lisab asutuse X-tee liikmegruppi "DHX kasutajad"

Sellisel juhul peame ette kirjutama, et teenus avatakse ainult grupile "DHX kasutajad".

Tunnistagem, et sellises korras on oma administratiivne võlu: DHX-i rakendamise protsess oleks jälgitav ja administratiivselt kontrollitav.

Võib küll öelda, et asjatu bürokraatia, kuid kui inimestele liiga vähe struktuuri ette anda, siis nad kaotavad orientatsiooni?

i don't know
How user client is connected to the security server?
give me a example please!!!!!

thanks for you!!!!

Ükshaaval kasutajate lisamine pole ilmselt mõistlik.
Kaaluda võib X-tee kasutajate grupi "DHX-i kasutajad" loomist. DHXi teenuseomanik avaks teenuse grupile. Gruppi peab keegi haldama - sinna liikmeid lisama. Võib-olla võiks seda teha RIA. Millised võiksid olla grupi haldamise reeglid?
Peaks hindama, kui suur on väärkasutamise oht.

Võib olla oleks mõistlik lisada representationList teenuse vastusesse ka kehtivusajad(ehk millal vahendamine algab ja lõpeb). Mõtlen et see võiks olla abiks et vigu vältida tulevikus. Ka teenustepakkujatele on see vist lihtsam - pärast lepingu sõlmimist võib vahendatava kohe lisada representationListi ja unustada, kuna lepingu alguskuupäeval vahendamine automaatselt algab ja lepingu lõppkuupäeval automaatselt lõpeb.

Hõlmamine? - mis praegu tuleb vastuseks kui kiri kohale tuleb? Kuidas täna on? Liivi otseselt hõlmamise vajadust ei näinud, kuid kättesaamise kohta peaks küll teate saama. Kas see kättesaamise teavitus on DHS-is kuidagi lahendatud? Kas siis peame eraldi teenuse selleks DHX-i raames tegema?

Kättesaamise kinnitus edastatakse X-tee vastussõnumis.
7.6 Dokumendi lugemine edastatuks
Saatev süsteem PEAB lugema dokumendi edastatuks, kui on saanud sendDocument teenuselt positiivse vastuskoodiga vastussõnumi.
Kinnitus dokumendi kättesaamise kohta saadetakse X-tee päring-vastus (request-response) sõnumipaari vastussõnumis. Kui osapooled vajavad kõrgema äriloogika kihi taseme kinnitusi, siis neid võib realiseerida DHX protokolli väliselt või DHX protokolli pealiskihina.
https://github.com/e-gov/DHX/blob/master/files/Protokoll.md#76-dokumendi-lugemine-edastatuks

Arvestatud on sellega, et kättesaamise kinnituse koostab ja saadab teele vastuvõttev süsteem ilma inimese sekkumiseta. Turvaserverid on tavaliselt seadistatud nii, et vastussõnumit (response) oodatakse 5 minutit. Kui selle aja jooksul vastussõnumit ei tule, siis loeb saatja süsteem, et dokument ei jõudnud kohale.

Kui soovime, et kättesaamise kinnituse koostamine vajab inimese sekkumist, siis tuleb see teostada eraldi teenusega (inimene ei mahu turvaserveri timeout-i sisse). Praegu sellist teenust protokolli võetud ei ole, kuna vajadus ei ole selge.

Oht on ka teha üldine teenus, mille semantika ei ole osapooltele selge. Kättesaamise semantika on ju laiem küsimus, kus võib olla konkreetsete dokumendiliikidest või kontekstist sõltuvaid nüansse.
„Sain kirja kätte“
„Sain raha kätte“
„Sain arve kätte“
„Sain kohtukutse kätte“
jne

Väljatöötamisel on X-tee monitooringulahendus. Statistikat hakatakse tootma ja tarbima selle kaudu.

Protokoll ei võta seisukohta selles küsimuses.

Eesmärk on "kapslit" võimalikult vähe muuta.
Lahendamist vajavad küsimused:

• Elektroonilise andmevahetuse metaandmete loend on nn semantiline standard, ei anna konkreetse masinloetava esituse süntaksit. Masinesituse süntaks on kirjeldatud DVK spetsifikatsioonis. DVK spetsifikatsioon kaob ära. "Kapsli" tehniline spetsifikatsioon tuleb tekitada - kas Elektroonilise andmevahetuse metaandmete loendi juurde või eraldi dokumendina või DHX-i osana.
• "Kapsli" võib hoida jõuda muutumatuna. Osa välju langevad kasutusest välja, osade semantika kohendub. Mingi aeg tuleks siiski kapsli täiendamine ette võtta.

Vt ka https://github.com/e-gov/DHX/blob/master/files/Mis%20mille%20sees%20k%C3%A4ib.md

Nõuete vormistus tuleb viia vastavusse standardiga RFC 2119.

Vt "Protokollide spetsifitseerimise parim praktika", p 6 "Nõuete tugevus".

Kas puhverdamine võiks toimuda TS tasemel? Algselt oli X-teel nii kavandatud („asünkroonne X-tee“) – teave Ahti Kelderilt.

Jah, DHX-i arendamisel üritatakse järgida avastandardite (ingl open standards) põhimõtteid.

Interneti standardimise organisatsioon IETF ([RFC 6852]) seab avastandardi kriteeriumiteks:

• kohast protsessi (ingl due process):
  • otsuseid tehakse osapoolte suhtes õiglaselt
  • standardiloome protsess on läbipaistev
    • sh jälg aruteludest
    • avaliku kommenteerimise periood enne lõplikku heakskiitmist ja kasutuselevõttu
  • perioodilise läbivaatuse ja täiendamise protsessid on selgelt määratletud
• laiahaardelist konsensust (ingl broad consensus)
• läbipaistvust
• tasakaalustatust - standardimistegevuses ei domineeri ükski konkreetne isik, ettevõte või huvirühm
• vabatahtlikku kasutuselevõttu. IETF on seisukohal, et standardi edukuse peab määrama turg.

Euroopa Liidu infopoliitikas on avastandardeid tähtsaks peetud. EL koosvõime raamistiku esimeses versioonis (v1.0, 2004) sõnastati avastandardi kriteeriumid:

• standardit haldab kasumit mittetaotlev organisatsioon
• standardi arendamise protsess on avatud kõigile huvitatud osapooltele
• otsuseid tehakse demokraatlikult (konsensus- või enamuspõhimõttel)
• standard on publitseeritud ja standardi tekst on kättesaadav tasuta või nominaalse tasu eest
• standardi kasutamise eest ei nõuta tasu (ingl royalty-free)
• ei seata piiranguid standardi taaskasutamisele.

Hiljem on avastandardi mõiste poliitiliste võitluste mõjul hägustunud. Ülevaate käesoleva hetke seisust annavad Euroopa Komisjoni teatis [COM(2016)] ja [Moody].

Täpsem ülevaade avastandardi mõistest ja selle erinevatest käsitlustest on Vikipeedia artiklis Open standard.

[RFC 6852] RFC 6852 Affirmation of the Modern Paradigm for Standards, 2013.
[COM(2016)] COM(2016) ICT Standardisation Priorities for the Digital Single Market.
Moody G (2016) FRAND is no friend: How to make EU tech standards compatible with open source, Ars Technica.

Nt Tallinna linnal.

X-tee arendaja tõi välja, et objectType atribuut on X-tee v6 headerites kohustuslik (Viide: http://x-road.eu/docs/x-road_message_protocol_v4.0.pdf, lk 7. Väljavõte: <xs:attribute ref="objectType" use="required"/>). Meie turvaserver kontrollib x-tee v6-te ja seetõttu ei lähe puuduliku headeriga sõnum läbi.
Teie spekis on samamoodi vastav atribuut client headeri puhul puudu: https://www.ria.ee/dhx/sendDocument

Sama probleem on ka https://www.ria.ee/dhx/representationList näites.

Teen ettepaneku, et enne üleriigilist üleminekut DHX protokollile teha analüüs AS4 protokolli sobivuse kohta, tuues välja DHX protokolli eelised ja puudused võrreldes laialdaselt kasutatava ning OASISe poolt standardiseeritud AS4 protokolliga.
AS4 peaks olema ka võimalik kasutada üle X-tee, siis saaks kasutada signeerimata/krüpteerimata sõnumeid. Vahetades sõnumeid X-tee väliselt, saaks kasutada sertide vahetamist ja signeerimist/krüpteerimist.

AS4 eelised:

• standardiseeritud OASISe poolt ja avatud standard
• võimaldab nii push kui ka pull mudelit
• kõrgetasemeline turvalisus ka X-tee kasutamise vajaduseta, samas võimalik kasutada ka üle X-tee
• • vajaks tegelikult testimist, kas ikka saab kasutada üle X-tee
• sõnumi kohalejõudmise teavitus nii sünkroonne kui ka asünkroonne
• AS4 tugi on realiseeritud väga paljudes tarkvarades, samuti on mitmeid avatud lähtekoodi ja litsensiga AS4 sõnumikäsitlejaid (message handler)

AS4 puudused:

• ei ole Eestis leiutatud?

DHX eelised:

• X-tee kasutamine tagab turvalisuse
• ???

DHX puudused

• ei võimalda push mudelit
• ei võimalda kasutamist väljaspool X-teed
• • puudub signeerimise/krüpteerimise võimalus
• puudub asünkroonne teavitus sõnumi kohalejõudmise kohta
• ???

Viited:
https://www.drummondgroup.com/index.php/component/content/article/127-b2b/b2b-products/b2b-faqs/243-as4-faq
https://www.oasis-open.org/news/pr/as4-profile-of-ebms-3-0-becomes-oasis-standard
https://www.codit.eu/blog/2016/02/01/as4-for-dummies-part-i-introduction/
http://holodeck-b2b.org/

Nõue on et dokument edastatakse "kapslis" (jaotis "Sõnumivorming", p 1). Kas vastuvõttev süsteem peaks seda kontrollima?

Jah, protokoll on suunatud Eesti avaliku sektori dokumendivahetusele, kus kapsel on nõutud. Protokolli tuleks täiendada nõudega, et vastuvõttev süsteem kontrollib kapsli olemasolu. Vigase kapsliga või kapslita saadetise kohta antakse veakood.

(küsitud kohtumisel arendajatega 17.03.2016)
Jah, DVK pakub asutustele võimalust publitseerida oma allasutuste nimekiri. Allasutuste nimekirju saab DVK-st X-tee teenuse abil pärida. DHS-ides kasutatakse seda dokumentide adresseerimisel.

DHX-i puhul tuleks sama teave võtta RKOARR-st. RKOARR-is on allasutuste andmed kõige autentsemal kujul. RKOARR viiakse üle Äriregistri juurde ning täiendatakse RKOARRi X-tee teenuseid. Selline andmekasutus vastaks riigi IT koosvõime ja AvTS nõudele.

Miinuseks on see, et DHS-is tuleks mõned asjad ümber teha. See on üks asi, mida võiks lahendada kavandatav Universaalne tarkvarakomponent?

Lahenduseks võib olla Universaalsesse tarkvarakomponenti sõnumijärje funktsionaalsuse lisamine.

X-tee nimeruumi predefined osa – ka kuskil X-tee dokumentatsioonis peaks olema tulevikus kirjas, et DHS/vms-nimelise infosüsteemi puhul kehtib X-tee EE/GOV nimeruumis eraldi reeglid (vt ülal). Et selle abil saaks siis hiljem automaatselt DHX protokolli kasutajaid leida. Paralleelselt/alternatiivselt tuleks kirjeldada ka, et sendDocuments pole EE/GOV osas vabas kasutuses.
........

Mõistlik oleks hoida DHX X-tee protokollist lahus – selles mõttes, et DHX kasutab X-tee protokollistikku (transpordikihina, e-identimise ja adresseerimise süsteemina), kuid ei ole X-tee protokolli osa ning X-tee protokoll üldse ei nimeta DHX-i. Aga kas see on võimalik?

Praktiliseks, aga ka juriidiliseks küsimuseks võib kerkida, kas X-tee liige, leides teise liikme teenuse sendDocument – või eeldades sellises teenuse olemasolu võimalust - võib eeldada, et tegu on DHXi teenusega? Kui X-tee kasutajate ja DHX-i kasutajate hulgad ei lange kokku, siis ta ei saa seda eeldada.

Liige A tahab saata liikmele B dokumenti, kasutades DHXi. Praeguse protokollikavandi kohaselt liige A paneb dokumendi „pimesi“ teele - katsetab, kas liikme B teenus sendDocument võtab dokumendi vastu.

Ei ole välistatud, et liikmel B on sama nimega, kuid erineva semantikaga, mitte-DHX teenus.

Kuna DHX ei ole X-tee protokolli osa, siis ei saa X-tee kasutamisest iseenesest tekkida X-tee liikmele kohustusi DHX-i suhtes midagi teha või arvestada. DHX-st ei saa tekkida X-tee liikmele kohustusi muul viisil, kui: 1) liige ise otsustab DHX-i kasutada; 2) DHX-i kasutamise kohustus pannakse mingile X-tee liikmete rühmale.

Seega X-tee liige B (kes ei ole DHXi kasutaja) võib teha teenuse sendDocument, mille sisu erineb DHXi sendDocument teenusest. X-tee reeglid ei keela tal seda tegemast.

Tekib semantiline konflikt – mitte-DHX teenus võib saadetist valesti tõlgendada. Ei ole välistatud isegi rasked tagajärjed.

Kas liige A võib DHX dokumendi „pimesi“ teele panna (praegune protokolli kavand) või ta peaks enne kindlaks tegema (kuidas?), et adressaadi sendDocument teenus on ikka DHXi teenus? Või peaks saatmine olema kaheringiline: esimesel pöördumisel kinnitab adressaat, et tegu on DHXi teenusega; dokument saadetakse alles pärast kinnitust?

Üks lahendus oleks DHX-is kasutada spetsiifilisemat nime, nt sendDHX vms.

Teine lahendus oleks võtta kasutusele „DHX-i kasutajate“ grupp (tehniliselt X-tee liikmegrupp). Sätestada protokollis, et DHX teenus avatakse ainult „DHX-i kasutajate grupile“. Gruppi võiks hallata pädev riigiasutus või isegi DHX-i kasutajate kogukond ise.

Või siis siduda DHX (ja teised sarnased süsteemid) otseselt X-tee protokolliga - kasutades IANA eritähendusega nimedega ja numbritega sarnast mehhanismi (https://tools.ietf.org/html/rfc6335).

[10.11.2016 12:43:30] Aleksei: "1.5 Dokumenti saatev süsteem PEAB määratlema kasutatava DXH protokolli versiooni." - kas seda etalonteostuses dokumendi vastuvõtmisel kontrollitakse?hetkel ei kontrollita. ma ei leidnud protkolli tekstis et on vaja kontrollida ja mis see kontroll peab siis olema, kas tuleb kontrollida et major version on sama?
[10.11.2016 12:54:50] Eneli Järve: Protokoll ütleb nii: Dokumenti saatev süsteem PEAB määratlema kasutatava DXH protokolli versiooni.
[10.11.2016 12:55:36] Eneli Järve: kas määratlema=kontrollima
[10.11.2016 12:56:02] Eneli Järve: see nagu ütleks, et kuskil peab olema versioon määratud
[10.11.2016 12:57:31 | Muudetud - 12:57:47] Tõnu Põld: Ma ütleks et kontrollimine on Vastuvõtva süsteemi ülesanne. Kui vastuvõttev süsteem ei toeta seda versiooni siis ta peaks andma vea
[10.11.2016 12:58:26] Eneli Järve: jah, see siis tähendab, et määrab ära, kas versioon on õige. Aga kas see on DHS-is vaja kuidagi rakendada ning kas peaks protokolli panema ka sellekohase kirjelduse?
[10.11.2016 12:59:20] Eneli Järve: Sest me oleme pannud küll, et peab versiooni defineerima - aga mis ta edasi teeb?
[10.11.2016 12:59:22 | Muudetud - 13:01:23] Tõnu Põld: Küsimus on kas kasutame selle vea jaoks koodi "DHX.Validation" või lisame uue vea "DHX.UnsupportedVersion"
[10.11.2016 12:59:39] Eneli Järve: Priit teab :)
[10.11.2016 13:04:00] Eneli Järve: Kui mina protokolli loen, siis ma ei loe välja seda, et ta peab andma vea...ma arvaks, et kuskil peab olema tuvastatav, et mis versioon on :D Noh nagu meil täna kapsliga on - saab saata nii 1.0 kui 2.1..ja see on eristatav, et millist versiooni siis keegi kasutab
[10.11.2016 13:04:20] Eneli Järve: aga võib-olla tehniline inimene saab aru paremini.
[10.11.2016 13:04:38] Tõnu Põld: Ei peagi viga andma, kuid ilus oleks
[10.11.2016 13:05:06 | Muudetud - 13:06:05] Tõnu Põld: Sest siis on meil püstitatud äri nõuete täitmine parem
[10.11.2016 13:05:23] Tõnu Põld: Sest viga andes saatja teab et vastuvõtja ei saanud dokumenti kätte
[10.11.2016 13:05:34] Tõnu Põld: muidu saadab saatja dokumente musta auku
[10.11.2016 13:05:35] Aleksei: teenuse spekkis öeldud et ikkkagi PEAKS vea andma, aga protokollis endas mitte:
[10.11.2016 13:05:36] Aleksei: Päringu saatja annab teada, millise DHX protokolli versiooni kohaselt päring on moodustatud. Vastuvõttev süsteem PEAB kontrollima parameetri DHXVersion olemasolu. Vastuvõttev süsteem PEAKS versiooninumbri alusel otsustama, kas suudab päringsõnumit töödelda ja suutlikkuse puudumisel päringu tagasi lükkama.
[10.11.2016 13:05:43 | Muudetud - 13:07:35] Tõnu Põld: ja äri-nõuded ei ole täidetud
[10.11.2016 13:05:59] Eneli Järve: mhm, see on sama teema
[10.11.2016 13:06:05] Eneli Järve: mida rääkisime
[10.11.2016 13:06:15] Eneli Järve: et kas me peame keelam,a kõike
[10.11.2016 13:06:37 | Muudetud - 13:06:51] Tõnu Põld: PEAKS tähendab et erijuhl ei pea, st see pole nii range kui PEAB
[10.11.2016 13:07:15] Eneli Järve: Priit ütles, et vaba maa - liberalism jne :)
[10.11.2016 13:07:37] Eneli Järve: igaühe otsustada, kas ta tahab kontrollida ja keelata
[10.11.2016 13:07:53 | Muudetud - 13:08:03] Eneli Järve: või võtab vastu ka teisi versioone
[10.11.2016 13:08:04] Tõnu Põld: PEAKS tähendab et üldjuhul PEAB andma vea
[10.11.2016 13:08:56] Tõnu Põld: tehnilised küsimused on:

1. Mis vea ta annab - kas DHX. vea mingi
2. Mis kujul on versiooni number, kas "1.0" esialgu esimene versioon ?
   [10.11.2016 17:24:10] Priit Parmakson: Küsimus oli ajendatud sellest, et kui protokolli versiooni näitamine on nõue, siis kas selle nõude täitmist saab testida (PEAKS testima)? Etalonteostuse pakkumise testimisvahendina tekib küsimus, kas etalonteostus suudab seda testida. Olen nõus teie aruteluga. Kui ei ole selget ettepanekut, kuidas täiendada, siis jätaks nii nagu on. ... Mind huvitab, kuidas inimesed ehitavad süsteeme, milles on mittevajalikke omadusi. "DHX.UnsupportedVersion" oleks vist vinge... aga kas on ette näha, et tekib mitmeid versioone? Ja kui tekib, siis kas "DHX.Validation" ajaks asja ära? Teenuse spetsifikatsioon on protokolli osa. Seega ikka peab kontrollima. Vastuvõtja aga saab ainult ise teada, milliseid versioone ta toetab. Etalonteostus ikka kontrollib parameetri DHXVersion olemasolu? Kui ta ühtki versiooni tagasi ei lükka, siis etalonteostus järelikult toetab kõiki versioone.. Millise veateate peaks mittetoetatava versiooni korral andma? Kas on vaja eraldi veateadet "DHX.UnsupportedVersion"?
   [10.11.2016 17:30:37] Aleksei: mulle tundub et eraldi veateadet on vaja. Kui on olemsa ette defineeritud veakood, siis lihtsam vea korral aru saada milles probleem on. Ma pakuks veel ühte - meil on olemas DHX.InvalidAddressee veakood, võiks lisada ka DHX.InvalidSender, kuna protokollis on nõue olemas et tuleb kontrollida kas X-tee saatja ja kapsli saatja on samad
   [10.11.2016 17:31:19] Aleksei: või mitte DHX.InvalidSender, aga DHX.SenderDoesNotMatch vms
   [10.11.2016 17:31:41] Priit Parmakson: see viimane tundub täpsem
   [10.11.2016 17:32:22] Priit Parmakson: Ja vastuvõtja PEAKS neid veakoode saatma?
   [10.11.2016 17:32:58] Aleksei: Vastuvõtja süsteem PEAB äriloogikalise või DHX protokolli reeglite vastu valideerimisel tekkinud vea tagastama sendDocuments vastuses, Body/sendDocumentResponse/fault XML elemendi sees, kasutades ühte järgmistest veakoodidest:
   [10.11.2016 17:33:02] Aleksei: see on spekkist
   [10.11.2016 17:33:14] Priit Parmakson: ok
   [10.11.2016 17:33:42] Priit Parmakson: ootame Tõnu arvamuse ka ära
   [10.11.2016 17:33:49] Aleksei: jah
   [10.11.2016 20:31:42 | Eemaldatud - 20:56:07] Eneli Järve: Sõnum eemaldati
   [0:59:00] Priit Parmakson: Võib-olla peaksime veakoodide hulga vabaks laskma?
   [1:02:26] Priit Parmakson: Kui vastuvõtja peab protokolli versiooni kontrollima, siis ta peab teadma, millise väärtuse vastu ta kontrollib. See väärtus tuleb ilmselt panna konfi. Peame selgitama, kuidas patch numbrit (nt 1.0.4) käsitleda. Kõik see lisab keerukust.
   [1:04:01] Priit Parmakson: Võib-olla jätta versiooninumbri olemasolu ja versiooni kontrollimise nõue üldse ära? Tahab - kontrollib, tahab - ei kontrolli. Saab dokumendist aru, ei saa - kui ei saa, siis annab ValidationError veateate.
   [1:04:57] Priit Parmakson: Etalonteostuses - kui tahame seda testimise abivahendina pakkuda, võiks ehk siiski lisada versiooninumbri olemasolu kontrolli. Seda aga testimise eesmärgil.
   [1:06:25] Priit Parmakson: Meil ei ole ka praegu ettekujutust, kas ja mismoodi protokolli versioonid võiksid vajalikuks osutuda. (Kui jätame patch-id kõrvale).
   [1:08:43] Priit Parmakson: Kui keegi peakski saatma versiooninumbrita, saaja suudab aga dokumendist aru saada, siis on kõik ok. (See oleks IETF robustness põhimõte).
   [9:28:34 | Muudetud - 9:31:51] Tõnu Põld: Tere,

Versiooni numbri kontroll vähemalt soovitusena võiks siiski jääda, kui kunagi tuleb uus versioon siis on elu tükk maad lihtsam.

Veakoodina eelistaks eraldi koodi DHX.UnsupportedVersion, sest see võimaldab DHX rakendajal peale ehitada automaatika - näiteks kui 2.0 versiooni korral saab ta vea DHX.UnsupportedVersion, siis proovib vanemat versiooni 1.0

Vea koodide vabaks laskmist ei poolda, sest vea koodide kasutamine võimaldab vajadusel teostada automaatset (masin) töötlust. Näiteks programmiliselt eristada kas dokumendi saatmist on mõtekas uuesti üritada jms.

Kui vea koodid vabaks lasta, siis pole neil üldse mõtet, siis jätame lihtsalt "vea tekst" välja, mis on siis mõeldud inimesele (mitte masinale)

Saadetavad versioonid numbrid võiksid olla sellised, mis ei sisalda patchi numbrit, st saata ainult major versioon 1 (mitte 1.0.10) või 2.

Kuigi see vajab pisut mõtlemist veel, äkki me soovime siiski et süsteemid käituksid erinevalt ka alamversioonide (1.3.2) korral? Kuigi see soov teeb asja kaunis keerukaks DHX rakendaja poolel ja võib muuta DHXi tegelikult soovitud nõuetele mitte-vastasavaks (kättetoimetatavus jt nõuded ei ole enam täidetud).

Vrdl CSS 3, HTML 5 jt.

Ei ole, aga see peab tekkima.

Kirjandus: RFC 6709 Design Considerations for Protocol Extensions (2012), jaotis 4.1 Version Numbers.

Vrdl RFC 6819 OAuth 2.0 Threat Model and Security Considerations.

Jah, turvakäsitlust (ingl Security Considerations, kui järgida IETF stiili, on vaja).

Hinnata protokolli RFC 5218 What Makes for a Successful Protocol? kriteeriumite lõikes. Vt ka Rogersi five generic characteristics of innovation that impact on the adoption decision: relative advantage, compatibility, complexity, trialability and observability.

Üleminek on planeeritud sujuvana.

Üleläinud asutus peab saatmisel välja selgitama, kas adressaadil on juba DHX-i võimekus (s.t kas adressaat on ka juba üle läinud). [Kuidas väljaselgitamine toimub on tehniline aspekt ja on kirjeldatud protokollis] Kui adressaadil on DHX-i võimekus, siis saadab DHX-iga. Vastasel korral saadab DVK-sse. Üle minemata adressaat saab dokumendi DVK-st kätte.

Kui üle minemata asutus soovib dokumenti saata, siis ta saadav tavalisel viisil DVK-sse. DVK-sse loome võimekuse, millega DVK vaatab, kas adressaat on juba DHX-le üle läinud ja kui on, siis edastab dokumendi adressaadile DHX protokolli kaudu.

Seega üleminekuperioodil toimib DVK vahendajana vana ja uue protokolli vahel. Süsteemid ise ei pea paralleelset DHX-i ja DVK võimekust endale looma.

(See korraldus rakendub ka e-arvete edastamisele. Ei ole vahet, millises järjekorras operaatorid ja nende DVK-d kasutavad kliendid üle lähevad.)

Vt https://github.com/e-gov/DHX/blob/master/Protokoll.md#9-%C3%9Cleminek

Kesksüsteemi, millega liituda või liidestuda, DHXis ei ole.
Ärilises plaanis:
DHX-ile ülemineku hõlbustamiseks võib siiski mõelda administratiivseid protseduure, DHXi rakendajate nimekirja pidamist ja infovahetust.
Tehnilises plaanis:
DHX saatmiseks pole vaja DHXiga liituda – ehk selleks et saata ühele DHX protokolli osapoolele dokumenti, pole vaja realiseerida endal vastuvõtmise päringut.
DHX vastuvõtmiseks tuleb välja arendada vastuvõttev teenus.

Segaduse tekkimise võimalus on pigem teoreetiline. Siiski peaks tagama, et segadust ei saaks tekkida. Pigem organisatsiooniliste kui tehniliste meetmetega, sest X-teel ei ole "kindla tähendusega nimede" (assigned names) mehhanismi. X-tee liikme alamsüsteemi DHX registreerimisel RIA-s tuleks kontrollida, et X-tee liige peab silmas DHX-i, mitte midagi muud.

Kirjandus: RFC 6943 Issues in Identifier Comparison for Security Purposes.

(küsitud kohtumisel arendajatega 17.03.2016)
Asutus saab DVK-s kirjeldama oma ametikohti. Saatjad kasutavad seda teavet.

Algallik-andmekoguks ametikohtade osas on Riigi personali- ja palgaarvestuse andmekogu (SAP). Loogiline - ja AvTS nõudele vastav - oleks võtta need andmed sealt.