From 71b46581b4d3bc10d12d60e7a594ac5c16b2bc5c Mon Sep 17 00:00:00 2001 From: Petter Reinholdtsen Date: Mon, 11 Mar 2019 16:26:11 +0100 Subject: [PATCH] Generated. --- blog/tags/noark5/index.html | 1594 +++++++++++++++++++++++++++++++++++ blog/tags/noark5/noark5.rss | 1003 ++++++++++++++++++++++ 2 files changed, 2597 insertions(+) create mode 100644 blog/tags/noark5/index.html create mode 100644 blog/tags/noark5/noark5.rss diff --git a/blog/tags/noark5/index.html b/blog/tags/noark5/index.html new file mode 100644 index 0000000000..4a16ca9806 --- /dev/null +++ b/blog/tags/noark5/index.html @@ -0,0 +1,1594 @@ + + + + + Petter Reinholdtsen: Entries Tagged noark5 + + + + + +
+

+ Petter Reinholdtsen + +

+ +
+ + +

Entries tagged "noark5".

+ +
+
+ Åpen og gjennomsiktig vedlikehold av spesifikasjonen for Noark 5 Tjenestegrensesnitt +
+
+ 11th March 2019 +
+
+

Et virksomhetsarkiv for meg, er et arbeidsverktøy der en enkelt kan +finne informasjonen en trenger når en trenger det, og der +virksomhetens samlede kunnskap er tilgjengelig. Det må være greit å +finne frem i, litt som en bibliotek. Men der et bibliotek gjerne tar +vare på offentliggjort informasjon som er tilgjengelig flere steder, +tar et arkiv vare på virksomhetsintern og til tider personlig +informasjon som ofte kun er tilgjengelig fra et sted.

+ +

Jeg mistenker den eneste måten å sikre at arkivet inneholder den +samlede kunnskapen i en virksomhet, er å bruke det som virksomhetens +kunnskapslager. Det innebærer å automatisk kopiere (brev, epost, +SMS-er etc) inn i arkivet når de sendes og mottas, og der filtrere +vekk det en ikke vil ta vare på, og legge på metadata om det som er +samlet inn for enkel gjenfinning. En slik bruk av arkivet innebærer at +arkivet er en del av daglig virke, ikke at det er siste hvilested for +informasjon ingen lenger har daglig bruk for. For å kunne være en del +av det daglige virket må arkivet enkelt kunne integreres med andre +systemer. I disse dager betyr det å tilby arkivet som en +nett-tjeneste til hele virksomheten, tilgjengelig for både mennesker +og datamaskiner. Det betyr i tur å både tilby nettsider og et +maskinlesbart grensesnitt.

+ +

For noen år siden erkjente visjonære arkivarer fordelene med et +standardisert maskinlesbart grensesnitt til organisasjonens arkiv. De +gikk igang med å lage noe de kalte +Noark +5 Tjenestegrensesnitt. Gjort riktig, så åpner slike maskinlesbare +grensesnitt for samvirke på tvers av uavhengige programvaresystemer. +Gjort feil, vil det blokkere for samvirke og bidra til +leverandørinnlåsing. For å gjøre det riktig så må grensesnittet være +klart og entydig beskrevet i en spesifikasjon som gjør at +spesifikasjonen tolkes på samme måte uavhengig av hvem som leser den, +og uavhengig av hvem som tar den i bruk.

+ +

For å oppnå klare og entydige beskrivelser i en spesifikasjon, som +trengs for å kunne få en fri og åpen standard (se +Digistan-definisjon), +så trengs det en åpen og gjennomsiktig inngangsport med lav terskel, +der de som forsøker å ta den i bruk enkelt kan få inn korreksjoner, +etterlyse klargjøringer og rapportere uklarheter i spesifikasjonen. +En trenger også automatiserte datasystemer som måler og sjekker at et +gitt grensesnitt fungerer i tråd med spesifikasjonen.

+ +

For Noark 5 Tjenestegrensesnittet er det nå etablert en slik åpen +og gjennomsiktig inngangsport på prosjekttjenesten github. Denne +inngangsporten består først og fremst av en åpen portal som lar enhver +se hva som er gjort av endringer i spesifikasjonsteksten over tid, men +det hører også med et åpent "diskusjonsforum" der en kan +komme med endringsforslag og forespørsler om klargjøringer. Alle +registrerte brukere på github kan bidra med innspill til disse +henvendelsene.

+ +

I samarbeide med Arkivverket har jeg fått opprettet et git-depot +med spesifikasjonsteksten for tjenestegrensesnittet, der det er lagt +inn historikk for endringer i teksten de siste årene, samt lagt inn +endringsforslag og forespørsler om klargjøring av teksten. Bakgrunnen +for at jeg bidro med dette er at jeg er involvert i +Nikita-prosjektet, +som lager en fri programvare-utgave av Noark 5 Tjenestegrensesnitt. +Det er først når en forsøker å lage noe i tråd med en spesifikasjon at +en oppdager hvor mange detaljer som må beskrives i spesifikasjonen for +å sikre samhandling.

+ +

Spesifikasjonen vedlikeholdes i et rent tekstformat, for å ha et +format egnet for versjonskontroll via versjontrollsystemet git. Dette +gjør det både enkelt å se konkret hvilke endringer som er gjort når, +samt gjør det praktisk mulig for enhver med github-konto å sende inn +endringsforslag med formuleringer til spesifikasjonsteksten. Dette +tekstformatet vises frem som nettsider på github, slik at en ikke +trenger spesielle verktøy for å se på siste utgave av +spesifikasjonen.

+ +

Fra dette rene tekstformatet kan det så avledes ulike formater, som +HTML for websider, PDF for utskrift på papir og ePub for lesing med +ebokleser. Avlednings-systemet (byggesystemet) bruker i dag +verktøyene pandoc, latex, docbook-xsl og GNU make til +transformasjonen. Tekstformatet som brukes dag er +Markdown, men det vurderes +å +endre +til formatet RST i fremtiden for bedre styring av utseende på +PDF-utgaven.

+ +

Versjonskontrollsystemet git ble valgt da det er både fleksibelt, +avansert og enkelt å ta i bruk. Github ble valgt (foran f.eks. Gitlab +som vi bruker i Nikita), da Arkivverket allerede hadde tatt i bruk +Github i andre sammenhenger.

+ +

Enkle endringer i teksten kan gjøres av priviligerte brukere +direkte i nettsidene til Github, ved å finne aktuell fil som skal +endres (f.eks. kapitler/03-konformitet.md), klikke på den lille +bokstaven i høyre hjørne over teksten. Det kommer opp en nettside der +en kan endre teksten slik en ønsker. Når en er fornøyd med endringen +så må endringen "sjekkes inn" i historikken. Det gjøres ved +å gi en kort beskrivelse av endringen (beskriv helst hvorfor endringen +trengs, ikke hva som er endret), under overskriften "Commit +changes". En kan og bør legge inn en lengre forklaring i det +større skrivefeltet, før en velger om endringen skal sendes direkte +til 'master'-grenen (dvs. autorativ utgave av spesifikasjonen) eller +om en skal lage en ny gren for denne endringen og opprette en +endringsforespørsel (aka "Pull Request"/PR). Når alt dette +er gjort kan en velge "Commit changes" for å sende inn +endringen. Hvis den er lagt inn i "master"-grenen så er den +en offisiell del av spesifikasjonen med en gang. Hvis den derimot er +en endringsforespørsel, så legges den inn i +listen +over forslag til endringer som venter på korrekturlesing og +godkjenning.

+ +

Større endringer (for eksempel samtidig endringer i flere filer) +gjøres enklest ved å hente ned en kopi av git-depoet lokalt og gjøre +endringene der før endringsforslaget sendes inn. Denne prosessen er +godt beskrivet i dokumentasjon fra github. Git-prosjektet som skal +"klones" er +https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/.

+ +

For å registrere nye utfordringer (issues) eller kommentere på +eksisterende utfordringer benyttes nettsiden +https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues. +I skrivende stund er det 48 åpne og 11 avsluttede utfordringer. Et +forslag til hva som bør være med når en beskriver en utfordring er +tilgjengelig som utfordring +#14.

+ +

For å bygge en PDF-utgave av spesifikasjonen så bruker jeg i dag en +Debian GNU/Linux-maskin med en rekke programpakker installert. Når +dette er på plass, så holder det å kjøre kommandoen 'make pdf html' på +kommandolinjen, vente ca. 20 sekunder, før spesifikasjon.pdf og +spesifikasjon.html ligger klar på disken. Verktøyene for bygging av +PDF, HTML og ePub-utgave er også tilgjengelig på Windows og +MacOSX.

+ +

Github bidrar med rammeverket. Men for at åpent vedlikehold av +spesifikasjonen skal fungere, så trengs det folk som bidrar med sin +tid og kunnskap. Arkivverket har sagt de skal bidra med innspill og +godkjenne forslag til endringer, men det blir størst suksess hvis alle +som bruker og lager systemer basert på Noark 5 Tjenestegrensesnitt +bidrar med sin kunnskap og kommer med forslag til forebedringer. Jeg +stiller. Blir du med?

+ +

Det er viktig å legge til rette for åpen diskusjon blant alle +interesserte, som ikke krever at en må godta lange kontrakter med +vilkår for deltagelse. Inntil Arkivverket dukker opp på IRC har vi +laget en IRC-kanal der interesserte enkelt kan orientere seg og +diskutere tjenestegrensesnittet. Alle er velkommen til å ta turen +innom +#nikita +(f.eks. via irc.freenode.net) for å møte likesinnede.

+ +

Det holder dog ikke å ha en god spesifikasjon, hvis ikke de som tar +den i bruk gjør en like god jobb. For å automatisk teste om et konkret +tjenestegrensesnitt følger (min) forståelse av +spesifikasjonsdokumentet, har jeg skrevet et program som kobler seg +opp til et Noark 5v4 REST-tjeneste og tester alt den finner for å se +om det er i henhold til min tolkning av spesifikasjonen. Dette +verktøyet er tilgjengelig fra +https://github.com/petterreinholdtsen/noark5-tester, +og brukes daglig mens vi utvikler Nikita for å sikre at vi ikke +introduserer nye feil. Hvis en skal sikre samvirke på tvers av ulike +systemer er det helt essensielt å kunne raskt og automatisk sjekke at +tjenestegrensesnittet oppfører seg som forventet. Jeg håper andre som +lager sin utgave av tjenestegrensesnittet vi bruke dette verktøyet, +slik at vi tidlig og raskt kan oppdage hvor vi har tolket +spesifikasjonen ulikt, og dermed få et godt grunnlag for å gjøre +spesifikasjonsteksten enda klarere og bedre.

+ +

Dagens beskrivelse av Noark 5 Tjenestegrensesnitt er et svært godt +utgangspunkt for å gjøre virksomhetens arkiv til et dynamisk og +sentralt arbeidsverktøy i organisasjonen. Blir du med å gjøre den +enda bedre?

+ +
+
+ + + Tags: digistan, noark5, norsk, standard. + + +
+
+
+ +
+
+ Time for an official MIME type for patches? +
+
+ 1st November 2018 +
+
+

As part of my involvement in +the Nikita +archive API project, I've been importing a fairly large lump of +emails into a test instance of the archive to see how well this would +go. I picked a subset of my +notmuch email database, all public emails sent to me via +@lists.debian.org, giving me a set of around 216 000 emails to import. +In the process, I had a look at the various attachments included in +these emails, to figure out what to do with attachments, and noticed +that one of the most common attachment formats do not have +an +official MIME type registered with IANA/IETF. The output from +diff, ie the input for patch, is on the top 10 list of formats +included in these emails. At the moment people seem to use either +text/x-patch or text/x-diff, but neither is officially registered. It +would be better if one official MIME type were registered and used +everywhere.

+ +

To try to get one official MIME type for these files, I've brought +up the topic on +the +media-types mailing list. If you are interested in discussion +which MIME type to use as the official for patch files, or involved in +making software using a MIME type for patches, perhaps you would like +to join the discussion?

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

+ +
+
+ + + Tags: debian, english, noark5, standard. + + +
+
+
+ +
+
+ Release 0.2 of free software archive system Nikita announced +
+
+ 18th October 2018 +
+
+

This morning, the new release of the +Nikita +Noark 5 core project was +announced +on the project mailing list. The free software solution is an +implementation of the Norwegian archive standard Noark 5 used by +government offices in Norway. These were the changes in version 0.2 +since version 0.1.1 (from NEWS.md): + +

    +
  • Fix typos in REL names
    • +
  • Tidy up error message reporting
    • +
  • Fix issue where we used Integer.valueOf(), not Integer.getInteger()
    • +
  • Change some String handling to StringBuffer
    • +
  • Fix error reporting
    • +
  • Code tidy-up
    • +
  • Fix issue using static non-synchronized SimpleDateFormat to avoid + race conditions
    • +
  • Fix problem where deserialisers were treating integers as strings
    • +
  • Update methods to make them null-safe
    • +
  • Fix many issues reported by coverity
    • +
  • Improve equals(), compareTo() and hash() in domain model
    • +
  • Improvements to the domain model for metadata classes
    • +
  • Fix CORS issues when downloading document
    • +
  • Implementation of case-handling with registryEntry and document upload
    • +
  • Better support in Javascript for OPTIONS
    • +
  • Adding concept description of mail integration
    • +
  • Improve setting of default values for GET on ny-journalpost
    • +
  • Better handling of required values during deserialisation
    • +
  • Changed tilknyttetDato (M620) from date to dateTime
    • +
  • Corrected some opprettetDato (M600) (de)serialisation errors.
    • +
  • Improve parse error reporting.
    • +
  • Started on OData search and filtering.
    • +
  • Added Contributor Covenant Code of Conduct to project.
    • +
  • Moved repository and project from Github to Gitlab.
    • +
  • Restructured repository, moved code into src/ and web/.
    • +
  • Updated code to use Spring Boot version 2.
    • +
  • Added support for OAuth2 authentication.
    • +
  • Fixed several bugs discovered by Coverity.
    • +
  • Corrected handling of date/datetime fields.
    • +
  • Improved error reporting when rejecting during deserializatoin.
    • +
  • Adjusted default values provided for ny-arkivdel, ny-mappe, + ny-saksmappe, ny-journalpost and ny-dokumentbeskrivelse.
    • +
  • Several fixes for korrespondansepart*.
    • +
  • Updated web GUI: +
      +
    • Now handle both file upload and download.
      • +
    • Uses new OAuth2 authentication for login.
      • +
    • Forms now fetches default values from API using GET.
      • +
    • Added RFC 822 (email), TIFF and JPEG to list of possible file formats.
      • +
    • +
+ +

The changes and improvements are extensive. Running diffstat on +the changes between git tab 0.1.1 and 0.2 show 1098 files changed, +108666 insertions(+), 54066 deletions(-).

+ +

If free and open standardized archiving API sound interesting to +you, please contact us on IRC +(#nikita on +irc.freenode.net) or email +(nikita-noark +mailing list).

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

+ +
+
+ + + Tags: english, noark5, nuug, offentlig innsyn, standard. + + +
+
+
+ +
+
+ Fetching trusted timestamps using the rfc3161ng python module +
+
+ 8th October 2018 +
+
+

I have earlier covered the basics of trusted timestamping using the +'openssl ts' client. See blog post for +2014, +2016 +and +2017 +for those stories. But some times I want to integrate the timestamping +in other code, and recently I needed to integrate it into Python. +After searching a bit, I found +the +rfc3161 library which seemed like a good fit, but I soon +discovered it only worked for python version 2, and I needed something +that work with python version 3. Luckily I next came across +the rfc3161ng library, +a fork of the original rfc3161 library. Not only is it working with +python 3, it have fixed a few of the bugs in the original library, and +it has an active maintainer. I decided to wrap it up and make it +available in +Debian, and a few days ago it entered Debian unstable and testing.

+ +

Using the library is fairly straight forward. The only slightly +problematic step is to fetch the required certificates to verify the +timestamp. For some services it is straight forward, while for others +I have not yet figured out how to do it. Here is a small standalone +code example based on of the integration tests in the library code:

+ +
+#!/usr/bin/python3
+
+"""
+
+Python 3 script demonstrating how to use the rfc3161ng module to
+get trusted timestamps.
+
+The license of this code is the same as the license of the rfc3161ng
+library, ie MIT/BSD.
+
+"""
+
+import os
+import pyasn1.codec.der
+import rfc3161ng
+import subprocess
+import tempfile
+import urllib.request
+
+def store(f, data):
+    f.write(data)
+    f.flush()
+    f.seek(0)
+
+def fetch(url, f=None):
+    response = urllib.request.urlopen(url)
+    data = response.read()
+    if f:
+        store(f, data)
+    return data
+
+def main():
+    with tempfile.NamedTemporaryFile() as cert_f,\
+    	 tempfile.NamedTemporaryFile() as ca_f,\
+    	 tempfile.NamedTemporaryFile() as msg_f,\
+    	 tempfile.NamedTemporaryFile() as tsr_f:
+
+        # First fetch certificates used by service
+        certificate_data = fetch('https://freetsa.org/files/tsa.crt', cert_f)
+        ca_data_data = fetch('https://freetsa.org/files/cacert.pem', ca_f)
+
+        # Then timestamp the message
+        timestamper = \
+            rfc3161ng.RemoteTimestamper('http://freetsa.org/tsr',
+                                        certificate=certificate_data)
+        data = b"Python forever!\n"
+        tsr = timestamper(data=data, return_tsr=True)
+
+        # Finally, convert message and response to something 'openssl ts' can verify
+        store(msg_f, data)
+        store(tsr_f, pyasn1.codec.der.encoder.encode(tsr))
+        args = ["openssl", "ts", "-verify",
+                "-data", msg_f.name,
+	        "-in", tsr_f.name,
+		"-CAfile", ca_f.name,
+                "-untrusted", cert_f.name]
+        subprocess.check_call(args)
+
+if '__main__' == __name__:
+   main()
+
+ +

The code fetches the required certificates, store them as temporary +files, timestamp a simple message, store the message and timestamp to +disk and ask 'openssl ts' to verify the timestamp. A timestamp is +around 1.5 kiB in size, and should be fairly easy to store for future +use.

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

+ +
+
+ + + Tags: english, noark5, sikkerhet. + + +
+
+
+ +
+
+ Release 0.1.1 of free software archive system Nikita announced +
+
+ 10th June 2017 +
+
+

I am very happy to report that the +Nikita Noark 5 +core project tagged its second release today. The free software +solution is an implementation of the Norwegian archive standard Noark +5 used by government offices in Norway. These were the changes in +version 0.1.1 since version 0.1.0 (from NEWS.md): + +

    + +
  • Continued work on the angularjs GUI, including document upload.
    • +
  • Implemented correspondencepartPerson, correspondencepartUnit and + correspondencepartInternal
    • +
  • Applied for coverity coverage and started submitting code on + regualr basis.
    • +
  • Started fixing bugs reported by coverity
    • +
  • Corrected and completed HATEOAS links to make sure entire API is + available via URLs in _links.
    • +
  • Corrected all relation URLs to use trailing slash.
    • +
  • Add initial support for storing data in ElasticSearch.
    • +
  • Now able to receive and store uploaded files in the archive.
    • +
  • Changed JSON output for object lists to have relations in _links.
    • +
  • Improve JSON output for empty object lists.
    • +
  • Now uses correct MIME type application/vnd.noark5-v4+json.
    • +
  • Added support for docker container images.
    • +
  • Added simple API browser implemented in JavaScript/Angular.
    • +
  • Started on archive client implemented in JavaScript/Angular.
    • +
  • Started on prototype to show the public mail journal.
    • +
  • Improved performance by disabling Sprint FileWatcher.
    • +
  • Added support for 'arkivskaper', 'saksmappe' and 'journalpost'.
    • +
  • Added support for some metadata codelists.
    • +
  • Added support for Cross-origin resource sharing (CORS).
    • +
  • Changed login method from Basic Auth to JSON Web Token (RFC 7519) + style.
    • +
  • Added support for GET-ing ny-* URLs.
    • +
  • Added support for modifying entities using PUT and eTag.
    • +
  • Added support for returning XML output on request.
    • +
  • Removed support for English field and class names, limiting ourself + to the official names.
    • +
  • ...
    • + +
+ +

If this sound interesting to you, please contact us on IRC (#nikita +on irc.freenode.net) or email +(nikita-noark +mailing list).

+ +
+
+ + + Tags: english, noark5, nuug, offentlig innsyn, standard. + + +
+
+
+ +
+
+ Idea for storing trusted timestamps in a Noark 5 archive +
+
+ 7th June 2017 +
+
+

This is a copy of +an +email I posted to the nikita-noark mailing list. Please follow up +there if you would like to discuss this topic. The background is that +we are making a free software archive system based on the Norwegian +Noark +5 standard for government archives.

+ +

I've been wondering a bit lately how trusted timestamps could be +stored in Noark 5. +Trusted +timestamps can be used to verify that some information +(document/file/checksum/metadata) have not been changed since a +specific time in the past. This is useful to verify the integrity of +the documents in the archive.

+ +

Then it occured to me, perhaps the trusted timestamps could be +stored as dokument variants (ie dokumentobjekt referered to from +dokumentbeskrivelse) with the filename set to the hash it is +stamping?

+ +

Given a "dokumentbeskrivelse" with an associated "dokumentobjekt", +a new dokumentobjekt is associated with "dokumentbeskrivelse" with the +same attributes as the stamped dokumentobjekt except these +attributes:

+ +
    + +
  • format -> "RFC3161" +
  • mimeType -> "application/timestamp-reply" +
  • formatDetaljer -> "<source URL for timestamp service>" +
  • filenavn -> "<sjekksum>.tsr" + +
+ +

This assume a service following +IETF RFC 3161 is +used, which specifiy the given MIME type for replies and the .tsr file +ending for the content of such trusted timestamp. As far as I can +tell from the Noark 5 specifications, it is OK to have several +variants/renderings of a dokument attached to a given +dokumentbeskrivelse objekt. It might be stretching it a bit to make +some of these variants represent crypto-signatures useful for +verifying the document integrity instead of representing the dokument +itself.

+ +

Using the source of the service in formatDetaljer allow several +timestamping services to be used. This is useful to spread the risk +of key compromise over several organisations. It would only be a +problem to trust the timestamps if all of the organisations are +compromised.

+ +

The following oneliner on Linux can be used to generate the tsr +file. $input is the path to the file to checksum, and $sha256 is the +SHA-256 checksum of the file (ie the ".tsr" value mentioned +above).

+ +

+openssl ts -query -data "$inputfile" -cert -sha256 -no_nonce \
+  | curl -s -H "Content-Type: application/timestamp-query" \
+      --data-binary "@-" http://zeitstempel.dfn.de > $sha256.tsr
+

+ +

To verify the timestamp, you first need to download the public key +of the trusted timestamp service, for example using this command:

+ +

+wget -O ca-cert.txt \
+  https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt
+

+ +

Note, the public key should be stored alongside the timestamps in +the archive to make sure it is also available 100 years from now. It +is probably a good idea to standardise how and were to store such +public keys, to make it easier to find for those trying to verify +documents 100 or 1000 years from now. :)

+ +

The verification itself is a simple openssl command:

+ +

+openssl ts -verify -data $inputfile -in $sha256.tsr \
+  -CAfile ca-cert.txt -text
+

+ +

Is there any reason this approach would not work? Is it somehow against +the Noark 5 specification?

+ +
+
+ + + Tags: english, noark5, offentlig innsyn, standard. + + +
+
+
+ +
+
+ Epost inn som arkivformat i Riksarkivarens forskrift? +
+
+ 27th April 2017 +
+
+

I disse dager, med frist 1. mai, har Riksarkivaren ute en høring på +sin forskrift. Som en kan se er det ikke mye tid igjen før fristen +som går ut på søndag. Denne forskriften er det som lister opp hvilke +formater det er greit å arkivere i +Noark +5-løsninger i Norge.

+ +

Jeg fant høringsdokumentene hos +Norsk +Arkivråd etter å ha blitt tipset på epostlisten til +fri +programvareprosjektet Nikita Noark5-Core, som lager et Noark 5 +Tjenestegresesnitt. Jeg er involvert i Nikita-prosjektet og takket +være min interesse for tjenestegrensesnittsprosjektet har jeg lest en +god del Noark 5-relaterte dokumenter, og til min overraskelse oppdaget +at standard epost ikke er på listen over godkjente formater som kan +arkiveres. Høringen med frist søndag er en glimrende mulighet til å +forsøke å gjøre noe med det. Jeg holder på med +egen +høringsuttalelse, og lurer på om andre er interessert i å støtte +forslaget om å tillate arkivering av epost som epost i arkivet.

+ +

Er du igang med å skrive egen høringsuttalelse allerede? I så fall +kan du jo vurdere å ta med en formulering om epost-lagring. Jeg tror +ikke det trengs så mye. Her et kort forslag til tekst:

+ +

+ +

Viser til høring sendt ut 2017-02-17 (Riksarkivarens referanse + 2016/9840 HELHJO), og tillater oss å sende inn noen innspill om + revisjon av Forskrift om utfyllende tekniske og arkivfaglige + bestemmelser om behandling av offentlige arkiver (Riksarkivarens + forskrift).

+ +

Svært mye av vår kommuikasjon foregår i dag på e-post.  Vi + foreslår derfor at Internett-e-post, slik det er beskrevet i IETF + RFC 5322, + https://tools.ietf.org/html/rfc5322. bør + inn som godkjent dokumentformat.  Vi foreslår at forskriftens + oversikt over godkjente dokumentformater ved innlevering i § 5-16 + endres til å ta med Internett-e-post.

+ +

+ +

Som del av arbeidet med tjenestegrensesnitt har vi testet hvordan +epost kan lagres i en Noark 5-struktur, og holder på å skrive et +forslag om hvordan dette kan gjøres som vil bli sendt over til +arkivverket så snart det er ferdig. De som er interesserte kan +følge +fremdriften på web.

+ +

Oppdatering 2017-04-28: I dag ble høringuttalelsen jeg skrev + sendt + inn av foreningen NUUG.

+ +
+
+ + + Tags: noark5, norsk, offentlig innsyn, standard. + + +
+
+
+ +
+
+ Free software archive system Nikita now able to store documents +
+
+ 19th March 2017 +
+
+

The Nikita +Noark 5 core project is implementing the Norwegian standard for +keeping an electronic archive of government documents. +The +Noark 5 standard document the requirement for data systems used by +the archives in the Norwegian government, and the Noark 5 web interface +specification document a REST web service for storing, searching and +retrieving documents and metadata in such archive. I've been involved +in the project since a few weeks before Christmas, when the Norwegian +Unix User Group +announced +it supported the project. I believe this is an important project, +and hope it can make it possible for the government archives in the +future to use free software to keep the archives we citizens depend +on. But as I do not hold such archive myself, personally my first use +case is to store and analyse public mail journal metadata published +from the government. I find it useful to have a clear use case in +mind when developing, to make sure the system scratches one of my +itches.

+ +

If you would like to help make sure there is a free software +alternatives for the archives, please join our IRC channel +(#nikita on +irc.freenode.net) and +the +project mailing list.

+ +

When I got involved, the web service could store metadata about +documents. But a few weeks ago, a new milestone was reached when it +became possible to store full text documents too. Yesterday, I +completed an implementation of a command line tool +archive-pdf to upload a PDF file to the archive using this +API. The tool is very simple at the moment, and find existing +fonds, series and +files while asking the user to select which one to use if more than +one exist. Once a file is identified, the PDF is associated with the +file and uploaded, using the title extracted from the PDF itself. The +process is fairly similar to visiting the archive, opening a cabinet, +locating a file and storing a piece of paper in the archive. Here is +a test run directly after populating the database with test data using +our API tester:

+ +

+~/src//noark5-tester$ ./archive-pdf mangelmelding/mangler.pdf
+using arkiv: Title of the test fonds created 2017-03-18T23:49:32.103446
+using arkivdel: Title of the test series created 2017-03-18T23:49:32.103446
+
+ 0 - Title of the test case file created 2017-03-18T23:49:32.103446
+ 1 - Title of the test file created 2017-03-18T23:49:32.103446
+Select which mappe you want (or search term): 0
+Uploading mangelmelding/mangler.pdf
+  PDF title: Mangler i spesifikasjonsdokumentet for NOARK 5 Tjenestegrensesnitt
+  File 2017/1: Title of the test case file created 2017-03-18T23:49:32.103446
+~/src//noark5-tester$
+

+ +

You can see here how the fonds (arkiv) and serie (arkivdel) only had +one option, while the user need to choose which file (mappe) to use +among the two created by the API tester. The archive-pdf +tool can be found in the git repository for the API tester.

+ +

In the project, I have been mostly working on +the API +tester so far, while getting to know the code base. The API +tester currently use +the HATEOAS links +to traverse the entire exposed service API and verify that the exposed +operations and objects match the specification, as well as trying to +create objects holding metadata and uploading a simple XML file to +store. The tester has proved very useful for finding flaws in our +implementation, as well as flaws in the reference site and the +specification.

+ +

The test document I uploaded is a summary of all the specification +defects we have collected so far while implementing the web service. +There are several unclear and conflicting parts of the specification, +and we have +started +writing down the questions we get from implementing it. We use a +format inspired by how The +Austin Group collect defect reports for the POSIX standard with +their +instructions for the MANTIS defect tracker system, in lack of an official way to structure defect reports for Noark 5 (our first submitted defect report was a request for a procedure for submitting defect reports :). + +

The Nikita project is implemented using Java and Spring, and is +fairly easy to get up and running using Docker containers for those +that want to test the current code base. The API tester is +implemented in Python.

+ +
+
+ + + Tags: english, noark5, nuug, offentlig innsyn, standard. + + +
+
+
+ +
+
+ Hva «mangler» i OEP - litt statistikk utledet fra saksnummer og dokumentnummer +
+
+ 29th January 2015 +
+
+

En ting jeg har lurt på når det gjelder offentlige postjournaler, +er hvor stor andel av det som ligger i de interne databasene kommer +ikke med i postjournalen. Dette er det mulig å finne ut basert på det +som ligger i postjournalen. For å forstå hva jeg mener, trengs det +litt bakgrunnsinformasjon. I henhold til +NOARK-standarden +for norske offentlige arkiv skal enhver sak ha et årstall og et +løpenummer, og ethvert dokument i saken skal gis et +dokument-løpenummer. Det vil si at en ender opp med dokument-ID som +ser ut som ÅÅÅÅ/SAKNR-DOKNR, f.eks. 2014/2-1 eller 2014/12312-14. +Mange oppgir kun tosifret årstall, men prinsippet er det samme. Så +vidt jeg vet skal saksnummer og dokumentnummer tildeles løpende og i +stigende rekkefølge. Gitt en instans med følgende dokument-ID i +postjournalen, så kan en regne ut hvor mye som ikke finnes i +journalen: + +

    +
  • 2014/2-1
    • +
  • 2014/5-1
    • +
  • 2014/5-3
    • +
+ +

Her ser en at saksnummer 2 og 5 finnes i postjournalen, mens +nummerene 1, 3 og 4 mangler. En ser også at i sak 2014/5 mangler +dokument 2. Ved hjelp av denne informasjonen har jeg regnet ut hvor +stor andel av saksnummer og dokumentløpenummer som ikke har dukket opp +i Offentlig Elektronisk Postjournal +(OEP). For saksnummer har jeg tatt utgangspunkt i at en ikke trenger +å starte på 1, og dermed regnet med området fra laveste til høyeste +saksnummer og talt antall unike saksnummer som forekommer i OEP. I +dette tilfellet betyr de at 2 av 4 saksnummer er ubrukte (50%). For +dokumentløpenummer har jeg tilsvarende tatt utgangspunkt i laveste og +høyeste kjente dokumentløpenummer, for å handtere databaser der jeg +mangler komplett postjournal. For sak 2014/5 her betyr det at 1 av 3 +dokumenter mangler (33%).

+ +

Det er flere årsaker til at det kan bli hull i nummerseriene. +Feilføring der et dokument tildeles et nytt saksnummer ved en feil, og +deretter flyttes inn i riktig sak vil gi et ubrukt saksnummer, da +saksnummer skal tildeles i stigende rekkefølge og en ikke får opprette +nye saker innimellom gamle saker. Tilsvarende kan skje med +dokument-løpenummer. Det er jo heller ikke sikkert at et saksnummer i +OEP er det samme som løpenummeret som brukes som saksnummeret i +instansens interne datasystem. Kanskje snakker vi om ulike ontologier +der en delmengde av interne saksnummer tilsvarer saksnummer i OEP. +Hvis like nummer også tildeles andre ting enn saker som skal til OEP +vil en tilsvarende få «hull» i saksnumrene i postjournalen.

+ +

Jeg er litt usikker på hva denne statistikken egentlig viser, og +heller ikke sikker på om det er reelt sett mangler i OEP (som kanskje +kunne anses å være kritikkverdig), bare er resultatet av hendelige +uhell i nummertildelingen eller resultat av ulik ontologi i OEP og +instansens datasystem. Men jeg syntes tallene og variasjonen var så +interessant at jeg hadde lyst til å dele dem med mine lesere. Jeg har +sortert listen på prosent upubliserte saksnummer for 2014.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SaksnummerDokumentnummerInstans
201420132014
%Upubl. saksnr.Totalt%Upubl. saksnrTotalt%Upubl. dok.nr.Totalt
0.6 8 1282 0.2 2 861 0.0 0 6105Vox, nasjonalt fagorgan for kompetansepolitikk
0.9 91 9863 2.7 313 11703 0.0 0 24029Direktoratet for byggkvalitet
1.0 161 15663 3.3 558 17045 0.0 0 41954Justervesenet
1.1 325 28515 1.2 357 29621 0.0 0 66871Arkivverket
1.8 28 1568 1.0 17 1722 0.0 0 9259Statistisk sentralbyrå
1.8 92 506675.43144 4169 0.0 0 17056Arbeids- og sosialdepartementet
2.2 32 1470 2.4 36 1471 0.0 0 9757Norsk Filminstitutt
2.3 34 1478 2.9 41 1425 0.0 0 4522Datatilsynet
2.7 49 1795 2.8 34 1199 0.0 0 5824Direktoratet for mineralforvaltning med Bergmesteren for Svalbard
3.1 134 4326 2.8 144 5119 0.0 0 12223Brønnøysundregistrene
3.1 201 6571 6.1 603 9870 0.0 0 22390Statens kartverk
3.2 228 7092 2.0 143 7032 0.1 14 24491Lotteri- og stiftelsestilsynet
3.6 32 891 4.9 37 753 0.0 0 3055Statens innkrevingssentral
3.81016 26466 2.5 716 28727 0.0 0 86951Husbanken
3.9 52 132614.4 180 1247 0.0 0 4922Sysselmannen på Svalbard
4.0 248 6250 4.6 332 7159 0.0 0 22063Post- og teletilsynet
4.1 102 2488 2.7 62 2291 0.0 0 9707Forbrukerombudet
4.8 51 106012.6 132 1046 0.0 0 3616Statens strålevern
5.2 924 17781 6.31184 18665 0.0 0 59772Fiskeridirektoratet
5.5 254 4638 6.1 315 5168 0.0 0 15470Barne-, likestillings- og inkluderingsdepartementet
6.0 80 1336 3.7 48 1314 0.0 0 2691Medietilsynet
6.1 91 1486 5.0 83 1651 0.2 17 7473Petroleumstilsynet
6.2 248 399773.73459 4693 0.0 0 10963Klima- og miljødepartementet
7.0 190 270010.2 207 2033 0.0 1 14299Samferdselsdepartementet
7.1 35 492 4.5 41 909 0.0 0 2960Konkurransetilsynet
7.1 482 6800 6.4 532 8259 0.0 0 28684Justis- og beredskapsdepartementet
7.2 87 1204 4.2 50 1199 0.0 3 7428Oljedirektoratet
7.2 106 1478 6.3 129 2045 0.0 2 4987Statens jernbanetilsyn
7.2 131 1813 8.5 124 1452 0.0 2 8758Statsministerens kontor
7.3 816 11218 6.1 655 10665 0.0 0 47160Norges forskningsråd
7.81150 14712 6.7 746 11202 0.0 0 33794Miljødirektoratet
7.9 411 5216 8.3 446 5365 0.0 0 16441Helse- og omsorgsdepartementet
8.3 376 4514 8.2 457 5548 0.0 3 20840Luftfartstilsynet
8.5 185 2181 9.8 175 1780 0.0 0 7669Landbruks- og matdepartementet
8.6 10 116 0.8 1 127 0.0 0 318Statens institutt for rusmiddelforskning
9.0 597 6648 9.7 705 7236 0.0 3 35663Utdanningsdirektoratet
9.01139 12632 8.21100 13344 0.0 2 36987Finanstilsynet
9.1 540 594913.4 769 5743 0.0 0 13908Finansdepartementet
9.2 256 2787 6.5 203 3147 0.0 0 9487Riksantikvaren - Direktoratet for kulturminneforvaltning
9.31596 17209 2.5 463 18438 0.0 0 53119Statens legemiddelverk
9.7 299 308510.7 329 3072 0.1 6 7579Forsvarsdepartementet
10.1 167 1650 4.5 65 1445 0.0 0 11157Statens helsetilsyn
10.9 59 542 7.7 44 569 0.0 0 1283Statens arbeidsmiljøinstitutt
11.3 46 40796.12591 2695 0.0 0 1489Landbruksdirektoratet Alta
11.4 675 593313.6 613 4492 0.0 0 24598Kystverket
11.6 739 638312.2 748 6121 0.0 1 18605Kunnskapsdepartementet
11.9 641 5398 9.3 432 4655 0.0 0 14438Kulturdepartementet
11.9 934 7835 0.0 0 0 0.0 0 33448Kommunal- og moderniseringsdepartementet
12.1 588 486012.2 522 4294 0.0 0 14173Politidirektoratet
12.11444 1189346.05212 11331 0.0 0 51438Helsedirektoratet
12.6 220 174517.5 112 640 0.1 3 4184Språkrådet
12.7 211 1664 9.7 226 2318 0.0 0 9151Direktoratet for utviklingssamarbeid
13.9 321 230915.1 329 2185 0.0 0 6307Olje- og energidepartementet
14.3 429 299612.5 303 2432 0.0 0 7560Nasjonalt folkehelseinstitutt
14.41408 9785 0.0 0 0 0.0 0 38923Nærings- og fiskeridepartementet
14.7 143 973 7.7 83 1084 0.0 0 4130Utlendingsnemnda
15.8 173 109738.8 621 1602 0.0 0 7557Direktoratet for forvaltning og IKT
16.71345 8069 8.6 703 8219 0.0 0 20834Norges vassdrags- og energidirektorat
17.5 61 34817.2 67 389 0.0 0 7732Senter for internasjonalisering av utdanning
18.93737 19734 4.4 606 13752 0.0 0 49938Direktoratet for samfunnssikkerhet og beredskap
19.11392 726919.11263 6601 0.0 0 19869Fylkesmannen i Troms
20.4 768 375815.7 471 3008 0.1 9 11280Integrerings- og mangfoldsdirektoratet
21.0 995 473717.8 978 5508 0.0 0 11260Fylkesmannen i Sogn og Fjordane
21.6 16 7497.32626 2698 0.0 0 155Statens reindriftsforvaltning
22.1 96 43517.6 81 459 0.2 3 1943Norges geologiske undersøkelse
22.3 27 12110.6 15 141 0.1 1 779Kunst i offentlige rom
22.41939 865921.81992 9120 0.0 1 17738Fylkesmannen i Nordland
22.5 52 23114.7 32 217 0.0 0 896Fredskorpset
22.52017 895795.540498 42425 0.0 0 14223Statens landbruksforvaltning
22.9 116 50715.2 81 532 0.0 0 2069Nasjonalbiblioteket
25.5 211 82920.8 205 987 0.0 0 3867Direktoratet for økonomistyring
26.1 6 23 9.7 3 31 0.0 0 106Kompetansesenter for distriktsutvikling
26.6 187 70228.5 248 871 0.0 1 3154Nasjonalt organ for kvalitet i utdanningen
27.1 90 33213.2 41 311 0.0 0 2400Norsk Akkreditering
28.3 562 198620.0 518 2586 0.0 0 6267Statens lånekasse for utdanning
28.8 443 153841.0 688 1679 0.0 0 5556Havforskningsinstituttet
29.81473 494424.81047 4230 0.0 0 9850Utlendingsdirektoratet
29.81563 524931.01421 4588 0.0 0 15660Fylkesmannen i Finnmark
30.8 314 102158.4 941 1610 0.3 13 3979Direktoratet for nødkommunikasjon
31.4 463 147537.0 280 757 0.1 7 4797Domstoladministrasjonen
31.84708 1478525.22236 8879 0.0 2 39313Utenriksdepartementet
36.1 526 145676.61364 1781 0.0 0 4472Departementenes sikkerhets- og serviceorganisasjon
36.7 447 121763.81503 2355 1.8 92 5121Garantiinstituttet for eksportkreditt
38.23341 874434.73096 8927 0.0 3 15180Fylkesmannen i Oppland
39.36267 1594737.76262 16606 0.1 15 29707Fylkesmannen i Hordaland
39.62122 536541.32242 5428 0.0 0 12680Fylkesmannen i Telemark
40.83137 769837.03059 8272 0.0 5 13848Fylkesmannen i Nord-Trøndelag
42.11528 362719.2 529 2750 0.0 1 13524Statsbygg
42.42844 670042.42913 6863 0.0 0 12090Fylkesmannen i Vest-Agder
42.9 6 1488.92398 2698 0.0 0 23Reindriftsforvaltningen
43.33310 764542.63369 7908 0.0 0 15739Fylkesmannen i Vestfold
43.43433 790540.83508 8594 0.0 0 12921Fylkesmannen i Møre og Romsdal
43.45540 1277340.15429 13534 0.0 0 22389Fylkesmannen i Rogaland
43.62334 535039.52314 5861 0.0 0 9997Fylkesmannen i Aust-Agder
43.72656 607923.1 890 3853 0.1 21 18064Forsvarsbygg
48.94276 874748.04189 8734 0.0 0 16281Fylkesmannen i Buskerud
50.95106 1002445.74584 10022 0.0 0 15340Fylkesmannen i Sør-Trøndelag
51.44477 870345.84240 9253 0.0 5 12067Fylkesmannen i Hedmark
51.5 210 40836.8 656 1785 0.0 0 658Departementenes servicesenter
52.74663 885246.64110 8824 0.0 0 13869Fylkesmannen i Østfold
59.714852 2486756.614366 25404 0.0 0 38706Fylkesmannen i Oslo og Akershus
61.144900 7349595.140365 42462 0.0 11 63747Landbruksdirektoratet Oslo
63.86812110680218.57592 41093 0.0 0144950Arbeidstilsynet
69.811022515796270.8105811149449 0.0 14106772Statens vegvesen Region øst
72.216772 2321595.216409 17238 0.0 0 16705Norsk kulturråd
78.612413115795677.6115949149462 0.0 0 77689Statens vegvesen Region sør
80.755587 6889671.936121 50269 0.0 0 42152Sjøfartsdirektoratet
81.012800615795680.1119743149456 0.0 8 74195Statens vegvesen Region vest
87.213779815796287.6130971149449 0.0 9 50814Statens vegvesen Region midt
88.012239 1390286.119158 22244 0.0 0 5492Barne-, ungdoms- og familiedirektoratet
90.814345315795690.6135441149453 0.0 0 39961Statens vegvesen Region nord
93.85865 625099.37093 7140 0.0 0 984Nasjonal kommunikasjonsmyndighet
95.34655 488394.33819 4049 0.1 1 967Landinfo
96.215193515787096.0143497149452 0.0 0 19555Statens vegvesen Vegdirektoratet
97.510079910337396.9119802123636 0.0 0 7605Toll- og avgiftsdirektoratet
97.724104 2466698.223640 24062 0.2 5 2108Kriminalomsorgsdirektoratet
98.360845 6192298.358575 59605 0.0 0 2837Statens pensjonskasse
99.599066199587399.4953094958529 0.0 0 18246Skattedirektoratet
+ +

Det kunne vært interessant å se hva som skjedde hvis en ba om +innsyn i en dokument-ID som ikke finnes i OEP... :) Det hadde også +vært interessant å få vite hva årsaken til at noen saksnummer ikke +dukker opp i OEP der det er få og mange. Jeg mistenker jo at årsaken +ikke er den samme hos Skattedirektoratet og hos Landinfo, selv om +andelen upubliserte nummer er ganske lik.

+ +
+
+ + + Tags: noark5, norsk, nuug, offentlig innsyn. + + +
+
+
+ +
+
+ Hvordan bør RFC 822-formattert epost lagres i en NOARK5-database? +
+
+ 7th March 2014 +
+
+

For noen uker siden ble NXCs fri programvarelisenserte +NOARK5-løsning +presentert hos +NUUG (video +på youtube +foreløbig), og det fikk meg til å titte litt mer på NOARK5, +standarden for arkivhåndtering i det offentlige Norge. Jeg lurer på +om denne kjernen kan være nyttig i et par av mine prosjekter, og for ett +av dem er det mest aktuelt å lagre epost. Jeg klarte ikke finne noen +anbefaling om hvordan RFC 822-formattert epost (aka Internett-epost) +burde lagres i NOARK5, selv om jeg vet at noen arkiver tar +PDF-utskrift av eposten med sitt epostprogram og så arkiverer PDF-en +(eller enda værre, tar papirutskrift og lagrer bildet av eposten som +PDF i arkivet).

+ +

Det er ikke så mange formater som er akseptert av riksarkivet til +langtidsoppbevaring av offentlige arkiver, og PDF og XML er de mest +aktuelle i så måte. Det slo meg at det måtte da finnes en eller annen +egnet XML-representasjon og at det kanskje var enighet om hvilken som +burde brukes, så jeg tok mot til meg og spurte +SAMDOK, en gruppe tilknyttet +arkivverket som ser ut til å jobbe med NOARK-samhandling, om de hadde +noen anbefalinger: + +

+

Hei.

+ +

Usikker på om dette er riktig forum å ta opp mitt spørsmål, men jeg +lurer på om det er definert en anbefaling om hvordan RFC +822-formatterte epost (aka vanlig Internet-epost) bør lages håndteres +i NOARK5, slik at en bevarer all informasjon i eposten +(f.eks. Received-linjer). Finnes det en anbefalt XML-mapping ala den +som beskrives på +<URL: https://www.informit.com/articles/article.aspx?p=32074 >? Mitt +mål er at det skal være mulig å lagre eposten i en NOARK5-kjerne og +kunne få ut en identisk formattert kopi av opprinnelig epost ved +behov.

+

+ +

Postmottaker hos SAMDOK mente spørsmålet heller burde stilles +direkte til riksarkivet, og jeg fikk i dag svar derfra formulert av +seniorrådgiver Geir Ivar Tungesvik:

+ +

+

Riksarkivet har ingen anbefalinger når det gjelder konvertering fra +e-post til XML. Det står arkivskaper fritt å eventuelt definere/bruke +eget format. Inklusive da - som det spørres om - et format der det er +mulig å re-etablere e-post format ut fra XML-en. XML (e-post) +dokumenter må være referert i arkivstrukturen, og det må vedlegges et +gyldig XML skjema (.xsd) for XML-filene. Arkivskaper står altså fritt +til å gjøre hva de vil, bare det dokumenteres og det kan dannes et +utrekk ved avlevering til depot.

+ +

De obligatoriske kravene i Noark 5 standarden må altså oppfylles - +etter dialog med Riksarkivet i forbindelse med godkjenning. For +offentlige arkiv er det særlig viktig med filene loependeJournal.xml +og offentligJournal.xml. Private arkiv som vil forholde seg til Noark +5 standarden er selvsagt frie til å bruke det som er relevant for dem +av obligatoriske krav.

+

+ +

Det ser dermed ut for meg som om det er et lite behov for å +standardisere XML-lagring av RFC-822-formatterte meldinger. Noen som +vet om god spesifikasjon i så måte? I tillegg til den omtalt over, +har jeg kommet over flere aktuelle beskrivelser (søk på "rfc 822 +xml", så finner du aktuelle alternativer).

+ + + +

Finnes det andre og bedre spesifikasjoner for slik lagring? Send +meg en epost hvis du har innspill.

+ +
+
+ + + Tags: noark5, norsk, offentlig innsyn. + + +
+
+
+ +

RSS Feed

+ +

+ Created by Chronicle v4.6 +

+ + + diff --git a/blog/tags/noark5/noark5.rss b/blog/tags/noark5/noark5.rss new file mode 100644 index 0000000000..acf8c6082f --- /dev/null +++ b/blog/tags/noark5/noark5.rss @@ -0,0 +1,1003 @@ + + + + Petter Reinholdtsen - Entries tagged noark5 + Entries tagged noark5 + http://people.skolelinux.org/pere/blog/ + + + + Åpen og gjennomsiktig vedlikehold av spesifikasjonen for Noark 5 Tjenestegrensesnitt + http://people.skolelinux.org/pere/blog/_pen_og_gjennomsiktig_vedlikehold_av_spesifikasjonen_for_Noark_5_Tjenestegrensesnitt.html + http://people.skolelinux.org/pere/blog/_pen_og_gjennomsiktig_vedlikehold_av_spesifikasjonen_for_Noark_5_Tjenestegrensesnitt.html + Mon, 11 Mar 2019 16:00:00 +0100 + <p>Et virksomhetsarkiv for meg, er et arbeidsverktøy der en enkelt kan +finne informasjonen en trenger når en trenger det, og der +virksomhetens samlede kunnskap er tilgjengelig. Det må være greit å +finne frem i, litt som en bibliotek. Men der et bibliotek gjerne tar +vare på offentliggjort informasjon som er tilgjengelig flere steder, +tar et arkiv vare på virksomhetsintern og til tider personlig +informasjon som ofte kun er tilgjengelig fra et sted.</p> + +<p>Jeg mistenker den eneste måten å sikre at arkivet inneholder den +samlede kunnskapen i en virksomhet, er å bruke det som virksomhetens +kunnskapslager. Det innebærer å automatisk kopiere (brev, epost, +SMS-er etc) inn i arkivet når de sendes og mottas, og der filtrere +vekk det en ikke vil ta vare på, og legge på metadata om det som er +samlet inn for enkel gjenfinning. En slik bruk av arkivet innebærer at +arkivet er en del av daglig virke, ikke at det er siste hvilested for +informasjon ingen lenger har daglig bruk for. For å kunne være en del +av det daglige virket må arkivet enkelt kunne integreres med andre +systemer. I disse dager betyr det å tilby arkivet som en +nett-tjeneste til hele virksomheten, tilgjengelig for både mennesker +og datamaskiner. Det betyr i tur å både tilby nettsider og et +maskinlesbart grensesnitt.</p> + +<p>For noen år siden erkjente visjonære arkivarer fordelene med et +standardisert maskinlesbart grensesnitt til organisasjonens arkiv. De +gikk igang med å lage noe de kalte +<a href="https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/">Noark +5 Tjenestegrensesnitt</a>. Gjort riktig, så åpner slike maskinlesbare +grensesnitt for samvirke på tvers av uavhengige programvaresystemer. +Gjort feil, vil det blokkere for samvirke og bidra til +leverandørinnlåsing. For å gjøre det riktig så må grensesnittet være +klart og entydig beskrevet i en spesifikasjon som gjør at +spesifikasjonen tolkes på samme måte uavhengig av hvem som leser den, +og uavhengig av hvem som tar den i bruk.</p> + +<p>For å oppnå klare og entydige beskrivelser i en spesifikasjon, som +trengs for å kunne få en fri og åpen standard (se +<a href="http://people.skolelinux.org/pere/blog/Fri_og__pen_standard__slik_Digistan_ser_det.html">Digistan-definisjon</a>), +så trengs det en åpen og gjennomsiktig inngangsport med lav terskel, +der de som forsøker å ta den i bruk enkelt kan få inn korreksjoner, +etterlyse klargjøringer og rapportere uklarheter i spesifikasjonen. +En trenger også automatiserte datasystemer som måler og sjekker at et +gitt grensesnitt fungerer i tråd med spesifikasjonen.</p> + +<p>For Noark 5 Tjenestegrensesnittet er det nå etablert en slik åpen +og gjennomsiktig inngangsport på prosjekttjenesten github. Denne +inngangsporten består først og fremst av en åpen portal som lar enhver +se hva som er gjort av endringer i spesifikasjonsteksten over tid, men +det hører også med et åpent &quot;diskusjonsforum&quot; der en kan +komme med endringsforslag og forespørsler om klargjøringer. Alle +registrerte brukere på github kan bidra med innspill til disse +henvendelsene.</p> + +<p>I samarbeide med Arkivverket har jeg fått opprettet et git-depot +med spesifikasjonsteksten for tjenestegrensesnittet, der det er lagt +inn historikk for endringer i teksten de siste årene, samt lagt inn +endringsforslag og forespørsler om klargjøring av teksten. Bakgrunnen +for at jeg bidro med dette er at jeg er involvert i +<a href="https://gitlab.com/OsloMet-ABI/nikita-noark5-core">Nikita-prosjektet</a>, +som lager en fri programvare-utgave av Noark 5 Tjenestegrensesnitt. +Det er først når en forsøker å lage noe i tråd med en spesifikasjon at +en oppdager hvor mange detaljer som må beskrives i spesifikasjonen for +å sikre samhandling.</p> + +<p>Spesifikasjonen vedlikeholdes i et rent tekstformat, for å ha et +format egnet for versjonskontroll via versjontrollsystemet git. Dette +gjør det både enkelt å se konkret hvilke endringer som er gjort når, +samt gjør det praktisk mulig for enhver med github-konto å sende inn +endringsforslag med formuleringer til spesifikasjonsteksten. Dette +tekstformatet vises frem som nettsider på github, slik at en ikke +trenger spesielle verktøy for å se på siste utgave av +spesifikasjonen.</p> + +<p>Fra dette rene tekstformatet kan det så avledes ulike formater, som +HTML for websider, PDF for utskrift på papir og ePub for lesing med +ebokleser. Avlednings-systemet (byggesystemet) bruker i dag +verktøyene pandoc, latex, docbook-xsl og GNU make til +transformasjonen. Tekstformatet som brukes dag er +<a href="https://www.markdownguide.org/">Markdown</a>, men det vurderes +å +<a href="https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues/9">endre +til formatet RST</a> i fremtiden for bedre styring av utseende på +PDF-utgaven.</p> + +<p>Versjonskontrollsystemet git ble valgt da det er både fleksibelt, +avansert og enkelt å ta i bruk. Github ble valgt (foran f.eks. Gitlab +som vi bruker i Nikita), da Arkivverket allerede hadde tatt i bruk +Github i andre sammenhenger.</p> + +<p>Enkle endringer i teksten kan gjøres av priviligerte brukere +direkte i nettsidene til Github, ved å finne aktuell fil som skal +endres (f.eks. kapitler/03-konformitet.md), klikke på den lille +bokstaven i høyre hjørne over teksten. Det kommer opp en nettside der +en kan endre teksten slik en ønsker. Når en er fornøyd med endringen +så må endringen &quot;sjekkes inn&quot; i historikken. Det gjøres ved +å gi en kort beskrivelse av endringen (beskriv helst hvorfor endringen +trengs, ikke hva som er endret), under overskriften &quot;Commit +changes&quot;. En kan og bør legge inn en lengre forklaring i det +større skrivefeltet, før en velger om endringen skal sendes direkte +til 'master'-grenen (dvs. autorativ utgave av spesifikasjonen) eller +om en skal lage en ny gren for denne endringen og opprette en +endringsforespørsel (aka &quot;Pull Request&quot;/PR). Når alt dette +er gjort kan en velge &quot;Commit changes&quot; for å sende inn +endringen. Hvis den er lagt inn i &quot;master&quot;-grenen så er den +en offisiell del av spesifikasjonen med en gang. Hvis den derimot er +en endringsforespørsel, så legges den inn i +<a href="https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/pulls">listen +over forslag til endringer</a> som venter på korrekturlesing og +godkjenning.</p> + +<p>Større endringer (for eksempel samtidig endringer i flere filer) +gjøres enklest ved å hente ned en kopi av git-depoet lokalt og gjøre +endringene der før endringsforslaget sendes inn. Denne prosessen er +godt beskrivet i dokumentasjon fra github. Git-prosjektet som skal +&quot;klones&quot; er +<a href="https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/">https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/</a>.</p> + +<p>For å registrere nye utfordringer (issues) eller kommentere på +eksisterende utfordringer benyttes nettsiden +<a href="https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues">https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues</a>. +I skrivende stund er det 48 åpne og 11 avsluttede utfordringer. Et +forslag til hva som bør være med når en beskriver en utfordring er +tilgjengelig som utfordring +<a href="https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues/14">#14</a>.</p> + +<p>For å bygge en PDF-utgave av spesifikasjonen så bruker jeg i dag en +Debian GNU/Linux-maskin med en rekke programpakker installert. Når +dette er på plass, så holder det å kjøre kommandoen 'make pdf html' på +kommandolinjen, vente ca. 20 sekunder, før spesifikasjon.pdf og +spesifikasjon.html ligger klar på disken. Verktøyene for bygging av +PDF, HTML og ePub-utgave er også tilgjengelig på Windows og +MacOSX.</p> + +<p>Github bidrar med rammeverket. Men for at åpent vedlikehold av +spesifikasjonen skal fungere, så trengs det folk som bidrar med sin +tid og kunnskap. Arkivverket har sagt de skal bidra med innspill og +godkjenne forslag til endringer, men det blir størst suksess hvis alle +som bruker og lager systemer basert på Noark 5 Tjenestegrensesnitt +bidrar med sin kunnskap og kommer med forslag til forebedringer. Jeg +stiller. Blir du med?</p> + +<p>Det er viktig å legge til rette for åpen diskusjon blant alle +interesserte, som ikke krever at en må godta lange kontrakter med +vilkår for deltagelse. Inntil Arkivverket dukker opp på IRC har vi +laget en IRC-kanal der interesserte enkelt kan orientere seg og +diskutere tjenestegrensesnittet. Alle er velkommen til å ta turen +innom +<a href="https://webchat.freenode.net/?channels=nikita">#nikita</a> +(f.eks. via irc.freenode.net) for å møte likesinnede.</p> + +<p>Det holder dog ikke å ha en god spesifikasjon, hvis ikke de som tar +den i bruk gjør en like god jobb. For å automatisk teste om et konkret +tjenestegrensesnitt følger (min) forståelse av +spesifikasjonsdokumentet, har jeg skrevet et program som kobler seg +opp til et Noark 5v4 REST-tjeneste og tester alt den finner for å se +om det er i henhold til min tolkning av spesifikasjonen. Dette +verktøyet er tilgjengelig fra +<a href="https://github.com/petterreinholdtsen/noark5-tester">https://github.com/petterreinholdtsen/noark5-tester</a>, +og brukes daglig mens vi utvikler Nikita for å sikre at vi ikke +introduserer nye feil. Hvis en skal sikre samvirke på tvers av ulike +systemer er det helt essensielt å kunne raskt og automatisk sjekke at +tjenestegrensesnittet oppfører seg som forventet. Jeg håper andre som +lager sin utgave av tjenestegrensesnittet vi bruke dette verktøyet, +slik at vi tidlig og raskt kan oppdage hvor vi har tolket +spesifikasjonen ulikt, og dermed få et godt grunnlag for å gjøre +spesifikasjonsteksten enda klarere og bedre.</p> + +<p>Dagens beskrivelse av Noark 5 Tjenestegrensesnitt er et svært godt +utgangspunkt for å gjøre virksomhetens arkiv til et dynamisk og +sentralt arbeidsverktøy i organisasjonen. Blir du med å gjøre den +enda bedre?</p> + + + + + Time for an official MIME type for patches? + http://people.skolelinux.org/pere/blog/Time_for_an_official_MIME_type_for_patches_.html + http://people.skolelinux.org/pere/blog/Time_for_an_official_MIME_type_for_patches_.html + Thu, 1 Nov 2018 08:15:00 +0100 + <p>As part of my involvement in +<a href="https://gitlab.com/OsloMet-ABI/nikita-noark5-core">the Nikita +archive API project</a>, I've been importing a fairly large lump of +emails into a test instance of the archive to see how well this would +go. I picked a subset of <a href="https://notmuchmail.org/">my +notmuch email database</a>, all public emails sent to me via +@lists.debian.org, giving me a set of around 216 000 emails to import. +In the process, I had a look at the various attachments included in +these emails, to figure out what to do with attachments, and noticed +that one of the most common attachment formats do not have +<a href="https://www.iana.org/assignments/media-types/media-types.xhtml">an +official MIME type</a> registered with IANA/IETF. The output from +diff, ie the input for patch, is on the top 10 list of formats +included in these emails. At the moment people seem to use either +text/x-patch or text/x-diff, but neither is officially registered. It +would be better if one official MIME type were registered and used +everywhere.</p> + +<p>To try to get one official MIME type for these files, I've brought +up the topic on +<a href="https://www.ietf.org/mailman/listinfo/media-types">the +media-types mailing list</a>. If you are interested in discussion +which MIME type to use as the official for patch files, or involved in +making software using a MIME type for patches, perhaps you would like +to join the discussion?</p> + +<p>As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p> + + + + + Release 0.2 of free software archive system Nikita announced + http://people.skolelinux.org/pere/blog/Release_0_2_of_free_software_archive_system_Nikita_announced.html + http://people.skolelinux.org/pere/blog/Release_0_2_of_free_software_archive_system_Nikita_announced.html + Thu, 18 Oct 2018 14:40:00 +0200 + <p>This morning, the new release of the +<a href="https://gitlab.com/OsloMet-ABI/nikita-noark5-core/">Nikita +Noark 5 core project</a> was +<a href="https://lists.nuug.no/pipermail/nikita-noark/2018-October/000406.html">announced +on the project mailing list</a>. The free software solution is an +implementation of the Norwegian archive standard Noark 5 used by +government offices in Norway. These were the changes in version 0.2 +since version 0.1.1 (from NEWS.md): + +<ul> + <li>Fix typos in REL names</li> + <li>Tidy up error message reporting</li> + <li>Fix issue where we used Integer.valueOf(), not Integer.getInteger()</li> + <li>Change some String handling to StringBuffer</li> + <li>Fix error reporting</li> + <li>Code tidy-up</li> + <li>Fix issue using static non-synchronized SimpleDateFormat to avoid + race conditions</li> + <li>Fix problem where deserialisers were treating integers as strings</li> + <li>Update methods to make them null-safe</li> + <li>Fix many issues reported by coverity</li> + <li>Improve equals(), compareTo() and hash() in domain model</li> + <li>Improvements to the domain model for metadata classes</li> + <li>Fix CORS issues when downloading document</li> + <li>Implementation of case-handling with registryEntry and document upload</li> + <li>Better support in Javascript for OPTIONS</li> + <li>Adding concept description of mail integration</li> + <li>Improve setting of default values for GET on ny-journalpost</li> + <li>Better handling of required values during deserialisation </li> + <li>Changed tilknyttetDato (M620) from date to dateTime</li> + <li>Corrected some opprettetDato (M600) (de)serialisation errors.</li> + <li>Improve parse error reporting.</li> + <li>Started on OData search and filtering.</li> + <li>Added Contributor Covenant Code of Conduct to project.</li> + <li>Moved repository and project from Github to Gitlab.</li> + <li>Restructured repository, moved code into src/ and web/.</li> + <li>Updated code to use Spring Boot version 2.</li> + <li>Added support for OAuth2 authentication.</li> + <li>Fixed several bugs discovered by Coverity.</li> + <li>Corrected handling of date/datetime fields.</li> + <li>Improved error reporting when rejecting during deserializatoin.</li> + <li>Adjusted default values provided for ny-arkivdel, ny-mappe, + ny-saksmappe, ny-journalpost and ny-dokumentbeskrivelse.</li> + <li>Several fixes for korrespondansepart*.</li> + <li>Updated web GUI: + <ul> + <li>Now handle both file upload and download.</li> + <li>Uses new OAuth2 authentication for login.</li> + <li>Forms now fetches default values from API using GET.</li> + <li>Added RFC 822 (email), TIFF and JPEG to list of possible file formats.</li> + </ul></li> +</ul> + +<p>The changes and improvements are extensive. Running diffstat on +the changes between git tab 0.1.1 and 0.2 show 1098 files changed, +108666 insertions(+), 54066 deletions(-).</p> + +<p>If free and open standardized archiving API sound interesting to +you, please contact us on IRC +(<a href="irc://irc.freenode.net/%23nikita">#nikita on +irc.freenode.net</a>) or email +(<a href="https://lists.nuug.no/mailman/listinfo/nikita-noark">nikita-noark +mailing list</a>).</p> + +<p>As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p> + + + + + Fetching trusted timestamps using the rfc3161ng python module + http://people.skolelinux.org/pere/blog/Fetching_trusted_timestamps_using_the_rfc3161ng_python_module.html + http://people.skolelinux.org/pere/blog/Fetching_trusted_timestamps_using_the_rfc3161ng_python_module.html + Mon, 8 Oct 2018 12:30:00 +0200 + <p>I have earlier covered the basics of trusted timestamping using the +'openssl ts' client. See blog post for +<a href="http://people.skolelinux.org/pere/blog/Public_Trusted_Timestamping_services_for_everyone.html">2014</a>, +<a href="http://people.skolelinux.org/pere/blog/syslog_trusted_timestamp___chain_of_trusted_timestamps_for_your_syslog.html">2016</a> +and +<a href="http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html">2017</a> +for those stories. But some times I want to integrate the timestamping +in other code, and recently I needed to integrate it into Python. +After searching a bit, I found +<a href="https://dev.entrouvert.org/projects/python-rfc3161">the +rfc3161 library</a> which seemed like a good fit, but I soon +discovered it only worked for python version 2, and I needed something +that work with python version 3. Luckily I next came across +<a href="https://github.com/trbs/rfc3161ng/">the rfc3161ng library</a>, +a fork of the original rfc3161 library. Not only is it working with +python 3, it have fixed a few of the bugs in the original library, and +it has an active maintainer. I decided to wrap it up and make it +<a href="https://tracker.debian.org/pkg/python-rfc3161ng">available in +Debian</a>, and a few days ago it entered Debian unstable and testing.</p> + +<p>Using the library is fairly straight forward. The only slightly +problematic step is to fetch the required certificates to verify the +timestamp. For some services it is straight forward, while for others +I have not yet figured out how to do it. Here is a small standalone +code example based on of the integration tests in the library code:</p> + +<pre> +#!/usr/bin/python3 + +""" + +Python 3 script demonstrating how to use the rfc3161ng module to +get trusted timestamps. + +The license of this code is the same as the license of the rfc3161ng +library, ie MIT/BSD. + +""" + +import os +import pyasn1.codec.der +import rfc3161ng +import subprocess +import tempfile +import urllib.request + +def store(f, data): + f.write(data) + f.flush() + f.seek(0) + +def fetch(url, f=None): + response = urllib.request.urlopen(url) + data = response.read() + if f: + store(f, data) + return data + +def main(): + with tempfile.NamedTemporaryFile() as cert_f,\ + tempfile.NamedTemporaryFile() as ca_f,\ + tempfile.NamedTemporaryFile() as msg_f,\ + tempfile.NamedTemporaryFile() as tsr_f: + + # First fetch certificates used by service + certificate_data = fetch('https://freetsa.org/files/tsa.crt', cert_f) + ca_data_data = fetch('https://freetsa.org/files/cacert.pem', ca_f) + + # Then timestamp the message + timestamper = \ + rfc3161ng.RemoteTimestamper('http://freetsa.org/tsr', + certificate=certificate_data) + data = b"Python forever!\n" + tsr = timestamper(data=data, return_tsr=True) + + # Finally, convert message and response to something 'openssl ts' can verify + store(msg_f, data) + store(tsr_f, pyasn1.codec.der.encoder.encode(tsr)) + args = ["openssl", "ts", "-verify", + "-data", msg_f.name, + "-in", tsr_f.name, + "-CAfile", ca_f.name, + "-untrusted", cert_f.name] + subprocess.check_call(args) + +if '__main__' == __name__: + main() +</pre> + +<p>The code fetches the required certificates, store them as temporary +files, timestamp a simple message, store the message and timestamp to +disk and ask 'openssl ts' to verify the timestamp. A timestamp is +around 1.5 kiB in size, and should be fairly easy to store for future +use.</p> + +<p>As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p> + + + + + Release 0.1.1 of free software archive system Nikita announced + http://people.skolelinux.org/pere/blog/Release_0_1_1_of_free_software_archive_system_Nikita_announced.html + http://people.skolelinux.org/pere/blog/Release_0_1_1_of_free_software_archive_system_Nikita_announced.html + Sat, 10 Jun 2017 00:40:00 +0200 + <p>I am very happy to report that the +<a href="https://github.com/hiOA-ABI/nikita-noark5-core">Nikita Noark 5 +core project</a> tagged its second release today. The free software +solution is an implementation of the Norwegian archive standard Noark +5 used by government offices in Norway. These were the changes in +version 0.1.1 since version 0.1.0 (from NEWS.md): + +<ul> + + <li>Continued work on the angularjs GUI, including document upload.</li> + <li>Implemented correspondencepartPerson, correspondencepartUnit and + correspondencepartInternal</li> + <li>Applied for coverity coverage and started submitting code on + regualr basis.</li> + <li>Started fixing bugs reported by coverity</li> + <li>Corrected and completed HATEOAS links to make sure entire API is + available via URLs in _links.</li> + <li>Corrected all relation URLs to use trailing slash.</li> + <li>Add initial support for storing data in ElasticSearch.</li> + <li>Now able to receive and store uploaded files in the archive.</li> + <li>Changed JSON output for object lists to have relations in _links.</li> + <li>Improve JSON output for empty object lists.</li> + <li>Now uses correct MIME type application/vnd.noark5-v4+json.</li> + <li>Added support for docker container images.</li> + <li>Added simple API browser implemented in JavaScript/Angular.</li> + <li>Started on archive client implemented in JavaScript/Angular.</li> + <li>Started on prototype to show the public mail journal.</li> + <li>Improved performance by disabling Sprint FileWatcher.</li> + <li>Added support for 'arkivskaper', 'saksmappe' and 'journalpost'.</li> + <li>Added support for some metadata codelists.</li> + <li>Added support for Cross-origin resource sharing (CORS).</li> + <li>Changed login method from Basic Auth to JSON Web Token (RFC 7519) + style.</li> + <li>Added support for GET-ing ny-* URLs.</li> + <li>Added support for modifying entities using PUT and eTag.</li> + <li>Added support for returning XML output on request.</li> + <li>Removed support for English field and class names, limiting ourself + to the official names.</li> + <li>...</li> + +</ul> + +<p>If this sound interesting to you, please contact us on IRC (#nikita +on irc.freenode.net) or email +(<a href="https://lists.nuug.no/mailman/listinfo/nikita-noark">nikita-noark +mailing list).</p> + + + + + Idea for storing trusted timestamps in a Noark 5 archive + http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html + http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html + Wed, 7 Jun 2017 21:40:00 +0200 + <p><em>This is a copy of +<a href="https://lists.nuug.no/pipermail/nikita-noark/2017-June/000297.html">an +email I posted to the nikita-noark mailing list</a>. Please follow up +there if you would like to discuss this topic. The background is that +we are making a free software archive system based on the Norwegian +<a href="https://www.arkivverket.no/forvaltning-og-utvikling/regelverk-og-standarder/noark-standarden">Noark +5 standard</a> for government archives.</em></p> + +<p>I've been wondering a bit lately how trusted timestamps could be +stored in Noark 5. +<a href="https://en.wikipedia.org/wiki/Trusted_timestamping">Trusted +timestamps</a> can be used to verify that some information +(document/file/checksum/metadata) have not been changed since a +specific time in the past. This is useful to verify the integrity of +the documents in the archive.</p> + +<p>Then it occured to me, perhaps the trusted timestamps could be +stored as dokument variants (ie dokumentobjekt referered to from +dokumentbeskrivelse) with the filename set to the hash it is +stamping?</p> + +<p>Given a "dokumentbeskrivelse" with an associated "dokumentobjekt", +a new dokumentobjekt is associated with "dokumentbeskrivelse" with the +same attributes as the stamped dokumentobjekt except these +attributes:</p> + +<ul> + +<li>format -> "RFC3161" +<li>mimeType -> "application/timestamp-reply" +<li>formatDetaljer -> "&lt;source URL for timestamp service&gt;" +<li>filenavn -> "&lt;sjekksum&gt;.tsr" + +</ul> + +<p>This assume a service following +<a href="https://tools.ietf.org/html/rfc3161">IETF RFC 3161</a> is +used, which specifiy the given MIME type for replies and the .tsr file +ending for the content of such trusted timestamp. As far as I can +tell from the Noark 5 specifications, it is OK to have several +variants/renderings of a dokument attached to a given +dokumentbeskrivelse objekt. It might be stretching it a bit to make +some of these variants represent crypto-signatures useful for +verifying the document integrity instead of representing the dokument +itself.</p> + +<p>Using the source of the service in formatDetaljer allow several +timestamping services to be used. This is useful to spread the risk +of key compromise over several organisations. It would only be a +problem to trust the timestamps if all of the organisations are +compromised.</p> + +<p>The following oneliner on Linux can be used to generate the tsr +file. $input is the path to the file to checksum, and $sha256 is the +SHA-256 checksum of the file (ie the "<sjekksum>.tsr" value mentioned +above).</p> + +<p><blockquote><pre> +openssl ts -query -data "$inputfile" -cert -sha256 -no_nonce \ + | curl -s -H "Content-Type: application/timestamp-query" \ + --data-binary "@-" http://zeitstempel.dfn.de > $sha256.tsr +</pre></blockquote></p> + +<p>To verify the timestamp, you first need to download the public key +of the trusted timestamp service, for example using this command:</p> + +<p><blockquote><pre> +wget -O ca-cert.txt \ + https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt +</pre></blockquote></p> + +<p>Note, the public key should be stored alongside the timestamps in +the archive to make sure it is also available 100 years from now. It +is probably a good idea to standardise how and were to store such +public keys, to make it easier to find for those trying to verify +documents 100 or 1000 years from now. :)</p> + +<p>The verification itself is a simple openssl command:</p> + +<p><blockquote><pre> +openssl ts -verify -data $inputfile -in $sha256.tsr \ + -CAfile ca-cert.txt -text +</pre></blockquote></p> + +<p>Is there any reason this approach would not work? Is it somehow against +the Noark 5 specification?</p> + + + + + Epost inn som arkivformat i Riksarkivarens forskrift? + http://people.skolelinux.org/pere/blog/Epost_inn_som_arkivformat_i_Riksarkivarens_forskrift_.html + http://people.skolelinux.org/pere/blog/Epost_inn_som_arkivformat_i_Riksarkivarens_forskrift_.html + Thu, 27 Apr 2017 11:30:00 +0200 + <p>I disse dager, med frist 1. mai, har Riksarkivaren ute en høring på +sin forskrift. Som en kan se er det ikke mye tid igjen før fristen +som går ut på søndag. Denne forskriften er det som lister opp hvilke +formater det er greit å arkivere i +<a href="http://www.arkivverket.no/arkivverket/Offentleg-forvalting/Noark/Noark-5">Noark +5-løsninger</a> i Norge.</p> + +<p>Jeg fant høringsdokumentene hos +<a href="https://www.arkivrad.no/aktuelt/riksarkivarens-forskrift-pa-horing">Norsk +Arkivråd</a> etter å ha blitt tipset på epostlisten til +<a href="https://github.com/hiOA-ABI/nikita-noark5-core">fri +programvareprosjektet Nikita Noark5-Core</a>, som lager et Noark 5 +Tjenestegresesnitt. Jeg er involvert i Nikita-prosjektet og takket +være min interesse for tjenestegrensesnittsprosjektet har jeg lest en +god del Noark 5-relaterte dokumenter, og til min overraskelse oppdaget +at standard epost ikke er på listen over godkjente formater som kan +arkiveres. Høringen med frist søndag er en glimrende mulighet til å +forsøke å gjøre noe med det. Jeg holder på med +<a href="https://github.com/petterreinholdtsen/noark5-tester/blob/master/docs/hoering-arkivforskrift.tex">egen +høringsuttalelse</a>, og lurer på om andre er interessert i å støtte +forslaget om å tillate arkivering av epost som epost i arkivet.</p> + +<p>Er du igang med å skrive egen høringsuttalelse allerede? I så fall +kan du jo vurdere å ta med en formulering om epost-lagring. Jeg tror +ikke det trengs så mye. Her et kort forslag til tekst:</p> + +<p><blockquote> + + <p>Viser til høring sendt ut 2017-02-17 (Riksarkivarens referanse + 2016/9840 HELHJO), og tillater oss å sende inn noen innspill om + revisjon av Forskrift om utfyllende tekniske og arkivfaglige + bestemmelser om behandling av offentlige arkiver (Riksarkivarens + forskrift).</p> + + <p>Svært mye av vår kommuikasjon foregår i dag på e-post.  Vi + foreslår derfor at Internett-e-post, slik det er beskrevet i IETF + RFC 5322, + <a href="https://tools.ietf.org/html/rfc5322">https://tools.ietf.org/html/rfc5322</a>. bør + inn som godkjent dokumentformat.  Vi foreslår at forskriftens + oversikt over godkjente dokumentformater ved innlevering i § 5-16 + endres til å ta med Internett-e-post.</p> + +</blockquote></p> + +<p>Som del av arbeidet med tjenestegrensesnitt har vi testet hvordan +epost kan lagres i en Noark 5-struktur, og holder på å skrive et +forslag om hvordan dette kan gjøres som vil bli sendt over til +arkivverket så snart det er ferdig. De som er interesserte kan +<a href="https://github.com/petterreinholdtsen/noark5-tester/blob/master/docs/epostlagring.md">følge +fremdriften på web</a>.</p> + +<p>Oppdatering 2017-04-28: I dag ble høringuttalelsen jeg skrev + <a href="https://www.nuug.no/news/NUUGs_h_ringuttalelse_til_Riksarkivarens_forskrift.shtml">sendt + inn av foreningen NUUG</a>.</p> + + + + + Free software archive system Nikita now able to store documents + http://people.skolelinux.org/pere/blog/Free_software_archive_system_Nikita_now_able_to_store_documents.html + http://people.skolelinux.org/pere/blog/Free_software_archive_system_Nikita_now_able_to_store_documents.html + Sun, 19 Mar 2017 08:00:00 +0100 + <p>The <a href="https://github.com/hiOA-ABI/nikita-noark5-core">Nikita +Noark 5 core project</a> is implementing the Norwegian standard for +keeping an electronic archive of government documents. +<a href="http://www.arkivverket.no/arkivverket/Offentlig-forvaltning/Noark/Noark-5/English-version">The +Noark 5 standard</a> document the requirement for data systems used by +the archives in the Norwegian government, and the Noark 5 web interface +specification document a REST web service for storing, searching and +retrieving documents and metadata in such archive. I've been involved +in the project since a few weeks before Christmas, when the Norwegian +Unix User Group +<a href="https://www.nuug.no/news/NOARK5_kjerne_som_fri_programvare_f_r_epostliste_hos_NUUG.shtml">announced +it supported the project</a>. I believe this is an important project, +and hope it can make it possible for the government archives in the +future to use free software to keep the archives we citizens depend +on. But as I do not hold such archive myself, personally my first use +case is to store and analyse public mail journal metadata published +from the government. I find it useful to have a clear use case in +mind when developing, to make sure the system scratches one of my +itches.</p> + +<p>If you would like to help make sure there is a free software +alternatives for the archives, please join our IRC channel +(<a href="irc://irc.freenode.net/%23nikita">#nikita on +irc.freenode.net</a>) and +<a href="https://lists.nuug.no/mailman/listinfo/nikita-noark">the +project mailing list</a>.</p> + +<p>When I got involved, the web service could store metadata about +documents. But a few weeks ago, a new milestone was reached when it +became possible to store full text documents too. Yesterday, I +completed an implementation of a command line tool +<tt>archive-pdf</tt> to upload a PDF file to the archive using this +API. The tool is very simple at the moment, and find existing +<a href="https://en.wikipedia.org/wiki/Fonds">fonds</a>, series and +files while asking the user to select which one to use if more than +one exist. Once a file is identified, the PDF is associated with the +file and uploaded, using the title extracted from the PDF itself. The +process is fairly similar to visiting the archive, opening a cabinet, +locating a file and storing a piece of paper in the archive. Here is +a test run directly after populating the database with test data using +our API tester:</p> + +<p><blockquote><pre> +~/src//noark5-tester$ ./archive-pdf mangelmelding/mangler.pdf +using arkiv: Title of the test fonds created 2017-03-18T23:49:32.103446 +using arkivdel: Title of the test series created 2017-03-18T23:49:32.103446 + + 0 - Title of the test case file created 2017-03-18T23:49:32.103446 + 1 - Title of the test file created 2017-03-18T23:49:32.103446 +Select which mappe you want (or search term): 0 +Uploading mangelmelding/mangler.pdf + PDF title: Mangler i spesifikasjonsdokumentet for NOARK 5 Tjenestegrensesnitt + File 2017/1: Title of the test case file created 2017-03-18T23:49:32.103446 +~/src//noark5-tester$ +</pre></blockquote></p> + +<p>You can see here how the fonds (arkiv) and serie (arkivdel) only had +one option, while the user need to choose which file (mappe) to use +among the two created by the API tester. The <tt>archive-pdf</tt> +tool can be found in the git repository for the API tester.</p> + +<p>In the project, I have been mostly working on +<a href="https://github.com/petterreinholdtsen/noark5-tester">the API +tester</a> so far, while getting to know the code base. The API +tester currently use +<a href="https://en.wikipedia.org/wiki/HATEOAS">the HATEOAS links</a> +to traverse the entire exposed service API and verify that the exposed +operations and objects match the specification, as well as trying to +create objects holding metadata and uploading a simple XML file to +store. The tester has proved very useful for finding flaws in our +implementation, as well as flaws in the reference site and the +specification.</p> + +<p>The test document I uploaded is a summary of all the specification +defects we have collected so far while implementing the web service. +There are several unclear and conflicting parts of the specification, +and we have +<a href="https://github.com/petterreinholdtsen/noark5-tester/tree/master/mangelmelding">started +writing down</a> the questions we get from implementing it. We use a +format inspired by how <a href="http://www.opengroup.org/austin/">The +Austin Group</a> collect defect reports for the POSIX standard with +<a href="http://www.opengroup.org/austin/mantis.html">their +instructions for the MANTIS defect tracker system</a>, in lack of an official way to structure defect reports for Noark 5 (our first submitted defect report was a <a href="https://github.com/petterreinholdtsen/noark5-tester/blob/master/mangelmelding/sendt/2017-03-15-mangel-prosess.md">request for a procedure for submitting defect reports</a> :). + +<p>The Nikita project is implemented using Java and Spring, and is +fairly easy to get up and running using Docker containers for those +that want to test the current code base. The API tester is +implemented in Python.</p> + + + + + Hva «mangler» i OEP - litt statistikk utledet fra saksnummer og dokumentnummer + http://people.skolelinux.org/pere/blog/Hva__mangler__i_OEP___litt_statistikk_utledet_fra_saksnummer_og_dokumentnummer.html + http://people.skolelinux.org/pere/blog/Hva__mangler__i_OEP___litt_statistikk_utledet_fra_saksnummer_og_dokumentnummer.html + Thu, 29 Jan 2015 20:30:00 +0100 + <p>En ting jeg har lurt på når det gjelder offentlige postjournaler, +er hvor stor andel av det som ligger i de interne databasene kommer +ikke med i postjournalen. Dette er det mulig å finne ut basert på det +som ligger i postjournalen. For å forstå hva jeg mener, trengs det +litt bakgrunnsinformasjon. I henhold til +<a href="http://www.arkivverket.no/arkivverket/Offentleg-forvalting/Noark">NOARK-standarden</a> +for norske offentlige arkiv skal enhver sak ha et årstall og et +løpenummer, og ethvert dokument i saken skal gis et +dokument-løpenummer. Det vil si at en ender opp med dokument-ID som +ser ut som ÅÅÅÅ/SAKNR-DOKNR, f.eks. 2014/2-1 eller 2014/12312-14. +Mange oppgir kun tosifret årstall, men prinsippet er det samme. Så +vidt jeg vet skal saksnummer og dokumentnummer tildeles løpende og i +stigende rekkefølge. Gitt en instans med følgende dokument-ID i +postjournalen, så kan en regne ut hvor mye som ikke finnes i +journalen: + +<ul> +<li>2014/2-1</li> +<li>2014/5-1</li> +<li>2014/5-3</li> +</ul> + +<p>Her ser en at saksnummer 2 og 5 finnes i postjournalen, mens +nummerene 1, 3 og 4 mangler. En ser også at i sak 2014/5 mangler +dokument 2. Ved hjelp av denne informasjonen har jeg regnet ut hvor +stor andel av saksnummer og dokumentløpenummer som ikke har dukket opp +i <a href="https://www.oep.no/">Offentlig Elektronisk Postjournal</a> +(OEP). For saksnummer har jeg tatt utgangspunkt i at en ikke trenger +å starte på 1, og dermed regnet med området fra laveste til høyeste +saksnummer og talt antall unike saksnummer som forekommer i OEP. I +dette tilfellet betyr de at 2 av 4 saksnummer er ubrukte (50%). For +dokumentløpenummer har jeg tilsvarende tatt utgangspunkt i laveste og +høyeste kjente dokumentløpenummer, for å handtere databaser der jeg +mangler komplett postjournal. For sak 2014/5 her betyr det at 1 av 3 +dokumenter mangler (33%).</p> + +<p>Det er flere årsaker til at det kan bli hull i nummerseriene. +Feilføring der et dokument tildeles et nytt saksnummer ved en feil, og +deretter flyttes inn i riktig sak vil gi et ubrukt saksnummer, da +saksnummer skal tildeles i stigende rekkefølge og en ikke får opprette +nye saker innimellom gamle saker. Tilsvarende kan skje med +dokument-løpenummer. Det er jo heller ikke sikkert at et saksnummer i +OEP er det samme som løpenummeret som brukes som saksnummeret i +instansens interne datasystem. Kanskje snakker vi om ulike ontologier +der en delmengde av interne saksnummer tilsvarer saksnummer i OEP. +Hvis like nummer også tildeles andre ting enn saker som skal til OEP +vil en tilsvarende få «hull» i saksnumrene i postjournalen.</p> + +<p>Jeg er litt usikker på hva denne statistikken egentlig viser, og +heller ikke sikker på om det er reelt sett mangler i OEP (som kanskje +kunne anses å være kritikkverdig), bare er resultatet av hendelige +uhell i nummertildelingen eller resultat av ulik ontologi i OEP og +instansens datasystem. Men jeg syntes tallene og variasjonen var så +interessant at jeg hadde lyst til å dele dem med mine lesere. Jeg har +sortert listen på prosent upubliserte saksnummer for 2014.</p> + +<table border="1"> +<tr><th colspan="6">Saksnummer</th><th colspan="3">Dokumentnummer</th><th rowspan="3">Instans</th></tr> +<tr><th colspan="3">2014</th><th colspan="3">2013</th><th colspan="3">2014</th></tr> +<tr><th>%</th><th>Upubl. saksnr.</th><th>Totalt</th> +<th>%</th><th>Upubl. saksnr</th><th>Totalt</th> +<th>%</th><th>Upubl. dok.nr.</th><th>Totalt</th> +</tr> + +<tr><td> 0.6</td><td> 8</td><td> 1282</td><td> 0.2</td><td> 2</td><td> 861</td><td> 0.0</td><td> 0</td><td> 6105</td><td>Vox, nasjonalt fagorgan for kompetansepolitikk</td></tr> +<tr><td> 0.9</td><td> 91</td><td> 9863</td><td> 2.7</td><td> 313</td><td> 11703</td><td> 0.0</td><td> 0</td><td> 24029</td><td>Direktoratet for byggkvalitet</td></tr> +<tr><td> 1.0</td><td> 161</td><td> 15663</td><td> 3.3</td><td> 558</td><td> 17045</td><td> 0.0</td><td> 0</td><td> 41954</td><td>Justervesenet</td></tr> +<tr><td> 1.1</td><td> 325</td><td> 28515</td><td> 1.2</td><td> 357</td><td> 29621</td><td> 0.0</td><td> 0</td><td> 66871</td><td>Arkivverket</td></tr> +<tr><td> 1.8</td><td> 28</td><td> 1568</td><td> 1.0</td><td> 17</td><td> 1722</td><td> 0.0</td><td> 0</td><td> 9259</td><td>Statistisk sentralbyrå</td></tr> +<tr><td> 1.8</td><td> 92</td><td> 5066</td><td>75.4</td><td>3144</td><td> 4169</td><td> 0.0</td><td> 0</td><td> 17056</td><td>Arbeids- og sosialdepartementet</td></tr> +<tr><td> 2.2</td><td> 32</td><td> 1470</td><td> 2.4</td><td> 36</td><td> 1471</td><td> 0.0</td><td> 0</td><td> 9757</td><td>Norsk Filminstitutt</td></tr> +<tr><td> 2.3</td><td> 34</td><td> 1478</td><td> 2.9</td><td> 41</td><td> 1425</td><td> 0.0</td><td> 0</td><td> 4522</td><td>Datatilsynet</td></tr> +<tr><td> 2.7</td><td> 49</td><td> 1795</td><td> 2.8</td><td> 34</td><td> 1199</td><td> 0.0</td><td> 0</td><td> 5824</td><td>Direktoratet for mineralforvaltning med Bergmesteren for Svalbard</td></tr> +<tr><td> 3.1</td><td> 134</td><td> 4326</td><td> 2.8</td><td> 144</td><td> 5119</td><td> 0.0</td><td> 0</td><td> 12223</td><td>Brønnøysundregistrene</td></tr> +<tr><td> 3.1</td><td> 201</td><td> 6571</td><td> 6.1</td><td> 603</td><td> 9870</td><td> 0.0</td><td> 0</td><td> 22390</td><td>Statens kartverk</td></tr> +<tr><td> 3.2</td><td> 228</td><td> 7092</td><td> 2.0</td><td> 143</td><td> 7032</td><td> 0.1</td><td> 14</td><td> 24491</td><td>Lotteri- og stiftelsestilsynet</td></tr> +<tr><td> 3.6</td><td> 32</td><td> 891</td><td> 4.9</td><td> 37</td><td> 753</td><td> 0.0</td><td> 0</td><td> 3055</td><td>Statens innkrevingssentral</td></tr> +<tr><td> 3.8</td><td>1016</td><td> 26466</td><td> 2.5</td><td> 716</td><td> 28727</td><td> 0.0</td><td> 0</td><td> 86951</td><td>Husbanken</td></tr> +<tr><td> 3.9</td><td> 52</td><td> 1326</td><td>14.4</td><td> 180</td><td> 1247</td><td> 0.0</td><td> 0</td><td> 4922</td><td>Sysselmannen på Svalbard</td></tr> +<tr><td> 4.0</td><td> 248</td><td> 6250</td><td> 4.6</td><td> 332</td><td> 7159</td><td> 0.0</td><td> 0</td><td> 22063</td><td>Post- og teletilsynet</td></tr> +<tr><td> 4.1</td><td> 102</td><td> 2488</td><td> 2.7</td><td> 62</td><td> 2291</td><td> 0.0</td><td> 0</td><td> 9707</td><td>Forbrukerombudet</td></tr> +<tr><td> 4.8</td><td> 51</td><td> 1060</td><td>12.6</td><td> 132</td><td> 1046</td><td> 0.0</td><td> 0</td><td> 3616</td><td>Statens strålevern</td></tr> +<tr><td> 5.2</td><td> 924</td><td> 17781</td><td> 6.3</td><td>1184</td><td> 18665</td><td> 0.0</td><td> 0</td><td> 59772</td><td>Fiskeridirektoratet</td></tr> +<tr><td> 5.5</td><td> 254</td><td> 4638</td><td> 6.1</td><td> 315</td><td> 5168</td><td> 0.0</td><td> 0</td><td> 15470</td><td>Barne-, likestillings- og inkluderingsdepartementet</td></tr> +<tr><td> 6.0</td><td> 80</td><td> 1336</td><td> 3.7</td><td> 48</td><td> 1314</td><td> 0.0</td><td> 0</td><td> 2691</td><td>Medietilsynet</td></tr> +<tr><td> 6.1</td><td> 91</td><td> 1486</td><td> 5.0</td><td> 83</td><td> 1651</td><td> 0.2</td><td> 17</td><td> 7473</td><td>Petroleumstilsynet</td></tr> +<tr><td> 6.2</td><td> 248</td><td> 3997</td><td>73.7</td><td>3459</td><td> 4693</td><td> 0.0</td><td> 0</td><td> 10963</td><td>Klima- og miljødepartementet</td></tr> +<tr><td> 7.0</td><td> 190</td><td> 2700</td><td>10.2</td><td> 207</td><td> 2033</td><td> 0.0</td><td> 1</td><td> 14299</td><td>Samferdselsdepartementet</td></tr> +<tr><td> 7.1</td><td> 35</td><td> 492</td><td> 4.5</td><td> 41</td><td> 909</td><td> 0.0</td><td> 0</td><td> 2960</td><td>Konkurransetilsynet</td></tr> +<tr><td> 7.1</td><td> 482</td><td> 6800</td><td> 6.4</td><td> 532</td><td> 8259</td><td> 0.0</td><td> 0</td><td> 28684</td><td>Justis- og beredskapsdepartementet</td></tr> +<tr><td> 7.2</td><td> 87</td><td> 1204</td><td> 4.2</td><td> 50</td><td> 1199</td><td> 0.0</td><td> 3</td><td> 7428</td><td>Oljedirektoratet</td></tr> +<tr><td> 7.2</td><td> 106</td><td> 1478</td><td> 6.3</td><td> 129</td><td> 2045</td><td> 0.0</td><td> 2</td><td> 4987</td><td>Statens jernbanetilsyn</td></tr> +<tr><td> 7.2</td><td> 131</td><td> 1813</td><td> 8.5</td><td> 124</td><td> 1452</td><td> 0.0</td><td> 2</td><td> 8758</td><td>Statsministerens kontor</td></tr> +<tr><td> 7.3</td><td> 816</td><td> 11218</td><td> 6.1</td><td> 655</td><td> 10665</td><td> 0.0</td><td> 0</td><td> 47160</td><td>Norges forskningsråd</td></tr> +<tr><td> 7.8</td><td>1150</td><td> 14712</td><td> 6.7</td><td> 746</td><td> 11202</td><td> 0.0</td><td> 0</td><td> 33794</td><td>Miljødirektoratet</td></tr> +<tr><td> 7.9</td><td> 411</td><td> 5216</td><td> 8.3</td><td> 446</td><td> 5365</td><td> 0.0</td><td> 0</td><td> 16441</td><td>Helse- og omsorgsdepartementet</td></tr> +<tr><td> 8.3</td><td> 376</td><td> 4514</td><td> 8.2</td><td> 457</td><td> 5548</td><td> 0.0</td><td> 3</td><td> 20840</td><td>Luftfartstilsynet</td></tr> +<tr><td> 8.5</td><td> 185</td><td> 2181</td><td> 9.8</td><td> 175</td><td> 1780</td><td> 0.0</td><td> 0</td><td> 7669</td><td>Landbruks- og matdepartementet</td></tr> +<tr><td> 8.6</td><td> 10</td><td> 116</td><td> 0.8</td><td> 1</td><td> 127</td><td> 0.0</td><td> 0</td><td> 318</td><td>Statens institutt for rusmiddelforskning</td></tr> +<tr><td> 9.0</td><td> 597</td><td> 6648</td><td> 9.7</td><td> 705</td><td> 7236</td><td> 0.0</td><td> 3</td><td> 35663</td><td>Utdanningsdirektoratet</td></tr> +<tr><td> 9.0</td><td>1139</td><td> 12632</td><td> 8.2</td><td>1100</td><td> 13344</td><td> 0.0</td><td> 2</td><td> 36987</td><td>Finanstilsynet</td></tr> +<tr><td> 9.1</td><td> 540</td><td> 5949</td><td>13.4</td><td> 769</td><td> 5743</td><td> 0.0</td><td> 0</td><td> 13908</td><td>Finansdepartementet</td></tr> +<tr><td> 9.2</td><td> 256</td><td> 2787</td><td> 6.5</td><td> 203</td><td> 3147</td><td> 0.0</td><td> 0</td><td> 9487</td><td>Riksantikvaren - Direktoratet for kulturminneforvaltning</td></tr> +<tr><td> 9.3</td><td>1596</td><td> 17209</td><td> 2.5</td><td> 463</td><td> 18438</td><td> 0.0</td><td> 0</td><td> 53119</td><td>Statens legemiddelverk</td></tr> +<tr><td> 9.7</td><td> 299</td><td> 3085</td><td>10.7</td><td> 329</td><td> 3072</td><td> 0.1</td><td> 6</td><td> 7579</td><td>Forsvarsdepartementet</td></tr> +<tr><td>10.1</td><td> 167</td><td> 1650</td><td> 4.5</td><td> 65</td><td> 1445</td><td> 0.0</td><td> 0</td><td> 11157</td><td>Statens helsetilsyn</td></tr> +<tr><td>10.9</td><td> 59</td><td> 542</td><td> 7.7</td><td> 44</td><td> 569</td><td> 0.0</td><td> 0</td><td> 1283</td><td>Statens arbeidsmiljøinstitutt</td></tr> +<tr><td>11.3</td><td> 46</td><td> 407</td><td>96.1</td><td>2591</td><td> 2695</td><td> 0.0</td><td> 0</td><td> 1489</td><td>Landbruksdirektoratet Alta</td></tr> +<tr><td>11.4</td><td> 675</td><td> 5933</td><td>13.6</td><td> 613</td><td> 4492</td><td> 0.0</td><td> 0</td><td> 24598</td><td>Kystverket</td></tr> +<tr><td>11.6</td><td> 739</td><td> 6383</td><td>12.2</td><td> 748</td><td> 6121</td><td> 0.0</td><td> 1</td><td> 18605</td><td>Kunnskapsdepartementet</td></tr> +<tr><td>11.9</td><td> 641</td><td> 5398</td><td> 9.3</td><td> 432</td><td> 4655</td><td> 0.0</td><td> 0</td><td> 14438</td><td>Kulturdepartementet</td></tr> +<tr><td>11.9</td><td> 934</td><td> 7835</td><td> 0.0</td><td> 0</td><td> 0</td><td> 0.0</td><td> 0</td><td> 33448</td><td>Kommunal- og moderniseringsdepartementet</td></tr> +<tr><td>12.1</td><td> 588</td><td> 4860</td><td>12.2</td><td> 522</td><td> 4294</td><td> 0.0</td><td> 0</td><td> 14173</td><td>Politidirektoratet</td></tr> +<tr><td>12.1</td><td>1444</td><td> 11893</td><td>46.0</td><td>5212</td><td> 11331</td><td> 0.0</td><td> 0</td><td> 51438</td><td>Helsedirektoratet</td></tr> +<tr><td>12.6</td><td> 220</td><td> 1745</td><td>17.5</td><td> 112</td><td> 640</td><td> 0.1</td><td> 3</td><td> 4184</td><td>Språkrådet</td></tr> +<tr><td>12.7</td><td> 211</td><td> 1664</td><td> 9.7</td><td> 226</td><td> 2318</td><td> 0.0</td><td> 0</td><td> 9151</td><td>Direktoratet for utviklingssamarbeid</td></tr> +<tr><td>13.9</td><td> 321</td><td> 2309</td><td>15.1</td><td> 329</td><td> 2185</td><td> 0.0</td><td> 0</td><td> 6307</td><td>Olje- og energidepartementet</td></tr> +<tr><td>14.3</td><td> 429</td><td> 2996</td><td>12.5</td><td> 303</td><td> 2432</td><td> 0.0</td><td> 0</td><td> 7560</td><td>Nasjonalt folkehelseinstitutt</td></tr> +<tr><td>14.4</td><td>1408</td><td> 9785</td><td> 0.0</td><td> 0</td><td> 0</td><td> 0.0</td><td> 0</td><td> 38923</td><td>Nærings- og fiskeridepartementet</td></tr> +<tr><td>14.7</td><td> 143</td><td> 973</td><td> 7.7</td><td> 83</td><td> 1084</td><td> 0.0</td><td> 0</td><td> 4130</td><td>Utlendingsnemnda</td></tr> +<tr><td>15.8</td><td> 173</td><td> 1097</td><td>38.8</td><td> 621</td><td> 1602</td><td> 0.0</td><td> 0</td><td> 7557</td><td>Direktoratet for forvaltning og IKT</td></tr> +<tr><td>16.7</td><td>1345</td><td> 8069</td><td> 8.6</td><td> 703</td><td> 8219</td><td> 0.0</td><td> 0</td><td> 20834</td><td>Norges vassdrags- og energidirektorat</td></tr> +<tr><td>17.5</td><td> 61</td><td> 348</td><td>17.2</td><td> 67</td><td> 389</td><td> 0.0</td><td> 0</td><td> 7732</td><td>Senter for internasjonalisering av utdanning</td></tr> +<tr><td>18.9</td><td>3737</td><td> 19734</td><td> 4.4</td><td> 606</td><td> 13752</td><td> 0.0</td><td> 0</td><td> 49938</td><td>Direktoratet for samfunnssikkerhet og beredskap</td></tr> +<tr><td>19.1</td><td>1392</td><td> 7269</td><td>19.1</td><td>1263</td><td> 6601</td><td> 0.0</td><td> 0</td><td> 19869</td><td>Fylkesmannen i Troms</td></tr> +<tr><td>20.4</td><td> 768</td><td> 3758</td><td>15.7</td><td> 471</td><td> 3008</td><td> 0.1</td><td> 9</td><td> 11280</td><td>Integrerings- og mangfoldsdirektoratet</td></tr> +<tr><td>21.0</td><td> 995</td><td> 4737</td><td>17.8</td><td> 978</td><td> 5508</td><td> 0.0</td><td> 0</td><td> 11260</td><td>Fylkesmannen i Sogn og Fjordane</td></tr> +<tr><td>21.6</td><td> 16</td><td> 74</td><td>97.3</td><td>2626</td><td> 2698</td><td> 0.0</td><td> 0</td><td> 155</td><td>Statens reindriftsforvaltning</td></tr> +<tr><td>22.1</td><td> 96</td><td> 435</td><td>17.6</td><td> 81</td><td> 459</td><td> 0.2</td><td> 3</td><td> 1943</td><td>Norges geologiske undersøkelse</td></tr> +<tr><td>22.3</td><td> 27</td><td> 121</td><td>10.6</td><td> 15</td><td> 141</td><td> 0.1</td><td> 1</td><td> 779</td><td>Kunst i offentlige rom</td></tr> +<tr><td>22.4</td><td>1939</td><td> 8659</td><td>21.8</td><td>1992</td><td> 9120</td><td> 0.0</td><td> 1</td><td> 17738</td><td>Fylkesmannen i Nordland</td></tr> +<tr><td>22.5</td><td> 52</td><td> 231</td><td>14.7</td><td> 32</td><td> 217</td><td> 0.0</td><td> 0</td><td> 896</td><td>Fredskorpset</td></tr> +<tr><td>22.5</td><td>2017</td><td> 8957</td><td>95.5</td><td>40498</td><td> 42425</td><td> 0.0</td><td> 0</td><td> 14223</td><td>Statens landbruksforvaltning</td></tr> +<tr><td>22.9</td><td> 116</td><td> 507</td><td>15.2</td><td> 81</td><td> 532</td><td> 0.0</td><td> 0</td><td> 2069</td><td>Nasjonalbiblioteket</td></tr> +<tr><td>25.5</td><td> 211</td><td> 829</td><td>20.8</td><td> 205</td><td> 987</td><td> 0.0</td><td> 0</td><td> 3867</td><td>Direktoratet for økonomistyring</td></tr> +<tr><td>26.1</td><td> 6</td><td> 23</td><td> 9.7</td><td> 3</td><td> 31</td><td> 0.0</td><td> 0</td><td> 106</td><td>Kompetansesenter for distriktsutvikling</td></tr> +<tr><td>26.6</td><td> 187</td><td> 702</td><td>28.5</td><td> 248</td><td> 871</td><td> 0.0</td><td> 1</td><td> 3154</td><td>Nasjonalt organ for kvalitet i utdanningen</td></tr> +<tr><td>27.1</td><td> 90</td><td> 332</td><td>13.2</td><td> 41</td><td> 311</td><td> 0.0</td><td> 0</td><td> 2400</td><td>Norsk Akkreditering</td></tr> +<tr><td>28.3</td><td> 562</td><td> 1986</td><td>20.0</td><td> 518</td><td> 2586</td><td> 0.0</td><td> 0</td><td> 6267</td><td>Statens lånekasse for utdanning</td></tr> +<tr><td>28.8</td><td> 443</td><td> 1538</td><td>41.0</td><td> 688</td><td> 1679</td><td> 0.0</td><td> 0</td><td> 5556</td><td>Havforskningsinstituttet</td></tr> +<tr><td>29.8</td><td>1473</td><td> 4944</td><td>24.8</td><td>1047</td><td> 4230</td><td> 0.0</td><td> 0</td><td> 9850</td><td>Utlendingsdirektoratet</td></tr> +<tr><td>29.8</td><td>1563</td><td> 5249</td><td>31.0</td><td>1421</td><td> 4588</td><td> 0.0</td><td> 0</td><td> 15660</td><td>Fylkesmannen i Finnmark</td></tr> +<tr><td>30.8</td><td> 314</td><td> 1021</td><td>58.4</td><td> 941</td><td> 1610</td><td> 0.3</td><td> 13</td><td> 3979</td><td>Direktoratet for nødkommunikasjon</td></tr> +<tr><td>31.4</td><td> 463</td><td> 1475</td><td>37.0</td><td> 280</td><td> 757</td><td> 0.1</td><td> 7</td><td> 4797</td><td>Domstoladministrasjonen</td></tr> +<tr><td>31.8</td><td>4708</td><td> 14785</td><td>25.2</td><td>2236</td><td> 8879</td><td> 0.0</td><td> 2</td><td> 39313</td><td>Utenriksdepartementet</td></tr> +<tr><td>36.1</td><td> 526</td><td> 1456</td><td>76.6</td><td>1364</td><td> 1781</td><td> 0.0</td><td> 0</td><td> 4472</td><td>Departementenes sikkerhets- og serviceorganisasjon</td></tr> +<tr><td>36.7</td><td> 447</td><td> 1217</td><td>63.8</td><td>1503</td><td> 2355</td><td> 1.8</td><td> 92</td><td> 5121</td><td>Garantiinstituttet for eksportkreditt</td></tr> +<tr><td>38.2</td><td>3341</td><td> 8744</td><td>34.7</td><td>3096</td><td> 8927</td><td> 0.0</td><td> 3</td><td> 15180</td><td>Fylkesmannen i Oppland</td></tr> +<tr><td>39.3</td><td>6267</td><td> 15947</td><td>37.7</td><td>6262</td><td> 16606</td><td> 0.1</td><td> 15</td><td> 29707</td><td>Fylkesmannen i Hordaland</td></tr> +<tr><td>39.6</td><td>2122</td><td> 5365</td><td>41.3</td><td>2242</td><td> 5428</td><td> 0.0</td><td> 0</td><td> 12680</td><td>Fylkesmannen i Telemark</td></tr> +<tr><td>40.8</td><td>3137</td><td> 7698</td><td>37.0</td><td>3059</td><td> 8272</td><td> 0.0</td><td> 5</td><td> 13848</td><td>Fylkesmannen i Nord-Trøndelag</td></tr> +<tr><td>42.1</td><td>1528</td><td> 3627</td><td>19.2</td><td> 529</td><td> 2750</td><td> 0.0</td><td> 1</td><td> 13524</td><td>Statsbygg</td></tr> +<tr><td>42.4</td><td>2844</td><td> 6700</td><td>42.4</td><td>2913</td><td> 6863</td><td> 0.0</td><td> 0</td><td> 12090</td><td>Fylkesmannen i Vest-Agder</td></tr> +<tr><td>42.9</td><td> 6</td><td> 14</td><td>88.9</td><td>2398</td><td> 2698</td><td> 0.0</td><td> 0</td><td> 23</td><td>Reindriftsforvaltningen</td></tr> +<tr><td>43.3</td><td>3310</td><td> 7645</td><td>42.6</td><td>3369</td><td> 7908</td><td> 0.0</td><td> 0</td><td> 15739</td><td>Fylkesmannen i Vestfold</td></tr> +<tr><td>43.4</td><td>3433</td><td> 7905</td><td>40.8</td><td>3508</td><td> 8594</td><td> 0.0</td><td> 0</td><td> 12921</td><td>Fylkesmannen i Møre og Romsdal</td></tr> +<tr><td>43.4</td><td>5540</td><td> 12773</td><td>40.1</td><td>5429</td><td> 13534</td><td> 0.0</td><td> 0</td><td> 22389</td><td>Fylkesmannen i Rogaland</td></tr> +<tr><td>43.6</td><td>2334</td><td> 5350</td><td>39.5</td><td>2314</td><td> 5861</td><td> 0.0</td><td> 0</td><td> 9997</td><td>Fylkesmannen i Aust-Agder</td></tr> +<tr><td>43.7</td><td>2656</td><td> 6079</td><td>23.1</td><td> 890</td><td> 3853</td><td> 0.1</td><td> 21</td><td> 18064</td><td>Forsvarsbygg</td></tr> +<tr><td>48.9</td><td>4276</td><td> 8747</td><td>48.0</td><td>4189</td><td> 8734</td><td> 0.0</td><td> 0</td><td> 16281</td><td>Fylkesmannen i Buskerud</td></tr> +<tr><td>50.9</td><td>5106</td><td> 10024</td><td>45.7</td><td>4584</td><td> 10022</td><td> 0.0</td><td> 0</td><td> 15340</td><td>Fylkesmannen i Sør-Trøndelag</td></tr> +<tr><td>51.4</td><td>4477</td><td> 8703</td><td>45.8</td><td>4240</td><td> 9253</td><td> 0.0</td><td> 5</td><td> 12067</td><td>Fylkesmannen i Hedmark</td></tr> +<tr><td>51.5</td><td> 210</td><td> 408</td><td>36.8</td><td> 656</td><td> 1785</td><td> 0.0</td><td> 0</td><td> 658</td><td>Departementenes servicesenter</td></tr> +<tr><td>52.7</td><td>4663</td><td> 8852</td><td>46.6</td><td>4110</td><td> 8824</td><td> 0.0</td><td> 0</td><td> 13869</td><td>Fylkesmannen i Østfold</td></tr> +<tr><td>59.7</td><td>14852</td><td> 24867</td><td>56.6</td><td>14366</td><td> 25404</td><td> 0.0</td><td> 0</td><td> 38706</td><td>Fylkesmannen i Oslo og Akershus</td></tr> +<tr><td>61.1</td><td>44900</td><td> 73495</td><td>95.1</td><td>40365</td><td> 42462</td><td> 0.0</td><td> 11</td><td> 63747</td><td>Landbruksdirektoratet Oslo</td></tr> +<tr><td>63.8</td><td>68121</td><td>106802</td><td>18.5</td><td>7592</td><td> 41093</td><td> 0.0</td><td> 0</td><td>144950</td><td>Arbeidstilsynet</td></tr> +<tr><td>69.8</td><td>110225</td><td>157962</td><td>70.8</td><td>105811</td><td>149449</td><td> 0.0</td><td> 14</td><td>106772</td><td>Statens vegvesen Region øst</td></tr> +<tr><td>72.2</td><td>16772</td><td> 23215</td><td>95.2</td><td>16409</td><td> 17238</td><td> 0.0</td><td> 0</td><td> 16705</td><td>Norsk kulturråd</td></tr> +<tr><td>78.6</td><td>124131</td><td>157956</td><td>77.6</td><td>115949</td><td>149462</td><td> 0.0</td><td> 0</td><td> 77689</td><td>Statens vegvesen Region sør</td></tr> +<tr><td>80.7</td><td>55587</td><td> 68896</td><td>71.9</td><td>36121</td><td> 50269</td><td> 0.0</td><td> 0</td><td> 42152</td><td>Sjøfartsdirektoratet</td></tr> +<tr><td>81.0</td><td>128006</td><td>157956</td><td>80.1</td><td>119743</td><td>149456</td><td> 0.0</td><td> 8</td><td> 74195</td><td>Statens vegvesen Region vest</td></tr> +<tr><td>87.2</td><td>137798</td><td>157962</td><td>87.6</td><td>130971</td><td>149449</td><td> 0.0</td><td> 9</td><td> 50814</td><td>Statens vegvesen Region midt</td></tr> +<tr><td>88.0</td><td>12239</td><td> 13902</td><td>86.1</td><td>19158</td><td> 22244</td><td> 0.0</td><td> 0</td><td> 5492</td><td>Barne-, ungdoms- og familiedirektoratet</td></tr> +<tr><td>90.8</td><td>143453</td><td>157956</td><td>90.6</td><td>135441</td><td>149453</td><td> 0.0</td><td> 0</td><td> 39961</td><td>Statens vegvesen Region nord</td></tr> +<tr><td>93.8</td><td>5865</td><td> 6250</td><td>99.3</td><td>7093</td><td> 7140</td><td> 0.0</td><td> 0</td><td> 984</td><td>Nasjonal kommunikasjonsmyndighet</td></tr> +<tr><td>95.3</td><td>4655</td><td> 4883</td><td>94.3</td><td>3819</td><td> 4049</td><td> 0.1</td><td> 1</td><td> 967</td><td>Landinfo</td></tr> +<tr><td>96.2</td><td>151935</td><td>157870</td><td>96.0</td><td>143497</td><td>149452</td><td> 0.0</td><td> 0</td><td> 19555</td><td>Statens vegvesen Vegdirektoratet</td></tr> +<tr><td>97.5</td><td>100799</td><td>103373</td><td>96.9</td><td>119802</td><td>123636</td><td> 0.0</td><td> 0</td><td> 7605</td><td>Toll- og avgiftsdirektoratet</td></tr> +<tr><td>97.7</td><td>24104</td><td> 24666</td><td>98.2</td><td>23640</td><td> 24062</td><td> 0.2</td><td> 5</td><td> 2108</td><td>Kriminalomsorgsdirektoratet</td></tr> +<tr><td>98.3</td><td>60845</td><td> 61922</td><td>98.3</td><td>58575</td><td> 59605</td><td> 0.0</td><td> 0</td><td> 2837</td><td>Statens pensjonskasse</td></tr> +<tr><td>99.5</td><td>990661</td><td>995873</td><td>99.4</td><td>953094</td><td>958529</td><td> 0.0</td><td> 0</td><td> 18246</td><td>Skattedirektoratet</td></tr> + +</table> + +<p>Det kunne vært interessant å se hva som skjedde hvis en ba om +innsyn i en dokument-ID som ikke finnes i OEP... :) Det hadde også +vært interessant å få vite hva årsaken til at noen saksnummer ikke +dukker opp i OEP der det er få og mange. Jeg mistenker jo at årsaken +ikke er den samme hos Skattedirektoratet og hos Landinfo, selv om +andelen upubliserte nummer er ganske lik.</p> + + + + + Hvordan bør RFC 822-formattert epost lagres i en NOARK5-database? + http://people.skolelinux.org/pere/blog/Hvordan_b_r_RFC_822_formattert_epost_lagres_i_en_NOARK5_database_.html + http://people.skolelinux.org/pere/blog/Hvordan_b_r_RFC_822_formattert_epost_lagres_i_en_NOARK5_database_.html + Fri, 7 Mar 2014 15:20:00 +0100 + <p>For noen uker siden ble NXCs fri programvarelisenserte +NOARK5-løsning +<a href="http://www.nuug.no/aktiviteter/20140211-noark/">presentert hos +NUUG</a> (video +<a href="https://www.youtube.com/watch?v=JCb_dNS3MHQ">på youtube +foreløbig</a>), og det fikk meg til å titte litt mer på NOARK5, +standarden for arkivhåndtering i det offentlige Norge. Jeg lurer på +om denne kjernen kan være nyttig i et par av mine prosjekter, og for ett +av dem er det mest aktuelt å lagre epost. Jeg klarte ikke finne noen +anbefaling om hvordan RFC 822-formattert epost (aka Internett-epost) +burde lagres i NOARK5, selv om jeg vet at noen arkiver tar +PDF-utskrift av eposten med sitt epostprogram og så arkiverer PDF-en +(eller enda værre, tar papirutskrift og lagrer bildet av eposten som +PDF i arkivet).</p> + +<p>Det er ikke så mange formater som er akseptert av riksarkivet til +langtidsoppbevaring av offentlige arkiver, og PDF og XML er de mest +aktuelle i så måte. Det slo meg at det måtte da finnes en eller annen +egnet XML-representasjon og at det kanskje var enighet om hvilken som +burde brukes, så jeg tok mot til meg og spurte +<a href="http://samdok.com/">SAMDOK</a>, en gruppe tilknyttet +arkivverket som ser ut til å jobbe med NOARK-samhandling, om de hadde +noen anbefalinger: + +<p><blockquote> +<p>Hei.</p> + +<p>Usikker på om dette er riktig forum å ta opp mitt spørsmål, men jeg +lurer på om det er definert en anbefaling om hvordan RFC +822-formatterte epost (aka vanlig Internet-epost) bør lages håndteres +i NOARK5, slik at en bevarer all informasjon i eposten +(f.eks. Received-linjer). Finnes det en anbefalt XML-mapping ala den +som beskrives på +&lt;URL: <a href="https://www.informit.com/articles/article.aspx?p=32074">https://www.informit.com/articles/article.aspx?p=32074</a> &gt;? Mitt +mål er at det skal være mulig å lagre eposten i en NOARK5-kjerne og +kunne få ut en identisk formattert kopi av opprinnelig epost ved +behov.</p> +</blockquote></p> + +<p>Postmottaker hos SAMDOK mente spørsmålet heller burde stilles +direkte til riksarkivet, og jeg fikk i dag svar derfra formulert av +seniorrådgiver Geir Ivar Tungesvik:</p> + +<p><blockquote> +<p>Riksarkivet har ingen anbefalinger når det gjelder konvertering fra +e-post til XML. Det står arkivskaper fritt å eventuelt definere/bruke +eget format. Inklusive da - som det spørres om - et format der det er +mulig å re-etablere e-post format ut fra XML-en. XML (e-post) +dokumenter må være referert i arkivstrukturen, og det må vedlegges et +gyldig XML skjema (.xsd) for XML-filene. Arkivskaper står altså fritt +til å gjøre hva de vil, bare det dokumenteres og det kan dannes et +utrekk ved avlevering til depot.</p> + +<p>De obligatoriske kravene i Noark 5 standarden må altså oppfylles - +etter dialog med Riksarkivet i forbindelse med godkjenning. For +offentlige arkiv er det særlig viktig med filene loependeJournal.xml +og offentligJournal.xml. Private arkiv som vil forholde seg til Noark +5 standarden er selvsagt frie til å bruke det som er relevant for dem +av obligatoriske krav.</p> +</blockquote></p> + +<p>Det ser dermed ut for meg som om det er et lite behov for å +standardisere XML-lagring av RFC-822-formatterte meldinger. Noen som +vet om god spesifikasjon i så måte? I tillegg til den omtalt over, +har jeg kommet over flere aktuelle beskrivelser (søk på "rfc 822 +xml", så finner du aktuelle alternativer).</p> + +<ul> + +<li><a href="http://www.openhealth.org/xmtp/">XML MIME Transformation +protocol (XMTP)</a> fra OpenHealth, sist oppdatert 2001.</li> + +<li><a href="https://tools.ietf.org/html/draft-klyne-message-rfc822-xml-03">An +XML format for mail and other messages</a> utkast fra IETF datert +2001.</li> + +<li><a href="http://www.informit.com/articles/article.aspx?p=32074">xMail: +E-mail as XML</a> en artikkel fra 2003 som beskriver python-modulen +rfc822 som gir ut XML-representasjon av en RFC 822-formattert epost.</li> + +</ul> + +<p>Finnes det andre og bedre spesifikasjoner for slik lagring? Send +meg en epost hvis du har innspill.</p> + + + + + -- 2.47.2