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